IoT SIG - 2019-09-04


  1. Alacer has left

  2. Alacer has joined

  3. Alacer has left

  4. Alacer has joined

  5. patrik has joined

  6. Alacer has left

  7. Alacer has joined

  8. Alacer has left

  9. Alacer has joined

  10. Tobi has joined

  11. Alacer has left

  12. Alacer has joined

  13. jjrh has left

  14. jjrh has joined

  15. jjrh has left

  16. jjrh has joined

  17. jjrh has left

  18. jjrh has joined

  19. COM8 has joined

  20. COM8

    So I started laying out the building blocks needed for a new approach to IoT. Now I would like to start working on the XEP(s). Should I create one single XEP or is it better when I spit stuff up into multiple XEPs. Any advice here? Planed topics: Registration, Discovery, Data Access, Trust Management, (Device Automatisation)

  21. flow

    COM8, I don't think that it does not matter that much at an early stage if you split or not. In general, splitting large XEPs in optional parts is usually a good idea

  22. flow

    COM8, I usually recommend setting up a system which automatically builds the XEPs from source and place the resulting html onto a webserver

  23. Alacer has left

  24. Alacer has joined

  25. COM8

    Ok, sounds good. Since splitting up can be done later I will start working on one compact XEP

  26. jjrh has left

  27. jjrh has joined

  28. jjrh has left

  29. jjrh has joined

  30. flow

    COM8, also, be aware that writing a standard and getting it published is not an easy task

  31. flow

    I suggest to gather feedback early and to seek for a way has the highest chance to get consensus

  32. flow

    I think IoT is especially challenging here, since it has so many different meanings and everyone has a slight different requirements etc

  33. flow

    Aaaaaaaaaaaand: running code, you want to develop a standard hand-in-hand with a (prototype) implementation

  34. MattJ

    Also an important note: a suite of IoT XEPs covering these topics was already published some years ago

  35. flow

    MattJ, I think COM8 is aware of the waher xeps

  36. Alacer has left

  37. MattJ

    Ok, good

  38. COM8

    flow: Yes, I'm aware of that. At the moment I'm working on the overall system design. So as soon as I got this done I will try to create a first draft for discussion.

  39. Alacer has joined

  40. COM8

    Mattj: Yes, since they have been revoked/deferred I started working on this.

  41. MattJ

    revoked and deferred are two very different things

  42. MattJ

    "deferred" just means they haven't been updated for a while, and nobody tried to advance them

  43. MattJ

    I don't think that's good enough reason to just do the same thing again

  44. MattJ

    a while == 12 months currently, iirc

  45. flow

    MattJ, are you sure that its the same thing? :) Also if someone feels like it, why not?

  46. flow

    I don't think much is salvageable from the existing XEPs, actually I can only think of one thing

  47. MattJ

    "why not?" => it's a waste of time just to gain 4 more XEPs that will be also deferred in 18 months from now

  48. COM8

    Also they were focusing more or less on automatisation/handling for large scale IoT networks and didn't had the simple enduser in mind. I want to define an XEP which lets enduser Bob register and handel his smart lightbulb/thermometer/... and control all of his devices in a way that is as simple and secure as possible.

  49. MattJ

    To be clear: I'm not against new XEPs, the old ones have plenty of issues

  50. MattJ

    But I think you need a clear objective that sets the new XEPs apart from the old ones

  51. MattJ

    COM8, people are already controlling light bulbs over XMPP, just ask ralphm

  52. MattJ

    Accomplished by registering a user account for a bot, and sending the bot a message

  53. MattJ

    We already have registration mechanisms in XMPP

  54. MattJ

    Why does IoT need something different?

  55. flow

    MattJ, well, even if they get deferred, there is probably a leasson learned or two, potentially only for COM8, but still

  56. flow

    MattJ, one issue that XMPP is missing is access control

  57. flow

    how do you set ACLs for your lightbulp?

  58. flow

    *lightbulb

  59. MattJ

    flow, by making the bot only accept requests from users on its roster

  60. flow

    MattJ, that is what I have for coarse grained ACLs in mind

  61. MattJ

    and the bot can manage its roster however it wants

  62. flow

    but how do roster entries get added and removed?

  63. MattJ

    How do ACL entries get added or removed? :)

  64. COM8

    Mattj: That is exactly what I do not want. I don't want an interface that is text based. I want that the device to provied a XEP004 based form where the user can change the color, brightnes, ... via a slider, color picker, ...

  65. flow

    Well we don't have a generic standard for that, that's the point i guess

  66. MattJ

    COM8, ok, so ad-hoc commands already exist, you're done :)

  67. flow

    and i think a generic standard for this would be benefical

  68. MattJ

    https://xmpp.org/extensions/xep-0050.html

  69. MattJ

    The gateway/bot can expose any commands it wants to, and serve forms

  70. MattJ

    And best of all: many clients and libraries already implement this

  71. flow

    MattJ, now some entity requests presence subscription from your thermometer, so that it can read its value. How does the thermometer forward the request to the owner of the thermometer?

  72. flow

    I aggree that existing building blocks should be used whenever sensible

  73. flow

    and it is probably sensible in most cases

  74. MattJ

    flow, https://xmpp.org/extensions/xep-0060.html#subscriber-subscribe-approval

  75. flow

    MattJ, so the full JID of the thermometer becomes a pubsub service?

  76. MattJ

    Why not the bare JID, which already is?

  77. flow

    that works for the pubsub case, but what if I want to pull the data?

  78. MattJ

    You can pull from pubsub

  79. flow

    live data, which some extra metadata what and how it should be pulled

  80. MattJ

    or you mean, you don't want the device to push to pubsub at all?

  81. flow

    i.e., when you don't want to talk to a pubsub service on the bare jid, but with the device itself via the full jid

  82. flow

    MattJ, it depends on the use case i'd say. Sure, for something like temperature, pubsub would be nice for most use-cases

  83. flow

    but there may be uses cases where you have to directly talk to the device

  84. MattJ

    https://xmpp.org/extensions/xep-0244.html may fit then

  85. flow

    for example because you don't want to read out a sensor, but talk to an actor

  86. flow

    not sure about xep244, I never understood or forgot the advantage over plain ad-hoc commands, but yes

  87. COM8

    Mattj: Yes, I know and I also do not want to reinvent the wheel again like it has been done in an earlier iteration. I want to use existing stuff where ever possible and define a simple and standartised way so every enduser even Bob how does not know what XMPP is and just want's to manage his stuff without having to send text messages with an exact sytax you allways have to remember/ look up

  88. MattJ

    COM8, so what will Bob use to interact?

  89. flow

    Also going back to https://xmpp.org/extensions/xep-0060.html#subscriber-subscribe-approval: First you said: use the roster, and then you came with pubsub. What is it now? ;)

  90. MattJ

    flow, I'm not claiming to have a specific solution, but I'm also not the person planning on yet more XEPs

  91. MattJ

    and I'll repeat: I'm not against new XEPs, if they're clearly needed

  92. MattJ

    I'd be happy to see gaps filled

  93. MattJ

    What I'm doing it throwing out proposals for reusing existing stuff, and if there's reasons they don't fit, that helps clarify exactly what is needed

  94. MattJ

    But when you tell me you just need an ACL, and we already have the roster being successfully used as an ACL in multiple situations already, I have a duty to point that out :)

  95. MattJ

    and it's very simple to implement, and widely supported

  96. MattJ

    So a XEP that allows delegated authority to approve roster requests may be all that is needed

  97. MattJ

    I live and breathe XMPP, and have done for a long time now. I also love IoT, and have far more home automation set up than the average person

  98. MattJ

    and yet I don't see a clear fit for XMPP into any of the stuff I've done

  99. COM8

    mattj: Yes that is the question! We have to make it as easy to use for endusers and as easy as possible to implement so everybody jumps ontop of our bandwagon. That's what I hope to archive with my XEP. A XEP that describes the process starting from pushing a button on the IoT device over scanning it's QR Code for registering it on your XMPP server. And once the device is registered how can a user manage and access the device. On top of that we can extend stuff like connecting it to ITTT, ... I'm not aware that any existing XEP describes this.

  100. Tobi has left

  101. Tobi has joined

  102. flow

    > MattJ> So a XEP that allows delegated authority to approve roster requests may be all that is needed see topic of this MUC :)

  103. MattJ

    flow, perfect :)

  104. MattJ

    COM8, I think you need a bit more incentive to get people on the bandwagon

  105. MattJ

    Ease-of-use is about UI/UX, and can typically be done on top of any protocol, HTTPS, MQTT, etc.

  106. MattJ

    and given that XMPP won't run on many microcontrollers that can handle CoAP or MQTT, manufacturers probably aren't going to jump on it fast either

  107. MattJ

    It may be a good fit for a hub/gateway device, but they can just as easily speak HTTPS/MQTT, which are already widely supported

  108. MattJ

    I'm not really trying to discourage you, I'm actually trying to help you think about what problem you are trying to solve

  109. flow

    I do believe that there should also be a fine grained ACL mechanism, which puts the ACL in a PEP for the devices nodes (N.B. not talking about pubsub nodes here, but "xep30" nodes)

  110. MattJ

    So you don't waste your time

  111. COM8

    Yes and I'm really thankful for that. That's why I'm in here to discuss with people and see how they look at this stuff.

  112. COM8 has left

  113. MattJ

    Here's the way I see things. For a general end-user smart-home situation (which is what I think you are targeting), you have a handful of devices with different roles

  114. Alacer has left

  115. Alacer has joined

  116. MattJ

    You have the device (e.g. a light bulb), a gateway (optional), a hub (also optional), and a controller (e.g. a phone or hardware control of some sort)

  117. MattJ

    Many IoT devices do not speak TCP/IP, or connect directly to a LAN - typically because of power constraints, microcontroller resources, wifi reliability, etc.

  118. MattJ

    So they will use Zigbee, Z-Wave, or something similar to communicate with a gateway/bridge device

  119. MattJ

    So there is no room for XMPP in this part of the stack

  120. MattJ

    Also this part of the stack is typically controlled by a single manufacturer, so doesn't necessarily need to be open, or is already based on an open(ish) standard such as Zigbee, Z-Wave or BLE

  121. MattJ

    For devices that don't need a gateway, but e.g. connect directly to wifi, you'll still generally find them using microcontrollers that are not capable enough to run XMPP

  122. MattJ

    and those devices tend to connect to a manufacturer's proprietary cloud anyway, so the manufacturer doesn't care about interop here

  123. MattJ

    Ok, so then you have the next layer: communication between a hub or controller and the gateway

  124. MattJ

    XMPP /could/ fit here, but why? It necessitates an extra piece of infrastructure (an XMPP server), and I don't see the gain

  125. MattJ

    I certainly don't want to depend on public XMPP services for turning my lights on/off, and neither do I expect everyone to run their own server (separate to all the stuff they'd already have)

  126. MattJ

    You could make the hub be an XMPP server, but again, I'm not sure of the benefit there

  127. MattJ

    That leaves communication between the hub and controlling device - would both need to communicate via an XMPP server instead of directly?

  128. MattJ

    Latency also becomes an issue

  129. MattJ

    If this is stuff you've already thought about, I'd love to hear your thoughts

  130. MattJ

    If not, hopefully it provides you something interesting to think about

  131. Tobi has left

  132. Tobi has joined

  133. Alacer has left

  134. Alacer has joined

  135. Alacer has left

  136. Alacer has joined

  137. Alacer has left

  138. Alacer has joined

  139. Alacer has left

  140. patrik has left

  141. patrik has joined

  142. patrik has left

  143. Tobi has left