Thoughts After CES 2019

CES 2019 at a Glance

Every year we make our way to CES (Consumer Electronics Show) in Las Vegas for the annual consumer electronics exhibition. Imagine over 4,500 vendors presenting new ideas and technological developments spread across an entire week — it really does give a whole new meaning to the city of lights. CES presents a great opportunity to meet like-minded individuals in similar fields, or different, helping catch new ideas, contacts, and ideas – it’s wonderful here.

The history of CES began over 52 years ago with organizers showing more progress each and every year. With the main theme being innovation and information technology, the width of coverage is vast:

  • Robotics,
  • Artificial Intelligence,
  • Three-dimensional Printing,
  • Design,
  • Drones,
  • Sport Technologies,
  • Smart Home,
  • Family & Lifestyle,
  • Virtual Reality (VR),
  • Games,
  • Unmanned Vehicles,
  • Music,
  • Entertainment & Content,
  • Cryptocurrency,
  • Internet of Things (IoT),
  • and Machine Intelligence.

 

All About IoT

The beginning of the year confirmed that IoT is coming to the mass market.  Focus has shifted from smartphones to other smart devices — and manufactures are taking notice.  Improved air quality sensors, door positions, windows, just to provide a few quick examples.  There are even smart window systems being developed that can inform the home when a window is opened wider than an indicated gap, for example.

Consumers can now choose between a wide variety of smart devices and systems, putting real pressure on manufactures and companies to advance smart home ecosystems. But the problem doesn’t just end there. Consumers need a way to connect many different smart devices to a single system – easy management.  This is where Zigbee and other wireless technologies flex their strength; gateways with multiantenna and customization service suggestions come to the rescue.

Hi Computer, Talk to Me

Voice automation control becomes more the norm than the rarity.  It falls into many devices and almost everyone has them now. People want to have a voice assistant in their home, in the office, and in the car, like Jarvis from Iron Man. Project recipes from the Internet to the kitchen door by voice request?  Yes, please!  Yet, even Alexa from Amazon or Google-assistant do not always suit as a compromising option.  Artificial intelligence is poised to grow wiser and communicate with people better and faster.  Companies that once winced at the idea of software in their products are now flocking to CES.  For example, Procter and Gamble – L’Oreal, are developing mirrors that can look at your face to determine if your skin needs support or treatment.  Maybe just a care cream?  Cameras take pictures of the users face and follow changes of the face in real time.  Maybe they’ll even notice skin cancer in due time.

It is interesting that companies that are seemingly far from “software” come into the sphere of technology.  These companies expand the development zone to such wide branches like automation for pets, children, sleep, and beauty.  There are even smart leashes and collars!  People even get interested in buying devices that can distribute pleasant smells throughout their homes.  And what if you could connect a device that could command three-dimensional TV? Cars? Batteries? Spotify on your steering wheel?  The ideas and possibilities are endless.

Robotics help businesses change their models.  It is especially gratifying that companies competing in the past are starting to cooperate.  To denote such activity, the new term ‘coopetition’ has appeared.  ‘Coopetition’ should bring even greater breakthroughs in overall development.  Teamwork gives rise to new achievements.  SDKs help bring the product to market.  Quick starts are real.

Meet & Talk

DSR had a lot of productive meetings with existing and prospective clients and it was the most successful CES to date. DSR was also a proud  sponsor of the Zigbee Alliance Social – an invitation only event that was a great opportunity to bring all of the members together in one location and celebrate Zigbee successes from 2018. During this event, Zigbee Alliance announced several of the new developments and expansions of the standard and also unveil the location of the next member meeting. The atmosphere for the event was very warm and inviting and perfect for conversations and celebration.

In Closing

Here are seven key CES 2019 takeaways that caught our attention:

  • IoT is finally an emerging mass market (and the data it gathers has lots of financial implications)
  • Amazon and Google are in “hand-to-hand combat” driving voice technology into the Smart Home and beyond
  • 5G, NB-IOT and Cat-M1 are expanding battery-powered WAN connectivity in amazing ways
  • Drones—from airborne to underwater to John Deere—are becoming platforms
  • Robotics are creating business change
  • Artificial Intelligence is getting smarter
  • “Coopetition” is happening in lots of places

