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

Question

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...

max4elektroda · Answer

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?

imvaloo · Answer

>>21269846 I did use a different channel (2). On the main page of OpenBeken the temperature is indeed wrong also. It shows 0 degrees.

max4elektroda · Answer

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:

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:

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):

addRepeatingEvent 5 -1 publishFloat DS1820Temp $CH2/100

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

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.

imvaloo · Answer

>>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:

However on the home page it doesn't show on Channel 2, even though the temperature is reported under DS1820:

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.

max4elektroda · Answer

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

divadiow · Answer

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

.747 - release before "Improve DS1820 driver (#1382) (ad816b7), closes #1382"

then on latest build

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)

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

max4elektroda · Answer

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.

divadiow · Answer

yep yep, sure. I just went off on a wishlist tangent

max4elektroda · Answer

BTW, in DEBUG the family discovered should be visible:

   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

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()"

divadiow · Answer

Code: TextLog in, to see the code the extent of DS1820 logs on EXTRADEBUG level

max4elektroda · Answer

Thanks - so it discovers family 0 instead of 0x28. Opened 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 ...)

divadiow · Answer

1394_merge_9665a7da33cb Code: TextLog in, to see the code Added after 7 [minutes]: same PR with the Maxim. ALL logging level Code: TextLog in, to see the code

max4elektroda · Answer

Hm, looks the sensor doesn't report the ROM at all. But the datasheet I found also lists 0x33 as read ROM: Did I get it right: Even with the changed code in 1394_merge_9665a7da33cb there are no temperatures shown for SensyLink?

divadiow · Answer

correct. no temps are read with the Sensylink with that PR. Here is ALL level log from start of driver Code: TextLog in, to see the code Added after 2 [minutes]:powersave 0 for all this, if there was any query about the state of that

imvaloo · Answer

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?

max4elektroda · Answer

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]: Please leave it open, seems there is an issue with some clone sensors ...

divadiow · Answer

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: TextLog in, to see the code Added after 2 [minutes]: @imvaloo latest being 1.17.756 or the PR version 1394_merge_9665a7da33cb? what version was this?

max4elektroda · Answer

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.

divadiow · Answer

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

max4elektroda · Answer

... or don't push it to the future, just do it Hope does the trick ... I'm not at home and can't test, so if you need another firmware to try

divadiow · Answer

you're a machine! Added after 10 [minutes]: well, I love it, but I guess it's up to bossman @p.kaczmarek2

max4elektroda · Answer

Na, this just made a boring 6 hours trip by train very enjoyable

p.kaczmarek2 · Answer

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...

divadiow · Answer

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.

max4elektroda · Answer

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?

p.kaczmarek2 · Answer

I think it can be Chip

divadiow · Answer

boring, but sure A little clearer I guess

sx642005elektroda · Answer

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

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

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Post #26

Post #27

Post #28

Post #29

Post #30

Topic summary