I’d like to draw attention and solicit input on a use case that seems under served by ESPHome: as a native first class firmware for commercial products.
My impression is that ESPHome mainly caters to enthusiasts who want to build their own sensors or retrofit cloud-based products to use them with HA, where the expectation is that the user authors the configuration file.
Now think about it from the perspective of a manufacturer. I want to foster open source and privacy friendly options, but also deliver a plug-and-play experience to users on many different (cloud) platforms. Uploading custom firmware is encouraged, but only for advanced users.
ESPHome offers some compelling features, but I see many manufacturers build from scratch or fall for Tuya. What I’m looking for is an open source Tuya that is a compelling platform for businesses to build around.
I think the recent OTA platform change is a great step in this direction. It would allow me to host binaries on my servers rather than having to tell customers how to flash them manually.
I think there could be some UX improvements to make various user-specific configurations available in the captive portal. For example, setting an API secret or MQTT message broker IP.
But the biggest gap seems to be integration with cloud platforms which makes it an immediate no-go for a commercial product. There doesn’t seem to be any way to connect ESPHome devices to Google Assistant, Alexa, HomeKit, or others without going through Home Assistant (Cloud).
It seems Tasmota has better support for this by pretending to be a Hue device or via Matter. But AIUI Tasmota is in general not as suitable as a native firmware due to its GUI based configuration. Maybe I’m mistaken, or missing some other options?
Curious to hear your thoughts on first class open firmware for commercial products.
Well perhaps I missed something but that’s the first feature and very important one of HA, it doesn’t depend of any cloud or third parties ! If you want to do these you can do it still in HA but no point to do it in ESP devices themselves
For info Athom for example that sells ESPbased devices with ESPHome firmware works perfect without any cloud feature in it (all clouds things if you want them can be done in HA itself
I do see the point in cloud support. All the devices I look at on Amazon or Ali prominently list “works with” for all the cloud providers. The average user might look at your device with just one “works with HA” icon and figure it’s an under-supported outlier.
So, how would you put more “works with” labels in the ad for your ESPHome device?
One way would be to be dishonest, like many of the others. Next to “works with Alexa” you’d have an asterisk, and a note in the fine print that says something like “if you use it with HA and the Alexa integration.”
This is not a HA question. The vast majority of people do not use HA. Designing a product that only works with HA has a minuscule market. If ESPHome is only suitable for use with HA it has no place as a first class firmware for manufacturers. That’s how you end up with even European manufacturers choosing Tuya firmware for their products.
Yes, you love HA, I love HA, we all love HA, but if I’m developing a product I need a firmware that my users can use out of the box with Alexa or what have you.
ESPHome is incredibly powerful, and I believe could be a Tuya killer, but only if there is a way to provide a good out of the box experience for customers with one of the cloud based platforms.
ESPHome works well enough without Home Assistant. You can author all manner of devices that perform all manner of functions, with sensors, buttons, displays, etc.
At the moment, where this falls down for use as a base for a commercial project is that I can’t find a way to create some kind of hash/key for OTA firmware updates, nor a way to disable the OTA update feature on the captive portal.
That means:
When your customer first sets this up by using a captive portal, in addition to selecting their WiFi network, they’ll see a big button to update new firmware
Any firmware can be flashed - what prevents someone from bricking the device by flashing some random esp firmware?
A lot of people are willing to go open, but guide-rails are needed. Someone buys a remote button controller and then accidentally flashed a thermostat controller firmware to it.
An ESP board is $3-5 - but if someone pays for a finished product that has an ESP built-in, they’re not looking for a simply $5 development board.
This is why other ESP solutions can prevent flashing random firmware.\
So as it stands, ESPHome is completely unsuitable for a commercial product and lacks features to make such a product polished to a suitable level for non-developer use.
Is the concern that someone buys your ESP-based widget and accidentally flashes new firmware to it?
Those who have the knowledge and skill to flash firmware to an ESP device are highly unlikely to make that mistake. They’re also highly unlikely to blame the manufacturer if they do.
The vast majority of customers don’t have the knowledge, skill or inclination to flash the firmware, so they’re not going to have this problem in the first place.
On the other hand, a nice hardware package which happens to include an ESP device we can flash with our own custom firmware would be a selling point for many of us.
Well don’t use it then. Stay in your walled garden.
EDIT to point out that Athom don’t consider this a barrier, nor Apollo automation, nor Elevated Sensors, nor Everything Presence, nor Elecrow, nor LocalBytes.
