I only have esphome on a dev pi (and no backups). I did load the dev version today and it still doesn’t work with my ESP8266 NodeMCU. Really happy I turned away from this BS 6 months ago when I had a few issues with Tasmota, dabbled briefly with esphome but went back to Tasmota thankfully. It seems esphome isn’t getting any attention to fix this wifi issue and it’s been an ongoing issue for a long time now.
Agree with your “you should not upgrade something that is working well unless there’s a compelling reason” for critical situations, like yours.
Thanks for the roll back tip in Hassio, didn’t thought about this.
I did like Tasmota and still do, but ESPHome has IMHO more positive sides and especially the way it bypasses mqtt is for me attractive. This was my first quarrel with ESPHome and it is solved for now.
As for mqtt… I also don’t see much love between HA and mqtt (in future) so I try to shift way from it. But I’m still using mqtt for many things.
1 Like
MQTT is never going to go away.
Rendering devices inoperable as the latest esphome does is somewhat a killer don’t you think?
I only use esphome for one specific device (an dot-matrix screen) and it did some cool things… but then 0.14.x bricked the esphome and there seems to be no interest in fixing it. Luckily I got a esp32 and that works with the exact same code. But I will avoid esphome from now on and just use Tasmota which I find apart from the 2.4.2 core debacle to be 100% reliable and solid.
It doesn’t matter how good a ‘native api’ is if it bricks devices!
When did this happen?
I just flashed ESPHome v1.14.3 two days ago on a Sonoff Basic and it is working fine.
1.14.0 for me. There is a VERY long issue about this and many people here had the same experience. It seems to be hit and miss wether or not you are affected but these WiFi issues have seemingly been a long time issue that is getting worse with every release… Lets face it, there have been 4 releases now in just a few weeks. 1.13.6 was working fine for me but there is no way to go back to that. The official method doesn’t work for me and I don’t have a snapshot of my dev pi to use…
Hmmm, I hadn’t heard about those issues.
I was running 1.13.6 before a few days ago and then updated because I was having issues with the same flashed Sonoff basic flashed with 1.13.6 not connecting to my wifi and thought that maybe the firmware was squirrely. In the end I don’t think the issue was ESPHome but it was some kind of strangeness with my network where it wouldn’t connect using a specific IP but it would on another.
which makes no sense when you think about it. With my nodemcu, I can flash Tasmota on it and it works fine (same IP address is used with esphome 1.13.6) It also does connect to the network (I see it in my router) with 1.14.2+ I think but the famed api - no connect and I can’t view the log either so esphome just won’t connect to it. It’s very frustrating and the deafening silence from the dev about it makes it even worse and as I said, plenty of threads here about issues with 1.14.x as well so it’s common.
I agree.
Maybe it actually was ESPHome as I originally thought and I just didn’t realize it in the end and thought it was my network.
I never use(d) fixed IP addresses in Tasmota so I didn’t really have that to compare.
hi guys,
can someone recap what is the situation?
I am facing problems with some devices flashed with 1.14.3 but I also have a lot of other devices around the house (in hard to reach places!!!) which are working well.
I will not flash them over OTA again unless a new version comes out.
I see rolling back to 1.13.6 is fine but this doesn’t work for me on HASS.IO plug-in config and I do not have a backup with 1.13.6 
Hi @mspinolo, I’m afraid I don’t really know. I lost interest in trying to solve it once I managed to roll back to 1.13.6, because once again everything just works. However, increasingly I am looking at reverting to Tasmota for switch-type devices, and using ESPHome just for custom devices.
In my experience, I was able to get 1.14.3 to work by manually specifying output_power: 17db in the Wifi section, but what I found was that I would get a much larger rate of disconnections from HA, where a device would connect, disconnect, connect, etc.
That’s why I went back to 1.13.6 - it’s stable.
I’m sorry to hear you are unable to roll back. That sucks.
Interesting… same conclusion I reached.
I have been thinking about this (having the same issue) I’ve been meaning to try this using a command line rather than the hass.io addon… or even just pulling a docker container - not using the hass.io addon as I think then I can control the version. I only have an issue with the one device running esphome and it’s not something I can use Tasmota for or I would. I solved it by using an ESP32 which seems to work ok but I’d love to ‘fix’ the esp8266 nodemcu just cos…
Hi,
I couldn’t find any reference in the documentation about
output power
Could you please make an example of the right syntax to use?
Also when you say reverting back to 1.13.6: did you flash devices with firmware compiled with 1.13.6 via OTA?
I have a spare Linux box and I could eventually do with it!
Sure. In your wifi section, put something like this:
wifi:
ssid: "yourSSID"
password: "yourPassword"
output_power: 17db
And that’s it. Some people have reported success with 17.5, others with 20. This is not a magic bullet. It’s just something that works on some devices.
As far as reverting to 1.13.6, yes, I was able to flash OTA, once I had rolled back to 1.13.6 - but only for devices that were still “alive” and readable by Home Assistant. So if something was running 1.14.3 and was showing up in Home Assistant, then OTA flash to 1.13.6 is possible.
But if a device was “bricked” by 1.14.3, I had to fetch it out of the wall (and out of the roof) and manually flash it.
Here are the lessons I have learned:
-
Never enable auto-update, of anything, ever.
-
When considering deploying a new version, test on a sacrificial device, on a test bench. If you don’t have a device you can just throw away, and you don’t have a test bench set up, then there is no reason to upgrade a working setup.
-
When installing smart hardware, avoid putting it in areas that are physically hard to reach, like the roof. It is better to put the ESP board in an easy-to-reach place like a cupboard or a store room, and run additional cable to reach the light. It is not easy to do this, or convenient, but when things go wrong, it makes life easier. I will bear this in mind for future installs because I am too old to be crawling between the rafters again - it takes days to recover.
Ultimately, this is a hobby, and we build our systems ourselves. The software makers have no responsibility towards us, and we have no right to demand anything from them. But therefore we also have to take responsibility for what we deploy, and how we do it, especially if we start to rely on this technology such that it becomes an important part of our lives.
When I had 1 or 2 ESPs in my home, it was very easy and fun to always install the latest stuff. But now that I have 30-40 around the property, running my home, controlling essential services like water supply etc, I have to change my attitude and be more like a company. I must ask myself, is there a compelling reason to install this new update? Is it a crucial security patch? Are there essential new features that I actually need? And if the answer is yes, then I must first test on the bench, and only deploy widely when I am satisfied that it won’t do harm.
3 Likes
Hi @mspinolo, had the same problem with ESPhome version 1.14.3 and Hass.io. Tried many things without much succes. Finally tried the dev version and that worked for me.
My ESPhome Sonoff Basic’s are now on version 1.15.0 dev.
To use the dev version is easy by changing the config in the Hass.io ESPHome addon to:
{
“esphome_version”: “dev”
}
They are now working fine for a few weeks. But haven’t tested OTA on them (as there is no new version at the moment).
ah cool, thanks for this hint!
I have a couple of sonoff basic bricked which i will test on 1.15.0
EDIT: tried and confirmed it works for me as well, although I didn’t do extensive testing
3 Likes
Hi @DeeBeeKay,
fully agree with all your statements.
In particular I believe EspHome Devs. are doing a great job and should not be blamed: at the end we get all for free and putting our effort to make sure we don’t create our own issue.
In order to be proactive I was thinking something which could help is in case of critical “bugs” like this or ESP32 wifi/BLE issue it could be really helpful to put an alert on esphome main page?
I am sure lots could be done to prevent a repeat of 1.14, but at the end of the day I would ask… did it really HAVE to be released that way? Most times folks expect major issues like that to be part if dev/beta, but for release it seems a bit premature, no (seems like little to no actual hardware testing done, which is nearly the definition of beta)?
This was a bummer thread to find, but at the same time it’s for the better… my first set of sonoffs is arriving today (s31’s just arrived, basic r3’s out for delivery) and I already had my esphome configs ready to go. Could you imagine the feeling of your first brand new sonoff’s appearing bricked? I know it’s not really bricked, and some probably nearly started fires their first time, but this wouldn’t be my first foray with esp + line voltage. Usually if I have a good plan, the release software will do the job… this case would have been a total failure of course, if I didn’t see this thread first.
Since I’m not far down the rabbit hole yet, I will give the dev branch a try and see how it goes. I feel like I need to get something out of the past day I spent learning esphome before I decide to just go tasmota, LOL. This is all so fun and easy to play with anyway, compared to how I was doing things (bare esp-12 modules & arduino/pio)
I managed to temporarily brick one of my Sonoff basic R2 devices last night as well.
I do however remember that this was an issue with some Tasmota releases too –
I’ve since moved my device over to Tasmota 8.2.0 (after having to remove it from a distribution box at 1:00 AM) and seems much better so far.
I disagree, we can demand anything. Whether they will listen is another story. I just think if you can’t test it before offering to the user, then don’t offer that update, period.
It’s NOT okay to brick devices. Whether the developer is working for free or getting paid doesn’t matter, when you’re offering a product you shouldn’t offer something that’s broken and yes this is software so bugs will come from time to time however they simply don’t seem to care about this issue, it’s been ongoing for more than a year.
I am still running 1.13.6. I hate running old versions of anything, it’s a security risk.
1 Like