It was a simple request after Sundar Pinchai’s announcement of Brillo. Carl, can you research it and write about it?
So off I went into the Google webpages, and basically all I found was a standard WordPress template and a lot of things that did not click to anywhere. For those of us with a history of drinking Google Kool-Aid and then having the supply cut off (i.e., Google Glass, Google Wave, etc.), a bit of hesitation is understandable.
Having said that, let’s talk about the concept of Brillo in relation to embedded devices. The concept is sound. Android has a lot of extra complexity to support voice, video, and displays. From the standpoint of most sensors, putting them on Android as the OS would be like turning a locomotive engine into a car. So scrubbing away the extras (hence the name Brillo) has logic, except for the fact that it may still be a locomotive engine even after the scrubbing.
However as an operating system Brillo is not documented yet, and candidly it’s hard to believe that in the end it won’t be based on what Nest already has done. Nest is a Linux- based solution according to Wikipedia. Here’s the entry: The operating system itself is based on Linux 2.6.37 and many other free software components. To comply with the terms of the GPLv3 license under which some components are available, Nest Labs also provides a special firmware image which will unlock the system so that it will accept unsigned firmware images. While the thermostat software by Nest Labs itself remains proprietary, a third party has re-implemented the basic logic in an open source replacement called FreeAbode.
Now from a sensor developer point of view the use of Nest as an OS may not be ideal. While Apple and Google dominate our smartphones, our homes, cars, and interests are more varied and best of breed will be in the eye of the beholder. While I personally like the Java Embedded strategy for sensors, I recognize that assumes a lot of processing and power capability. On the RF side of the equation we have LoRA, SIGFOX, and Weightless all trying to support low power wide area requirements. This means that low power thresholds will exist for many devices as well.
Recently I interviewed Peter Zeidman and he explained that for many developers, returning to C is the most efficient interface for sensors. Zeidman recently developed SynthOS, which is a developer’s tool. SynthOS assures that the sensor’s functions are properly managed by the OS. In effect, SynthOS keeps the real-time operating system locked down and more secure.
Now, regardless of the sensor’s OS, the focus of the developer has to be making the device addressable for the higher end applications. Steve Wilmont, the CEO of 3scale, has pointed out that 3scale’s focusing on API management enables the developer to trust access control, rate limits, security, and monitoring, which are often problematic when developing APIs from scratch.
For people who are developing in the Google ecosystem, the use of Nest’s APIs is well documented and a much easier way to connect your device to the Google strategy. For those interested in aligning with Apple, Homekit is the strategy, but is more application-oriented with speech control than an OS solution.
The bottom line is for those at the sensor level of the development, keeping a clean core that uses APIs to reach application environments is much safer than going with a specific environmental experience.
Carl Ford is CEO and community developer of Crossfire Media.
Edited by
Ken Briodagh
