XSF logo 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