[Standards] updated Sensors proposal

Arc Riley arcriley at gmail.com
Wed May 18 16:48:49 UTC 2011

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).
>    -Anthony
> ---------------------------- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110518/a1ac2e4b/attachment.html>

More information about the Standards mailing list