Sensor-over-XMPP - IOT

18 Dec 2012

Hi Antony

Used some time to read and watch "your tutorial for getting up and running with our
tools:
http://sensor.andrew.cmu.edu:9000/raw-attachment/wiki/quick-start/sensor-an…

Interesting.
Noticed that you are using strophe.im libs and I guess ejabberd as jabber server?
After watching your video I called some colleagues running research projects in
e-maintance including remote surveillance and diagnostic in machines.

Will read your report "Sensor Andrew: Large-Scale Campus-Wide Sensing and
Actuation" this evening and  if possible can I come back with some questions?

Yours Sincerely
Sven-Erik Tiberg
Lulea Univ of Technology.
Sweden

From: standards-bounces(a)xmpp.org [mailto:standards-bounces@xmpp.org] On Behalf Of Peter
Waher
Sent: den 17 december 2012 20:22
To: XMPP Standards; mat henshall
Cc: gauravbhatia(a)cmu.edu; iot(a)xmpp.org; Joachim Lindborg (joachim.lindborg(a)sust.se);
marioberges(a)cmu.edu
Subject: Re: [Standards] Status of XEP-xxxx: Sensor-over-XMPP

Hello Anthony.

Great to hear from you. I'm sorry I didn't know of your XEP until now.

Our implementations has been one of transport mainly, only the advantages of XMPP
transport, including client authentication, and network topology independence. We've
left most of meter/sensor communication to the protocol transported on-top (being it
M-bus, Modbus, etc.), with payload being identified using a content type attribute. Our
desire is to create a better abstract interface which is protocol independent, which would
allow for the same things. (And we have such an abstraction already defined for other
purposes, but it is not used in our xmpp implementation, so we have some ideas on what we
would need in a new XEP.)

However, we don't see it as necessarily advantageous to start specifying interfaces
for different kinds of devices in the XEP. We believe this is a bad abstraction.
(Something outside of the interfaces defined, would not be valid until one updates the
XEP.) However, an interoperability section online would probably be required, for people
wanting to define specific interfaces for certain use cases.

We don't either see a difference between sensors and a actuators in how devices are
handled, they are examples of two extremes of the same abstraction: To us most devices
consists of a collection of both readable values (i.e. "sensor" values, but also
other kind of non-sensor values) and writable values (configurable values, output values,
etc.). A PLC is an example where you cannot simply say it's a sensor (it may have
sensing capacities and most probably will) or an actuator (it most probably has output
values, but might not use them).

This we want to include in a XEP (and if previous XEPs could/should/shouldn't be used
and why):

*         Abstract interface description, describing available sensor resources
(readable/writable values, data types, meta information, etc.)

*         Request/response mechanism for readout.

*         Request/response mechanism for output.

*         Spontaneous reporting of momentary values  based on subscription rules,
hysteresis levels, and/or other logic.

*         Node topology information (if sensor part of larger whole, like a concentrator,
for instance).

*         Abstract metering data description, including:

o   Timestamps

o   Description

o   Units (if numerical)

o   Precision (if numerical)

o   Statuses (sequence of flags: error, QoS, tampering, etc.)

o   Data types (numerical, Boolean, string, date & time, enum, time span)

o   Value Types (momentary values, historical values, status values, informative values,
etc.)

o   Localization information

We also want to include several other things in a separate xep (like control logic), based
on what's possible if XMPP is connected to a semantic web environment.

Would anybody be interested in working on such a XEP with us?

Sincerely,
Peter Waher

From: Anthony Rowe [mailto:agr@ece.cmu.edu]<mailto:[mailto:agr@ece.cmu.edu]>
Sent: den 17 december 2012 13:45
To: mat henshall
Cc: gauravbhatia@cmu.edu<mailto:gauravbhatia@cmu.edu>;
iot@xmpp.org<mailto:iot@xmpp.org>; Joachim Lindborg
(joachim.lindborg@sust.se<mailto:joachim.lindborg@sust.se>); XMPP Standards;
marioberges@cmu.edu<mailto:marioberges@cmu.edu>
Subject: Re: [Standards] Status of XEP-xxxx: Sensor-over-XMPP

Hi all,

