[quote=“orange-assistant, post:39, topic:340828, full:true”]
BTW: esphome actually had already a dallas-auto-setup-sensors (pr) but it was reverted:
WOW that’s [maybe] too bad! I guess they have their reasons. Thanks for that background info. I’ll take a look. To me, having to compile the sensor ID’s into the firmware seems less than ideal. That’s the kind of stuff that car makers do these days which makes them harder to repair. I came over to ESPHome because I liked the fact that firmware was custom compiled but burning the sensor ID’s in seems going a little far.
Apologies for the shouting earlier in the thread. Someone else came in picking an argument, not understanding many things – including that I was trying to build a system that was as robust and easy to use as possible. I completely agree with you on that! That’s why I was going to the trouble to try make swapping sensors possible – should one go bad should I not be living nearby or get hit by a bus and not be able to help. I am installing them with JST connectors, and will have some spares left over, so they’d be super easy to physically swap.
You could then just already pre-configure all the spare sensors in esphome. It will then be possible to swap then. Anyhow I use ds18b20 for many years (including in water tanks which go up to 85°C) and none died.
On the other hand you maybe want prepare a spare esp too (hardware can fail) - not sure how “plug’n’play” you get that but firmware wise it should be no problem because with esphome you can easily reproduce devices, just use the same yaml and flash it to another esp.
And the only solution for this (imho) is esphome because it has all logic and settings burned into the binary and will not loose it’s config like tasmota, espeasy and others tend do (intended or unintended).
That is good to know. These do seem like nice robust devices and the price is excellent so I went a little crazy and ordered a few dozen. I want to put them all over my parent’s HVAC systems (they have two) and maybe monitor the temperature at the back of the blower fan motor, ambient temp in the attic, and near the roof vents and fans that bring in outside air. Each unit will have at least 4 temp sensors – incoming/outgoing refrigerant lines and incoming/outing air temp in the duct boxes.
Yes, that is a good idea. My parents live in the desert and I think the temp in the attic must get above 120F in the summer. So I have been wondering how the devices will hold up. The esp and dallas devices are so cheap that I may just build live, redundant systems. I’m hoping to put enough sensors up there that I can help diagnose any HVAC problems remotely for them, and be able to ensure the system is running at peak efficiency. I even got some float valves for the pans under the units to capture condensate if it isn’t draining (a problem we had over this summer on one unit). For another problem, we were running around with a laser thermometer trying to understand what is going on but since these dallas sensors are so cheap this will be a much better solution.
For the attic/HVAC, I’m going to have so many sensors in so many locations that I may have multiple ESP units handle it. Probably 1 per HVAC unit at least, maybe more if I break out the airflow sensors onto their own ESP boards.
Funny — I woke up this morning wondering about if Tasmota does lose the settings!
Regarding burning the Dallas ID’s into the firmware – my main point is that these ID’s should not need any config at all. I feel that the device handler should simply report what is on the bus, like a switch or router. If someone puts a sensor on the bus, they likely want to hear what it is saying… so just pass it through whatever ID it gives.
But I guess the dynamic nature was why the code was reverted – they said they didn’t want constraints because some “weird components start to dynamically create components.”
I know you said you hate MQTT but it seems like the perfect thing for this. Maybe it would be a workaround if that would allow ESPHome to avoid creating individual components for each sensor. If the integration simply sat there and spit out MQTT messages like a “router/switch” between the Dallas bus and MQTT, it might get around the normal ESPHome/Home Assistant component integration methods.