IOT

iot@xmpp.org

138 discussions

by Peter Waher

Hello We're planning to start writing a new XEP proposal for IoT device discovery. I've received interest from a couple of people who wants to work on this. If anybody is interested in participating in this work, please let me know. The first proposal for the proto-XEP will be published in normal order on the standards list for anybody to comment on. Best regards, Peter Waher

12 years

Comments on XEP0323

by Emmanuel Frécon

Dear Folks! I have just gone through a thorough reading of XEP-0323 with the view of understanding its details before an implementation. I have a number of comments and suggestions, but also questions that I would like to share and raise. Note that I haven't spent so much time on "cross-XEP" reading. But first of all, I would like to congratulate Peter on putting together a strong (set of) XEP(s) that aim at solving some of the issues faced by IoT applications! Well done. And now... comes the list in no particular order, you will notice that there is a mix of tiny problems and sometimes larger questions. * I have a general question about security and request/responses. I don't see any protection against too many requests sent within a too short time frame. This could harm the receivers since we are usually talking about tiny devices with few resources. The proposal mentions that these requests might not be served, but having to process too many of them, even if taking the decision of not serving them might put a small sensor to its knees. I understand that requesting and requested must be friends, but such an issue might occur because of bad coding or corner cases being reached. I have no real solution, but I thought that I would mention it. * Every example in the text uses a sequence number that matches the "id" field of the <iq>. A non-initiated might be misled that they should be the same. * I am bit puzzled by having values listed as a sub-element of a <timestamp>. This is especially true since, for example, errors place the timestamp as an attribute of the <error> tag. What are the design decisions that led to this ordering? * As a side-note, I think that some of the example should highlight the fact that the dateTime type can also specify fractions of seconds, these might be important for some applications. * Since units are only under recommendation (and I think that this is very wise), we might consider having not having them as a "required" attribute for numerical values at all. Obviously, this is not very interoperable but it is as good as introducing unknown units that are only recognised within the namespace of an application. * In the read-out from multiple devices, I would have preferred that the <field>s are placed as sub-element of the <node>. * Wouldn't it be more future-proof to have <historical*> field types represented by a field called <historical> with an attribute describing the period of the history? * I wonder what the real difference is between "peak" and "computed" in the field types. The problem that I have with peak is that it shuts off other mathematical constructs such as mean, median, average, etc. Maybe is "peak" misleading just by its name, or maybe is it too specific and we could allow for a "comment" (or "method") attribute for the "computed" field type? * My first reaction to localising strings was that it brings unnecessary complexity to the XEP. The name of the fields, as transported over the wire/air, will seldom be shown to the user without passing through a software layer that would be able to perform the necessary localisations? Why should this information be carried as part of the protocol? Please bear with me if you already have discussed some of these issues in the past. I hope that this input will help improving the content of the XEP. /Emmanuel

12 years

"Understanding The Protocols Behind The Internet Of Things"

by Peter Saint-Andre

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI: http://electronicdesign.com/embedded/understanding-protocols-behind-interne… I provided a comment correcting some errors about XMPP... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSoUQpAAoJEOoGpJErxa2pxRcQAKPmVldFr9YArrkvFzpBDTOj cWEYVnwft+7XEYiUvE6zbyif9BIVQU4pB6zQEph4WoQtBytMOsG1xsvWsbsvyXmI ryyo9HCMH4fn3QAJjRVvds/JGusEhSNoIpIYoUC0crP1FBqAALQAY4auNqcCoe7d rZ6p+G8O98O8b17pzD0z1uQcRoYDGch+is1t2aqL28KBHZJRHKgW5ssiPC5REccW LY/532s9YC8wuq5yRCa9I/YwRhugb7utPBPsstf/DqDCN/KsWXlzaywI6isZxww/ sJPuiSLLZMNU+8bEZvhES0BQ4LweH4iwoJI/gZvp942RzsVpBYk6JPL6g0ScLrB3 DoEvY5a4+5h9fjlby78Lyqa6ZCw8eTvn4evBY/nYU5v947YVT1x3KcyVOQ9SV4kK KklM9Qg00gh5M9pypb1rj9+vFOEBv2lrA5XLX/0lQQt8OEKW6O/mcH3xeGSucgxB 5MsikGd1WsGOfURjjm02Mo/u5SBAqM0ClHg/wNf30aOPq5pM3n6tvd4+gVH5Cxgm Onap1xJLznqe8Krhqz770W4QEnClrn1h6kDrM9w7Lo2+0nebMBJuAZlNDZ5DoeDz Mn2hLnzywrHCQ+ugJlTCXhbYeaJaC1rt2IkfW6ZcS+X4i2emb+W3Mvkv1ctnx1JL 0FJZ1dPDul/ZaB93rNaP =qB29 -----END PGP SIGNATURE-----

