[Standards] updated Sensors proposal
css at google.com
Wed May 18 21:39:14 UTC 2011
Great! We would love to get some additional feedback regarding the
sensor portion while we consider the comments regarding the actuation
For a "read-only" sensor network, the only difference would be to not
implement (or respond to) the <TransdcuerSetValue/> tag. No other
change to the proposed spec would be needed for the sensor-only use
There is a sample client library in java that fully implements the
proposed spec available at the CMU svn repository (open source, apache
svn checkout svn://sensor.andrew.cmu.edu:/srv/svn/repos/sensor-andrew/sox
which can be used as a reference if interested. The java client
library code is at .../sox/lib/lib_java and the java examples that use
that library are at .../sox/examples. Feel free to ignore the
TransducerSetValue.java file and any examples that use that tag :) The
java client library code is known to work with recent versions of both
ejabberd and openfire xmpp servers.
As the conversation regarding actuation moves forward, we'll be trying
to keep that java implementation up to date. We are also working on a
C/C++ library but it is not yet ready.
On Wed, May 18, 2011 at 9:48 AM, Arc Riley <arcriley at gmail.com> wrote:
> A group of us with HacDC were working on a similar system to what Nathan
> proposed for our sensors project; PubSub (in our case, with
> presence=subscription and body-xslt so it works from non-pubsub clients) and
> AdHoc Commands for, well, commands. That project has been idle for a few
> months now, but we learned a lot from the experience.
> I agree with Matthew that actuators should be separated and implemented with
> AdHoc Commands. I don't see a strong need to actually define a separate
> "actuators" XEP, but perhaps a mention AdHoc Commands in the SoX draft as
> the recommend way to control sensors and related devices.
> I would be happy to implement your Sensors over XMPP proposal sans-actuators
> in our system, provide feedback, and share our embedded software
> On Wed, May 18, 2011 at 11:55 AM, Anthony Rowe <agr at ece.cmu.edu> wrote:
>> Hi Nathan,
>> I agree that usually sending commands should be a transactional process
>> (with an ACK), but I think PubSub doesn't necessarily prohibit that type of
>> interaction, and we could even integrate XEP-0050 on top of it to deal with
>> things like command discovery and lists. In cases where we would like
>> acknowledgements, we typically have the publisher also subscribed to the
>> same node. We basically handle acknowledgments like call-backs where the
>> agent doing the actuation should publish the updated state of the actuator
>> once it finishes. An interested node (or nodes) can use this as an ACK.
>> This might not be the most efficient way of handling a simple
>> point-to-point actuation, but it has significant advantages in the case
>> where multiple agents control devices since all participating agents
>> essentially see the ACK. The PubSub model also helps deal with timing
>> delays for devices that might have slow reactions or intermittent network
>> connectivity. In many sensor networking cases, the round-trip might take
>> long enough that nodes would want to disconnect, sleep and reconnect in
>> separate sessions to see if the actuation was successful.
>> As for the broadcast control case, there are many examples (we can go
>> ahead and put a few in the XEP). Think about smart grid applications where
>> a power distributor wants to do load shedding and sends out a broadcast
>> command specifying that all low,medium or high criticality devices shut-off.
>> Other examples could include group actuation of distributed components
>> (window controllers in a building, lights etc).
>> ---------------------------- Original Message ----------------------------
>> Subject: Re: [Standards] updated Sensors proposal
>> From: "Nathan Fritz" <nathanfritz at gmail.com>
>> Date: Wed, May 18, 2011 10:44 am
>> To: "XMPP Standards" <standards at xmpp.org>
>> This feedback is obviously very late, but here it is just the same.
>> The reason that I vetoed this spec is specifically that I think
>> sending commands over Publish-Subscribe is a misuse of the spec.
>> Commands generally require error handling and acknowledgement.
>> Additionally, I don't see the use-case for broadcasting commands to
>> subscribers in this spec. IQ payloads, XEP-0050, and others handle
>> sending commands, and given the nature of the examples in the spec, I
>> think these would be better suited for the "setValue" scenario.
>> I encourage you to either provide an example and argument against my
>> reasons stated or re-submit the spec using a more appropriate method
>> for setValue. I agree that this has use, but I disagree with the
>> current form for sending commands.
>> I apologize that this feedback is so late.
>> -Nathan Fritz
More information about the Standards