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 service. 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 lets take a look why it is not here yet.
The reasons for diversity
Why would a standard be good? So, the devices can easily connect to other manufacturers devices. You bought a NetAtmo weather station. Do you need a thermostat of the same company or will a thermostat of another brand work with the NetAtmo forecast? Why does a radio-controlled thermostatic valves need other radio interface and why can’t the box, managing the video camera system, also do the valves management? However, these cameras are not connected with an electronic safety system of other brand.
There are valid reasons.
Business problems: 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 that is just a myth. They do, and very often, when they can, they go as far as the law will allow them. Smaller companies can’t do as the bigger ones 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 camera in the security system, sending picture just in case of emergency. And there are even sensors sending lots of data all the time, for example video cameras in security systems, which send almost the rate of the data on the internet. Take into account also the fact that some are used on a short distance, while others are used for longer distances and some need to emit the signal for hundreds of meters or more. Therefore more frequencies are used, not only 2,4GHz, but also 433 and 868 MHz range.
Sensor transmitter and Homebase of Energomonitor.
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 ones also. 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 “profiles”. In fact they are independent radio protocols. The costs for running and identification of more protocols at once are not negligable. You need much more powerful hardware, which is not very pleasant in the IoT architecture (because of dimensions and price), or because you need more power and therefore the battery life suffers.
That is our issue at Energomonitor, too. We employ an older radio protocol C2 (used by Current Cost before they bancrupted and moved in to the new Current Cost company in Hongkong) 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 the IoT included in the WiFi router and being able to operate all the interconnected devices. Nowadays you need to have a different gate for every device of one manufacturer, which is not practical.
The gate is not only a receiver of the 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 gate 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 sensors manufacturer should support as many “appstores” 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 I wrote an another article about it.
That is not something the 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 the manufacturers. Some other companies, including IBM, are also working with a different progress and level of seriousness for this coquetry. 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 increase in performance, will solve lots of problems during this time.
Borders of IoT philosophy
My last topic is the philosophy itself. In fact, the great technological interconnection of the IoT world is not important. Gathering the data about the 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 components of IoT. Geeks are leading the demand but they are not a customer group that would be interesting in long term. Therefore a single standard for IoT is still a matter of dreams. There would be several partial solutions, practices and procedures, widespread and maybe even widely accepted in a group of sensors (as KNX in automated parts) but there will be lots of reasons to use the proprietary solution.
What is important for user is the extent to which will the solution perform as promised…
You will find more about IoT and Energomonitor on our Medium blog Technology behind Energy Efficiency, Facebook, LinkedIn and on Twitter.
Originally published on Medium on February 10, 2016.
