Amazon Common Software for Devices
developer.amazon.com
developer.amazon.com
Realistically, Whirlpool just isn't going to be able to field that team to make their laundry machine resilient to malware attacks or a bricking update.
I always thought the only way forward with IoT was if it a big tech player offered an SDK / IoT platform that allowed developers to focus on the widgety part of their widget without having to think about the complexities of running an internet connected device. This seems like a big jump towards that.
(I worked at a wifi router company.)
"Pray we do not alter the Terms and Conditions further". Walled gardens, app stores and closed ecosystems are FAANG staples at this point.
I think in many cases the technical delivery risks (say, having crappy updates, janky apps and the odd CVE) seem more survivable than taking on those kinds of business risks.
Everything I have since read about the major mobile hardware/phone companies taught me to stop over estimating the ability for organisations who are monomaniacally focussed on exploiting initial (fluke by statistical measures) in SF insights implemented by early engineering focus by arguably genius minds, have no ability whatsoever to understand how anything can interoperate or even coexist, because they are hell bent on protecting the boundaries of their product features and technology surface.
Our offering comes down to three things:
1. Pre-certified hardware modules (open source [2]) that support WiFi or Cellular in a few form factors.
2. An on-device OS (also open source) that handles communication in the background and abstracts away the hardware using an Arduino-like API.
3. A cloud-based "command center" (closed source) that allows you to link up your backend services with events flowing to and from your devices via webhooks, manage over the air updates, and see connectivity metrics across your fleet. No data is stored - just ferried between your devices and the other end of the pipe that you configure.
Oh, and you can buy our devices off-the-shelf in small volumes and get them up and running in a few minutes!
I see that your dev kits are more expensive than pure ESP-based boards but aside from Argon (which is an ESP32 with an extra processor), it's unclear why. Photon, P0 and P1 all have an STM32F205 which is much less powerful than an ESP32 yet the P0, which is a raw module, is more expensive than the retail price for an ESP32-PICO-KIT, which is a full dev board. The Cypress chip doesn't look to be anything special either.
Is there something I'm missing?
Our core products are our cellular modules, as the certification burden on them far outweighs the process for WiFi modules (PTCRB, carrier certs). While we definitely have customers that use our WiFi products in a production capacity, generally our customers use our WiFi portfolio to prototype in their offices and then migrate to a cellular module for their end product. Saves cost and complexity when you just want to get something working, and our DeviceOS allows you to use the same or similar publish APIs regardless of the underlying connectivity technology.
When you purchase one of our modules, you are buying into a proven and tested platform that is guaranteed to work with our cloud. You just need to make your hardware and set up your backend. We handle the rest. Additionally, we don't make a lot of margin on our hardware - it's not the business we are in.
In terms of processing power, we target applications that don't need to crunch numbers. A great way to describe our platform is a "pipe" that takes your data from some sensor out in a field and drops it in your cloud backend/database. Our best applications are ones in which someone needs to answer "where is my device?" or "how is my device functioning?". In these verticals, it's all about data transmission rather than processing. Often these devices are battery powered and geographically hard to access. They spend a lot of time asleep, and when awake want to consume as little energy as possible.
The IoT landscape is vast, and we have narrowed in on a set of solutions that work well with specific verticals. Our product isn't a fit for every situation, as you have pointed out. For the ones it does fit for, we can provide significant value as a platform.
Of course, not everyone follows this line of thinking; due to their cheap, accessible hardware there are innumerable people with Arduino/ESP8266 experience, which might lead people to attempt mass produced projects with them.
That was my experience exactly. I've been working on an embedded project for work and since I'm so used to using the ESP32s at home, I chose them without much thought for work as well.
> [2] https://github.com/particle-iot
Wait, what? Open source cellular modules? Can you point me to something? All I could find in the linked repo was some helper utility to address a couple of modules.
I don't know if I missed it before, but the products I'm seeing on your site now really look more suited to what I need than they did back then. I've done a lot of network programming and IoT work, but since connectivity is such a minor feature of the machine, it would definitely be preferable to have a smart module to abstract away most of it for me.
Oh, well. There's always next time :-)
I think you're just using Whirlpool as an example, but they're not a great one. They have a fairly large IoT group that spans their entire ecosystem. (I'm a vendor in said ecosystem, and work with them on a weekly basis).
Your point is well taken, though: I work with many smaller companies on their IoT products, and they aren't in a position to manage their IoT projects.
Yes, well hopefully not _a_ provider who will lock their customers into a proprietary platform. Hopefully many providers so manufacturers have options to choose from. Even better would be if there is an open standard, and then providers can compete on providing a better implementation.
Qualifying new vendors is a pain in the ass.
If I'm the guy at the end and I'm good enough to build the device, I don't need the rent-seeking guy in the middle.
If I need the guy in the middle, I, by definition, am not good enough to be the guy at the end building the device.
You would be amazed how many of the big players are doing exactly that. But I shouldn't talk about it any more, I work for one.
It merely remains for IoT device management to achieve the same level of maturity as plumbing. Wait a couple of millennia, we'll get it right.
I bet you've got some stories to tell.
At some point, you may want to version your apis in a breaking way. You'll spend weeks sketching out a migration plan for all active routers in the field, sell it internally , get a thumbs up, then try to prep customer support. Customer support might tell you that you still need to support some devices which were unplugged on a firmware released 6 months ago. Oops.
When building deployed firmware, you always need to include a reliable fallback that allows you to bump the firmware on that device, even when it can't talk to anything else wirelessly.
+1 to AMZ for their investment in FreeRTOS.
"We can solve any problem by introducing an extra level of indirection."
I'm extremely skeptical that this solves any particular problem other than for Amazon building devices, silicon vendors who want to be in Amazon devices. Which is fine, but the scope of this seems to be broader. It just doesn't sound like the right idea to me.
The biggest issue is the "common" part. You want to produce an api or abi common across OSs? How many chances do you have to get it right and not run into a web of api version bugs & issues? Who has made this successful in the past? UDI? (nope) And then you want a common api across an RTOS and Linux? Good luck.
Oh and by the way, where's the source code for this middleware?
I don't know why you wouldn't take the approach of making the underlying OS's easier to work with. If FreeRTOS is missing something, enhance it. If embedded Linux(s) are hard to integrate with, start an open source project to work on that problem.
"Can" amazon, if they wanted, abuse this? It seems likely all the technical items are in place that they could. I don't see why they would, you are voluntarily putting everything they want into the device for them.
It would be nice if they could do stuff such as updating the Linux distribution.
To update ubuntu with greengrass we made a lambda.
That said, this is solving a lot of real-world problems, and I'm glad to see them moving this forward.
Edit: To be clearer: I hope the products get better and more compelling. I don't look forward to the attempts at vendor lock-in :-)
That is to say, potentially lethal, but protected against by education, not having sockets in the bathroom, and having RCD protection on sockets.
Basically it allows vendors to plug this low-level wrapper on top of their hardware's OS so they can easily add things like Alexa capabilities without writing their own API for that.
From what I understand, this is more or less what it does. It's like OpenWRT but for IoT devices and with the single purpose of integrating Amazon's SDKs in your hardware.
They may have more success than Apple has had, but I'm not so sure the incentives are in place to make general IoT devices less terrible.
I got it working for my Phillips Hue devices maybe twice before I ended up going the DIY route.
Also a win for AWS, of course, as this would make it easier to use their services.
But the problem is that most hardware makers either refuse to realize that they're bad at making software.
I'm a "fan" of what Apple tried to do with HomeKit ecosystem, but vendors hate it because it removes some of their control, and also is a pain to get right, so the whole thing ends up looking terrible even though the ideas and implementation are solid.