Hey everyone… is there a simple auto-recognition and auto-configuration option for the Dallas DS18B20 in ESPHome once you have set up a Dallas one-wire GPIO pin? I believe that in Tasmota you don’t need to hard code the sensor’s internal address and they just appear.
Correct me if I am wrong, but in ESPHome, it seems like you have to hook the sensors up and discover the addresses using the console, and THEN bake them into the firmware with the yaml file? I can’t say for sure if they were auto-discovered in Home Assistant as well but I think they were. On the other hand, I’m thinking that the ESPHome sensors didn’t show up until I coded the address in the YAML (and then does that bake into the firmware? Or is that just for Home Assistant?)
I am fairly new to all of this and started with Tasmota a few weeks ago, but then decided to start using ESPHome. But it seemed like when I hooked one-wire sensors up to Tasmota they just auto-discovered. This is appealing as I am setting them up for my parent’s home. I could leave them some extra sensors should they ever need to swap some out.
These particular devices are going to be several Dallas probes to monitor their AC/heating system and then a CT clamp to sense when the blower is running.
@Hellis81 well, the auto-discovery as described by the docs is really not “plug and play” and what I am trying to confirm is if Tasmota is really “plug and play” as I have described, and if there is any way to get ESPHome to be similar.
ESPHome is really more “tailing the logs” and then you seem to be required to not only hard code the addresses but also build the firmware. With Tasmota, I’m under the impression none of that is needed. The sensors may just appear in Home Assistant. Of course, that’s a lot more simple for my older parents.
I tried to setup the sensors in ESPHome using the index method, wondering if that was a work-around, but it seems like I had to hard code the addresses before Home Assistant picked them up.
@nickrout “Required” is not as explicit as you suggest because if you read the description for Address and Index you can see that only one is required.
As I described, I tried the index method hoping it was a work-around to having to hard code by address, and this method would have been GREAT except that it doesn’t seem like Home Assistant recognizes the sensors this way. The sensors appeared fine via the terminal output but didn’t get picked up in Home Assistant until I used the address hard coding. Perhaps there is a bug somewhere, since teh docs do not say this is incompatible with Home Assistant, or maybe I need to try harder. Or if anyone has any suggestions, I’m all ears!
The address of the sensor. Use either this option or index.
And with index option you don’t need to recompile the code to add the address.
But I don’t understand what the issue is.
Had you just compiled, debuged, copy paste and installed again it would have been done long before you even had written half of this thread.
What is the issue here?
Thank you for restating things I have already stated. My reply to @nickrout said what your reply to me just said (about only one of the two being required).
What is the point? As I said in my first post, I am trying to set this up to be as plug and play as possible for my OLDER PARENTS so they can replace a sensor if needed without having to discover the address or recompile the firmware.
The simple solution is just to use Tasmota which seems to be far more plug and play. That is the subject line of this entire thread – which one is better for this purpose? Alternatively, if there is a way to get ESPhome to be more plug and play.
As stated in my original post:
As far as how Home Assistant recognized or didn’t recognize them. I am pretty sure that for both index and hard coded address, I went into configuration > esphome > device name > reload
The reload didn’t work until I hard-coded the addresses. The docs don’t say anything about this method being incompatible, just that if one sensor goes offline then the index may get screwed up.
Again, all this seems like far too much trouble if the Tasmota handling of the DS18B20 will “just work” without all the hassle that ESPHome seems to require in comparison. I’ll have to go set up a Tasmota device and test all this that way again to be sure I didn’t miss any “gotchas” the first time around. In particular, how they get picked up in Home Assistant and how you can keep track of which sensor is which. I know that in the Tasmota web interface, the sensors would just automatically get listed by address. And I’m pretty sure they popped up in Home Assistant without much effort.
@Hellis81 ESPHome integration is already added, and so was the esp8266 device. The issue is recognizing the DS18B20 sensors without having to compile custom firmware for the device anytime you change one. Recompiling and hard coding a sensor you wish to be swappable is obviously not ideal. As I stated, Home Assistant did not seem find any DS18B20 sensors added to a previously configured ESPHome device under the INDEX method, which is not an expected result as that seems like something that would be documented. There is no problem seeing the ESPHome device that hosts the sensors, and the sensors and index method seem OK in the console on the device.
I don’t know how much more clearly I can say it… I seem to remember Tasmota “just working” with none of the hard coding effort. I want this to be “plug and play” and “high availability/repairability” for my parents. I’ll just try Tasmota again unless someone can advise me of a way to make it that simple under ESPHome.
@nickrout Not really — my question still stands. All of this was stated in my initial post. Nobody has offered an opinion about if Tasmota or ESPHome is better for this purpose, which is the subject line of the entire thread.
As for the docs – to me it feels like the INDEX method isn’t working as the developer who implemented it expected. Because if it is simply not useful for Home Assistant, I’m not sure what the point of even documenting the method is. That smells like a bug, or maybe I flew through it all too quickly and it’s my mistake.
tasmota is a ready-made firmware with a set of all devices that it supports. Esphome this is pure code in which you decide what and how to add. as a result of which we ourselves dispose of what it should work for them and do not choose what the developers of tasmotu gave us to add… clean code allows you to write your components and build your devices.
Thanks @lordzid - yes this is why I like ESPHome and moved over to it. And I did wonder if in this case someone might enlighten me about how to customize ESPHome to work as easy as Tasmota on this sensor.
For popular sensors, it really just matters as to which gets the job done easier and more robustly. If Tasmota’s standard sensor firmware has this sensor built in, and it is more “plug and play” since it has automatic device name/ID generation, I don’t see any advantage to compiling ESPHome for this particular device.
Automatic naming seems like a great idea that could be easy to adopt in ESPHome’s code for this sensor.
I was just perusing the handlers for this device in ESPHome and Tasmota… here’s where Tasmota uses the address as the device name/identifier so that it is automatically recognized without needing to hard code and compile the address.
It would be cool if ESPHome adopted something like this. Not much to it.
void Ds18x20Name(uint8_t sensor) {
uint8_t index = sizeof(ds18x20_chipids);
while (--index) {
if (ds18x20_sensor[ds18x20_sensor[sensor].index].address[0] == ds18x20_chipids[index]) {
break;
}
}
GetTextIndexed(DS18X20Data.name, sizeof(DS18X20Data.name), index, kDs18x20Types);
if (DS18X20Data.sensors > 1) {
#ifdef DS18x20_USE_ID_AS_NAME
char address[17];
for (uint32_t j = 0; j < 3; j++) {
sprintf(address+2*j, "%02X", ds18x20_sensor[ds18x20_sensor[sensor].index].address[3-j]); // Only last 3 bytes
}
snprintf_P(DS18X20Data.name, sizeof(DS18X20Data.name), PSTR("%s%c%s"), DS18X20Data.name, IndexSeparator(), address);
#else
snprintf_P(DS18X20Data.name, sizeof(DS18X20Data.name), PSTR("%s%c%d"), DS18X20Data.name, IndexSeparator(), sensor +1);
#endif
}
}
ESPHome has an optional index method to identify the sensors but I think this is ESPHome implementation choice/code. This is not the Dallas 1-wire protocol… it’s ESPHome driver code. The index above in the Tasmota code, similarly, is just referencing an array introduced by the author of the Tasmota module under their implementation. This is just a temporary register where they stored all the embedded addresses for any sensors they discovered on the 1-wire bus. (I’m assuming a lot here as I have not studied this closely, but feel safe going out on this limb.)
ESPHome discourages use of their index method because it does not uniquely identify each sensor. ESPHome effectively anonymizes the sensors using that index method which seems counter productive. The code above for Tasmota does not anonymize (this code is the process to automatically utilize the embedded unique ID).
The bottom line is there is no need to use an index method that anonymizes the sensors (or to manually discover and compile the address into the firmware) when all devices already have a unique identifier burnt into the sensor. Just refer to any sensors discovered on the bus by the name (address) they were given at birth.
It is probably safe to assume that if a device has been placed on the 1-wire bus that the user wishes for it to appear in the system. Currently, the “recommended” method is to connect the device and have the user monitor the bus to see what addresses appear. And then you save the address and compile it into the system. Why all the fuss, and is there anything here that cannot be handled in code? No. Simply discover and utilize any device talking on the bus. That seems to be how Tasmota does it.
Especially as the esphome docs say