IoT is moving capabilities out of smart phones and into different smart things. People want their homes, cars and offices to have a voice like Jarvis (see the Ironman movie franchise). And not everyone wants Amazon Alexa or Google Assistant as the go-between. Battery-powered WAN connectivity in a variety of speeds is making the cloud easier by “losing the gateway.” Drones and robotics platforms are giving new capabilities to businesses and consumers. Artificial Intelligence (“AI”) is changing the way products and services interact with humans. And if Apple and Samsung are teaming up, is it time to evaluate how “coopetition” might help your 2019 business goals?

What is Dotdot?

What is Dotdot?

A bit of history — the creation of Zigbee standard required a lot of effort, time and knowledge to construct. Dotdot is an alias for ZCLIP, which stands for Zigbee Cluster Library (ZCL) over IP. It is about exposing ZCL functionality to the IP world, in contrast to classic Zigbee that is always isolated from IP networks and requires a Zigbee gateway to connect Zigbee mesh with the outer world. This would become a bridge between IoT and other networks. Different manufacturers have Zigbee Gateway solutions mostly for connectivity of Zigbee network with cloud.

In classic Zigbee there are all instruments for organization, self-organization, restoring and stability of the network. Above all of this sits the Cluster Library, which calls functions allowing the clusters to communicate. Although, there is one short fall with this system – it cannot get online. With ZCL exposed to IP, it becomes possible to establish a direct communication channel between Internet/Intranet application and Dotdot device when border device remains transparent for and unaffected by the details of communication. The same way communication between Dotdot devices located on different networks is also possible under condition that device services are properly advertised across network borders or devices appear bound by means of a third-party application.

New Language: Old Terms, New Sense

Dotdot is a standard that allows you to put ZCL on any “rails” other than Zigbee – WiFi, Thread, and so on.  This is an add-on for Zigbee.  An application level protocol that allows smart devices from closed networks (with addresses) to communicate more openly through the address space that is on the Internet and other networks.  It is important to not just reach the device itself, but also to address the command to a specific cluster within, and do so securely.

 

Figuratively, Dotdot receives commands in one language and translates them into a language understandable for smart devices.  This makes smart devices ecosystem more open.  Dotdot uses the Zigbee approach in ZCL and has extended it to other types of transports as well. The mesh built for some Dotdot solution deployments is not mandated to contain only Dotdot-compatible devices.

The Commissioning Application

The Dotdot commissioning application was developed next to and based on Thread that was taken from the official Thread Commissioning App mostly as is, courtesy of the Thread Group. The application allows managing the expansion process of the Dotdot network. Seamless integration of the parts and stabilization of Thread for both mobile platforms was also performed.

This application allows third-party devices to enter, which is critical for maintaining network security.  The top layer works with Dotdot enabled devices over Thread. Thread is responsible for commissioning new Thread enabled devices to the home network and discovering devices that are already there. Dotdot makes use of device lists from Thread and as a result uncovers Dotdot enabled devices and their services. The system interrogates the device, finds what services and clusters are running, on which endpoint, and which commands support the device, allowing for a complete picture of the device’s capabilities.  Once this is completed, you are able to change the attributes and send commands from the application itself.  There are clusters, attributes, bindings and reporting.

Why Should Companies Implement Dotdot?

Speed. Abstraction. Interoperability. Dotdot provides the opportunity to create applications in a more flexible way. This is because Dotdot solutions use “generic” border routers that are standard, easy replaceable even at run time, and are not a “single point of failure.” The same data model is provided for different IoT technologies, despite what protocols are used to send data (WiFi, BLE, Zigbee, Thread, and so on), this means there is a wider market for solution spread. You can create a wider IoT system where all the devices understand each other. This creates an easier entry point for companies to develop solutions and allows application developers to focus on the application and functionality, without delving into the underlying specifics of a particular wireless network.

