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 (Arduino-based). On Wed, May 18, 2011 at 11:55 AM, Anthony Rowe <[email protected]> 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" <[email protected]> > Date: Wed, May 18, 2011 10:44 am > To: "XMPP Standards" <[email protected]> > -------------------------------------------------------------------------- > > > 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 > >