12 years, 2 months

IoT in San Francisco in 12-14 november, gogonetlive and XMPP meetup

by Joachim Lindborg

Hi all I'm talking on the http://gogonetlive.com/gogonetlive-speakers.aspInternet of things IPv6 conference 13,14th november. The effort we are doing with IoT in the XSF today will be a topic There will be a workshop on the 12th where we will do IoT with the XMPP extensions. After the conference I'm also hosting a meetup in San Francisco. In case any of you are in the neighbourhood lets meet and have a beer and discuss how to proceed to get XMPP more known in the IoT world On the 14th I'm hosting a meetup in San Francisco to discuss more on the topics http://www.meetup.com/technology-11/events/146609572 rsvp on meetup or just send me an email does anyone know a good venue? *Regards* Joachim Lindborg CTO, systems architect *Keynote speaker at GoGonet live IPv6 conferens 12-14 november <http://gogonetlive.com/gogonetlive-speakers.asp> * Sustainable Innovation AB Adress: Box 55998 102 16 Stockholm Besöksadress: Storgatan 31 (Malmgården) Email: Joachim.lindborg(a)sust.se, www.sust.se linkedin: http://www.linkedin.com/in/joachimlindborg Tel +46 706-442270

12 years, 3 months

Re: [IOT] [Standards] Standard for Throttling/Queueing Stanzas

by Joachim Lindborg

This is also needed in the IoT world when small devices are connected. where we have low level of computational power or are battery operated. Also co posting to the IOT list 2013/10/27 Peter Saint-Andre <stpeter(a)stpeter.im> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/27/2013 10:16 AM, Spencer MacDonald wrote: > > I have observed from the XMPPFramework mailing list and Github > > issues, that one of the biggest problems that iOS Developers have > > with including XMPP (alongside VoIP) in their iOS apps, is that > > their apps get terminated for receiving to much data while in the > > background. > > > > There are proprietary solutions that allow an XMPP client to inform > > the XMPP Server that the app is going to be put in the background. > > The XMPP Server then queues the stanzas until the client in with > > the XMPP Server, which on iOS is less than or equal to 10 minutes. > > Some solutions also filter out presence packets so only the most > > recent one is queued for each jid. > > > > I appreciate that the problem is iOS specific, but the solution can > > be generic. > > > > Is this something that should be incorporated into an XEP? or is > > there already a solution for this issue? > > This is one reason we defined SIFT: > > http://xmpp.org/extensions/xep-0273.html > > However, that might be more than we need. Perhaps something simpler > would be of interest? > > Peter > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSbZGaAAoJEOoGpJErxa2pg6UP/1PYUTvCcKo1kP5+7G+vRmkC > h573r1zTOJg4qJQfUKs1I46tzkBmbL5295owf80KH0SsKJ5KTd2f+eqtOcJhj6w2 > 8PxYIFKkxj9uo4ToMlnv7SJHcl5dTIIQphrg4KxTUbf8VJ0G8KJz3zRw1hiHz2aM > etiroiDL84KXLastoQnKKcpFleQfbhWHeSt9udvNSbWY7o+ySdOMfAUYZpfgy56+ > amYG1PDC9KPr32TEXzukoawdv/ILVrS51RGFsfMjTyaAKhIrhIEa3xm7+8IDlb1k > kicuImmibo1Yd7kg+SD3ZVvSeR7yeYb6ENfHboLxIsxcPbzOg6PSVb1GQ0qYzEnE > vZ5Z3wp2uvGt7HuedxXucbqHfJ+Io/oYId/d0n/fG8NXl+xWPa+Pb5+nkmD8zCa1 > l5pmHQkqAfVnvFItOEcYGi0whj9BXU1fngxAVRfHKfEMpFHPhd+XOLfOY9OzNgqw > V5In7hT1yrtTUB9HMb3jeXUHNXb8aL26vI82MGKgXzUkm9+mprGVb4dcl1PMsizt > 7QngxEX86rhUP2ByIQLxYW+9ptZ2B9xxkaHSnEFSZYKN/3Yo6ToEp8WwXGpDGbTD > h0DUsdnpD8yO3IvzhfwW1pS3XQiE44x2/QsxjX9lrTIc0xCdbguotOWGIvM5HVfb > ZMh/Yz5+oEaZTtFwX8FG > =AyEt > -----END PGP SIGNATURE----- > -- *Regards* Joachim Lindborg CTO, systems architect *Keynote speaker at GoGonet live IPv6 conferens 12-14 november<http://gogonetlive.com/gogonetlive-agenda.asp> * Sustainable Innovation AB Adress: Box 55998 102 16 Stockholm Besöksadress: Storgatan 31 (Malmgården) Email: Joachim.lindborg(a)sust.se, www.sust.se linkedin: http://www.linkedin.com/in/joachimlindborg Tel +46 706-442270

