For a project that I’m doing with several partners I’m proposed to use the XMPP IoT experimental extensions (including the not yet submitted eventing extension). One requirement for the project is that the ‘Things’ should use as little data as possible and for this we wanted to optimise the data the Things are sending to subscribers. Another requirements was that we would like to be able to have fine grained control on which subscribers would be allowed to subscribe and receive the data.
We want to accommodate multiple listeners to the same events, this is quite pub/sub like, and discussed to use either MQTT or XMPP.
A few things I noticed during our discussion:
1. The partners did not see the eventing extension as pubsub but rather as p2p because clients need to subscribe to all the different things instead of to only a single topic.
2. There is currently no best practises in using pubsub or PEP for IoT.
3. Management of pubsub nodes (manage subscribers and publishers) is cumbersome and not all functions (authorization schemes) are supported by all XMPP servers.
4. I proposed an alternative pubsub like service, that I called ‘dealer’, which acts as a IoT concentrator towards the subscribers and that would subscribe to all Things the clients would want to receive events from.
Currently the project is leaning towards MQTT, mostly because partners like that concept of pubsub over the XMPP alternatives (verbosity of XMPP is not considered an issue).
I would like to share this feedback as it might be useful in progressing the IoT extensions further.
Cheers,
Eelco
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
Hi Saurabh pleased to meet you and wonderful that you are working the field
of IoT and especially using xmpp for it. coposting this to the iot(a)xmpp.org
list.
The extensions published are as Arc pointed out totally free to use. They
have been worked on for some time and there are some implementations
around, you are free to use them and of-course also discuss changes. It is
a hope that these published XEP's can be that source for a uniform IoT
standard across implementations.
your site is nice looks promising (you need to redirect www... to the same
adress as http://iotfy.co/) let's discuss how the XEP's published works in
your implementaion, on the iot(a)xmpp.org list or offline if you prefer. just
send me an email.
Introductions: (please help out with the work)
http://xmpp-iot.github.io/
wiki
http://wiki.xmpp.org/web/Tech_pages/IoT_systems
Another commercial implementation done by clayster
https://www.thingk.me/Provisioning/Index.xml
/Joachim Lindborg
*Regards*
Joachim Lindborg
CTO, systems architect
Sustainable Innovation SUST.se
Barnhusgatan 3 111 23 Stockholm
Email: Joachim.lindborg(a)sust.se
linkedin: http://www.linkedin.com/in/joachimlindborg
Tel +46 706-442270
2015-04-19 16:35 GMT+02:00 Arc Riley <arcriley(a)gmail.com>:
> XMPP and all XEPs are free and open for use. You should find an IP
> disclaimer on each, eg;
> PermissionsPermission is hereby granted, free of charge, to any person
> obtaining a copy of this specification (the "Specification"), to make use
> of the Specification without restriction, including without limitation the
> rights to implement the Specification in a software program, deploy the
> Specification in a network service, and copy, modify, merge, publish,
> translate, distribute, sublicense, or sell copies of the Specification, and
> to permit persons to whom the Specification is furnished to do so, subject
> to the condition that the foregoing copyright notice and this permission
> notice shall be included in all copies or substantial portions of the
> Specification. Unless separate permission is granted, modified works that
> are redistributed shall not contain misleading information regarding the
> authors, title, number, or publisher of the Specification, and shall not
> claim endorsement of the modified works by the authors, any organization or
> project to which the authors belong, or the XMPP Standards Foundation.
>
> On Sun, Apr 19, 2015 at 9:57 AM, Saurabh Shandilya <
> saurabhshandilya.1991(a)gmail.com> wrote:
>
>> Hey all,
>>
>> I come to know about XMPP IoT. I along with my team have also been
>> working on the same concept and about to launch.
>> I would like to know about the commercial aspects or open sourced status
>> of the project. If clouds service are provided, then how are they managed.
>> Kindly provide me with appropriate pointers and/or suggestions.
>> www.iotfy.co
>> is our website, that works on almost the same concept (as much as I have
>> understood by now)
>>
>>
>> --
>> Regards,
>> saurabh shandilya
>> www.embedded4fun.com
>> sshandil(a)andrew.cmu.edu
>> +91 9910118292
>>
>
>
Hi,
Paragraph 5.1 of XEP-0347 says it is only needed to ‘become friends’ with the Thing registry if the registry isn’t a server component.
> 5.1 JID vs Component Thing Registries <>
> A client must treat the connection between a Thing Registry differently if it is hosted as a client, having a JID, or if it is hosted as a Jabber Server Component. If it is hosted as a server component, there's no need for the thing to become friends with the Thing Registry. Messages and requests can be made directly to the server component without having to add it to the roster or request presence subscriptions. If the Thing Registry is hosted as a client, having a JID (@ in the address), the Thing Registry must be added to the roster of the client before the client can communicate with the Thing Registry.
>
However, for the registry to determine if a Thing is online or offline (to check if it is able to notifiy it about claimed, disowned and removed states) the Thing registry needs a presence subscription with the Thing. This does not mean that the Thing also has a presence subscription on the registry but there must be some kind of ‘friendship’ relation between the 2. So the text above is ambiguous in my opinion.
Also paragraph “3.6 Registering a Thing” states that a Thing must find and befriend a registry before the Thing can register itself with the registry.
Should paragraph 5.1 be updated or removed?
Thanks,
Eelco
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
Inspired from the XMPP lounge hacking at FOSDEM, where we had Philips Hue
lamps connected to Beatles music over the xmpp network. Loads of interested
people where playing with the lamps.
Couldn't we on the 9th of april 2015 which is the global IoT day, connect
color lamps all over the world controlled from London with lloyd's music
feed? I can setup most of the turorial.
Each lamp friending music_master@controller or join the Disco MUC room
receives individual messages and own symbols/nicks on the youtube channel
sending the music and Visualisation stream.
Then an https://talky.io/XMPP_world_disco session from all sites
*Regards*
Joachim Lindborg
CTO, systems architect
Sustainable Innovation SUST.se
Barnhusgatan 3 111 23 Stockholm
Email: Joachim.lindborg(a)sust.se
linkedin: http://www.linkedin.com/in/joachimlindborg
Tel +46 706-442270
