Headworx

The other day I had an interesting conversation with a commercial real estate developer. They told me that for every building they erect, they build a cloud. This cloud is an integral part of the building. It is a virtual representation of everything that is happening inside, sucking real time data from tens of thousands sensors: occupancy, temperature, ambient light, air quality, ... Everything. My surprise was not what I heard but who told me that. For years at Silvair we've been touting lighting networks as infrastructure networks that collect and carry real time sensory data in buildings. We've been communicating that vision to lighting companies. Big and small. And they have been slow getting it. After all, for all those years, they were making light sources that had to be provided power. And the pitch of "your lamp is a sensory data router" was not getting through. And then I realized that what lighting companies and communication infrastructure vendors di...

Bluetooth is a great technology. But the standard is broad and evolving quickly, so things that are clear for insiders may be confusing for others. When we exit the 2016, there will be three fundamental variants of Bluetooth: Classic, Smart and Mesh. Classic is the one that started it all back in 1990's. It is based on the fundamental technology referred to as BR/EDR (Basic Rate / Enhanced Data Rate). It is a streaming radio, used primarily for audio, although there are many other profiles serving scenarios like file / object exchange and products like computer peripherals. BR/EDR is connection - oriented, forming a star topology with a master device in the middle, capable of being in a connection with up to seven slave devices at the same time. Trust relationship is in pairs (master - slave) and slaves do not see each other and cannot exchange data with anybody but the master. Smart is based on a fundamentally different technology, called LE (Low Energy). LE was originally ...

News about the passive WiFi breakthrough circled and confused the world. It is supposed to use 10 thousand times less power compared to standard WiFi. Yet still being 100% compatible, as demonstrated on the video . People keep repeating the story on and on and not many took the effort to read the original paper and especially the fine print. So what is in the fine print? Here are the quotes: "...the power-consuming RF components such as frequency synthesizers and power amplifiers are delegated to a single plugged-in device in the network. This device provides the RF functions for all the passive Wi-Fi devices in the vicinity by transmitting a single-frequency tone..." "...we set the plugged-in device to transmit its tone at a frequency that lies outside the desired Wi- Fi channel..." "We set Pt , Gt , Gr and Gpassive to 30 dBm, 6 dBi , 0 dBi, and 2 dBi respectively." What they mean is the system is powered by a +30dBm 1 Watt (!!!) transmitte...

There is a fairly common misconception about security (in IoT systems) that it is all about encryption. Security is about protecting secrets, right? Not quite... In most systems what really matters is authentication. I am a door lock. You are sending me an "Open" command. Does it have to be encrypted? Not really. It is like in the analog world you would want to hide the fact you are opening the door. Even if the "unlock" command can be heard by my neighbors... so what? The key part is authentication. I, as a lock, have to trust the command is legitimate and it comes from a legitimate authority. I have to be able to cryptographically verify nobody altered the command. And who is the originator. If it is a verified command coming from a verified trusted source, I accept it, and open. It does not matter the neighbors around can hear it. They also see me standing at my door. So it is rather obvious I am commanding the door lock to open. I don't need to hid...

It has been a bin unexpected start of the Smart Home Year 2016. Greg Burns moved from Qualcomm to Intel. And now in an unusual style both companies are shaking hands together merging Allseen/Alljoyn with OIC. What comes out is the Open Connectivity Foundation (OCF), backed by both eternal enemies, as well as some other industry heavy weights: Microsoft, Cisco, IBM, Honeywell, Samsung and a bunch of others. And if you did not follow the news, the entire UPnP is there already. Only Google and Apple are missing. But having Intel and Qualcomm joining forces, and especially Qualcomm accepting the defeat of Alljoyn, is both unexpected and positive. This may really hint for reduced technology fragmentation in Smart Homes. Fragmentation that has been the key reason this market is still far from the full potential. So it suddenly looks like we are down to three Smart Home platforms: OCF, Google/Weave and Apple/Homekit. Apple will probably not be able to pull it off, as they are still con...

It looks like the Apple iBeacon standard has just got a serious competitor: Google Eddystone. Not that Eddystone is this week's breaking news. It was released some time ago and even before the Google beacon format had been promoted as the Physical Web. But the big news is Google Chrome, version 49. Available in beta now. It natively supports Eddystone URL-broadcasting beacons. What is the big deal here? Beacons no longer require an app or any Cloud platform. Here is how it works. A Bluetooth Smart radio (which can be a standalone product or can already sit in another product like a lamp) broadcasts a URL. A good, old, well known URL. A phone with the Chrome browser installed (pretty much 90% of phones today) picks up the broadcasted URL and pops a system notification. A user - if interested - clicks on the notification and opens the URL. The URL can point to anything. A bus stop may point to the timetable URL. A painting in a museum may point to the web page with more info...

There has been a lot of noise around beacons for the last couple of years but they still do not seem to be nearing a mass scale market adoption. There are two reasons for that. One is the technology fragmentation. We have the two competing standards: the Apple iBeacon and Google Eddystone. But that would not pose too much of a challenge, as it is relatively easy to build beacons that interleave both message formats. Second is the DRM problem. Which is much more difficult to solve. Say United installs a network of beacons that guides United passengers to the gates using the United App. As passengers are guided to gates, the competitor's App picks the same Beacon signals and offers cheaper flights next time. This is certainly not what United would like to see. Which makes them scratching their heads whether they should be installing beacons in the first place. The second problem really comes down to the issue of how do we allow the legitimate app to receive beacon signals whi...