The fairy tale about a single standard for the Internet of Things
Standards are good. They allow the prices of products to go down quickly, they eliminate the fear of buying something that will not be compatible soon, and they lower the price of services. In a nutshell, standards speed up the adoption of new technology and lower its price. This is crucial. It is not a surprise that the IoT mantra is “we need a standard”. And I agree we need it — but let’s take a look why it is not here yet.
The reasons for diversity
Why are standards good? So that different devices can easily connect within other manufacturers ecosystems. You bought a Netatmo weather station. Do you need a thermostat from the same company or will a thermostat of another brand work with the Netatmo? Why do radio-controlled radiator valves need to use a different radio interface and why can’t the box managing the video camera system also perform valve management? There are valid reasons.
Business problems: The struggle for domination on the market
I am going to discuss the business reason just briefly. Companies want to dominate the market. When their format becomes the de facto standard, they get income from patents; they can shape the market according to their wishes and even block the entry of competitors. You may think that modern online companies do not behave this way, but then you would be misinformed. Why is it so hard to perform a Google search with Amazon Alexa? They do, and very often, when they can, they go as far as the law will allow them. Smaller companies generally don’t succeed at this because they do not have the necessary size and budget.
Technical: the demands are quite heterogeneous
There are also technical reasons. A standard would need to be in fact very complex, including not only the radio and cable communication, but also the application interface. The fact that there are several radio interfaces is caused by different needs. Some sensors send very little data, with a low frequency: a sensor for a door opening transmits its state only several times a day. Others send very little data very often: a sensor for the electricity meter sends a signal once every 1–90 seconds with several kB of data. Others sensors send a lot of data but not very often — i. e. wireless cameras in a security system that send pictures only in case of emergency. On the other side, there are sensors sending lots of data all the time, for example CCTV cameras in security systems, which depending on resolution, send at a very high bitrate. Take into account also the fact that some are used on a short distances, while others are used for longer distances and some need to emit the signal for hundreds of meters or even multiple kilometers in the case with LoRa. Therefore more frequencies are used, not only 2.4 GHz, but also 433 and 868 MHz range.
The solution is “simple”: create a universal radio protocol for all those uses. Zigbee tried this approach but with a lot of limitations. The biggest limitation was the financial one: license fees. But there were lots of technical limitations imposed as well. Other protocols, which are planned or suggested in Bluetooth, WiFi, or Google Thread, are just conglomerates enveloping several protocols (Bluetooth vs. LE) under one name and “profile”. In fact, they are independent radio protocols. The costs for running and identification of more protocols at once are not negligible. You need much more powerful hardware, which is not ideal in IoT architecture (because of dimensions and price), or because you need more power and therefore battery life suffers.
This was an issue at Energomonitor, too. We employed an older radio protocol “C2” (used by Current Cost before they bankrupted and moved in to the new Current Cost company in Hong Kong) and our proprietary Chirp which is better, more robust, etc.
Enabling them concurrently is painful, the device needs to detect and wait. It lowers the performance and brings no real profit. We decided in the end not to implement them both, we use only the newer one and if somebody needs to use the device within an older network, we equip the device with the older protocol.
Missing application interface
Last, but not least a very important issue is letting the gateway know what to do with the data from an unknown device. It sounds awesome, to have a gate (or “edge router”) for IoT included in the WiFi router able to operate all the interconnected devices. Nowadays you need to have a different gateway for every manufacturer, which is not practical.
The gateway is not only a receiver of data through the radio interface; it also processes the data and sends it onwards to the internet. In the case of Energomonitor, the data from the sensor the gateway registers is encrypted and forwarded to our servers, through the older internal protocol or standardized MQTT. It is embedded in our firmware and it is not easy to make it happen without it. I can imagine an “Appstore” for different routers that can let you use the Energomonitor app which would offer the same functionality. There are several issues, though. The sensor manufacturer should support as many “app stores” as the router suppliers (they won’t agree on a standard in the near future), it should be tested extensively. The most data compact sensors of Energomonitor send the data once every second. How do you want to make sure that this is done by a router fulfilling other tasks that our coders are even not aware of?
We are leaving the world of single-purpose devices and entering the realm of full-fledged embedded operating systems and problems, which their servicing and developing for real-time systems involves — it is called “edge computing” and we wrote an another article about it.
That is not something small teams in IoT can afford. There is some progress, though. Google and Samsung are developing their proprietary IoT operating systems focused on parallel running of several different tasks and bridging manufacturers. Some other companies, including IBM, are also working with a different progress and level of seriousness for this endeavor. There will be so much happening in this field, but who wants to sell today needs to stay with the tested and proven — single-purpose devices with a low price. Organic technological development, including the lowering of hardware prices and increases in performance, will solve lots of problems during this time.
Borders of IoT philosophy
My last topic is philosophy itself. In fact, the great technological interconnection of the IoT world is not important. Gathering the data about energy consumption is a different task than telling the blinds to lower themselves or gathering camera and security sensor data. It is difficult to find a simple and beneficial concept, which would need such an interconnection. Of course, it is possible to lower the blinds every time when the lights in the living room are turned on — but why? If you want to do this, you can do it manually. If you want to solve this problem, you should be interested in data interconnection, when you take a state of one system (light control) and forward it to another system (order to lower the blinds). For this purpose you do not need to connect the device on the hardware level, but with an API bridge, as offered by IFTTT or Zapier.
Business rules
What is the decisive factor in the end? The business suitability of the chosen solution. Nowadays there is a shortage of real customer scenarios, which would justify a bigger integration of IoT components. Geeks are leading the demand but they are not a customer group that are interesting in long term. Therefore a single standard for IoT is still a the stuff of dreams. There will be several partial solutions, practices and procedures, widespread and maybe even widely accepted in a group of sensors (as KNX is in automated parts), but there will be lots of reasons to use a proprietary solution.
What is most important for the user is the extent to which the solution performs as promised…
