Odd behaviour of DS18B20

I have modified the emonth sketch to accept up to 4 external DS18B20 while keeping the same packet format. However, something very odd seems to be happening. I bought some new DS18B20 a couple of years ago. My old ones recently ran out so I’ve started using the new ones. However, they are behaving very oddly.

The software detects the DS18B20 and I’ve added code to print their addresses. However, the first temperature measure always reads 25.0 followed by zero for subsequent reads.

emonTH FW: Mike:V1 V326
No EEPROM config
Int RFM...
RFM Started
Node: 24 Freq: 433MHz Network: 212
Int SI7021..
SI7021 Started, ID: 21
SI7021 t: 18.99
SI7021 h: 72.03
2 DS18B20

'+++' then [Enter] for RF config mode
(Arduino IDE Serial Monitor: make sure 'Both NL & CR' is selected)
waiting 5s...

Note I hijacked the existing values so temp is the first external DS18B20 (old). tempex0 is the internal temp and humidity is the second DS18B20 (new).
I realise the codes supports multiple external DS18B20 but I wanted to keep the packet size the same. My code simply reuses other fields when it sees more DS18B20 but by disconecting the external sensors the the box reverts back to standard.

I thought it was the connection or cable lengths but the results are always the same no matter how I connect them or in what combination.

If I revert to the old DS18B20 ones everything works as expected.

If that wasn’t odd enough I have used the same sensors on a RFM69pi board which I have adapted to become a radiator monitor, and there I noticed it also starts off at 25 but for subsequent reads it settles down to the correct values. It seems to take 2 or three goes for the temperatures to reach what I believe to be the correct values.

The writing on the sensors suggests they are all Dallas.

Has anyone notice different characteristics for these devices or can explain what I am seeing?

Have you read this topic: Ds18b20 and emonTX3CM firmware - post 78 in particular and onwards.

What are the serial numbers of your sensors?

1 Like

<Direct link to post 78>

Thanks all. Sorry must have missed this. Great work!
I see that the issue can be worked around by adjusting the delay to 750 and precision to 12 bit. This has worked (so far) so at least I can use my sensors.

The addresses are in the thread above although they are reversed and in decimal.
40-133-16-75-5-0-0-34 = 2200000548108528
40-207-198-117-208-1-60-242 = F23C01D075C6CF28.

These troublesome variations might also explain why I had so much trouble on my PI. The sensors would just lock up after a numbers of days and needed to be powered off to restart them. The Pi OS didn’t have this control so had to use something call bit-bang library off github. This allowed me to power the device from a data line so when it stopped I could reboot it. The resolution seems to drop after hours or days before it eventually locks up.

I’d forgotten about that (though I had remembered that not all DS18B20s are equal) :laughing:

They are still hooked up via a Wemos D1 Mini running Tasmota though the 3C ones are on their own device (Tasmota will only do a max of 8) reporting every 10s.