Great to see so much interested in XMPP for IoT applications.  The XEP was basically a
summarization of how we had been using XMPP and pubsub in our sensor andrew project.  We
were also lucky enough to get a fair amount of input form Charles at Google with some
interesting use-cases and a few idea on reducing message traffic.  The main hangup was
that the XMPP council didn't like the idea of linking sensors and actuators and there
was some concern if pubsub was generally a good fit for actuation.  We basically decided
that as researchers in a University environment we would just keep doing what we were
doing and revisit the XEP in the future if there was more interest.    One easy fix would
have been for us to split the XEP into a sensor and actuator document.

I would be very interested to hear about how you all have been structuring your XMPP
communication.  Is it similar to what we proposed?  Is anyone using pubsub?  We are still
actively using our proposed model with a few minor changes to the XEP.  Our most recent
version of the XEP document can be found here:
http://sensor.andrew.cmu.edu/xep/sox-xep.html

We also have a simple tutorial for getting up and running with our tools:
http://sensor.andrew.cmu.edu:9000/raw-attachment/wiki/quick-start/sensor-an…

As for implementations, we have a C, java and python version of our library (called SOX)
that we have continued to develop.   We have been focusing our recent efforts on the
slightly higher-level problems associated with data storage, meta information management
and application hosting.  These all for the most part exist above the XEP which is just
our simple message passing format.

I wouldn't be opposed to revamping our XEP with other's inputs and trying to
resubmit.  We have been getting interest from our corporate sponsors to take another shot
at the XEP.

    -Anthony

On Dec 17, 2012, at 11:16 AM, mat henshall
<mat@squareconnect.com<mailto:mat@squareconnect.com>> wrote:

We are using XMPP for both sensor reporting and control for building and home automation
applications. We have implemented a very rich set of stanza's that cover almost all
common types of devices and it is designed to work on very low resource embedded devices.
This implementation is currently in closed beta although there are some very large brands
who have started to develop applications and hardware using our protocol and technology.
Our intention is to make the protocol public once we had a full working public available
implementation.

When we became aware of the proposed XEP extension mentioned here we were already a long
way down the road with our own, and as there is so much more to making a complete system
than is exposed in this XEP, we felt we needed a working implementation to compare and
contrast and make meaningful contributions based on experience...

We would be excited to work with others on creating a standard... the problem as always is
time to commit to this exercise. That being said, we do have executing code and multiple
devices talking to each otehr across continents... so I think we are at the stage where we
could add to any serious attempt for standardization.

Mat

On Mon, Dec 17, 2012 at 9:54 AM, Hannes Tschofenig
<hannes.tschofenig@gmx.net<mailto:hannes.tschofenig@gmx.net>> wrote:
Hi all,

I was actually wondering myself about the status of XMPP & SIP usage for sensors. I
dropped Peter a mail a month ago to hear more about the deployment situation.
It seems that if there are implementations then they are using HTTP.

Ciao
Hannes

On Dec 17, 2012, at 5:47 PM, Matthew Wild wrote:

...
  On 17 December 2012 12:35, Peter Waher
<Peter.Waher@clayster.com<mailto:Peter.Waher@clayster.com>> wrote:

 Hello,

 I'm writing to you to, to ask about the status of the following document:

 http://xmpp.org/extensions/inbox/sensors.html

  I'm interested in developing extensions for
allowing sensor data communication and IoT, among other things. We have multiple
applications using XMPP and sensors. Before proposing an extension by ourselves, I've
been waiting to find colleagues working in the same area, so we could propose an extension
together, this increasing the probability for it to become useful.

 What is the status of the above mentioned document? Is it set in stone, or is it possible
to work on it, redefine parts of it, etc., in order for it to become more general and
suitable also to our needs? Are you able to invite other authors to partake in the
development of this proposed extension? 
 It was rejected by the council at its meeting 2011-04-27:
 http://mail.jabber.org/pipermail/council/2011-May/003164.html

 Nathan posted his reasoning here:
 http://mail.jabber.org/pipermail/standards/2011-May/024545.html - and
 the discussion continued here:
 http://mail.jabber.org/pipermail/standards/2011-May/024547.html

 No new version was submitted as far as I know, and I know of no public
 implementations of the protocol (that's not to say there aren't any of
 course...).

 Regards,
 Matthew 

--

Mat Henshall
Founder and CEO, Square Connect, Inc.
San Jose, CA
www.squareconnect.com<http://www.squareconnect.com/>
cell: 650.814.7585