Status of XEP-xxxx: Sensor-over-XMPP
Hello. I'm writing to you to, to ask about the status of the following document: http://xmpp.org/extensions/inbox/sensors.html How is this proposed extension used today, and in what implementations? 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? Sincerely, Peter Waher Peter Waher, Gerente General [cid:image001.png@01CDDC39.8577CD00] Clayster Chile Ltda Calle Blanco 1623, oficina 1402 Valparaíso, Chile Teléfono: +56-32-2122533, +56-9-71993640 Skype: peter.waher Correo electrónico: peter.waher@clayster.com<mailto:peter.waher@clayster.com> Twitter: https://twitter.com/ClaysterLabs, https://twitter.com/PeterWaher LinkedIn: http://se.linkedin.com/pub/peter-waher/1a/71b/a29 La información contenida en esta transmisión es confidencial y propietaria y no puede ser utilizada por personas distintas a su(s) destinatario(s). La utilización no autorizada de la información contenida en este correo por cualquier forma puede ser sancionada criminalmente de conformidad con la Ley Chilena e infringir normas sobre propiedad intelectual, propiedad industrial o secretos comerciales. Si ha recibido esta transmisión por error, por favor destrúyala y notifique al remitente telefónicamente, con cobro revertido o vía e-mail. Atendido que no existe certidumbre que el presente mensaje no será modificado como resultado de su transmisión por correo electrónico CLAYSTER Laboratorios Chile Limitada, no será responsable si el contenido del mismo ha sido modificado. Visite nuestra página WEB www.clayster.com<http://www.clayster.com/>. The information contained in this transmission is confidential and proprietary and it cannot be used by any person other than its addressee(s). Unauthorized use of the information contained in this transmission in any form may be punished under Chilean Law and be considered a copyright, industrial property or trade secrets infringement. If received in error, please destroy it and notify the sender by calling collect or e-mail. As there can be no certainty that this message will not be modified as a result of its transmission via e-mail, CLAYSTER Laboratorios Chile Limitada shall not be responsible if the content of the same has been modified. Visit www.clayster.com<http://www.clayster.com/>.
On 17 December 2012 12:35, Peter Waher <Peter.Waher@clayster.com> wrote:
Hello,
I’m writing to you to, to ask about the status of the following document:
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
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> wrote:
Hello,
I’m writing to you to, to ask about the status of the following document:
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
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> 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> wrote:
Hello,
I’m writing to you to, to ask about the status of the following
document:
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 cell: 650.814.7585
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-and... 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> 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> 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> wrote:
Hello,
I’m writing to you to, to ask about the status of the following document:
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 cell: 650.814.7585
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] Sent: den 17 december 2012 13:45 To: mat henshall Cc: gauravbhatia@cmu.edu; iot@xmpp.org; Joachim Lindborg (joachim.lindborg@sust.se); XMPP Standards; 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-and... 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:
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
We are setting up a driver simulator that could be working together with a remote controlled minicar with webcam. The direction, acc and video from the minicar will be feeded back to the driversimulator with a 6 DOF motion base ( trough a bit of filtering program ) . Seems a bit strange application but we let our students work on this as a first stage towards our main goal. The protocol would be able to transfer state packages at 10 packaged per second. According to naval postgrade school in Monterey CA this could be possible. Appreciate your opinion. Btw project described at wbsp.arb.ltu.se/Motionbase<http://wbsp.arb.ltu.se/Motionbase> /Sven-Erik Tiberg Luleå Univ of technology Sweden Skickat från min iPhone 17 dec 2012 kl. 17:46 skrev "Anthony Rowe" <agr@ece.cmu.edu<mailto:agr@ece.cmu.edu>>: 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-and... 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:
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
Hello all, our students did something similar using our Mobilis Framework (https://github.com/danielschuster/mobilis) and a Lego NXT Robot. For further information see http://141.76.40.90/~wiki/index.php/RemoteBot (sorry for the IP in the URL, we currently don't have a DNS entry for that server as it's mainly used internally and by our students) and http://www.youtube.com/watch?v=cPCDRsmcSKA. Kind regards, Sven Bendel -- Dipl. Inf. Sven Bendel Wissenschaftlicher Mitarbeiter Technische Universität Dresden Fakultät Informatik Institut für Systemarchitektur Lehrstuhl Rechnernetze Nöthnitzer Str. 46, 01187 Dresden, Raum INF 3085 Tel.: +49 351 463-38235 E-Mail: sven.bendel@tu-dresden.de
Sven-Erik Tiberg <mailto:Sven-Erik.Tiberg@ltu.se> 17. Dezember 2012 23:03 We are setting up a driver simulator that could be working together with a remote controlled minicar with webcam. The direction, acc and video from the minicar will be feeded back to the driversimulator with a 6 DOF motion base ( trough a bit of filtering program ) . Seems a bit strange application but we let our students work on this as a first stage towards our main goal. The protocol would be able to transfer state packages at 10 packaged per second. According to naval postgrade school in Monterey CA this could be possible. Appreciate your opinion. Btw project described at wbsp.arb.ltu.se/Motionbase <http://wbsp.arb.ltu.se/Motionbase> /Sven-Erik Tiberg Luleå Univ of technology Sweden
Just to add our voice to the discussion - We've been using XMPP for M2M communication between our smart energy gateways our servers. Our devices run linux+ python and we use SleekXMPP which we've contributed quite a bit to. What we've been using so far has been mostly our own messaging language that's specific to our use cases. We haven't used PubSub either – We chose IQs for command and control, and messages for telemetry. I'm also involved in OpenADR 2.0 which is an energy interop language. While not strictly an XEP, it will work over HTTP and XMPP. - Thom From: Anthony Rowe <agr@ece.cmu.edu<mailto:agr@ece.cmu.edu>> Reply-To: XMPP in the Internet of Things <iot@xmpp.org<mailto:iot@xmpp.org>> Date: Monday, December 17, 2012 11:44 AM To: mat henshall <mat@squareconnect.com<mailto:mat@squareconnect.com>> Cc: "gauravbhatia@cmu.edu<mailto:gauravbhatia@cmu.edu>" <gauravbhatia@cmu.edu<mailto:gauravbhatia@cmu.edu>>, "iot@xmpp.org<mailto:iot@xmpp.org>" <iot@xmpp.org<mailto:iot@xmpp.org>>, "Joachim Lindborg (joachim.lindborg@sust.se<mailto:joachim.lindborg@sust.se>)" <joachim.lindborg@sust.se<mailto:joachim.lindborg@sust.se>>, XMPP Standards <standards@xmpp.org<mailto:standards@xmpp.org>> Subject: Re: [IOT] [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-and... 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:
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 This email and any information disclosed in connection herewith, whether written or oral, is the property of EnerNOC, Inc. and is intended only for the person or entity to which it is addressed. This email may contain information that is privileged, confidential or otherwise protected from disclosure. Distributing or copying any information contained in this email to anyone other than the intended recipient is strictly prohibited.
participants (8)
-
Anthony Rowe -
Hannes Tschofenig -
mat henshall -
Matthew Wild -
Peter Waher -
Sven Bendel -
Sven-Erik Tiberg -
Thomas Nichols