Nothing will change unless people actually report individual issues and work through the troubleshooting to figure out the root cause.
As far as the DS18B20 goes, those are known to be almost 100% fake. I do have some real ones I got 15 years ago, but pretty sure now (unless you pay $10/sensor) they are fake. These fakes have slightly different behavior and the esphome code doesn’t handle all the different fakes well, but mostly works for most people.
I get it if you are not interested in doing that troubleshooting. But, I took am interested in what you find that works better. I just started using esphome. I have a long history with Tasmota and esp8266 generally think it is great. But I don’t like it for esp32, since it takes too long to compile and has too much baked in and is hard to develop in for new stuff. I probably should just use platform.io, but that means developing a bunch of basic stuff before I get to solving my particular problem. esphome does a decent job of getting the basics good enough for me. I really like the OTA solution. Learning the details of how to make a good solution (more than the hello world of sensors) for many devices is hard. The mental model you need to have is not really clear. There are significant differences between esphome and Tasmota’s models. That is not to say one is right and the other isn’t. They are different and you have to learn how to hold them to get the results you want. That will be the case for any tool.
And you quote a breaking change that was foreshadowed by several versions.
You do NOT have to update every ESP device with every release. I have an ESP8266-01 temperature sensor using a DS18b20 in the attic. It’s been there five years and never updated. And it still works. But since the Dallas Component was replaced by “one_wire”, an update would require a change to my configuration. But it is working- so why update?
You didn’t read what i wrote above at all, didn’t you?
For start just one example: there’s THIS cheap chinese fake and there’s (one of many) THIS chinese original. Now you know what i mean?
I have quite some of those aliexpress fakes (from my starts), they tend to work ok for a year or two, sometimes i must calibrate them, and they are not as linear as originals. Depends what you want… When some of fakes go too far off, i replace it, if i need accuracy with original, if i need “informational value” with fake.
And a good example of another chinese original vs chinese fake chip: once famous MC34063A switching regulator: it should go up to 40V. Orignal, yes, but aliexpress fake explodes at 28-30V. And i mean EXPLODES. Just when i connect it to power, no load. Or LM2596 3A switcher. Exploded at under 2A if it’s fake. Etc…
The real DS18B20’s from US based distributors cost $6-10 each. The fakes from China usually work but are only accurate to one or two degrees. For most household uses, that is close enough.
Just for info: i bought fake dallas chips from reputable seller a while ago (i won’t name it, but it’s one of largest europe’s seller). They returned my money, still claimng that they are orignals. But i kinda doubt that 5 dallasses would die at over 80 degrees one after another, right?
You don’t have to apply every update but there have been some major breaking changes over those 5 years. You are going to have a bad time eventually.
I only update my nodes if I notice a breaking change that affects them. So once every year or so. There was a big one recently with the old way the board / device is defined finally being depreciated. I suspect that may be Richard’s issue, or that their wifi network has too many clients, but as they are not interested in a solution I guess you can ignore that.
Some people claim their potato () routers can only handle (active?) 20 wifi clients
Yea, quite amusing that Richard doesn’t present anything (yaml, logs or any facts really) but at the same time isn’t impressed were the thread is heading
And still Richie thinks waiting and watching (instead of troubleshooting and possible upstream bugfixing) will change something
Problem is that some router can give specs for 200 clients. But when it can’t handle all of them, it doesn’t give a warning or error. It just misbehaves, not expected way…
Sure is, but I still want to know the magical project that is so much better it is worth moving to. Maybe the grass really is greener over there and maybe that isn’t because it has a lot more fertilizer.
I just wanted to highlight this, because I think it’s something important that has been missed in all of the other posts I’ve seen in this thread. Have you considered that it’s not the hardware, or esphome? I have had routers that have notoriously bad multicast packet handling and it would destroy mdns, SSDP and other protocols that used multicast technology. I’ve also had devices that go haywire and prevent other multicast devices from being detectable on the network until the misbehaving device was rebooted or removed from the network.
So perhaps that problem isn’t all of your esphome hardware that was working perfectly fine until recently (especially considering your ‘off-the-shelf’ Apollo device), but something environmental? You could check this in a couple of ways - restart your whole home (breakers), take your all esphome and as many non-essential other devices as possible offline and bring them back on one at a time until/unless you hit the same issues, move the esphome devices to a different network (and location if possible) and see if you can reproduce the issue there. You can see where I’m going with this I think.
That is assuming you are talking about DS18B20. I have a long history with these devices. Even the fakes I have generally work, at least until they don’t. I have heard lots of people complaining about them on pretty much every platform. At various times I have written code to deal with them more robustly, so I do understand the frustration.
I do also recall reading issues on GitHub where devs were asking for samples because they were unable to reproduce the issue with what they had. I don’t recall seeing them get samples, so of course they were unable to make the code more robust.
I have also read where people suggest using a single sensor per line, since some failures will make it impossible to read any of the sensors if just one fails.
But, it does seem like @RichardU is so frustrated, doing anything more doesn’t seem like it is worth it. I have been there too. My compost pile is a harsh environment and it eats DS18B20 every couple of months or so.
If I do get to that situation then I would just flash it with cable and start over.
It’s far less of an issue than dealing with every single breaking change, since there is far to many of them on ESP-Home.
You must be incredibly unlucky. I can remember two that affected me in the last two years.
1-wire
Old platform/board config removal. I was surprised this had been depreciated years ago. I somehow missed it and kept using my boilerplate definitions for new devices.
I have had lots of issues with ESPHome too. I only use if for voice assist but their updates are often corrupt and not tested properly at all. Currently, my M5Stack Atom Echo is not functional because of the bad updates and they don’t offer previous working versions for burning either. Once you get a version that actually works, you should not update until the version has been out there for a many months and have checked the negative feedback first.
That is not a guaranteed solution.
I had a lambda code stop working because of an update.
All these breaking changes makes ESP-Home very hard to use.
I have no issues with HA breaking changes. They are usually announced long before it happens and it’s just one instance I need to fix.
With ESP-Home you have many devieces you need to fix and most of the time the actual change is not easily fixed.
I guess you can ignore that.
) routers can only handle (active?) 20 wifi clients 