How to Get Started

  1. Download an SDK from a company that provides the solution.
  2. Study the provided API and Zigbee clusters description. Find the needed clusters and start own device (certified by Zigbee Alliance) implementation.
  3. Gain access to the Dotdot Commissioning Application.
  4. To accelerate your development, engage a company with experience in Dotdot and wireless technologies.
  5. Lastly, consider becoming a member of the Zigbee Alliance (if you are not already) to get access to even more tools and become involved in the development of IoT standards.

CES 2017 Impressions

Every year CES is the culmination of the latest and greatest in technology and invention. From TVs to cars, cellphones to virtual reality, industrial grade hardware to watches and players, everything is competing for consumer attention and it’s barely possible for a person to see everything displayed. CES 2016 was all about TVs, virtual reality and drones. 2017, while still following last year’s trend, moved towards the Smart Home, Smart Appliances, and Artificial Intelligence (AI). The entire IoT industry was there: starting from end-to-end solutions to wireless connectivity chips and platforms. This includes the well-positioned ZigBee Alliance booth, which included the products showcase powered by DSR with an impressive 105 products from 30+ companies for both Residential and Commercial markets.
CES2_1
This was the largest wireless ecosystem display in the entire show and is a true testament to ZigBee interoperability and presence on the market. The devices in the display were connected to DSR’s zHome IoT cloud and mobile apps, working through DSR’s low cost gateway. 
 
CES1_1
The discussion and questions at the ZigBee Alliance products demo were mainly around the gateway and ecosystem. The impressive wall also raised some questions if the products all truly  function together and they do. The impression from previous shows is that consumers as well as installers have experience with a mixed bag of installation and controls. Providing a single display demonstrated a cohesive and diverse ecosystem of interoperable products.
 
CES3_1
 
 
Some other interesting observations from the IoT/Smart Home space showed that Data and Security applications are as relevant as ever. Voice control, driven by the major push in AI is gaining major traction, with Alexa embedded in Echo leading over Google Home. The start-up area is always full of new and reinvented ideas, including speaker products, data analytics, energy consumption profiling, health sensors and apps, analytical mirrors, security and nursing products. Finally, a visible expansion in child caring and monitoring beyond the standard baby monitors and cameras are looking to address the growing needs and demands of the market and modern day parenthood. 
 
To conclude, CES 2017 was as big as ever and full of new, amazing, and improved. DSR was excited to be part of the experience and to also represent the products demo wall at the ZigBee Alliance booth, making it the largest display of products from different companies working together via a single protocol in one space. 
 
For more information about DSR products and services in IoT, please visit www.ioticity.solutions and www.dsr-zboss.com.

To Mesh and Beyond

Not too long ago Bluetooth® SIG announced that Bluetooth® is going mesh, giving a rise to a new wave of interest to Mesh networking. Although the interest is growing rapidly, solutions available on the market keep using just the trusted star topology. But what are the real possibilities?

Mesh, Ad hoc and MANET

Most networks on the market are declared to be “mesh ad hoc,” so in most cases these terms are used together in turn blurring the difference between them. But there is a difference and it’s important to highlight it.

Mesh network is a kind of a network topology where all the possible connections between nodes are established. This leads to the main mesh network feature – self-healing, where broken routes can be restored using different access links between devices.

Ad hoc network is a decentralized wireless network that does not require any infrastructure to form and maintain. Nodes connection depends on its possibility. This network is self-configuring, which means that devices can join or form it on the fly.

In this way, mesh network is the most robust static type of ad hoc networks. But when both terms are used together, they typically mean ad hoc only. Mesh explains just the physical layer of wireless communication that is broadcasting from its nature where all devices that are close enough hear each other (i.e., connected) and form enough links for self-healing. To be completely accurate, it should be mentioned, that “ad hoc” means that the nodes are stationary. There is a term for mobile nodes – Mobile ad hoc networks (MANET’s). But today in PAN/LAN context (Wi-Fi, Bluetooth, ZigBee) nodes are assumed to be static due to their use cases, even if they can be moved sometimes from place to place.

