9 ms·

Google launches developer preview of Android Things

134 points by type0 10y ago

jfoster 10y ago
It's interesting, but I'm skeptical of Google's first attempt at anything, particularly Android. It took them a few attempts at TV and Auto, and they're probably not done with those yet. It's great that they've got something for IoT, but I wouldn't want to build anything serious with this yet.
- monkmartinez 10y ago
  Chromecast is pretty darn awesome! Google Assistant ("Ok, Google") is miles ahead of many of its competitors. You don't really need Android Things (Brillo 2.0) to build IoT stuff using Google services. Also, not its first attempt.
- IshKebab 10y ago
  Technically this is their third or forth attempt. There was Android@Home, and Brillo which was also based on Android, but didn't include the Java stack. I'm pretty sure there was another attempt that I've forgotten too.
pikzen 10y ago
I know the entire IoT sphere is completely pants on head stupid these days but... Android. On an embedded product. Even with no UI (assuming it will all be controlled through one gateway), Android doesn't scream "efficient with its resources" to me. 1GB of RAM on a microcontroller to get it running efficiently (what the Edison seems to have)? And joy oh joy, another Google-made API to use. You can feel me bursting with joy at this prospect. They are of such good quality. I guess automatic updates are sweet.
- astebbin 10y ago
  Google Weave, aka libiota, is targeted at lower-capability MCUs like the Marvell MW302 with its 512kB of RAM: https://developers.google.com/weave/guides/overview/what-is-weave https://developers.google.com/weave/guides/overview/what-is-... Based on these two links (including the parent), it wouldn't surprise me if a Google Weave API was soon exposed on Android Things.
  - lgleason 10y ago
    From what I've heard it will be eventually.
- Eridrus 10y ago
  The performance issue stood out to me at first too, but with no UI and Dalvik really only being optional and Google's background services stripped out, this is mostly just a weird Linux, so I'm not sure why this would perform significantly worse than any other Linux-based OS. Sadly I don't know enough about hardware economics to say whether hosting a whole OS is crazy or not, but we've been trading off CPU time for less developer time in every other area of development, so I don't see why it would be different here. To the extent that the OS itself is not what is causing you problems, you can keep optimising your app code as you go and release on cheaper and cheaper hardware if you want.
  - cbdfghh 10y ago
    So what's the advantage of using Android over straight Linux?
    - Eridrus 10y ago
      The advantage seems to be that you don't have to worry about the details and you get updating for free. Writing good update code is hard and thankless, but you can certainly do it yourself. Not a tonne of benefits, but not a tonne of costs either. I'm sure Samsung won't use this, but this might be good for projects just getting off the ground.
    - stbtrax 10y ago
      some are: access to media frameworks, there are more android app devs and resources out there compared to whatever linux GUI framework you might use.
  - Normal_gaussian 10y ago
    If you don't have a tight power budget hosting a 'whole OS' isn't crazy (though it doesn't mean it isn't wasteful). Most chips will use an RTOS for the timing guarantees, and they generally provide better power resilience than other OS's.
- lgleason 10y ago
  The Pico is a half a gig of ram. That is not micro-controller size, but it is still a little better.
- mszcz 10y ago
  That's what I've always wondered. What the hell are those things doing with these resources? I mean if you take a step back and just look at what their purpose is - operating a light switch or reading the temperature - the amount of resources they use seems ridiculous. I've been tinkering with the ESP8266 and it's got 64k RAM and that seems enough to get a TCP/IP stack, WiFi and even a simple web server.
  - pjmlp 10y ago
    The issue is of scale, it is just a few euros difference. So unless you are mass producing and need to save each cent per unit, the comfort of using something more productive will always win out in total project costs (hardware cost + development time).
    - TeMPOraL 10y ago
      > the comfort of using something more productive This is reaching levels of absurdity nowadays. I mean, Android / Android Studio and "productive", compared on how you work with ESP8266? With NodeMCU, all you need is simple Lua, few console commands and a text editor. We're replacing that with a huge cow Android Studio is, shit ton more of commands and complexity need to operate it, and what? Now each new toaster, instead of shipping an uC, will ship a whole PC inside? :/.
      - pjmlp 10y ago
        I find the ESP8266 quite good, specially its successor ESP32. Given the programming languages we already could use on MS-DOS, both those chips are quite good. However, I bet Google is trying to put Android into those areas that are now moving from C and C++ to Java. This is the same game currently being played in HPT, it is cheaper to get Java developers, even with the increased hardware costs, than to keep writing trading systems in pure C++. Hence the pressure Oracle has got into improving Java's story in regards to AOT and value types. So if a business is just going to deploy a couple of units, the difference between $15.15 (ESP8266) and $39.95 (Raspberry PI 3) might not be significant, when adding the salaries and respective development costs on top. Of course, the best approach for those that care about Java and IoT is to just use a plain GNU/Linux distribution like Yocto and standard Embedded Java, instead of Android Java fork. But overall I agree with your dismay.
