The ultimate long term solution --- refuse to buy any home product that defies local control.

If a wifi password is required to make full use of the device, I will return it.

If some users want to sacrifice security and privacy for "convenience", that's on them. But if you want to sell me the product, at least provide the option to decline without loss of functionality. Otherwise, no sale.

As an example, I refuse to buy a doorbell camera that doesn't support RTSP.

The result of this process is that the air purifier boosts when the air quality inside drops.

I feel like that is something that doesn’t or at least shouldn’t require a string of IoT devices, apps, wireless communication and hubs. Why not leave all of that out and just attach an air quality sensor to the air purifier and a small LCD to adjust the settings?

The light in my hallway turns on automatically when I walk past. No cloud, no HomeAssist, no WiFi, no Zigbee, no apps, no batteries to change. Just a motion sensor hardwired to the light fixture. Hasn’t failed me once in the past ten years. Works great even if the network goes down.

For vendors of ESP32-based IoT devices:

  Give a man a fish, and you feed him for a day.

> My intentions were solely to upgrade the smart device I've purchased to integrate with my smart home system. Doing so does not affect any other instances of this product or its cloud services.. sensitive product-specific data, such as private keys, domains, or API endpoints, have been obfuscated or redacted.

For owners of ESP32-based IoT devices:

  Teach a man to fish, and you feed him for a lifetime.

> Creating an open-source project to de-cloud and debug smart home products; I've learned much more about the technical aspects.. I put a massive amount of effort into creating [this post].. probably more than.. the project itself. It would be amazing to receive feedback on the format!

blog author: https://x.com/jmswrnr

I wonder if it would be possible to figure out which pins are connected to what on the device's board and just flash the thing completely with ESPHome and write a custom yaml config for it, rather than adapting the existing vendor firmware.

Very nice article!

Every time I was part of a team designing IoT devices, there would be a slightly more security-focused engineer who would manage to have some level of protection for the boot. I'm surprised there was no resistance here to dump and reflash the firmware. Why would they not even bother encrypting the flash? How common is that?

It would have been nice to give the product name.