12 years, 3 months

Re: [IOT] [Standards] Standard for Throttling/Queueing Stanzas

by Peter Waher

Hello Spencer As Joachim mentioned, there is interest from the Internet of Things (IoT) community to create such a XEP. In fact, it is already planned because there's a need, but it is yet to be written. Anybody interested in co-authoring such a XEP is welcome to contact me. The envisioned XEP however is not IOS specific, but rather concerns battery-powered sensors, but can be applied to sensors in resource constrained networks (where bandwidth is constrained). The same solutions can be applied in the IOS case you mentioned, since it can be seen as a resource constrained device, when the application runs in the background. Peter Saint-André mentioned that the deferred XEP 0273 could solve part of this issue, by permitting the filtering of certain messages. Forwarding of offline stanzas (XEP-0160) can also be used. I.e. the bandwidth can be controlled by the device, using the presence as an indication when the server can send information. (Here battery powered sensors often go into sleep mode and wake up regularly to perform a task. They can only receive messages when awake.) Other solutions can be envisioned, for instance using presence=away to signal clients restricting them to send important messages only, queuing not as important messages for later when online, etc. Ideas are welcome. Best regards, Peter Waher From: Spencer MacDonald [mailto:spencer.macdonald.other@gmail.com] Sent: den 27 oktober 2013 13:17 To: XMPP Standards Subject: [Standards] Standard for Throttling/Queueing Stanzas I have observed from the XMPPFramework mailing list and Github issues, that one of the biggest problems that iOS Developers have with including XMPP (alongside VoIP) in their iOS apps, is that their apps get terminated for receiving to much data while in the background. There are proprietary solutions that allow an XMPP client to inform the XMPP Server that the app is going to be put in the background. The XMPP Server then queues the stanzas until the client in with the XMPP Server, which on iOS is less than or equal to 10 minutes. Some solutions also filter out presence packets so only the most recent one is queued for each jid. I appreciate that the problem is iOS specific, but the solution can be generic. Is this something that should be incorporated into an XEP? or is there already a solution for this issue? Regards Spencer

12 years, 3 months

XMPP & IoT presentation @ IEEE WG meeting

by Peter Waher

Hello Here's a XMPP & IoT presentation I held at IEEE WG meeting. Extensions for safe and interoperable communications for the Internet of Things: http://prezi.com/esosntqhewhs/ The aim was to discuss the Interoperability XEP (work in progress), but previous IoT-related XEPs were also presented. Best regards, Peter Waher Peter Waher, Gerente General [cid:image001.png@01CED18C.B11FC900] Clayster Chile S.A. Calle Blanco 1623, oficina 1402 Valparaíso, Chile Teléfono: +56-32-2122533, +56-9-64324113 Nextel CD: 46*206*14419 Skype: peter.waher Correo electrónico: peter.waher(a)clayster.com<mailto:peter.waher@clayster.com> Twitter: https://twitter.com/ClaysterLabs, https://twitter.com/PeterWaher LinkedIn: http://se.linkedin.com/in/peterwaher/ 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/>.

