Google Weave/Brillo

[mikehenrty]

Let's make an experiment with Google Wave and Brillo.

[atilag]

Ok, so my plan to test this technology is the following: 1º - Download and build a Brillo image for the Intel Edison 2º - Flash the image into the Intel Edison 3º - Prepare a very simple example to test Weave in the Edison, probably reusing one of the existing examples I found looking through the source code. This will involve building two programs to connect each other, one will be targeted for the Edison and the other one will be executed in my laptop... if I have time I'd love to execute the latter in a FxOS/Android phone. 4º - Setup the environment to test the Cloud Weave workflow 5º - Setup the environemnt to test the LAN (direct connect) Weave workflow.

[atilag]

Project Information

Google recently announced two new technologies targeted to IoT landscape: Brillo Operative System and Weave protocol. They are related in a way that Brillo as an Operative System (OS) that includes an implementation of the Weave protocol via native binary library with a basic setup. But the relation between them finishes here, because they are two different and isolated things that should be explored separately, so I splitted the experiment in two sections: Brillo and Wave. Let's start with Brillo.

Google Brillo

Brillo is an OS designed to run on embedded devices. The minimum requirements of the embedded device must be: 128 MB disk space, 32 MB RAM running on ARM, Intel or MIPS architecture. It's based on Android (starting at Marshmallow 6.0) so inherits a lot of the features that are already present in Android like:

