[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Re: Consensus on BSC temperature reporting?
--------------010803030601090205030503
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Gregg Liming wrote:
> Hi Lehane,
>
> Quoting Lehane Kellett (8/29/06 1:01 PM):
>
>> OK - so how about new classes - sensor.report and sensor.cmd?
>>
>> Devices could be simple (one wire) or complex (complete CH
system).
>>
>
> One reaction that I had is that it appears that each sensor.report
> message has a single body. Is that correct? I am asking as a result
of
> having wrestled w/ how to treat one of my physical devices that
reports
> both humidity and temperature (the chip itself does that). For the
time
> being, I've decided to "virtualize" this single device into
multiple
> subaddresses--each having their own xAP UID. While that keeps the
> mapping of single block to single device clean, it does cause some
> complications--among them having to track multiple UIDs to single real
> device (which often has it's own real ID). It also means that the
> reporting interval is somewhat arbitrary from a command standpoint in
> that both ought to give out their values together. On the other hand,
> it does make sense from an event standpoint (vice info) as one of the
2
> measurements passed some delta (change) and not both
>
I prefer not to virtualise for the reasons you stated and the complexity
is in the sensor - possibly a
small device. In most cases determining which value has changed is
trivial in the recipient,
assuming you actually need to.
However, I'd have no problem with the concept if that was the consensus.
> Also, while I can't think of any sensors off-hand that don't limit to
> single, scalar values, I don't see how the value example is extended
to
> multi-variant. If it were multi-variant, would values be comma
separated?
>
Personal preference is to find another approach - it makes the parsing
so much more complex with CSV.
> Somewhat related, I've been working on a "raw anemometer"
project that
> uses the NetIOM xAP to report pulse counts on x revolutions. In turn,
I
> calculate wind-speed. One good thing about this is I have more
control
> over the reporting and calculation of instantaneous wind speed than
most
> consumer weather stations. But, if I were to use the schema that you
> posted, I seem to only have room for one "value". How are
> "instantaneous" vice "average" values handled?
Also, I can change the
> baseline for the averaging "window". How might that
ancillary
> parameters that provide a context (e.g., averaging window in seconds)
> for "value" be reflected in the schema?
>
> Gregg
>
>
Well, it was barebones schema.. and it some ways it goes back to the
thorny problem of configuring xAP devices.
As to reporting, each would have a section - one value would be
instantaneous windspeed and another average.
I'm just hoping to throw some ideas around as after BSC sensor data
seems to be the next most important - ahead
of audio/visual.
Lehane
Lehane
--------------010803030601090205030503
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">
Gregg Liming wrote:
<blockquote cite="mid44F4797C.6010200@xxxxxxx"
type="cite">
<pre wrap="">Hi Lehane,
Quoting Lehane Kellett (8/29/06 1:01 PM):
</pre>
<blockquote type="cite">
<pre wrap="">OK - so how about new classes - sensor.report
and sensor.cmd?
Devices could be simple (one wire) or complex (complete CH system).
</pre>
</blockquote>
<pre wrap=""><!---->
One reaction that I had is that it appears that each sensor.report
message has a single body. Is that correct? I am asking as a result of
having wrestled w/ how to treat one of my physical devices that reports
both humidity and temperature (the chip itself does that). For the time
being, I've decided to "virtualize" this single device into
multiple
subaddresses--each having their own xAP UID. While that keeps the
mapping of single block to single device clean, it does cause some
complications--among them having to track multiple UIDs to single real
device (which often has it's own real ID). It also means that the
reporting interval is somewhat arbitrary from a command standpoint in
that both ought to give out their values together. On the other hand,
it does make sense from an event standpoint (vice info) as one of the 2
measurements passed some delta (change) and not both
</pre>
</blockquote>
<br>
I prefer not to virtualise for the reasons you stated and the
complexity is in the sensor - possibly a<br>
small device. In most cases determining which value has changed is
trivial in the recipient,<br>
assuming you actually need to.<br>
<br>
However, I'd have no problem with the concept if that was the
consensus.<br>
<blockquote cite="mid44F4797C.6010200@xxxxxxx"
type="cite">
<pre wrap="">
Also, while I can't think of any sensors off-hand that don't limit to
single, scalar values, I don't see how the value example is extended to
multi-variant. If it were multi-variant, would values be comma separated?
</pre>
</blockquote>
Personal preference is to find another approach - it makes the parsing
so much more complex with CSV.<br>
<blockquote cite="mid44F4797C.6010200@xxxxxxx"
type="cite">
<pre wrap="">
Somewhat related, I've been working on a "raw anemometer" project
that
uses the NetIOM xAP to report pulse counts on x revolutions. In turn, I
calculate wind-speed. One good thing about this is I have more control
over the reporting and calculation of instantaneous wind speed than most
consumer weather stations. But, if I were to use the schema that you
posted, I seem to only have room for one "value". How are
"instantaneous" vice "average" values handled? Also, I
can change the
baseline for the averaging "window". How might that ancillary
parameters that provide a context (e.g., averaging window in seconds)
for "value" be reflected in the schema?
Gregg
</pre>
</blockquote>
Well, it was barebones schema.. and it some ways it goes back to the
thorny problem of configuring xAP devices.<br>
As to reporting, each would have a section - one value would be
instantaneous windspeed and another average.<br>
<br>
I'm just hoping to throw some ideas around as after BSC sensor data
seems to be the next most important - ahead<br>
of audio/visual.<br>
<br>
Lehane<br>
<br>
<br>
Lehane<br>
<br>
<span width="1" style="color:
white;"/>__._,_.___</span>
<!-- **begin egp html banner** -->
<img src="http://geo.yahoo.com/serv?s=97476590&grpId=9674343&grpspId=1600007709&msgId=2987&stime=1156880772";
width="1" height="1"> <br>
<!-- **end egp html banner** -->
<!-- **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;_ylc=X3oDMTJjbjlhaDlwBF9TAzk3NDc2NTkwBF9wAzEEZ3JwSWQDOTY3NDM0MwRncnBzcElkAzE2MDAwMDc3MDkEc2VjA3NsbW9kBHN0aW1lAzExNTY4ODA3NzI-?t=ms&k=Workflow+automation&w1=Workflow+automation&w2=Automation+equipment&w3=Industrial+automation&w4=Test+automation&w5=Factory+automation&c=5&s=123&g=0&.sig=UMuHyfDcKCN-8Czn5DvjNg";>Workflow
automation</a></tt>
</td>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads;_ylc=X3oDMTJjNTBic2UxBF9TAzk3NDc2NTkwBF9wAzIEZ3JwSWQDOTY3NDM0MwRncnBzcElkAzE2MDAwMDc3MDkEc2VjA3NsbW9kBHN0aW1lAzExNTY4ODA3NzI-?t=ms&k=Automation+equipment&w1=Workflow+automation&w2=Automation+equipment&w3=Industrial+automation&w4=Test+automation&w5=Factory+automation&c=5&s=123&g=0&.sig=hRMkcOBBZ36mW9UeMEmhhg";>Automation
equipment</a></tt>
</td>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads;_ylc=X3oDMTJjOGMxbWcwBF9TAzk3NDc2NTkwBF9wAzMEZ3JwSWQDOTY3NDM0MwRncnBzcElkAzE2MDAwMDc3MDkEc2VjA3NsbW9kBHN0aW1lAzExNTY4ODA3NzI-?t=ms&k=Industrial+automation&w1=Workflow+automation&w2=Automation+equipment&w3=Industrial+automation&w4=Test+automation&w5=Factory+automation&c=5&s=123&g=0&.sig=2fnn4Mg42mPil-CoKXA_kg";>Industrial
automation</a></tt>
</td>
</tr>
<tr valign=top>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads;_ylc=X3oDMTJjZ2hpanM3BF9TAzk3NDc2NTkwBF9wAzQEZ3JwSWQDOTY3NDM0MwRncnBzcElkAzE2MDAwMDc3MDkEc2VjA3NsbW9kBHN0aW1lAzExNTY4ODA3NzI-?t=ms&k=Test+automation&w1=Workflow+automation&w2=Automation+equipment&w3=Industrial+automation&w4=Test+automation&w5=Factory+automation&c=5&s=123&g=0&.sig=7d_lPdR-fmMQUamXeHQA_A";>Test
automation</a></tt>
</td>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads;_ylc=X3oDMTJjazRuMXBlBF9TAzk3NDc2NTkwBF9wAzUEZ3JwSWQDOTY3NDM0MwRncnBzcElkAzE2MDAwMDc3MDkEc2VjA3NsbW9kBHN0aW1lAzExNTY4ODA3NzI-?t=ms&k=Factory+automation&w1=Workflow+automation&w2=Automation+equipment&w3=Industrial+automation&w4=Test+automation&w5=Factory+automation&c=5&s=123&g=0&.sig=zHQZiPVzgLReC50UMD151Q";>Factory
automation</a></tt>
</td>
</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> Visit your group "<a
href="http://groups.yahoo.com/group/xap_automation";>xap_automation</a>"
on the web.<br> </tt>
<tt><li type=square> To unsubscribe from this group,
send an email to:<br> <a href="mailto:xap_automation-unsubscribe@xxxxxxx?subject=Unsubscribe";>xap_automation-unsubscribe@xxxxxxx</a><br> </tt>
<tt><li type=square> Your use of Yahoo! Groups is
subject to the <a href="http://docs.yahoo.com/info/terms/";>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** -->
<span style="color: white;"/>__,_._,___</span>
</body>
</html>
--------------010803030601090205030503--
xAP_Automation Main Index |
xAP_Automation Thread Index |
xAP_Automation Home |
Archives Home
|