12 years, 3 months

Fwd: [FOSDEM] CFP for Internet of Things Devroom

by Peter Saint-Andre

FYI -------- Original Message -------- Subject: [FOSDEM] CFP for Internet of Things Devroom Date: Fri, 11 Oct 2013 12:18:17 +0200 From: Pieter Hintjens <ph(a)imatix.com> To: fosdem(a)lists.fosdem.org, devroom-managers(a)lists.fosdem.org Next February 2nd, we're organizing a [http://fosdem.org FOSDEM] devroom for the Internet of Things. We're now calling for proposals. Do you have an interesting project you'd like to present to 5,000+ free and open source developers? If you have a project you'd like to present, or a talk you want to give, please submit it via [https://penta.fosdem.org/submission FOSDEM's Pentabarf] web tool. You will create an account (if you don't have one from a previous year), and select the "Internet of Things devroom" as the track. We'll discuss and select talks on [https://groups.google.com/forum/?hl=en#!forum/iot-devroom the Google iot-devroom group]. Anyone who wants to join in the review process, please just join that group. The organizers will take the final decision on talks if there is no consensus. We'll look for talks that include a technical/developer oriented discussion or showcase covering one or more of the following topics: * FOSS solutions for machine-to-machine communication on small embedded devices. * Distributed FOSS applications in any field of interest for autonomous/self-controlled devices, (e.g. domotics, automotive, etc. * Presentation of embedded devices with one or more possibilities to join a network. * Infrastructure related (TCP/IP, mesh networking, message queuing, cross-layer solutions). * Real-life problematics and their solution (Cost of maintenance, power management, reachability). * Interoperability solutions for heterogeneous applications, devices, protocols, media. All presentations must be fully FOSS, and related to software development. The devroom will last one day, with a welcome at 9:45, and talks from 10:00 to 17:00. Provisionally, talks will last 25 minutes each, and we will have a brainstorming / hacking session from 15:30 to 17:00. The goal is to make this devroom as interesting and diverse as possible, which means we will favor talks that contrast each other. For the hacking session, proposals are welcome. We will consider running multiple parallel hacking sessions during the same time. The deadline for submissions is December 1st. If you submit late, your talk may still be considered but will have to be exceptionally interesting. The program will be finalized by December 30th. _______________________________________________ FOSDEM mailing list FOSDEM(a)lists.fosdem.org https://lists.fosdem.org/listinfo/fosdem

12 years, 4 months

XEP 323, 325 IoT sensordata and control first implementation published

by Joachim Lindborg

We now have a first python sleekXMPP implementation of two experimental extensions published. XEP 323 http://xmpp.org/extensions/xep-0323.html XEP 325 http://xmpp.org/extensions/xep-0325.html The code is merged into the official develop branch of sleek on https://github.com/fritzy/SleekXMPP/tree/develop We will continue working on the implementation in https://github.com/joachimlindborg/SleekXMPP/tree/xep_0323_325 If you would like to participate please fork from my repository There is an easy to use example that you can start using https://github.com/joachimlindborg/SleekXMPP/blob/xep_0323_325/examples/IoT… please send any feedback -- Regards Joachim Lindborg CTO, systems architect Sustainable Innovation AB Adress: Box 55998 102 16 Stockholm Besöksadress: Storgatan 31 (Malmgården) Email: Joachim.lindborg(a)sust.se, www.sust.se linkedin: http://www.linkedin.com/in/joachimlindborg Tel +46 706-442270

12 years, 5 months

Paper: Extending the Semantic Web to Peer-to-Peer-like Sensor Networks based on XMPP

by Peter Waher

Hello everybody. I've written a paper titled "Extending the Semantic Web to Peer-to-Peer-like Sensor Networks based on XMPP", where I mention some of the work we've done in IoT XEPs 0322-0326 but mainly the HTTP over XMPP XEP 0332. I'd be happy to receive any questions/comments/suggestions you would have. Sincerely, Peter Waher

12 years, 6 months

← Newer
1
...
6
7
8
9
10
11
12
13
14
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

IOT