DS18B20 Sensor Output

[Papablaubaer]

Silk me
#define USE_DS18x20_RECONFIGURE
#define DS18x20_USE_ID_AS_NAME
to compile my own version of tasmota, using DS18b20 has become significantly easier.
It would be even easier if a missing sensor would remain in the sensor output and send an impossible value like -999.
It would be best if the sensors were retained even after a restart.
The output in the console
Read sensor 0 failed in Ds18x20EverySecond.
Read sensor 0 failed in Ds18x20Show.
I can't use it in rules.

[sfromis]

"Impossible" values are generally a bad idea, but it could make sense with null (which is valid JSON), but some tools may not be up to the task. Retaining defunct ones would also require a clean-up mechanism, which becomes a bit too much management (which is expected to happen backend), instead of simply reporting sensor data.

To have better options for local handling of sensor data, I'd recommend using ESP32 and the Berry language, where you could easily check if you're not getting the expected sensors reporting, and other local sensor management.

[Papablaubaer]

A "null" in the sensor output would have helped me a bit. I've already thought about Berry, but so far I've been able to solve all my requirements with rules. In the case of a DHT11 sensor, it is also the case that "null" is returned in the event of an error. Here it is also the case that a restart does not change anything about the sensor output. Perhaps this can be solved in a similar way to the DHT11, even if several DS18B20s are used, including DS18Alias doesn't really help, since non-existent sensors are not taken into account in the sensor output. Maybe it would be possible to take all DS18B20 aliases into account in the sensor output, regardless of whether "null" or a valid value is returned. Then the existing DS18Alias function could and should be used for cleaning up not be programmed additionally. If the settings of DS18Alias were persistent, this could perhaps be done with reasonable effort.

[sfromis]

The things you want to do are the reasons why I suggest skipping rules, to instead use ESP32 and Berry, as Tasmota is not designed for management of your expectations around how you like to process sensors. Or you can do it backend, of course.

IIRC, if you connect multiple DHT11, you are not getting any persistence around each sensor, thus you are worse off than with DS18B20 and having the sensor id.

[Papablaubaer]

First of all, I would like to say how excited I am about Tasmota.
A lot of what I want is already with the introduction of
#define USE_DS18x20_RECONFIGURE
completed.
Is the effort involved in packing this into the sensor output really that high?

[Jason2866]

Maybe #20522 is a solution for you?

[Papablaubaer]

Unfortunately I can't get the script from #20522 to run, but I've already contacted the author about it.
It can be the solution for ESP32 devices, but I would also like to run ESP16 devices with it.
Is my idea of incorporating the sensors into the SensorOutput not feasible?

[wjohn007]

After some investigation, i found that most of my sensors are 'faked'.

A great source for this issue can be found at https://github.com/cpetrich/counterfeit_DS18B20.

I adjusted my application for that

The original sensors only have a slight deviation. (all sensors are at the same location)

@Papablaubaer
Please try the current version.

@anyone
I'm looking for a waterproof sensor with an original Maxim chip and about 2m of cable. Hints are welcome.

[jeroenst]

Why is USE_DS18x20_RECONFIGURE not enabled by default?