Odd behaviour of DS18B20

[mburden (Mike)]

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.

OpenEnergyMonitor.org
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
40-133-16-75-5-0-0-34
40-207-198-117-208-1-60-242

'+++' then [Enter] for RF config mode
(Arduino IDE Serial Monitor: make sure 'Both NL & CR' is selected)
waiting 5s...
temp:181,tempex0:189,humidity:250,batt:27
temp:180,tempex0:190,humidity:0,batt:27
temp:180,tempex0:188,humidity:0,batt:27

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?

[Robert.Wall]

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

What are the serial numbers of your sensors?

[Greebo]

<Direct link to post 78>

Ds18b20 and emonTX3CM firmware

If only life were that clean! I’ve noticed significant variations in how the various non-genuine ds18b20s work. Most are actually an improvement on the genuine part, but one group are a real pain to deal with. In my collection I’ve identified 4 different classes and it looks like the MSByte of the UID gives some clue as to which class they’re in: [Screenshot from 2020-06-08 09-55-32] The first group of 3 are genuines and perform as per the spec, with very little variation. I’ve got 100 of…

[mburden (Mike)]

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.

[borpin (Brian Orpin)]

@Robert.Wall

Have you read this topic:

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

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.