logo elektroda
logo elektroda
X
logo elektroda
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

Issues with DS1820B Sensor Temperature Reporting - Negative temperature and reports to HA

imvaloo 4998 48
Best answers

How can I make an OpenBeken DS1820B sensor report its below-zero temperature correctly on the dashboard and in Home Assistant?

Set the DS1820 channel to `Temperature_div100`; otherwise the dashboard will show `0.0` for that channel even though the sensor reads a negative value. `publishChannel 2` sends the DS1820 reading as an integer scaled by 100, so a reading like `-20.81` becomes `-2081`, and `publishFloat` can be used if you want the float value instead [#21270035] The MQTT `temp` field is the internal CPU temperature, not the DS1820 value [#21270035] If you were seeing the problem on an older build, upgrading to the latest firmware also fixed the reporting for the original poster in both Home Assistant and the OpenBeken dashboard [#21271549]
Generated by the language model.
ADVERTISEMENT
  • #31 21328160
    max4elektroda
    Level 24  
    Posts: 756
    Help: 48
    Rate: 187
    Actually this "simple" driver only supports one device. One restriction is that for small code we simply ask "all devices" and not a dedicated one.
    It's even not possible to have multiple devices on different pins: the DS1820 code would work in this case ("all" devices is on), but handling more than one pin is just not implemented.
    There is some more complete DS1820 code, but it never was fully adapted yet.
    Maybe, if I have some spare time ...
  • ADVERTISEMENT
  • #32 21328393
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14632
    Help: 655
    Rate: 12647
    We can try to get some DS18B20 with @DeDaMrAz and help, what exatly is left to be done? To be ported? I guess something that looks like I2C scan? I don't know OneWire protocol well..
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #33 21328461
    max4elektroda
    Level 24  
    Posts: 756
    Help: 48
    Rate: 187
    If I remember correctly, the DS18(X)20 code is already in git. It probably will be something like porting the usleep from the "simple " code to the complete one and add some code to get and display the results.
  • #34 21329381
    max4elektroda
    Level 24  
    Posts: 756
    Help: 48
    Rate: 187
    @sx642005elektroda what kind of device do you use?
    I'm trying to add the other driver which allows multiple DS18B20 or maybe just extend the actual one.
    I will add a testing version the next days for I don't have multiple sensors to test the code during the week...
  • ADVERTISEMENT
  • #35 21329698
    DeDaMrAz
    Level 22  
    Posts: 608
    Help: 34
    Rate: 129
    @max4elektroda

    do you have a compiled OTA for N module where I can test that DS sensor again?? And of course share if you have that, thanks.
  • #36 21330178
    sx642005elektroda
    Level 5  
    Posts: 6
    Help: 1
    Rate: 1
    DS18B20 temperature sensor with three wires.

    I use this DS18B20 on this image "OpenBK7231N_1.17.780.rbl".
    I tested these 2 sensors on tasmota which detects the 2 together. As the platform I will use has a BK731N chip, OpenBeken is the solution for my need.
    I changed the value several times (0 then 1 then 2) in the channel field associated with the DS1820_IO module, but it had no effect.

    Added after 7 [minutes]:

    Désolé @max4elektroda, je n'avais pas lu ta réponse du 01 Dec 2024 19:18 ( #31 21328160) avant de faire ma réponse.

    Added after 33 [seconds]:

    English version
    Sorry @max4elektroda, I didn't read your answer of 01 Dec 2024 19:18 (#31 21328160) before making my answer.
  • #37 21330326
    max4elektroda
    Level 24  
    Posts: 756
    Help: 48
    Rate: 187
    O.k., as I'm busy today, please find my first try for BK7231N attached.
    Define pin like other driver - or keep definition, if already done ;-)

    startDriver DS18B20 [<seconds between reading of sensor>]


    Screenshot of OpenBK7231N interface displaying temperatures and sensor statuses.
    Attachments:
    • dev_20241203_072219.zip (9.91 MB) You must be logged in to download this attachment.
  • #38 21331905
    sx642005elektroda
    Level 5  
    Posts: 6
    Help: 1
    Rate: 1
    Thank you max4elektroda, I read your message way too late. I'll test this new version later (tomorrow), I'm going to bed! :)
  • #40 21336187
    sx642005elektroda
    Level 5  
    Posts: 6
    Help: 1
    Rate: 1
    Hi max4elektroda,

    I tested your dev version (dev_20241203_072219) then the latest (1.17.794), and I get the same result, still an error.
    I also changed the number of channels (0 to 2) without effect.
    This is the error message with dev_20241203_072219 version :
    Info:SENSOR:DS1820[0] - Starting conversion
    Info:SENSOR:DS1820[0] - Temp=23.12
    Error:SENSOR:DS1820[0] - Read CRC=40 != calculated:c7 (errcount=1)
    Error:SENSOR:DS1820[0] - Scratchpad Data Read: 70 1 55 5 7f a5 a5 66 40
    Error:SENSOR:DS1820[0] - Read CRC=40 != calculated:c7 (errcount=2)
    Error:SENSOR:DS1820[0] - Scratchpad Data Read: 70 1 55 5 7f a5 a5 66 40
    Error:SENSOR:DS1820[0] - Read CRC=40 != calculated:c7 (errcount=3)
  • #41 21336427
    max4elektroda
    Level 24  
    Posts: 756
    Help: 48
    Rate: 187
    The latest version won't help, the new driver is only in the testing branch or in the zip file.
    Seems you did activate the "old" driver, but to test the new one, you need to run (only!) the new driver with
    startDriver DS18B20

    Please note the B between 18 and 20.
  • #42 21351856
    hojnikb
    Level 12  
    Posts: 45
    Rate: 2
    I'm trying to get this sensor working in home assistant. I've set up the pin and channel and started the driver; the device is shown at the first page and shows values correctly.

    But I can't seem to be able to get that value to publish to homeassistant.

    Any ideas what to configure? I've set the DS1820 to channel 1
  • #43 21351979
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14632
    Help: 655
    Rate: 12647
    Set channel type to Temperature.
    Helpful post? Buy me a coffee.
  • #44 21356295
    romvya
    Level 1  
    Posts: 1
    He publishes the temperature to MQTT as soon as it changes by 0.06 degrees, but it changes with every measurement on the DS18B20 sensor. How can I set it up so the temperature is sent once every 5 minutes or when it changes by 0.2 degrees? (Learning C is easier than OpenBeken.)
  • #45 21356384
    max4elektroda
    Level 24  
    Posts: 756
    Help: 48
    Rate: 187
    Usually that's intended to have the actual temperature, for "no message" can mean "no change in temperature" or "the device/sensor doesn't report any temperature" (might be dead).
    But I can check if/how it would be possible to change the behavior by either sending updates only every X seconds, regardless if it changed or not or introduce a minimum change needed to trigger an update (which might lead to the problems mentioned above)

    Added after 5 [minutes]:

    Btw, thinking it over again: it should be possible even now to change the interval of updates:
    Calling the driver with an additional value is possible.
    So if you start it with

    startDriver DS1820 300

    should trigger a reading of the sensor every 5 minutes and hence the updates should follow the readings.
  • #46 21537078
    imvaloo
    Level 3  
    Posts: 5
    Hi guys,
    Today I've upgraded the version of OpenBeken to version 1.18.94 and now the DS1820 sensor that I have does not communicate anymore.
    In the logs I receive errors about bad CRC.

    Info:CMD:[WebApp Cmd 'startDriver DS1820' Result] OK
    Debug:SENSOR:DS1820[9] - Discover CRC failed (CRC=ad != calculated:90)
    Error:SENSOR:DS1820[9] - Family not discovered


    Before that, I was running on version 1.17.754 and this same sensor was working fine. Only I had occasional reboots of the micro-controller and it triggered the relay rapidly. Which was disturbing the compressor of my freezer.

    I read somewhere to try the DS18B20 driver, but I cannot seem to find it?
  • #47 21537101
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14632
    Help: 655
    Rate: 12647
    Hey, can you help us and narrow down which version breaks DS18B20 for you?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #49 21537136
    max4elektroda
    Level 24  
    Posts: 756
    Help: 48
    Rate: 187
    imvaloo wrote:
    oday I've upgraded the version of OpenBeken to version 1.18.94

    You use a BK7231N, right?

    Beken timing is kind of unreliable, but there is another approach form git user "rpv-tomsk" for timing which is very promising (https://github.com/openshwprojects/OpenBK7231T_App/pull/1579).
    I made some slight changes, you may try this version from here (if you have a git user to download the artifacts:
    https://github.com/MaxineMuster/OpenBK7231T_App/actions/runs/14796474485

    Added after 30 [minutes]:

    Just tried here with the version you mentioned:
    "Built on Apr 25 2025 15:29:36 version 1.18.94"
    Works for me on BK7231N with my DS18B20 clones

Topic summary

✨ The discussion addresses issues with DS1820B temperature sensor integration on an Antela Smart Plug flashed with OpenBeken firmware for freezer temperature monitoring. The main problem was incorrect temperature reporting in Home Assistant and the OpenBeken dashboard, showing 0.0°C despite correct negative values in logs. It was clarified that the sensor channel must be set to "Temperature_div100" type to display correct DS1820 readings, as the default "Temperature" channel type reports internal CPU temperature, which can be misleading. Firmware updates introduced a new DS18B20 driver supporting multiple sensors and improved family detection, but some clone sensors (e.g., Sensylink CT1820B) initially failed due to unrecognized family codes and CRC errors. Debug logs revealed that some sensors report family 0 or fail CRC checks, causing driver rejection. Subsequent firmware revisions and pull requests improved compatibility by relaxing family checks and enhancing debug output. The new DS18B20 driver requires explicit activation via "startDriver DS18B20" and supports multiple sensors on a single pin, unlike the older "simple" DS1820 driver. Users reported successful temperature readings and MQTT publishing after applying these updates. Discussions also covered configuration for MQTT update intervals and temperature change thresholds. Naming conventions for internal CPU temperature were debated, suggesting clearer labels like "%platform% chip temperature" instead of "internal temperature." Overall, the thread provides troubleshooting steps, firmware version references, and configuration tips for reliable DS1820B/DS18B20 sensor operation with OpenBeken and Home Assistant integration.
Generated by the language model.

FAQ

TL;DR: If OpenBeken logs -20.81°C but the UI or Home Assistant shows 0.0°C, the fix is usually channel mapping, not sensor math: "-2081 degrees is simply not reasonable". This FAQ helps OpenBeken users make DS18B20 readings display, publish, and survive firmware changes on freezer-monitor projects. [#21271033]

Why it matters: A smart plug can read a freezer probe correctly in logs yet still expose the wrong value to MQTT, Home Assistant, or the dashboard, which can hide real sub-zero conditions.

Option What it reports Best use Limitation
Temperature plain temperature value UI/HA entity display wrong if source channel actually stores value ×100
Temperature_div100 channel value divided by 100 DS1820 channel carrying raw -2081 style values requires correct channel assignment
DS1820 simple driver one sensor on one pin quick single-probe setup no multi-sensor bus support
DS18B20 newer driver newer testing path for multiple sensors advanced testing and future expansion was still under testing in December 2024

Key insight: The thread shows two separate issues: display/publishing errors came from using the wrong channel type, while CRC and “Family not discovered” errors came from driver timing, clone behavior, or wiring quality. [#21270035]

Quick Facts

  • The failing freezer example logged -20.81°C correctly, while the home page and Home Assistant initially showed 0.0°C instead. [#21269605]
  • OpenBeken stores some DS1820 channel values as temperature ×100; the thread uses -2081 to represent -20.81°C. [#21270035]
  • The simple DS1820 driver reads on a 15-second default interval, and startDriver DS1820 1 changes that to 1 second. [#21271553]
  • A repeating MQTT publish example used addRepeatingEvent 5 -1 publishFloat DS1820Temp $CH2/100, which sends a float every 5 seconds from channel 2. [#21270035]
  • The simple DS1820 driver supports only one device; connecting 2 sensors on the same setup caused CRC errors and only one valid reading. [#21328160]

1. Why does a DS18B20 sensor show the correct negative temperature in OpenBeken logs but appear as 0.0°C on the dashboard and in Home Assistant?

Because OpenBeken was reading the external sensor correctly but exposing the wrong channel or channel type to the UI and Home Assistant. In the freezer case, logs showed -20.81°C, yet the page still displayed 0.0°C until the DS1820 channel was mapped properly instead of relying on the device’s separate internal temperature field. [#21269605]

2. How do I configure the DS1820 or DS18B20 channel type in OpenBeken so the temperature displays correctly instead of showing raw values like -2081?

Set the sensor’s channel type to Temperature_div100 when the channel carries raw DS1820 values scaled by 100. 1. Assign the DS1820 pin to a free channel, such as channel 2. 2. Run setChannelType 2 Temperature_div100. 3. Confirm the main page shows a normal temperature instead of -2081. [#21270035]

3. What is the difference between the OpenBeken 'Temperature' and 'Temperature_div100' channel types for DS18B20 readings?

Temperature expects a normal temperature value, while Temperature_div100 converts an integer scaled by 100 into degrees. In this thread, the DS1820 channel held values like -2081, which means -20.81°C. Using plain Temperature on that raw value makes the reading unreasonable or invisible in the UI. [#21271033]

4. How can I publish a DS18B20 temperature from OpenBeken to MQTT and Home Assistant using publishChannel or publishFloat?

Use publishChannel for the raw integer or publishFloat for a human-readable temperature. publishChannel 2 sends the scaled integer from channel 2, so -20.81°C becomes -2081. To publish a float every 5 seconds, use addRepeatingEvent 5 -1 publishFloat DS1820Temp $CH2/100. [#21270035]

5. Why does OpenBeken sometimes send the MCU's internal temperature as 'temp' instead of the external DS18B20 sensor value?

Because the built-in temp field can refer to the chip’s own internal sensor, not the external OneWire probe. In the thread, the maintainer stated that MQTT temp was the internal CPU temperature, and on one W800 device it stayed at 0.0. The DS1820 value had to be published separately from its assigned channel. [#21270035]

6. What is galvanic isolation, and why does it matter when adding a DS18B20 probe to a mains-powered smart plug like the Antela plug?

"Galvanic isolation" is an electrical safety measure that separates two circuits so current cannot pass directly between them, reducing shock risk when a low-voltage sensor touches a mains-powered device. It matters because some smart plugs can place live potential on CPU GND or Vcc, making an external metal probe dangerous without proper isolation. [#21270035]

7. How should I safely connect a DS18B20 freezer probe to a mains smart plug running OpenBeken without exposing dangerous voltage on the sensor body?

Keep the probe isolated from mains-referenced circuitry and verify the probe body is not electrically connected to dangerous points. In the Antela example, the user checked the metal jacket with a multimeter and reported no connection, and also noted a small transformer on the board. That reduced risk, but the warning remained valid for plugs with live-referenced low-voltage sections. [#21270950]

8. What does the OneWire 'family' code mean for DS18B20-compatible sensors, and why would OpenBeken report 'Family not discovered' or family 0?

The OneWire family code identifies the sensor type during ROM discovery, and OpenBeken expected 0x10 or 0x28. When discovery failed, the debug log showed family 0 and even read ROM: 0 0 0 0 0 0 0 0, which means the device did not return a usable ROM code during detection. [#21271409]

9. Why do some DS18B20 clone sensors such as Sensylink CT1820B trigger CRC errors or 'Family not discovered' messages in newer OpenBeken builds?

They can fail when ROM discovery or scratchpad reads return invalid bytes, especially on newer builds with stricter checks. One test showed Discover CRC failed (CRC=ff != calculated:14) and scratchpad data of nine ff bytes. Later retesting showed the same Sensylink clone worked after reseating connections and reflashing, so wiring quality also mattered. [#21271571]

10. Which OpenBeken driver should I use for a DS18B20 sensor — the simple DS1820 driver or the newer DS18B20 driver — and what are the practical differences?

Use the simple DS1820 driver for a single sensor today, and test the newer DS18B20 driver if you need future multi-sensor support. The maintainer said the simple driver supports only one device and asks “all devices” on the bus, while the newer driver branch was being ported to handle fuller DS18B20 behavior. [#21328160]

11. How do I start the DS18B20 driver in OpenBeken, and where can I find it if I only see references to the older DS1820 driver?

Start it with startDriver DS18B20, making sure you include the B. In December 2024, the maintainer posted a BK7231N testing build and explicitly said the new driver was not in the normal latest release, only in the testing branch or attached zip. That is why users mostly saw older DS1820 references. [#21336427]

12. What is the best way to troubleshoot DS18B20 bad CRC errors on a BK7231N device after upgrading OpenBeken from 1.17.754 to 1.18.94?

Compare versions, check wiring, and test timing-sensitive builds on the same BK7231N hardware. 1. Confirm the old working version, such as 1.17.754. 2. Re-test on 1.18.94 and collect exact CRC logs. 3. Try the alternate timing approach suggested in the May 2025 thread and verify the data-line pull-up. [#21537136]

13. How does the pull-up resistor on the DS18B20 data line affect reliability, timing, and CRC errors in OpenBeken?

It directly affects bus stability, so missing or weak pull-up can cause CRC failures and unreliable timing. In the May 2025 follow-up, a responder asked first whether a pull-up resistor was present after the user reported CRC errors on 1.18.94. That makes the pull-up one of the first hardware checks when OneWire reads start failing. [#21537116]

14. Why does the current OpenBeken DS1820 driver fail with two DS18B20 sensors on the same setup, and what would be needed for multi-sensor support?

Because the current simple driver supports only one device and does not implement full address handling for multiple sensors. The maintainer explained it issues commands to “all devices” for small code size and does not manage multiple pins or per-sensor selection. Proper multi-sensor support needs the more complete DS18X20 code to be ported and its results displayed. [#21328160]

15. How can I make OpenBeken report DS18B20 temperature to MQTT less often, such as every 5 minutes or only after a 0.2°C change?

Set a longer driver interval if you want fewer MQTT updates; threshold-based 0.2°C publishing was discussed but not implemented in this thread. The maintainer said startDriver DS1820 300 should read the sensor every 300 seconds, so MQTT updates follow every 5 minutes instead of each short measurement cycle. [#21356384]
Generated by the language model.
ADVERTISEMENT