Wi-Fi

Wi-Fi is an area that already has ad hoc solutions available through documents and open source. Official specification IEEE 802.11S is the less effective and innovative one. It introduces two new kinds of devices: Mesh portals and Mesh points. Mesh portals are ordinary Access points with wired connection to the Internet. Mesh points act as wireless routers between stations and portals. Everything that has “mesh” prefix is connected together where it is possible. The standard is completely the same as B.A.T.M.A.N. adv Wi-Fi mesh that is already included in the Linux core.

In parallel, open source community works on cjdns (Hyperboria) that is a real candidate for the DarkNet set of protocols. Cjdns is developed in the way to create a wireless mesh network that is totally disconnected from the Internet. Its core advantages are:

  • End-to-end encryption
  • Tunnels between segments over the Internet
  • Decentralized generation of IP addresses

The last one is a headache for all Wi-Fi ad hoc networks. Old DHCP conflicts with the essence of the ad hoc network and mobility.

Mesh networking using Wi-Fi sounds ready but not for small low-power devices. Thus, we better pay attention to Bluetooth® Low Energy (BLE) and ZigBee®.

Bluetooth®

The first thing that Mesh-network-sceptics say about Bluetooth® is that it was not designed for Mesh networking. However it is widely spread, so why not to try using it?

Existing solutions on BLE are nothing more than trying to sell things that we already have in ZigBee® under the “Mesh network” label. To build a “mesh” the customer should buy a BLE gateway that forwards packets to the cloud. All main-powered BLE devices act as routers and interconnected with each other, while battery powered devices talk to routers only. Nothing special.

But BLE wins in that it is already in devices that have the Internet connection through 3G, LTE, Wi-Fi, and even the cable. That means that in theory the customer can get more than one gateway connected by the Internet. Moreover, customer’s tablets and smartphones bring the mobility to such network.

The power of the Wi-Fi + BLE collaboration has already been explored by Apple: check out the Multipeer connectivity framework for iOS 7 and, for example, FireChat application that proudly announces “Internet is not needed to chat.”

ZigBee®

When talking about ZigBee® one thing should be kept in mind – it was initially designed to be ad hoc. The routing mechanism implemented in ZigBee® is called Ad hoc On-Demand Distance Vector (AODV). Although RFC is operating IP frames, there are no major differences. The algorithm is quite simple for CPU and gentle to ROM and is available even for a bulb or smart socket or any other main-powered device.

As it was mentioned earlier, ZigBee®-based systems on the market currently prefer to use star topology, even though it has everything to be a mesh network and should be used as such. When Wi-Fi or BLE implement mesh, it is not only a technological step forward, but a marketing reason. The truth is ZigBee® is already a step ahead in terms of technology, but maybe a step behind in terms of marketing.

One might mot like that ZigBee® network is not using IPv6. Well, neither does BLE, but it does not disturb it. Nevertheless, there is IEEE 802.15.4 + IPv6 + UDP solution called 6Lowpan and Thread or JupiterMesh built over it. Though they haven’t still made a splash on the market, probably nobody has positioned them as “mesh.”

As we can see, if the market wants mesh/ad hoc/MANET, there are all the pre-requisites for it. It is already around but the customer is not aware of it because either the market is too “shy” or that field has not yet been covered in depth. Anyway, the results will come soon and they will come from Wi-Fi, BLE, ZigBee or even a collaboration between them.

Keep Calm and Implement ZigBee Security

At the end of last year, a group of researchers from Cognosec presented their “ZigBee exploited” report at the BlackHat conference in the USA. They demonstrated a tool that allows an intruder to open your doors, shut up motion sensors off and even turn the lights off in your bedroom, of course only if these devices are controlled via ZigBee. IT and for the most part non-IT sources repeated the news many times with excessive drama effect and as a result, we had got a categorical accusation of lack of security in ZigBee and even the entire IoT. Based on the forecast that there will be 29 billion of IoT devices in the not so far 2020, “experts” convinced their readers that it is not the problem of the future but the present and that all devices are vulnerable. Now when the panic has calmed down, let’s see what happened in terms of ZigBee.

