--------------080807090206060008070902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Kevin Hawkins wrote:
> g8kmh wrote:
>
>> OK,
>> Look forward to that.
>>
>> BTW. One thing I noticed is that floorplan assumes it is in
control
>> of all devices. If something else changes the state of a BSC
device,
>> and the device responds with an .event response, floorplan misses
>> that change of status until an .info is sent, which could be a
while.
>>
>>
> Interesting .. are you sure on this ? - I have each of the segments in
a
> 7 segment display set up as a BSC binary device in Floorplan. It
mimics
> the status display on my boiler - connected to a xAP Netiom. As the
> boiler cycles it goes through four states very quickly (perhaps 2
> seconds overall) and each of these is reflected realtime in
> Floorplan.... The messages are all BSC events. I wonder if it is for
> some other type of device or for one created a different way perhaps
>
The way I was checking was with the DMX lights. If they were controlled
with floorplan then they were reported
correctly but if I used xAPSend then the status didn't get updated until
the next .info (ignoring the .event) I'll run
some more checks to be sure 100%.
>> Another thing that may be useful, is if at startup it does a
'target
>> all' BSC query to kick all the devices connected to respond and
>> floorplan can then build its list.
>>
>>
> James just recently added this to HomeSeer and it works really well ,
he
> directly addresses known devices and spaces the query messages a bit
> apart to avoid floods. I'm hoping it'll make it to FP too .
>
> The other approach of course as you suggest is to target everything at
> startup, you can create a simple script at startup to do this which is
> how I survived before in HS. However I have 4 xAP Netioms here and
they
> each send 120 odd nodes so it's quite a flood that happens and
actually
> some get missed in both HS and FP. The Netiom is a ludicrously fast
> device on Ethernet. C-Bus and the alarm sensors add a lot too.
Really
> I've just been lazy & I should disable more than half of the
Netiom I/O
> as it's not used (the counters and outputs mainly ) which would cut
it
> down a lot. In fact looking on Viewer I am seeing 14 devices and 620
sub
> addresses which is rather frightening but just noticed also ....240
> messages per minute This is still absolutely negligible network
> bandwidth of course but for xAP nodes it means they have to process 4
> messages per sec. Some of this is the BSC.info's so its about time I
> removed the unused I/O and altered the periods on the .info reports
> which I never really need anyway. The main culprit however is the
> electricity metering which is currently reporting on every pulse from
> the meters (which are about 1 per two seconds on each of four circuits
> ie 120/min) . This will change as I'm going to use a Viom for the
> realtime calculations as it has timers, so that will remove them all
off
> xAP - I will still count the pulses on the Netiom counters although
> again the larger counters in the Viom (32 bits vs 16) are better
suited
> as the Netiom ones cycle in about 14 hours.
>
>
It's easy to assume that 240 messages a minute is a lot but of course it
is pretty small beer even for
a 10Mbps network. When you get to a serial 38k4 then it is a different
story..... so tuning out the
additional .info messages has been a priority. The lightswitches even
use part of the UID to generate
the heartbeats/.info at different time intervals, in case of all
restarting after power failure. The downside
of xAP is the broadcast nature of the traffic so it isn't generally
possible to filter (although the serial
connector does inspect targets and doesn't forward them if the device
isn't on the serial bus).
Talking of broadcasts, presumably xAP over IPv6 will need to move to
multicasting?
Lehane
--------------080807090206060008070902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Kevin Hawkins wrote:
<blockquote cite="mid44059AA6.9080303@xxxxxxx"
type="cite">
<pre wrap="">g8kmh wrote:
</pre>
<blockquote type="cite">
<pre wrap="">OK,
Look forward to that.
BTW. One thing I noticed is that floorplan assumes it is in control
of all devices. If something else changes the state of a BSC device,
and the device responds with an .event response, floorplan misses
that change of status until an .info is sent, which could be a while.
</pre>
</blockquote>
<pre wrap=""><!---->Interesting .. are you sure on
this ? - I have each of the segments in a
7 segment display set up as a BSC binary device in Floorplan. It mimics
the status display on my boiler - connected to a xAP Netiom. As the
boiler cycles it goes through four states very quickly (perhaps 2
seconds overall) and each of these is reflected realtime in
Floorplan.... The messages are all BSC events. I wonder if it is for
some other type of device or for one created a different way perhaps
</pre>
</blockquote>
The way I was checking was with the DMX lights. If they were controlled
with floorplan then they were reported<br>
correctly but if I used xAPSend then the status didn't get updated
until the next .info (ignoring the .event)&nbsp; I'll run<br>
some more checks to be sure 100%.<br>
<br>
<blockquote cite="mid44059AA6.9080303@xxxxxxx"
type="cite">
<blockquote type="cite">
<pre wrap="">Another thing that may be useful, is if at
startup it does a 'target
all' BSC query to kick all the devices connected to respond and
floorplan can then build its list.
</pre>
</blockquote>
<pre wrap=""><!---->James just recently added this to
HomeSeer and it works really well , he
directly addresses known devices and spaces the query messages a bit
apart to avoid floods. I'm hoping it'll make it to FP too .
The other approach of course as you suggest is to target everything at
startup, you can create a simple script at startup to do this which is
how I survived before in HS. However I have 4 xAP Netioms here and they
each send 120 odd nodes so it's quite a flood that happens and actually
some get missed in both HS and FP. The Netiom is a ludicrously fast
device on Ethernet. C-Bus and the alarm sensors add a lot too. Really
I've just been lazy &amp; I should disable more than half of the Netiom
I/O
as it's not used (the counters and outputs mainly ) which would cut it
down a lot. In fact looking on Viewer I am seeing 14 devices and 620 sub
addresses which is rather frightening but just noticed also ....240
messages per minute This is still absolutely negligible network
bandwidth of course but for xAP nodes it means they have to process 4
messages per sec. Some of this is the BSC.info's so its about time I
removed the unused I/O and altered the periods on the .info reports
which I never really need anyway. The main culprit however is the
electricity metering which is currently reporting on every pulse from
the meters (which are about 1 per two seconds on each of four circuits
ie 120/min) . This will change as I'm going to use a Viom for the
realtime calculations as it has timers, so that will remove them all off
xAP - I will still count the pulses on the Netiom counters although
again the larger counters in the Viom (32 bits vs 16) are better suited
as the Netiom ones cycle in about 14 hours.
</pre>
</blockquote>
It's easy to assume that 240 messages a minute is a lot but of course
it is pretty small beer even for<br>
a 10Mbps network. When you get to a serial 38k4 then it is a different
story..... so tuning out the<br>
additional .info messages has been a priority. The lightswitches even
use part of the UID to generate<br>
the heartbeats/.info at different time intervals, in case of all
restarting after power failure. The downside<br>
of xAP is the broadcast nature of the traffic so it isn't generally
possible to filter (although the serial<br>
connector does inspect targets and doesn't forward them if the device
isn't on the serial bus).<br>
<br>
Talking of broadcasts, presumably xAP over IPv6 will need to move to
multicasting?<br>
<br>
Lehane<br>
<br>
<!-- **begin egp html banner** -->
<br><br>
<div style="width:500px; text-align:right; margin-bottom:1px;
color:#909090;">
<tt>SPONSORED LINKS</tt>
</div>
<table bgcolor=#e0ecee cellspacing="13"
cellpadding="0" width=500px>
<tr valign=top>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads?t=ms&k=Workflow+automation&w1=Workflow+automation&w2=Automation+equipment&w3=Industrial+automation&w4=Test+automation&w5=Sales+automation&w6=Factory+automation&c=6&s=145&.sig=F4tRNBO_G_ZzajQmbmwe7Q&quot;>Workflow
automation</a></tt>
</td>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads?t=ms&k=Automation+equipment&w1=Workflow+automation&w2=Automation+equipment&w3=Industrial+automation&w4=Test+automation&w5=Sales+automation&w6=Factory+automation&c=6&s=145&.sig=9-eliEiH2rHCvwCe6xpvLw&quot;>Automation
equipment</a></tt>
</td>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads?t=ms&k=Industrial+automation&w1=Workflow+automation&w2=Automation+equipment&w3=Industrial+automation&w4=Test+automation&w5=Sales+automation&w6=Factory+automation&c=6&s=145&.sig=xI5A0mNmlPHiPI__bxZwUQ&quot;>Industrial
automation</a></tt>
</td>
</tr>
<tr valign=top>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads?t=ms&k=Test+automation&w1=Workflow+automation&w2=Automation+equipment&w3=Industrial+automation&w4=Test+automation&w5=Sales+automation&w6=Factory+automation&c=6&s=145&.sig=babdTZ-cZ8AbgxQRUJqztw&quot;>Test
automation</a></tt>
</td>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads?t=ms&k=Sales+automation&w1=Workflow+automation&w2=Automation+equipment&w3=Industrial+automation&w4=Test+automation&w5=Sales+automation&w6=Factory+automation&c=6&s=145&.sig=-x7c78RB2nUpuPBRifr1YA&quot;>Sales
automation</a></tt>
</td>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads?t=ms&k=Factory+automation&w1=Workflow+automation&w2=Automation+equipment&w3=Industrial+automation&w4=Test+automation&w5=Sales+automation&w6=Factory+automation&c=6&s=145&.sig=zQtSND_pDmyn0UaMn4LPgQ&quot;>Factory
automation</a></tt>
</td>
</tr>
</tr>
</table>
<!-- **end egp html banner** -->
<!-- **begin egp html banner** -->
<br>
<div style="text-align:center; color:#909090;
width:500px;">
<hr style="border-bottom:1px; width:500px;
text-align:left;">
<tt>YAHOO! GROUPS LINKS</tt>
</div>
<br>
<ul>
<tt><li type=square>&nbsp;Visit your group "<a
href="http://groups.yahoo.com/group/xap_automation&quot;>xap_automation</a>"
on the web.<br>&nbsp;</tt>
<tt><li type=square>&nbsp;To unsubscribe from this group,
send an email to:<br>&nbsp;<a href="mailto:xap_automation-unsubscribe@xxxxxxx?subject=Unsubscribe&quot;>xap_automation-unsubscribe@xxxxxxx</a><br>&nbsp;</tt>
<tt><li type=square>&nbsp;Your use of Yahoo! Groups is
subject to the <a href="http://docs.yahoo.com/info/terms/&quot;>Yahoo!
Terms of Service</a>.</tt>
</ul>
<br>
<div style="text-align:center; color:#909090;
width:500px;">
<hr style="border-bottom:1px; width:500px;
text-align:left;">
</div>
</br>
<!-- **end egp html banner** -->
</body>
</html>
--------------080807090206060008070902--

Comments to the Webmaster are always welcomed, please use
this contact form
. Note that as this site is a mailing list archive, the Webmaster has no control
over the contents of the messages. Comments about message content should be directed
to the relevant mailing list.