Better for Dallas DS18B20: ESPHome vs Tasmota?

ESPHome
21

Did you even bother to read the code you posted yourself?

I’m fairly sure you are wrong on your assumptions.
Arduino based chips can’t save value in code, that is why you need to compile them.
There is the EEPROM, but if that was used then where is the EEPROM write function call in that code snippet?
And just looking at how often the word index appears versus EEPROM.
But maybe I’m wrong…

You could test it, connect two Dallas sensors to one Tasmota and unplug one or the other and see if it still places the values in the correct entity.

I’ll give it a plausible chance of it working since Tasmota obviously use the EEPROM to store the configuration

22

Who needs to save any value? The values are already stored… IN THE SENSORS! They broadcast and you show them. What’s so hard to understand? Tasmota shows them by their embedded addresses… that’s why I’m lamenting about how nice that is. I had 2 sensors connected. Once had a loose connection and disappeared. I wiggled it in the breadboard and it showed back up! NEVER did I have to code the address anywhere!

23

This really should not be hard to understand. The WHOLE point in all of this is that the sensors already have unique identifiers! There is no need to look in the console to see what they are. If they are in the console, then by definition the code can see them too! It does not take a human being to look at the console to see the identifier. So Tasmota understands this and just brings them into the system by the identifier. Automagically. It’s not hard.

24

OF COURSE it will be placed in the correct entity. THE ENTITY IS BURNED INTO THE SENSOR! I could connect it to a completely different Tasmota device and it would show up by EXACTLY the same name with ZERO configuration.

25

Stop shouting, and above all stop being an asshole.

1 Like
26

You are such a nice guy, maybe you should change your nickname.

No, it’s not about the sensor. Read the code!
The code needs to know what adress to associate the entity with, and that is not “burned” in the sensor.

27 
`#ifdef DS18x20_USE_ID_AS_NAME`

See above comment in the code that sums it up nicely… “use ID as name”

28

In Tasmota, the entity name and the sensor address are one and the same. I can’t explain this any more plainly.

29

But it’s not stored in the EEPROM? So where is it stored?
If it’s not stored then it’s based on index, and if it’s indexed then it could change order, and that is the issue.
But it only affects if you have more than one sensor connected to the same device.

30

No… tasmota does not have the HA entity name.
It’s impossible.

31

I don’t know why you guys need to argue so much and why why this is so hard to understand. Are you familiar with MAC addresses? If an unknown device shows up on a network, can other systems recognize it and get along? Of course. The device tells you it’s mac address. The dallas sensors do the same thing. There is no problem for Tasmota to take the address and pass it upstream along with the data it presents, saying “hey this device XYZ123 said the temp is 1000 degrees” or whatever. If you don’t think the name XYZ123 is very pretty then I’m fairly sure you can change the display name other places.

32

But you can’t store this anywhere.
And that is the issue.

If you have two connected, and boot the ESP then it will see two just fine.
Power down and add two other sensor and it will believe these two sensors are the previous two.
If you remove one, it could make the second one be the first (after a reboot).

And this is the issue.
ESP and Arduino based boards are clueless! The only way to make them less clueless is to use EEPROM or hard code it.
Tasmota seems to be using neither.

33

Where does tasmota store the configuration template and other changes you make in the web interface? You can rename the device, change the GPIO sensors… all kinds of things. They seem to be saved on the device without much issue. Why would it be difficult to map the sensor ID to some pretty name in the same space?

34

All data from the sensors attached to the 1 wire bus come across from the embedded address set at the factory. This just needs to be passed upstream – the data and the address it comes from – up to anywhere you might want to change it. You could pass the temperature and some UUID all the way up to Home Assistant if necessary and then have a pretty name associated there. You could connect the same sensor to another device and then your HA could say “hey! good to see you sensor 1239ouddse47y8398743! Looks like you’ve relocated ot a better neighborhood!”

35

Here’s how you configure a dallas sensor in ESPHome:

  - platform: dallas
    dallas_id: dallas_hub_1
    name: my_pretty_name
    address: 0x6A00000003F5E828

This is how Tasmota does it (conceptually – because no configuration is actually needed other than to set the pin as a Dallas 1-wire bus):

  - platform: dallas
    dallas_id: dallas_hub_1
    name: 0x6A00000003F5E828
    address: 0x6A00000003F5E828

As you can see, you don’t need to save the name anywhere if you simply create a name from the address burned into the sensor. The code I posted from tasmota basically does this (and it may shorten/clean it up a bit).

36

Nick, I must take exception to your use of"asshole". We, ostensibly, speak the same language, despite the disagreement over vowels. The correct spelling is “arsehole”, not the American abomination. :rofl:

3 Likes
37

You’re not listening at all so why should I bother anymore.
You are hopeless!

Is there any way you can block a person on this forum so that you don’t see them at all?

38

You are the one who came into a thread I started and picked an argument. I have thoroughly explained how Tasmota does this and it seems to work great. That is the point of this thread. You apparently have not tried this in Tasmota as I have, yet you want to challenge me that it can actually work. You are free not to interact on this thread. I am not following you around trying to have a discussion. Feel free to go on with your life and unfollow this thread. I will not @ you on anything further, however I may add to this thread with other useful information as I did with the code snippet from Tasmota you felt a need to engage upon once again. It was not addressed to you.

I promise you that no hard-coding a sensor value into firmware is needed with Tasmota. In fact, Tasmota firmware is pre-compiled so there is no way that could happen. Yet, somehow the Dallas sensors work great! They don’t get confused if you connect and disconnect them. What more can I say. It strikes me as odd to hard-code these values in firmware.

1 Like
39

In fact this is the biggest downside from projects like Tasmota, Esp Easy, ESPurna and others.
I can tell you because I’m using esp’s since over 5 years and the first years esphome wasn’t even a thing back then. :older_man:

There are certain problems with pre-compiled binaries reaching from limited function sets (typically various flavors of binaries are released some support display’s others more sensors and so on…) but also problematic update and lost configurations. I had it all and I certainly don’t miss it :wink:

By far the biggest downside for actually is the reproducibility (and scalability). I have over 100 esp’s deployed and they all need to do what they should do (what’s hard coded actually :bulb:)

BTW: esphome actually had already a dallas-auto-setup-sensors (pr) but it was reverted:

40

Do you leave them a spare esp too? Not sure if you scenario might be a little far from reality?

It’s not a valid data set at all but from around 100 esp’s I had in my hands actually two (in numbers 2) died. From my roughly 10 dallas ds18b20 (probably 99% fake) all are working fine since ever (years).

Just do your OLDER PARENTS (why do we need to shout that out loud?) a favor and build them a solid system. Hardware can always fail and then you should be the one fixing it (as you introduced the system).

From my experience (many many years tinkering with esp’s and having used all bigger *wares available) I can tell the most rock solid and stable systems are running esphome.

For example there (was?) a hidden sequence in tasmota turning the esp on and off to actually factory reset the device. In theory that should only happen when this is really wanted but if you look in the www you find plenty of people devices reset (rendered unuseful) for no obviously reason. Might be brown outs or whatever… but it’s just not a rock solid system is what I try to say :wink:

Best day in my smart home career actually was when I migrated my last tasmota node to esphome and finally turned that mqtt broker off for good :rocket:

1 Like