Haha, this is a KB-related thread, so it’s certainly not a bad thing.
We’re always looking to improve the docs we provide (especially when it comes to KB’s)
markusressel Managing ESPHome devices can be done in a myriad of ways, and I really like how the LocalDeck is designed around that.
Thank you for saying this! We had a lot of mixed reactions to having the 2 USB ports, so I’m glad to see someone else is on my side there :p
What I can say is that any devices we design have this ethos in mind; they’re not our devices that you use, they’re your devices that we provide. So you can expect them to be reflashable however you desire!
markusressel But to me this makes the product a little less attractive, because as awesome as ESPHome is, sometimes a wired reflash is what it takes to get it back to working, and I don’t like the idea of never updating the device either.
We’d be lying if we didn’t acknowledge this as a tradeoff.
Ultimately, making direct reflashing easier would pose significant risks that would need to be managed. Doing so and going through all the reassessments for certification would be cost-prohibitive for us, with very little benefit for most users.
I think I’m yet to have an ESPHome update actually fail completely, since most “failures” will cause a fallback! (touch wood)
Tasmota, I’ve had one or two die, but purely from misreading the docs around the minimal firmware… [LocalBytes YouTube / Switching Firmware / Oops]
For context:
I believe both Tasmota and ESPHome make use of A/B partitions in ArduinoOTA.
Tasmota is larger because “most” features are compiled in, so it explicitly uses a -minimal.bin.gz stage.
ESPHome is usually small enough, given its opt-in workflow for components/features, so it doesn’t have that separate binary.
Hope this helps!
—
NB, thanks to @MichaelMKKelly for the in-depth replies too. I love our community! ❤️
