Hi, Do you know if an open-source standard exists for things?
Transport layers:
I see that IPv4 and IPv6 is the raising standard.
Bluetooth, etc…
LoRa - LTE-M - Sigfox are interesting long distance protocol.
You often have a device that link IPv4 (or 6) and other transport layers.
Distribution Protocol:
I see that many devices use a local multicast address (I haven’t seen any standards). [If you want to test: you can use mtools].
As an example: 224.192.32.19 on port 22600 (for theowl intuition).
Some companies have registered a port on iana.
MQTT is a “rising star” too.
Communication format:
I see the following standard: xml, binaries, json
Format description:
XSD (xml description) is one of the standard I saw.
So my question:
Do we have a “vanilla” standard we can support (or we support)?
As an example if I build my own “connected power plug” arduino’s based, my personal temperature module:
Do I have an open and standard way to share the information that my energy is : xxx on channel 1, etc…
I mean if I connect to a multicast ip, on a specific port, other tools will be able to receive and understand my call without having to redevelop a plugin
Nothing exists or a lot exists, depends on your perspective. The idea is at the moment to have a convention on top of Mqtt like Homie. Mqtt is TCP based and SSL is not that simple for Microcontrollers, therefore Mqtt might not be a solution for a secure device.
The other protocol that gets a lot of attention is CoAP (not only due to IKEAs Tradfri smart bulb hub). On top of CoAP there is LwM2M which perfectly describes all kind of devices. It is UDP based and uses DTLS to optionally secure the connection.
Regarding the physical layer:
Bluetooth somehow didn’t make it into the smarthome section. That’s probably because it doesn’t support mesh networks and only 1 on 1 connections. Zigbee, ZWave and LTE will do the race if you ask me.
Nothing exists or a lot exists, depends on your perspective.
I totally agree in fact. So many technologies exists, so many different standards - but no “standard” or “white label” solution.
Why don’t we have a binding in openHab that support all “standards” modules “out of the box”?
As an example I want to develop some opensource modules on top of LoRa and connect them to openHab2.
It means:
(1) - I have to build my own communication protocol to transport information between LoRa modules and LoRaWan. ← Often an embedded system. (How do I send the value? as an int, as a char, encryption key and channel?)
(2) - I have to build my own communication protocol to transport information between LoRaWan and openHab2 (could be using mqtt, or another protocol). Should I send “comma separated values on mqtt”, other? )
(3) - I have to build my own plugin in openHab to be able to understand this protocol.
If (2) is able to share information using a “standard way”, I don’t need to implement (3) - and it will support more plugins that just openhab and smarthome.
If (1) is able to share information using a “standard way”, I don’t need to implement (2) - and I’ll not need a specific “lora receiver” for each “brands” of lora product.
Note: I’m not linked to a company, so no strong “ownership” of my code or protocol.
Note2: Agree with SSL… and often we disable on these modules what makes SSL useful (I mean the verification of the certificate authority).
No. The IoT industry is hopelessly fragmented right now. There is no one standard to rule them all.
While there is no standard, the most common approach in this scenario is to publish JSON on MQTT.
It depends on how your device bridges to TCP/IP. If it directly on the WiFi or wired Ethernet network then yes, SSL/TLS is hard for these devices to manage. If you are using something like an RFM69HW for wireless communication the RMF69HW libraries do support encryption. Then the gateway that bridges between the wireless to TCP/IP can handle the MQTT SSL/TLS.
The rai·son d’ê·tre for OH is to bridge between all the standards. But there are literally hundreds of standards, many of which are not even internally compatible (e.g. two Zigbee devices are not guaranteed to work together even though they both implement the Zigbee “standard”).
It is frankly an impossible thing to develop. The fact that OH has found a way to bridge between 200+ technologies, standards, and APIs is actually quite impressive. I can’t think of any other solution that supports as many.
Since LoRa is a wireless protocol and OH is software I don’t see how OH could support anything else. However, if there is a standard LoRaWan USB dongle with a serial interface (e.g. like Zwave), or a LoRaWan server with an API (e.g. Zway binding) then any of the following are possible depending on the interface:
Serial Binding
HTTP Binding
Exec Binding (to run command line scripts to communicate with the device
TCP/UDP Binding
Write a custom LoRaWan Binding
Absolutely not. If you have some way to get the LoRaWan stuff to a gateway of some sort, which you may need to write if you can’t/don’t do 1., then use an existing protocol to publish the data to OH. Like I said above, MQTT is the most commonly used, but making REST HTTP calls directly to OH is also a popular approach. Though UDP/TCP is also possible, but would probably take more effort on the OH side.
If you do step 1. then you may need to write a new binding if the existing bindings are not going to work to receive messages directly from the LoRaWan. If you do step 2, you may need to write a gateway to receive the LoRaWan messages and publish them to OH in some standardized and existing manner.
I do exactly this with my RFM69HW devices:
Arduino wired to an RFM69HW device publishes a message (temp, humidity, and telemetry data) using a standard RMF69HW library
A RPi wired to an RFM69HW receives the message using a Python script I wrote (about 40 or so lines of code), parses it out of the binary structure using a standard RFM69HW library, and publishes the data using MQTT. I chose to publish each piece of data to a separate topic but one could just as easily encode the message as JSON and publish to a single topic.
OH has an Item for each piece of information published bound to the given topic. I don’t need to implement anything at all in OH beyond using the existing MQTT binding.
But this is, if I’m not mistaken, a physical issue caused by the fact that each lora receiver works differently (different APIs, different waveforms, different wireless protocols, etc). There is nothing OH, which is just software, can do to solve that problem. If there is some sort of lora standard for receivers and/or there is a standard API then it is possible for someone to write a binding to support LoRa and the only real problem is that no one has chosen to do so yet.
Bluetooth somehow didn’t make it into the smarthome section. That’s probably because it doesn’t support mesh networks and only 1 on 1 connections. Zigbee, ZWave and LTE will do the race if you ask me.
Bluetooth Low Energy 4.0 and later versions actually support mesh networks as an optional feature since 2016, the only issue is that for some reason there are nearly no devices on the market implementing it yet. The only one I heard of is this one. Maybe 2018 will be the year where Bluetooth will start into the race. I think it’s very attractive for manufacturers as it makes it possible to sell the very same product as a smartphone gadget as well as a smart home device.