First, let’s talk about silent motion detectors. Motion detection in the system that was hacked works the following way: when a sensor detects a movement it sends a ZigBee message to a gateway (you may call it smart hub, ZigBee hub, etc.), which uses TCP/IP to deliver this message to the user. Cognosec researchers used a jammer to break the ZigBee link between the sensor and the gateway. Even when the jammer had been turned off, the motion alarm was not retransmitted because the retransmit attempts were over or the sensor decided that the link was lost (we can only guess). Samsung, whose hub was attacked during the research, has already given the proper comment and we agree with it 100%: ZigBee Motion sensors are not designed to be a professional, highly secure alarm system. We wonder if anybody has already seen a professional alarm based on a wireless protocol. Although the jammer attack is not specially a weakness of ZigBee, it may be useful for those customers, who want to get an alarm but do not want to pay a high cost.

Moving on, now we are going to discuss the weakness that was introduced as a supermassive hole in the ZigBee security, but it is actually not ZigBee specification’s fault. The reality is that a large number of ZigBee devices available on the market use the default Trust center link key to encrypt active network key transport. This key is open and there is not much difference for security in sending the network key as plain text or encrypted by the default key. ZigBee specification warns developers about such threat and recommends out of band or not-by-the-air methods to deliver an initial master key to both the trust center and the device. Researchers criticize this recommendation because it is not a requirement when the required by the specification default trust center link key in its turn breaks the security. But why shouldn’t the not in-band key delivery be a part of wireless protocol specification? Moreover, as anybody, even researchers, agree, unsecured key transport is ideally performed only once, during an association and most likely is not a threat, of course unless a maniac with an enabled ZigBee sniffer is spying on your house 24/7. And here the thing that everyone is talking about comes to the surface. Assuming that a quick, low-power, unsecured key transmission is performed once, hackers enable their jammer again to force link loss. When the link is lost, there are two ways to get the key:

  • A “typical” user triggers association one more time when an intruder’s sniffer is enabled;
  • Device tries an unsecured rejoin (that is allowed by the specification).

Respectively, there are two ways to dispute:

  • Strictly saying a “typical” user will most likely reset the device, reset doesn’t mean a factory reset, just power off/on. The reset will trigger a rejoin process and now we move on to the second point;
  • Although ZigBee allows unsecured rejoin, secured one is not forbidden; it’s just a policy, an option that can be configured by the manufacturers. The problem wouldn’t exist if the devices under the test implemented secured rejoin. There also wouldn’t be any problem, if there weren’t high security requests to the devices that implement unsecured rejoin.

The main conclusion from our dispute is that the found exploit is not a “ZigBee” one, it’s “Current ZigBee implementation exploit.” It will not be superfluous to say that researchers from Cognosec are ZigBee users too and they pointed out that ZigBee specification provides all the good recommendations to build a secure system. But dramatic headlines and maybe mass hysteria turned the device problem into the core standard one. There won’t be any panic, if anybody interested in IoT (or ZigBee), based their opinion on the original source:

https://www.youtube.com/watch?v=9xzXp-zPkjU

https://www.blackhat.com/docs/us-15/materials/us-15-Zillner-ZigBee-Exploited-The-Good-The-Bad-And-The-Ugly.pdf

The Real Reasons Behind Most ZigBee Interoperability Problems

Interoperability is a buzzword that we hear often when talking about wireless protocols, including ZigBee. Being an already trusted but still young standard, ZigBee itself can raise many questions when reading the official documentation. However, that is not the topic of this blog. With over a decade of experience in wireless communications software development and 7 years working closely with ZigBee, we have seen many cases where although the specification gives adequate description, developers invent their own bicycle. Our extensive experience integrating and working with a large number of sensors from different manufacturers provided us the valuable insight we are sharing in this blog.