- pjmlp 10y ago
  > I know the entire IoT sphere is completely pants on head stupid these days but... Android. On an embedded product. That is what people asked for, apparently. The initial plan for Brillo was to replicate some of the Android frameworks in C++. "We incorporated the feedback from Project Brillo to include familiar tools such as Android Studio, the Android Software Development Kit (SDK), Google Play Services, and Google Cloud Platform." https://android-developers.googleblog.com/2016/12/announcing-googles-new-internet-of-things-platform-with-weave-and-android-things.html https://android-developers.googleblog.com/2016/12/announcing...
- fest 10y ago
  The general trend for embedded devices is in the direction of richer ways of user interaction. That usually involves adding touchscreen LCD. Once you add LCD, you want nice graphics, animations etc. While you can use microcontrollers for low-res LCDs, when you get past, say 640x480px resolution, due to increasing memory and CPU requirements it often makes sense to go with system-on-chip solution running high-level OS. The existing libs/frameworks to create nice looking, polished UIs for embedded Linux devices are not as easy to use, well understood and having large base of developers as Android is. So this leaves device manufacturers seriously considering Android. Working on software stack directly with SoC manufacturers is PITA (although they want you to buy chips from them, they don't want to spend time on support), so having a flavour of Android geared towards embedded devices is a good value proposition from Google.
- IshKebab 10y ago
  I agree. The minimum requirements for Brillo were already infeasible for most products. Now they want to use Java? Most IoT devices run on a Cortex-M or similar with less than 1 MB of RAM. That said, you don't have to use Android Things. I guess it's more a case of "if you have a system that runs Linux anyway, why not use Android Things?".
ndesaulniers 10y ago
From what I've seen, the automatic update system is sweet. I'm really glad the team decided to tackle one of the largest blockers to adoption (IMO) which was providing security updates.
- taneq 10y ago
  So all of my network-aware things are now going to have an excuse to demand internet connectivity so they can dial Google on a regular basis? I'm not sure that's worth the tradeoff.
  - bitmapbrother 10y ago
    What exactly did you think the "I" in IOT stood for? Also, like Android there's no need to use Google services. Just patch it and update it yourself if you're so inclined.
    - tdkl 10y ago
      Local network connected devices that can be reached over the Internet if desired. You know, like PCs.
    - taneq 10y ago
      I was kind of hoping it meant "internet" in the sense of "I can connect to and control the device from my phone", not "the device will be sending data to its manufacturer". Hopelessly naive, I know.
      - kakarot 10y ago
        That is Intranet of Things, IoT's lesser known cousin.
      - bitmapbrother 10y ago
        Last time I checked using Google Services was still an option when using an Android phone.
    - 10y ago
mtgx 10y ago
From what I hear not only will all Android Things collect data for Google, but also all devices that use the Weave protocol (for which the device makers have to use Google's servers). That's crazy, if true. An IoT communication protocol shouldn't rely on Google or any other company to work. Imagine if your Wi-Fi router only worked if Samsung got to collect all the data that passes through it. This sounds even worse than when people complained that in some cases data from AMP pages would go through Google. At least then developers could still use the open source independent version of AMP.
- theDoug 10y ago
  Any sources? I ask in good faith, but it's also easy to say "from what I hear" then "that's crazy, if true" for nearly anything.
- taneq 10y ago
  Well, a fair few smart TV functions only work if you allow the TV to phone home (and agree to them using the built-in mic and camera to capture and upload audio and video at any time and use it for any purpose). This is another step beyond that, where your light bulbs have to phone home to Google and to their manufacturer.
lai 10y ago
Has anyone tried to get Android Things (Brillo) to work with other micro-controllers than the ones they support out of the box?
- lgleason 10y ago
  I'm not sure I would call these platforms micro-controllers. With that being said there is support for weave on a select number of micro-controllers.
- anujdeshpande 10y ago
  Brillo is for microprocessors (think Raspberry Pi, BeagleBone Black, etc) whereas Weave is for micro-controllers (think the newer Arduino's which are running a Cortex-M of some sort)
  - IshKebab 10y ago
    Nope. Brillo (Android Things) is the OS. Weave is the communications protocol. You can have Weave without Android Things, or Android Things without Weave.
ClassyJacket 10y ago
Google's willingness to drop their projects really gives me no confidence as a potential developer. What happened to Brillo? Why start a new project with a new name instead of just making Brillo 2.0? Should I invest anything in this or will they just drop it again?
- Navarr 10y ago
  From what I understand, this _is_ Brillo. Just rebranded with some upgrades (e.g. "Brillo 2.0")
  - ddeck 10y ago
    Yep. From the article: It combines Google’s earlier efforts around Brillo (which was also Android-based, but never saw any major uptake from developers) with its Android developer tools like Android Studio, the Android SDK, Google Play Services and Google’s cloud computing services. Support for Weave, Google’s IoT communications platform that (together with Brillo) makes up Google’s answer to Apple’s HomeKit, is on the roadmap and will come in a later developer preview
  - pjmlp 10y ago
    Not just rebranded, they dropped the plan of having the frameworks redone in C++ as discussed at Embedded Linux talks, and took the Java ones from Android instead.
sker 10y ago
I wonder what will MS come up with to counteract this: Microsoft Windows Ultimate Surface Things.
- monkmartinez 10y ago
  I hope it is something cool. They have shown a remarkable willingness to contribute "something" to just about "everything" in recent memory. A lot of has been open to boot! I do not want to let you down, however, and will provide an equally inflammatory remark: We do know that Apple will continue to build walls around Homekit making it virtually useless to anyone outside the already fortified walls of iOS!
- dano 10y ago
  MUST - nice acronym
- pjmlp 10y ago
  They already did, UWP support for Window 10 IoT is older than Brillo/Android Things.
hardwaresofton 10y ago
As long as this version of android stays as open as regular android I think I'll be happy. It is super sad that Mozilla decided to leave this space though (even if trying to pivot FirefoxOS was nothing but trying to buy time). Wish there was a less insidious company trying to get into all my devices. Also, why "Weave" instead of just using Thread? ( https://en.wikipedia.org/wiki/Thread_(network_protocol) https://en.wikipedia.org/wiki/Thread_(network_protocol) ) [EDIT] - It looks like Weave IS built on Thread, though it's a little sad that it took me so long to figure it out: https://www.silabs.com/products/wireless/Pages/nest-weave-thread.aspx https://www.silabs.com/products/wireless/Pages/nest-weave-th... My knowledge of the Thread Group's management/scheme layout was lacking, it looks like it's INTENDED that thread is meant to be below one layer of abstraction, managed by different vendors (sillicon labs, nxp, etc)
- rohan1024 10y ago
  How about Canonical https://www.ubuntu.com/internet-of-things https://www.ubuntu.com/internet-of-things
  - hardwaresofton 10y ago
    Thanks so much, haven't kept up with Canonical since switching off of Ubuntu, didn't know there was another option like this [EDIT] After spending some time looking at Ubuntu Core... is it just a smaller Ubuntu distro + managed updates? I do like the "snap store" concept... marketing jargon aside, it seems like Canonical is paying attention to both developer and user ergonomics more than ever [EDIT2] Ubuntu core & snapcraft.io are pretty exciting
- astebbin 10y ago
  Thread provides a network, but no application-level semantics. In other words, Thread is to 802.15.4 as WiFi is to 802.11. Once you've set up a Thread network, you still need an application layer like CoAP or Weave to control your connected devices.
  - hardwaresofton 10y ago
winter_blue 10y ago
What's the benefit of using Android on a micocontrolller? Since these devices will likely have no UI, a significant chunk of the Android API will be irrelevant. Is the pro that you get to use Java with a (hopefully) friendly API vs writing in C or C++ as in the old days?
- BoorishBears 10y ago
  Why do you assume they'll have no UI? The displays are optional, not disallowed. For what we do at my workplace this is a godsend. We design installations for retail environments that need to have very rich interfaces. For us it's not MCU vs Android, it's embedded PC vs Android hardware. We were already doing similar things with stock Android except we had to use custom boards interfacing over USB to do anything involving sensors to stay somewhat free from specific hardware. We were running into limitations in Android that centered around the fact that it is targeting consumer devices first and foremost. Android 6 brought COSU mode, but it still showed signs of the steady march towards a more locked down Android. Besides the pro of supporting our usecase in a first class manner, having access to the Android UI framework or a web browser is big for those complex interfaces. The productivity gains vs trying to build up that stack from a bare ARM MCU are immeasurable in the literal sense (a separate company contracted to do something like that would probably have more employees than we currently have working on software) And of course, being able to hire Android devs and take advantage of the ecosystem doesn't hurt.
brutus1213 10y ago
I work in this space. While this platform looks a lot better than previous Google efforts, this is no way a solution. A key problem with IoT is too many standards that don't play nice with each other. And this is not a technical problem - everyone just wants control of the platform. If you think Android is open, you are being naive. In recent months, I thought things were going to get better with major consolidation between Iotivity and AllJoyn. This is not a step in the right direction. Oh .. and obligatory xkcd: https://www.explainxkcd.com/wiki/index.php/File:standards.png https://www.explainxkcd.com/wiki/index.php/File:standards.pn...
- XorNot 10y ago
  What I want is my IoT devices to get IP addresses and respond to a simple HTTP REST api. The semantics of it don't matter much to me, provided it supports SSL and avoids session-management BS as much as possible, but I'll deal. If you want to offer a cloudy service on top of that, I'll buy your cloudy-service box which offers to do that, but it better be using the same API to control those devices because maybe I don't want your cloudy box and want to integrate them with vendor B's devices or vendor C's + some homebrew stuff.
  - brutus1213 10y ago
    I'm curious what kind of API would you want? There are so many devices out there, it makes things challenging. Best proposals I've seen define a base API for discovering what are other APIs that a particular device supports.

134 points by type0 10y ago

It's interesting, but I'm skeptical of Google's first attempt at anything, particularly Android. It took them a few attempts at TV and Auto, and they're probably not done with those yet. It's great that they've got something for IoT, but I wouldn't want to build anything serious with this yet.

monkmartinez 10y ago
Chromecast is pretty darn awesome! Google Assistant ("Ok, Google") is miles ahead of many of its competitors. You don't really need Android Things (Brillo 2.0) to build IoT stuff using Google services. Also, not its first attempt.
IshKebab 10y ago
Technically this is their third or forth attempt. There was Android@Home, and Brillo which was also based on Android, but didn't include the Java stack. I'm pretty sure there was another attempt that I've forgotten too.

pikzen 10y ago

I know the entire IoT sphere is completely pants on head stupid these days but... Android. On an embedded product. Even with no UI (assuming it will all be controlled through one gateway), Android doesn't scream "efficient with its resources" to me. 1GB of RAM on a microcontroller to get it running efficiently (what the Edison seems to have)? And joy oh joy, another Google-made API to use. You can feel me bursting with joy at this prospect. They are of such good quality. I guess automatic updates are sweet.

astebbin 10y ago
Google Weave, aka libiota, is targeted at lower-capability MCUs like the Marvell MW302 with its 512kB of RAM: https://developers.google.com/weave/guides/overview/what-is-weave https://developers.google.com/weave/guides/overview/what-is-... Based on these two links (including the parent), it wouldn't surprise me if a Google Weave API was soon exposed on Android Things.
- lgleason 10y ago
  From what I've heard it will be eventually.
Eridrus 10y ago
The performance issue stood out to me at first too, but with no UI and Dalvik really only being optional and Google's background services stripped out, this is mostly just a weird Linux, so I'm not sure why this would perform significantly worse than any other Linux-based OS. Sadly I don't know enough about hardware economics to say whether hosting a whole OS is crazy or not, but we've been trading off CPU time for less developer time in every other area of development, so I don't see why it would be different here. To the extent that the OS itself is not what is causing you problems, you can keep optimising your app code as you go and release on cheaper and cheaper hardware if you want.
- cbdfghh 10y ago
  So what's the advantage of using Android over straight Linux?
  - Eridrus 10y ago
    The advantage seems to be that you don't have to worry about the details and you get updating for free. Writing good update code is hard and thankless, but you can certainly do it yourself. Not a tonne of benefits, but not a tonne of costs either. I'm sure Samsung won't use this, but this might be good for projects just getting off the ground.
  - stbtrax 10y ago
    some are: access to media frameworks, there are more android app devs and resources out there compared to whatever linux GUI framework you might use.
- Normal_gaussian 10y ago
  If you don't have a tight power budget hosting a 'whole OS' isn't crazy (though it doesn't mean it isn't wasteful). Most chips will use an RTOS for the timing guarantees, and they generally provide better power resilience than other OS's.
lgleason 10y ago
The Pico is a half a gig of ram. That is not micro-controller size, but it is still a little better.
mszcz 10y ago
That's what I've always wondered. What the hell are those things doing with these resources? I mean if you take a step back and just look at what their purpose is - operating a light switch or reading the temperature - the amount of resources they use seems ridiculous. I've been tinkering with the ESP8266 and it's got 64k RAM and that seems enough to get a TCP/IP stack, WiFi and even a simple web server.
- pjmlp 10y ago
  The issue is of scale, it is just a few euros difference. So unless you are mass producing and need to save each cent per unit, the comfort of using something more productive will always win out in total project costs (hardware cost + development time).
  - TeMPOraL 10y ago
    > the comfort of using something more productive This is reaching levels of absurdity nowadays. I mean, Android / Android Studio and "productive", compared on how you work with ESP8266? With NodeMCU, all you need is simple Lua, few console commands and a text editor. We're replacing that with a huge cow Android Studio is, shit ton more of commands and complexity need to operate it, and what? Now each new toaster, instead of shipping an uC, will ship a whole PC inside? :/.
    - pjmlp 10y ago
      I find the ESP8266 quite good, specially its successor ESP32. Given the programming languages we already could use on MS-DOS, both those chips are quite good. However, I bet Google is trying to put Android into those areas that are now moving from C and C++ to Java. This is the same game currently being played in HPT, it is cheaper to get Java developers, even with the increased hardware costs, than to keep writing trading systems in pure C++. Hence the pressure Oracle has got into improving Java's story in regards to AOT and value types. So if a business is just going to deploy a couple of units, the difference between $15.15 (ESP8266) and $39.95 (Raspberry PI 3) might not be significant, when adding the salaries and respective development costs on top. Of course, the best approach for those that care about Java and IoT is to just use a plain GNU/Linux distribution like Yocto and standard Embedded Java, instead of Android Java fork. But overall I agree with your dismay.
pjmlp 10y ago
> I know the entire IoT sphere is completely pants on head stupid these days but... Android. On an embedded product. That is what people asked for, apparently. The initial plan for Brillo was to replicate some of the Android frameworks in C++. "We incorporated the feedback from Project Brillo to include familiar tools such as Android Studio, the Android Software Development Kit (SDK), Google Play Services, and Google Cloud Platform." https://android-developers.googleblog.com/2016/12/announcing-googles-new-internet-of-things-platform-with-weave-and-android-things.html https://android-developers.googleblog.com/2016/12/announcing...
fest 10y ago
The general trend for embedded devices is in the direction of richer ways of user interaction. That usually involves adding touchscreen LCD. Once you add LCD, you want nice graphics, animations etc. While you can use microcontrollers for low-res LCDs, when you get past, say 640x480px resolution, due to increasing memory and CPU requirements it often makes sense to go with system-on-chip solution running high-level OS. The existing libs/frameworks to create nice looking, polished UIs for embedded Linux devices are not as easy to use, well understood and having large base of developers as Android is. So this leaves device manufacturers seriously considering Android. Working on software stack directly with SoC manufacturers is PITA (although they want you to buy chips from them, they don't want to spend time on support), so having a flavour of Android geared towards embedded devices is a good value proposition from Google.
IshKebab 10y ago
I agree. The minimum requirements for Brillo were already infeasible for most products. Now they want to use Java? Most IoT devices run on a Cortex-M or similar with less than 1 MB of RAM. That said, you don't have to use Android Things. I guess it's more a case of "if you have a system that runs Linux anyway, why not use Android Things?".

ndesaulniers 10y ago

From what I've seen, the automatic update system is sweet. I'm really glad the team decided to tackle one of the largest blockers to adoption (IMO) which was providing security updates.

taneq 10y ago
So all of my network-aware things are now going to have an excuse to demand internet connectivity so they can dial Google on a regular basis? I'm not sure that's worth the tradeoff.
- bitmapbrother 10y ago
  What exactly did you think the "I" in IOT stood for? Also, like Android there's no need to use Google services. Just patch it and update it yourself if you're so inclined.
  - tdkl 10y ago
    Local network connected devices that can be reached over the Internet if desired. You know, like PCs.
  - taneq 10y ago
    I was kind of hoping it meant "internet" in the sense of "I can connect to and control the device from my phone", not "the device will be sending data to its manufacturer". Hopelessly naive, I know.
    - kakarot 10y ago
      That is Intranet of Things, IoT's lesser known cousin.
    - bitmapbrother 10y ago
      Last time I checked using Google Services was still an option when using an Android phone.
  - 10y ago

mtgx 10y ago

From what I hear not only will all Android Things collect data for Google, but also all devices that use the Weave protocol (for which the device makers have to use Google's servers). That's crazy, if true. An IoT communication protocol shouldn't rely on Google or any other company to work. Imagine if your Wi-Fi router only worked if Samsung got to collect all the data that passes through it. This sounds even worse than when people complained that in some cases data from AMP pages would go through Google. At least then developers could still use the open source independent version of AMP.

theDoug 10y ago
Any sources? I ask in good faith, but it's also easy to say "from what I hear" then "that's crazy, if true" for nearly anything.
taneq 10y ago
Well, a fair few smart TV functions only work if you allow the TV to phone home (and agree to them using the built-in mic and camera to capture and upload audio and video at any time and use it for any purpose). This is another step beyond that, where your light bulbs have to phone home to Google and to their manufacturer.

lai 10y ago

Has anyone tried to get Android Things (Brillo) to work with other micro-controllers than the ones they support out of the box?

lgleason 10y ago
I'm not sure I would call these platforms micro-controllers. With that being said there is support for weave on a select number of micro-controllers.
anujdeshpande 10y ago
Brillo is for microprocessors (think Raspberry Pi, BeagleBone Black, etc) whereas Weave is for micro-controllers (think the newer Arduino's which are running a Cortex-M of some sort)
- IshKebab 10y ago
  Nope. Brillo (Android Things) is the OS. Weave is the communications protocol. You can have Weave without Android Things, or Android Things without Weave.

ClassyJacket 10y ago

Google's willingness to drop their projects really gives me no confidence as a potential developer. What happened to Brillo? Why start a new project with a new name instead of just making Brillo 2.0? Should I invest anything in this or will they just drop it again?

Navarr 10y ago
From what I understand, this _is_ Brillo. Just rebranded with some upgrades (e.g. "Brillo 2.0")
- ddeck 10y ago
  Yep. From the article: It combines Google’s earlier efforts around Brillo (which was also Android-based, but never saw any major uptake from developers) with its Android developer tools like Android Studio, the Android SDK, Google Play Services and Google’s cloud computing services. Support for Weave, Google’s IoT communications platform that (together with Brillo) makes up Google’s answer to Apple’s HomeKit, is on the roadmap and will come in a later developer preview
- pjmlp 10y ago
  Not just rebranded, they dropped the plan of having the frameworks redone in C++ as discussed at Embedded Linux talks, and took the Java ones from Android instead.

sker 10y ago

I wonder what will MS come up with to counteract this: Microsoft Windows Ultimate Surface Things.

monkmartinez 10y ago
I hope it is something cool. They have shown a remarkable willingness to contribute "something" to just about "everything" in recent memory. A lot of has been open to boot! I do not want to let you down, however, and will provide an equally inflammatory remark: We do know that Apple will continue to build walls around Homekit making it virtually useless to anyone outside the already fortified walls of iOS!
dano 10y ago
MUST - nice acronym
pjmlp 10y ago
They already did, UWP support for Window 10 IoT is older than Brillo/Android Things.

hardwaresofton 10y ago

As long as this version of android stays as open as regular android I think I'll be happy. It is super sad that Mozilla decided to leave this space though (even if trying to pivot FirefoxOS was nothing but trying to buy time). Wish there was a less insidious company trying to get into all my devices. Also, why "Weave" instead of just using Thread? ( https://en.wikipedia.org/wiki/Thread_(network_protocol) https://en.wikipedia.org/wiki/Thread_(network_protocol) ) [EDIT] - It looks like Weave IS built on Thread, though it's a little sad that it took me so long to figure it out: https://www.silabs.com/products/wireless/Pages/nest-weave-thread.aspx https://www.silabs.com/products/wireless/Pages/nest-weave-th... My knowledge of the Thread Group's management/scheme layout was lacking, it looks like it's INTENDED that thread is meant to be below one layer of abstraction, managed by different vendors (sillicon labs, nxp, etc)

rohan1024 10y ago
How about Canonical https://www.ubuntu.com/internet-of-things https://www.ubuntu.com/internet-of-things
- hardwaresofton 10y ago
  Thanks so much, haven't kept up with Canonical since switching off of Ubuntu, didn't know there was another option like this [EDIT] After spending some time looking at Ubuntu Core... is it just a smaller Ubuntu distro + managed updates? I do like the "snap store" concept... marketing jargon aside, it seems like Canonical is paying attention to both developer and user ergonomics more than ever [EDIT2] Ubuntu core & snapcraft.io are pretty exciting
astebbin 10y ago
Thread provides a network, but no application-level semantics. In other words, Thread is to 802.15.4 as WiFi is to 802.11. Once you've set up a Thread network, you still need an application layer like CoAP or Weave to control your connected devices.
- hardwaresofton 10y ago

winter_blue 10y ago

What's the benefit of using Android on a micocontrolller? Since these devices will likely have no UI, a significant chunk of the Android API will be irrelevant. Is the pro that you get to use Java with a (hopefully) friendly API vs writing in C or C++ as in the old days?

BoorishBears 10y ago
Why do you assume they'll have no UI? The displays are optional, not disallowed. For what we do at my workplace this is a godsend. We design installations for retail environments that need to have very rich interfaces. For us it's not MCU vs Android, it's embedded PC vs Android hardware. We were already doing similar things with stock Android except we had to use custom boards interfacing over USB to do anything involving sensors to stay somewhat free from specific hardware. We were running into limitations in Android that centered around the fact that it is targeting consumer devices first and foremost. Android 6 brought COSU mode, but it still showed signs of the steady march towards a more locked down Android. Besides the pro of supporting our usecase in a first class manner, having access to the Android UI framework or a web browser is big for those complex interfaces. The productivity gains vs trying to build up that stack from a bare ARM MCU are immeasurable in the literal sense (a separate company contracted to do something like that would probably have more employees than we currently have working on software) And of course, being able to hire Android devs and take advantage of the ecosystem doesn't hurt.

brutus1213 10y ago

I work in this space. While this platform looks a lot better than previous Google efforts, this is no way a solution. A key problem with IoT is too many standards that don't play nice with each other. And this is not a technical problem - everyone just wants control of the platform. If you think Android is open, you are being naive. In recent months, I thought things were going to get better with major consolidation between Iotivity and AllJoyn. This is not a step in the right direction. Oh .. and obligatory xkcd: https://www.explainxkcd.com/wiki/index.php/File:standards.png https://www.explainxkcd.com/wiki/index.php/File:standards.pn...

XorNot 10y ago
What I want is my IoT devices to get IP addresses and respond to a simple HTTP REST api. The semantics of it don't matter much to me, provided it supports SSL and avoids session-management BS as much as possible, but I'll deal. If you want to offer a cloudy service on top of that, I'll buy your cloudy-service box which offers to do that, but it better be using the same API to control those devices because maybe I don't want your cloudy box and want to integrate them with vendor B's devices or vendor C's + some homebrew stuff.
- brutus1213 10y ago
  I'm curious what kind of API would you want? There are so many devices out there, it makes things challenging. Best proposals I've seen define a base API for discovering what are other APIs that a particular device supports.