logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

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

imvaloo 6045 48
Best answers LABEL_AI_GENERATED

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]
AI summary based on the discussion. May contain errors.
ADVERTISEMENT
Report a violation of the law
Reply | New topic

  • Negative DS1820B readings show as 0.0C in HA

    #1 21269605
    imvaloo
    Level 3  
    Posts: 5
    Hi everyone,
    I've converted an Antela Smart plug to Openbeken and I'm super happy to be able to remove the cloud from my devices.

    I have modified this energy metering plug to include a DS1820B temperature sensor because I am aiming at monitoring my freezer with it.
    And I have an issue:

    My freezer is obviously below 0 degrees celsius. The Log information reports this correctly, but on the home page and in Home Assistant, it reports the temperature as "Temperature 0.0C (2)". Here is the log:

    Code: text Expand Select all Copy to clipboard
    Info:CFG:DS1820 - Pin=9 temp=-20.81 
Info:CFG:DS1820 - High=254 Low=179 Val=333 Tc=2081  -- Read CRC=65 - calculated:65 


    Edit: Temperature is reported in HA, but incorrect.
    Nowe złączki do PCB od WAGO [sponsorowany]
  • ADVERTISEMENT
  • #2 21269846
    max4elektroda
    Level 24  
    Posts: 758
    Help: 49
    Rate: 189
    Did you take a different channel for DS1820 (different to the relay...)?
    On the main page of OpenBeken the temperature for DS1820 is wrong, too?
    What's the reading on the channel assigned to DS1820 there?
  • #3 21269868
    imvaloo
    Level 3  
    Posts: 5
    >>21269846

    I did use a different channel (2).
    On the main page of OpenBeken the temperature is indeed wrong also. It shows 0 degrees.
    Configuration channel settings list in OpenBeken showing settings for pins P6 to P11.

    OpenBeken home page displays freezer status with incorrect temperature reading of 0 degrees Celsius.

  • Set channel 2 to Temperature_div100 and publish DS1820 value

    #4 21270035
    max4elektroda
    Level 24  
    Posts: 758
    Help: 49
    Rate: 189
    The temperature line from the sensor on the main page should be something like


    DS1820 Temperature: -20.1 C (read 4 secs ago)

    Could you please check for that line?

    Added after 8 [minutes]:

    And: what's the value of CH 2 shown on main page?

    Added after 2 [hours] 11 [minutes]:

    I don't use HA, so I can only look into the "main page" atm.

    Just did a quick try here, and it seems o.k. (will take a deeper look this afternoon:

    OpenW800 status screen with temperature and WiFi signal data

    Added after 2 [hours] 59 [minutes]:

    O.k., tried here with a W800. This is one device without internal (CPU-)Temperature in GUI, it will allways schow "0" there.

    To get "Temperature" on the Main page, you will need to set this channel (2 in your config) to type "Temperature_div100" (in Web Application or as User command "setChannelType 2 Temperature_div100").

    The "temp" in MQTT is the internal CPU-Temperature (its 0.0 with my W800, too).
    In order to get the DS1820 value, you will need to publish the value:

    Code: text Expand Select all Copy to clipboard
    publishChannel 2


    will give the integer value of 100*temperature (so -20.81 will be -2081 there).

    Or you add a regular publishing of the float value (you might need to enable "#define ENABLE_EXPAND_CONSTANT 1" in the obk_config.h file for your platform to make "calculation" work):

    Code: text Expand Select all Copy to clipboard
    addRepeatingEvent 5 -1 publishFloat DS1820Temp $CH2/100


    This is how it looks here (with channel 4 for my DS1820):

    User interface showing details of device W800C0DCE97B2, including DS1820 temperature status.
    Code: text Expand Select all Copy to clipboard


    Added after 2 [hours] 36 [minutes]:

    imvaloo wrote:
    modified this energy metering plug to include a DS1820B temperature sensor

    Out of curiosity: did you (how) do a galvanic isolation?
    These plugs usually have live voltage potential on the GND/Vcc of CPU so I would never use a sensor outside the plugs case without this security measure.

  • DS1820 firmware update broke family detection

    #5 21270950
    imvaloo
    Level 3  
    Posts: 5
    >>21270035

    I tried to upgrade to the latest firmware because I saw there were some modifications to the DS1820 code, but it broke the readings for me, it was giving errors about the family. So I reverted back to the firmware that I used previously and that reported the temperature.

    I'm currently running 1.17.732.
    My device also reports internal temperature.

    I did set the Temperature to channel 2:
    Screenshot of device configuration settings.

    However on the home page it doesn't show on Channel 2, even though the temperature is reported under DS1820:
    Screenshot of the Antela smart plug user interface displaying power and temperature parameters.

    Thanks a lot for looking into this!

    Regarding the galvanic isolation, my temperature sensor's metal jacket is not connected to anything inside, I checked with a multimeter.
    And my device "Antela smart plug" has a little transformer on the board, so I expect there is some insulation already, but I verified there was no leakage on the metal jacket.
  • #6 21271033
    max4elektroda
    Level 24  
    Posts: 758
    Help: 49
    Rate: 189
    Regarding the temperature, please see my comment, it needs to be "Temperature_div100"
    (-2081 degrees is simply not reasonable ;-))

    Could you please post the exact error message for the family with the new code ?
    We need to fix this...
    Thanks

  • Suggesting DS18B20 clone detection and clearer temperature labels

    #7 21271081
    divadiow
    Level 38  
    Posts: 5213
    Help: 446
    Rate: 914
    just trying a few things on my own BK-N/DS1820 - P9/CH2 and a few builds. This particular DS1820 is a Maxim DS18B20 - A1 family - https://www.elektroda.com/rtvforum/topic4056286-30.html#21165112
    Screenshot of the OpenBK7231N user interface showing various device statistics.

    .747 - release before "Improve DS1820 driver (#1382) (ad816b7), closes #1382"
    Screenshot of the OpenBK7231N user interface displaying DS1820 sensor data and system information.

    then on latest build
    OpenBK7231N control screen displaying DS1820 temperature chart and configuration options.
    Code: Text
    Log in, to see the code


    Added after 12 [minutes]:

    BUT

    with a Sensylink CT1820B clone on 1.17.754 (https://www.elektroda.com/rtvforum/topic4062365.html#21158431)

    Code: Text
    Log in, to see the code


    Added after 5 [minutes]:

    on a related driver function note, is adding the fake/clone/family check function seen in https://github.com/koendv/CheckDS18B20 a possibility so users can be state what their ACTUAL device is too when reporting issues?

    Added after 1 [hours]:

    Maybe the "Internal temperature" name should be a little clearer too. Doesn't really say what it's internal to. Inside the case of the device? Inside the CPU? Inside a sensor (if the device has other sensors and the user doesn't know yet how they're distinguished in the GUI)?

    Ideas:
    Core Temperature
    MCU Chip Temp
    SoC Temperature
    Processor Temp
    CPU Temp

    I think I prefer SoC. But, thoughts?

    Added after 2 [minutes]:

    or maybe the platform type is a variable somewhere and it could be

    "%platform% MCU Temperature:"
    "%platform% CPU Temperature:"
    "%platform% SoC Temperature:"

    So there'd be no mistaking something that says "BL602 SoC Temperature", "BK7231N SoC Temperature" etc etc
  • #8 21271226
    max4elektroda
    Level 24  
    Posts: 758
    Help: 49
    Rate: 189
    divadiow wrote:
    Error:SENSOR:DS1820[9] - Family not discovered

    That's not good.
    Will take a look on how to fix this, without doing a full family check.
    The driver intentionally was named "simple" ;-)

    I think I'll start with just reporting an unknown family and not rejecting it.
    Then see how we can distinguish old 1820 (which needs special treatment) from "all others".
  • #9 21271231
    divadiow
    Level 38  
    Posts: 5213
    Help: 446
    Rate: 914
    yep yep, sure. I just went off on a wishlist tangent ;)
  • ADVERTISEMENT

  • Debug output needed to pinpoint DS1820 family detection failure

    #10 21271283
    max4elektroda
    Level 24  
    Posts: 758
    Help: 49
    Rate: 189
    BTW, in DEBUG the family discovered should be visible:

    Code: text Expand Select all Copy to clipboard
       if (family == 0x10 || family == 0x28) {
      ds18_family = family;
      DS1820_LOG(INFO, "Discover Family - discovered %x", family);
      return 1;
   } else {
      DS1820_LOG(DEBUG, "Discover Family %x not supported", family);
      return 0;
   }


    And there might be another issue following the datasheet of Sensylink CT1820B
    64-bit ROMID definition including CRC code, serial number, and family code.
    the family is 0x28 here, too

    Added after 38 [minutes]:

    Just checked some other pages - even the faked ones should report family 0x28.

    So there must be something else causing the issue...

    Added after 17 [minutes]:

    It would be great to get the "DEBUG" output to see, where it fails:
    Beside a really "unknown" family, it could be a failed reset, CRC error, everything that can go wrong in "DS1820_DiscoverFamily()"
  • #11 21271360
    divadiow
    Level 38  
    Posts: 5213
    Help: 446
    Rate: 914
    Code: Text
    Log in, to see the code


    the extent of DS1820 logs on EXTRADEBUG level
  • #12 21271408
    max4elektroda
    Level 24  
    Posts: 758
    Help: 49
    Rate: 189
    Thanks - so it "discovers" family 0 instead of 0x28.
    Opened https://github.com/openshwprojects/OpenBK7231T_App/pull/1394 for some additional output.
    Let's see if we can get closer to the source of the issue...
    My "problem" is, that all sensors I have will pass the check, so I need your support here (again, this becomes a habit: I do some code and let you do the tests ...)

  • DS1820 family 28 discovered with 12-bit readings

    #13 21271409
    divadiow
    Level 38  
    Posts: 5213
    Help: 446
    Rate: 914
    1394_merge_9665a7da33cb

    Code: Text
    Log in, to see the code


    Added after 7 [minutes]:

    same PR with the Maxim. ALL logging level

    Code: Text
    Log in, to see the code
  • #14 21271507
    max4elektroda
    Level 24  
    Posts: 758
    Help: 49
    Rate: 189
    divadiow wrote:
    Discover Family 0 not supported (read ROM: 0 0 0 0 0 0 0 0)

    Hm, looks the sensor doesn't report the ROM at all.

    But the datasheet I found also lists "0x33" as "read ROM":
    https://www.micros.com.pl/mediaserver/UIDS1820BZ_SEN_SENSYLINK_0001.pdf

    Did I get it right: Even with the changed code in "1394_merge_9665a7da33cb" there are no temperatures shown for SensyLink?

  • Sensylink still returns all-ff scratchpad data

    #15 21271529
    divadiow
    Level 38  
    Posts: 5213
    Help: 446
    Rate: 914
    max4elektroda wrote:
    Did I get it right: Even with the changed code in "1394_merge_9665a7da33cb" there are no temperatures shown for SensyLink?


    correct. no temps are read with the Sensylink with that PR. Here is ALL level log from start of driver

    Code: Text
    Log in, to see the code


    Screenshot showing temperature readings from the DS1820 sensor.

    Added after 2 [minutes]:

    powersave 0 for all this, if there was any query about the state of that
  • #16 21271549
    imvaloo
    Level 3  
    Posts: 5
    After upgrading again to the latest firmware, I see that it's now reported correctly, both in Home Assistant and on the Dashboard.
    Shall I close the topic?

  • Clone sensors may need faster DS1820 polling

    #17 21271553
    max4elektroda
    Level 24  
    Posts: 758
    Help: 49
    Rate: 189
    Hm, all bits "0" or all "1", that doesn't sound too good.

    But Sensylink used to work with the version before the "improvement" (e.g. with .747)?
    I ask, because we didn't change timing, so with the changes I made in the PR, it should(!) simply work as before (even if printing some errors/warnings about the family ...)

    Maybe you could "speed up" the conversions by calling the driver with "startDriver DS1820 1" (so it should do a reading every second, not every 15 seconds as in default).

    Added after 1 [minutes]:

    imvaloo wrote:
    Shall I close the topic?

    Please leave it open, seems there is an issue with some clone sensors ...

  • Reseating connections and reflashing fixed DS1820 readings

    #18 21271571
    divadiow
    Level 38  
    Posts: 5213
    Help: 446
    Rate: 914
    yeh. let me start again in case it's just me. it did work with .747 yes.

    I'll buy a bundle of clones from Ali I think, I only have 1.

    Added after 30 [minutes]:

    apologies. it was me. reseated all connections and reflashed.

    Sensylink on 1394_merge_9665a7da33cb

    Code: Text
    Log in, to see the code


    Added after 2 [minutes]:

    imvaloo wrote:
    After upgrading again to the latest firmware, I see that it's now reported correctly

    @imvaloo latest being 1.17.756 or the PR version 1394_merge_9665a7da33cb?

    imvaloo wrote:
    I tried to upgrade to the latest firmware because I saw there were some modifications to the DS1820 code, but it broke the readings for me, it was giving errors about the family

    what version was this?
  • ADVERTISEMENT
  • #19 21271618
    max4elektroda
    Level 24  
    Posts: 758
    Help: 49
    Rate: 189
    That's good news @divadiow !
    Thank you so much for all the time you spent!

    Added after 1 [minutes]:

    But let's keep "renaming internal temperature" on the todo list, that's really misleading.
  • #20 21271622
    divadiow
    Level 38  
    Posts: 5213
    Help: 446
    Rate: 914
    no worries. all good fun. I do want more so I can swap between the clones in case any are duff. Also, some other clone brands/families would be interesting.

    Added after 54 [seconds]:

    max4elektroda wrote:
    But let's keep "renaming internal temperature" on the todo list, that's really misleading.

    maybe I'll just make a GH issue so it's there logged for whenever
  • ADVERTISEMENT
  • #22 21271739
    divadiow
    Level 38  
    Posts: 5213
    Help: 446
    Rate: 914
    you're a machine!

    BK7231N SoC temperature reading shows 35.3°C. Display showing W600 SoC temperature as 0.0°C. Image showing BK7231T SoC temperature: 61.2°C LN882H SoC temperature: 24.2°C
    Display showing BL602 SoC temperature: 36.6°C. W800 SoC temperature indicator showing 0.0°C.

    Added after 10 [minutes]:

    well, I love it, but I guess it's up to bossman @p.kaczmarek2
  • #23 21271920
    max4elektroda
    Level 24  
    Posts: 758
    Help: 49
    Rate: 189
    divadiow wrote:
    you're a machine!

    Na, this just made a boring 6 hours trip by train very enjoyable ;-)
  • #24 21272317
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14756
    Help: 659
    Rate: 12881
    Hmm so you think that it's more understandable now than "internal"? I hope that our users will know what's "SoC". Maybe better call it "CPU"? Still, it's not technically 100% correct...
    Helpful post? Buy me a coffee.
  • #25 21272321
    divadiow
    Level 38  
    Posts: 5213
    Help: 446
    Rate: 914
    or maybe just "%platform% internal temperature".

    or something else...

    even if SoC is an unknown term to the user, the platform prefix still makes it clearer what the reading refers to. I'd like to think I would infer the gist of the term 'SoC' from the mention of the specific chip/platform beforehand, if I didn't know otherwise. But that's me I guess.
  • #26 21272424
    max4elektroda
    Level 24  
    Posts: 758
    Help: 49
    Rate: 189
    I also think, "internal" is not clear, if we are talking about a a device like a plug for example. I agree that some users won't know the meaning of SoC.

    So "%platform% temperature" would be better than "internal temperature".

    Or what about
    "%platform% chip temperature" ?
    Or even only "Chip temperature"?
  • #27 21276081
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14756
    Help: 659
    Rate: 12881
    I think it can be "Chip" :D
    Helpful post? Buy me a coffee.
  • #28 21276087
    divadiow
    Level 38  
    Posts: 5213
    Help: 446
    Rate: 914
    boring, but sure ;)

    A little clearer I guess

  • Multiple DS1820 sensors causing CRC read errors

    #30 21328143
    sx642005elektroda
    Level 5  
    Posts: 6
    Help: 1
    Rate: 1
    I would like to know if the DS1820 driver supports multiple temperature sensors ?
    I just did a test with 2 sensors connected and I have the temperature for one but not for the other.
    Here is the error message when I connect the second sensor :
    Info:SENSOR:DS1820[0] - Starting conversion
    Info:SENSOR:DS1820[0] - Temp=21.12
    Info:SENSOR:DS1820[0] - Starting conversion
    Error:SENSOR:DS1820[0] - Read CRC=28 != calculated:6f (errcount=1)
    Error:SENSOR:DS1820[0] - Scratchpad Data Read: 50 1 55 5 7f a5 a5 66 28
    Error:SENSOR:DS1820[0] - Read CRC=28 != calculated:6f (errcount=2)
    Error:SENSOR:DS1820[0] - Scratchpad Data Read: 50 1 55 5 7f a5 a5 66 28
    Error:SENSOR:DS1820[0] - Read CRC=28 != calculated:6f (errcount=3)
    Error:SENSOR:DS1820[0] - Scratchpad Data Read: 50 1 55 5 7f a5 a5 66 28
    Error:SENSOR:DS1820[0] - Read CRC=28 != calculated:6f (errcount=4)
    Error:SENSOR:DS1820[0] - Scratchpad Data Read: 50 1 55 5 7f a5 a5 66 28
    Error:SENSOR:DS1820[0] - Read CRC=28 != calculated:6f (errcount=5)
    Error:SENSOR:DS1820[0] - Scratchpad Data Read: 50 1 55 5 7f a5 a5 66 28
    Error:SENSOR:DS1820[0] - Read CRC=28 != calculated:6f (errcount=6)
    Error:SENSOR:DS1820[0] - Scratchpad Data Read: 50 1 55 5 7f a5 a5 66 28
    Info:SENSOR:DS1820[0] - Starting conversion
    Info:SENSOR:DS1820[0] - Temp=21.06
Reply | New topic
Report a violation of the law

Topic summary

LABEL_AI_GENERATED
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.
AI summary based on the discussion. May contain errors.
Today's popular

FAQ LABEL_AI_GENERATED

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]
AI summary based on the discussion. May contain errors.
ADVERTISEMENT