The field where there is so much space for creativity and hence mistakes, is the application layer, when profiles join the game.

Let us start with one simple flag – “Manufacturer specific” flag in ZCL header, invalid usage of which may cause a variety of problems. The right way of using it is extending the functionality of ZCL (HA), adding attributes or whole clusters that are not provided officially. For example, we cannot guess, why “Temperature measurement” cluster has a “tolerance” attribute, while the “Humidity measurement” does not. It is about the fact that if you want “Tolerance” attribute in your humidity sensor, you need to make a manufacturer specific attribute. Or, in another example, let’s say you are working on a ZigBee-based pet tracking system. We promise there is no “Animal tracker” cluster in any specification. You will need to implement it yourself and, yes, it will be manufacturer-specific.

The common mistake of using this flag is marking general attributes and commands with it. We faced it while working with IAS sensors and made us wonder why the standard enrollment procedure needs any manufacturer code. Do developers really consider their manufacturer code safer from intruders than the entire ZigBee security system?

Anyway, it can be easily debugged, because the only thing we need to know in this case is the manufacturer code. There is a way to obtain it using only ZigBee tools: the code is placed into the node descriptor. If the node descriptor does not work, it can be requested from the manufacturer. And, when there are no contacts, ZigBee sniffer can help too. If there is a coordinator that the intended device successfully enrolls with, then with the proper enrollment procedure caught by the sniffer, we will get the code. Another way to achieve this is by writing any attribute in the intended cluster and probably getting the response with the code. Moreover, configuring and binding the intended cluster may cause some manufacturer-specific attribute to be reported with the code. So, they key is just to be patient.

This mistake may be worse when the device confuses ZDP discovery tools: for example, the cluster is not returned in a simple or match descriptor response, but some commands are supported and they are manufacturer-specific. In this case, discovery does not work and you will need either a technical contact or a lot of time to experiment.

In this case all we know is that the device in our hands is a ZigBee device and what it is used for. So we can predict its cluster list. The only thing we can do without manufacturer help is to send commands to the predicted cluster waiting for the response with some status.

The next issue has to do with attribute semantics misunderstanding. When the number of attributes exceeds two-three and cluster logic becomes complicated, this can lead to misunderstanding of an existing attribute’s meaning . Just imagine the situation when you try to set temperature on a thermostat but it is still too cold or hot in the room. Now we take this HVAC system and try to guess, which setpoint the “Setpoint Raise/Lower” command operates with? It depends on the command’s mode as well as current system’s mode. But some developers may like only one clear attribute and of course it will cut the existing logic. In this case, specification misunderstanding can even cause attribute duplication.

One of the last common problems has to do with a very useful HA extension – poll control. Even though it is strongly recommended to implement it, it is often ignored. However, real problems come, when the device has its own long poll interval that is much longer than the default one. If we leave the situation as is we will for sure have many packets lost for such a sleepy device. Therefore, we should increase the timeout for deleting expired indirect packets. This does come with a risk: if the interval is too high, the queue most likely will got overflowed. That is why when increasing the indirect queue timeout, updated coordinator should be tested in a large network with a lot of sleepy devices connected.

To close, we want to add a few words about the mistake that will not break interoperability, but can be frustrating and easily avoided. Unfortunately, as of today we do not have as many reportable attributes as we may want. And everybody who faces this problem solves it in his or her own way. We have seen “Write attributes” sent to the client cluster and even reports that were not configured. It is the only problem described here that can be attributed to by the lack of functionality in the official specifications. We are sure this will be addressed in one of the next updates. But we are sure that the devices that skip the configure/bind logic before sending reports will not disappear for many years.

We hope this blog gave enough examples to show that most interoperability problems at the application layer appear because of not completely understanding ZigBee Alliance documents. With the growth of ZigBee technology and the number of well-designed devices, such misunderstanding may make the product less competitive and supported. It is key to take time to understand and follow the standard to avoid these issues and ensure the success of your products.