• A SDK with good known tools to build, test and debug (called BDK and based on Android's NDK)
• Standard core services to easy development and improve getting stared experience (Weave is included)
• Metric services integrated to collect user data (with their permissions) and extract usage patterns
• Easy upgradeable via OTA
• It's Open Source, the same way Android is... but I'll talk about it later. The main difference with a regular Android system is the lack of the Java stack, so:
• No High-level Android SDK
• No Dalvik/Ant virtual machines

One of the key points I see with Brillo is that developers can use their BDK, which is low-level native SDK that gives the basics to build your own software stack on top of it. This will brings you more freedom than Android to articulate your product strategy without being tided to stupid constraints like closed high-level APIs or primitive object-disoriented languages.

Competitors

It's is believed that Google Brillo and Weave were born as an strategy to compete with other major actors in the IoT space, like Apple HomeKit or ARM mbed, but Brillo by itself is just a platform, an OS, so in this field there are other Open Source OS's out there which have been present in the market for years, but the in the world of embedded devices the OS is usually something tailor-made, because of the nature of the embedded devices, so there's a lot of fragmentation in this area. There's not a clear dominance. Anyway, other potential alternatives exist which address the same target as Brillo, like for example OpenEmbedded project or Yokoto project, which is a fork of the former. But they are not OSs by itself, they are more like frameworks to build those tailor-made OS's, so it's hard to think about them like direct competitors of Brillo.

Target Market

Google Brillo is clearly a product focused on IoT market. As a platform can be used with any other end-user product so the target could be everywhere an embedded solution is required. The possibilities are many.

Marketshare / Contributors working on this Project

Google is pushing this project, so as long as the product is profitable for Google, it will have a good support. It's still in it's early days but Google's plan is to release minor updates every 6 weeks, and major updates for long term support every 6 months. This is an Open Source project with the same license as Android, Apache mostly. But, like Android, the project is completely controlled by Google so the contributions are very much restricted, and opens the same window as Android did to private and closed solutions to pollute the ecosystem by restricting freely redistributions of the software, which is something that we do hate at Mozilla, but... it's a model that promotes the adoption of the platform in a wide range of OEMs. Of course, as an Open Source project with Apache license it can be forked.

Goals

Brillo is intended to be the preferred platform for IoT products, where an embedded hardware is needed.

Hardware

Google has partnered with some hardware manufacturers to certificate Brillo on their devices. For the time being, there are two supported hardware platforms: Intel Edison and Qualcomm Dragonboard 410c, but more are coming soon.

Target Platform

I tested Brillo on Intel Edison with a mini breakout board kit

About the experiment

So my main goal with Brillo was to build and flash it into an Intel Edison form scratch and have an overall idea of how mature and complex is the process as a whole, and how this technology fits into our IoT strategy. I could manage to make it in about 20 hours, mainly because of the lack of documentation and some problems related to it's beta state, so a lot of hacking by my side in order to achieve the goal. Anyway the process is very similar to building Android, so most of the tools and process are well known to Mozilla because of B2G.

Conclusions

After finishing the experiment, these are my conclusions:

• Brillo is intended to be for IoT space, what Android is for mobile industry. Google is behind pushing the project forward, so looks like a promising platform that we should take into account in at least one of these situations:
  • As the platform whenever we want to build an end-user, "in a box" like product.
  • Whenever we need to have a platform for prototyping and testing developments.
• As I mentioned earlier, another important point is that we have a huge amount of experience with Android internals because of B2G, so the platform looks very familiar and the entry barrier to adopt this technology is pretty lower for us.

Google Weave

Weave is a new platform to connect devices directly, through the cloud or through a mobile using a common language and a shared understanding. It's a platform because It provides an implementation of the Weave protocol in the form of a device side library, a SDK and WebServices to enable remote interaction. All information is encrypted by default, even the information stored in the Google cloud. The Weave library implementation provides an interface for the following main features:

• Device Discovering
• Provisioning
• Authentication
• Interaction But it's up to the implementer to decide what background technologies they use to accommodate library interfaces. Some other low-level features that the library provides for the implementers are:
• Integration with your platform-specific event-loop system.
• Monitoring network status, so you can control when you are online or not.
• Bluetooth integration (TODO)
• Wifi integration
• Configuration store system, so your app con load and store configuration data using files, flash, etc..
• HTTP client so the app can call external services
• HTTP server for Privet APIs (a cloud protocol for local discovery)

There are some code examples that you can use as a base to start with your Weave-enabled product. For example you can see int the examples that Device Discovery is implemented with mDNS via avahi client classes, or for example they use libevent for the platform-specific loop.

Competitors

There are plenty of IoT protocols over there, they play in different levels of abstraction, from the lowest network hardware levels to the highest application levels. With all this fragmentation on the field, there's no a clear dominant so far. Weave is classified as a high-level application protocol and in this level I could find another protocol which is pretty much identical on it's goals, and it's called Weave as well. It was created by Nest , which was bought by Google in 2014. Google announced that both protocols are going to be compatible so I wouldn't classify it as a competitor. Another possible competitor could be MQTT this is an application-level protocol to send lightweight messages over web technologies (http/https) to other devices. It's being supported and widely used by Amazon, one of the main actors in the IoT space at the time being.

Target Market

IoT market in all it's definition. Because Weave could be used for Home spaces or even industrial spaces. Whatever space that needs devices to be connected directly, or via mobile phone, or via cloud.

Marketshare / Contributors working on this Project

As happens with Brillo, Weave is being promoted by Google, so there's a good foundation for the protocol to succeed.

Goals

Weave's goal as a protocol is pretty clear: Connect devices using a common language in a hardware-agnostic way.

Target Platform

The good thing about Weave is that it's not dependent of any platform, even Brillo. The protocol is open so anybody can implement it, and Google offers an open source BSD license like implementation in form of a library that hides all the protocol detail for the developers, so it's adoption shouldn't have any barrier.

About the experiment

My initial approach was to build some of the examples that already exist in the library and target them Brillo running in an Intel Edison, but, surprisingly, I've found a lot of problems to cross-compile them. But, I could able to run them on my Ubuntu laptop without any major problem, so I could make a test with the device-to-cloud use case. This is how the experiment worked: first I built the "sample" example to run in my Ubuntu laptop, this "sample" program is a daemon which once launched, starts to listen for incoming Weave messages. Then I went to https://developers.google.com/oauthplayground/ and followed the steps to fulfill all the parameters and send a JSON like message to my endpoint (the sample app daemon) with one of the commads/actions predefined. After launching the request, I could see a message in my laptop screen with the information sent from the web, and in the web, I could see the raw response from the daemon. The experiment itself was pretty simple, maybe the tough part was setting all up because the little documentation I found had some mistakes so I needed to figure out how actually made it work.

Conclusions

I really thing that this protocol is going to be implemented by a wide range of manufacturers, mainly because Google is behind it and there a lot of manufacturers that already have experience developing their products with Android, so the effort they have to make to support Brillo as their base platform is close to zero. Once again, one of the problems that I have found is the lack of documentation, but this is something that will disappear as soon as Google decides to open the project to the public.

So, enabling our IoT products to support Weave will give us the opportunity to reach a wide range of devices in a near future.

[vsivanagulu]

Is brillo and android things OS both are same or different