So, why does this device need such processing power? Can this really be cost effective?
The software complexity of these protocols is greater than the complexity of a rudimentary 3D game like Doom, so it's expected that whatever chip can run these protocols can also run Doom.
Datasheet of MGM210L for the curious: https://www.silabs.com/documents/public/data-sheets/mgm210l-...
Also, higher clock speed = lower power consumption. It sounds counterintuitive, but getting the job done quickly so you can go back to low power mode sooner actually saves power, even if the instantaneous power draw while processing is higher.
The WiFi, or BT protocol stacks themselves are however almost always in software on MCUs simply because nobody would bother making a separate ASIC IP for that which will be outdated by the next standard errata.
The real reason is it reduces the cost (and duration) of iterating in the development phase.
The chip is SoC with Arm core, FP, Crypto Acceleration, DSP extensions and FPU unit plus radio parts.
And this also assured it being dead on arrival.
Tuya on other hand is just in every retail outlet, it's just people don't know that Tuya is under the bonnet.
They literally have more talkshops per months than devices released.
That's unfortunate. Protocols, particularly those used for security should be a simple as possible. I know it's a hard problem and people tend to use what is available rather than solving the hard problem.
You could probably find exactly the right chip that only has exactly just as many bits of RAM as you need for the lamp's functionality. But that would probably be more expensive to develop and chip than just using standard parts?
Even more radical: I suspect with a bit of cleverness you could probably do everything the lamp needs to do with some relays and transistors. But today, that would be more expensive.
Compare https://www.youtube.com/watch?v=NmGaXEmfTIo for the latter approach.
Interestingly, a friend rented a house in college once that had a system of low voltage light switches that ran back to a cabinet filled with relays that controlled light switches and outlets. No major benefit to the user other than a control panel in the master bedroom that lets you control the exterior and some interior lights. It was a neat system but definitely outdated. I'd imagine a retrofit would be to drop all of the relays for solid state and provide a networked controller to monitor status and provide remote control.
These IKEA smart bulbs cost about $9 so yes, it is cost effective.
https://hackaday.com/2019/04/26/making-a-three-cent-microcon...
Chips that can run Doom, though, are just about at the low end for internet-connected devices. You can't run an IoT stack on that $.03 thing. The chip in the bulb is exactly in the right ballpark for the application. You do need a fairly beefy chip to run multiple network protocols efficiently.
* Cost effective solution for lightbulb would be not having it wireless connection at all instead of having less powerful MCU. So it being IoT already means that target audience doesn't care about the price that much. * It uses of the shelf FCC certfied wireless module with embedded antenna. For product designer it makes sense using a ready module because it avoids need to do RF design and the certification.It also simplifies the design if you run your user application inside the wireless module instead of having an additional MCU communicating with wireless module. Such modules tend to have medium to high end MCUs.
Why do wireless modules need such processing power?
* 2.4 Ghz Antenna has certain size requirements so the size constraints for rest of the system aren't too tight. * Wireless circuitry puts the module in certain price category, it makes sense to have the MCU in similar price category. Wireless certification is a pain, so there will be less product variants for wireless modules compared to something like 8bit micro controller which come in wide variety of memory, size and IO configurations. If you have single product variant better have slightly more powerful MCU part making it suitable for wider range of applications. * The wireless communication part itself has certain amount of memory and computing requirements. Might as well split the resource budget on the same order of magnitude for wireless part and user application. N kB of memory for wireless and N kB for user application instead of N and 0.001N especially if the first part can easily vary by 10% or more due to bugfixes and compiler changes. Similarly there are basic speed requirements for digital logic buffering the bits from the analog RF part and doing the checksums. * Modern silicon manufacturing technologies allow easily running at few tens of MHz so if the SOC has memory in the range of 30-500KB and isn't targeting ultra low power category it is probably capable of running at that speed.
Plus how else will malware people run their stuff?
If you had to design an IoT bulb, this is the ideal setup.
In other words, it does connect to the internet, it also sits on the LAN to give attackers access to all your other devices, AND it sits on Zigbee to give attackers access to those as well.
And if you have attackers on your LAN, you're at the point where controlling your lightbulb is the least of your problems. As for Zigbee, go on, present your alternative - I'm all ears!
Source: I run a HomeAssistant local IoT hub and to integrate it with Google Home I had to give it a public hostname and sign up as an IoT vendor with Google to register it as a developer/testing mode service (if I were a real vendor it would be one cloud hub for all my customers, it wouldn't be Google to individual homes, it's just that in my case there is only one user and the server is at my house).
Here's how you hook up Home Assistant to Google cloud. As you can see, turning it into a cloud service from Google's POV is required. You can either use Home Assistant Cloud (see? cloud service) or set up your own single-user cloud integration (which is what I do), turning your "local" server into a cloud service (with public IP and SSL cert and domain and everything) and registering yourself as an IoT vendor in their developer console, pointing at your "cloud" service URL.
https://www.home-assistant.io/integrations/google_assistant/
There is no way to keep the entire system local and have the Google Home devices only access it locally, without any cloud infrastructure. The commands flow from Google Home devices, to Google's cloud, to the vendor's cloud, to the vendor's devices.
Bulb --> Zigbee --> Zigbee Gateway --> WiFi/eth --> LAN --> Your router --> WAN --> IKEA cloud --> Google cloud --> WAN --> Your router --> LAN --> WiFi --> Google Home device.
If that sounds stupid, congrats, this is why they call it the internet of shit.
EDIT: Perhaps the terminology got somewhat twisted around here: when I talked about the LAN gateway, I meant specifically the thing that does Zigbee-LAN "translation". Now, that same physical box might also have the capability to work as a Zigbee-Alexa or Zigbee-Google transaltor, which would require a vendor server as you said, but those options are, well, optional. You can certainly disable them and use something like HASS or openHAB as the bridge to whatever cloud service you wish. Same way that my home router has a built-in VPN feature, but I don't use it because I run a VPN server on my NAS instead.
For example, I had to work out that in order to get Broadlink devices to stop rebooting every 3 minutes because they can't contact their cloud crap you have to broadcast a keepalive message on the LAN (it normally comes from their cloud connection, but their message handler also accepts it locally, and thankfully that's enough to reset the watchdog). This involved decompiling their firmware. I think that patch finally got merged into Home Assistant recently.
My point is that this is not the intended use for these devices. Normal people are going to put the gateways on the internet and enable the Google integration; in fact, it's quite likely that they will sign in to some IKEA cloud service as soon as you put the gateways on a network with outgoing internet connectivity, even before you enable the integration.
When you’re away from home, iCloud will be used, and no IoT vendor systems come into play. This means that all IoT devices can be kept offline and limited to your LAN. The connection would be Bulb —> Zigbee —> Zigbee Gateway —> Hone Hub (Apple TV or iPad or HomePod) —> WAN —> iCloud —> WAN —> iPhone.
> Hone Hub (Apple TV or iPad or HomePod) —> WAN
This is how some IoT devices work. As far as I can tell. IKEA has no servers or infrastructure for their devices. And the Apple/Google hubs manage everything for them.
These days Google Home has local fulfillment, but that seems to only be offered as an addition to cloud fulfillment. It always has a cloud fallback path.
Here's how you hook up Home Assistant to Google cloud. As you can see, turning it into a cloud service from Google's POV is required. You can either use Home Assistant Cloud (see? cloud service) or set up your own single-user cloud integration (which is what I do), turning your "local" server into a cloud service (with public IP and SSL cert and domain and everything) and registering yourself as an IoT vendor in their developer console, pointing at your "cloud" service URL.
https://www.home-assistant.io/integrations/google_assistant/
There is no way to keep the entire system local and have the Google Home devices only access it locally, without any cloud infrastructure. The commands flow from Google Home devices, to Google's cloud, to the vendor's cloud, to the vendor's devices. There is a bypass path these days for local access, but it is always in addition to the cloud path, and only an optimization.
I know this because I run some local Raspberry PIs that pretend to be WeMo devices and I'm able to control them without any cloud connections from the PIs. The echo discovers the WeMo devices via upnp.
This has been a thing for quite a while[0].
I believe you are correct that Google Home has no local network device control.
[0]: https://hackaday.com/2015/07/16/how-to-make-amazon-echo-cont...
Big difference from what?
You do realize that the vast majority of remotely exploitable security vulnerabilities are in software which can be commanded from the Internet, right?
You could exploit the cloud service directly and gain control of the device, but that's like stealing the security guard's master keys - you can't call that a vulnerability in the door lock, can you?
If you buy the dumb remote, you get a useful smart light setup with no internet or even local network connectivity. Its useful because you can turn a room full of lamps on at once or adjust their color.