DS18B20 reading 85 deg

[kenmercer]

Hardware: NodeMCU running Tasmota 6.0.0a (great software!) compiled under Atom/PlatformIO. Various DS18B20s connected to GPIO14 singularly (also multiples). user_config.h has my own customizations including uncommenting #define USE_DS18x20

The problem: More or less every 5 minutes the reading alternates between room temperature and 85 deg (which is the power on reset value of the sensor). I have one sensor which works flawlessly and a batch of others which fail as described.

Observations: Using an Arduino Nano running the example program DS18x20_Temperature.ino I adjusted the delay which follows starting the conversion. Anything delay less than 600ms returns 85 deg.

In Tasmota in the file xsns_05_ds18x20.ino the Ds18x20Convert() function has a similar delay which is commented out. I have put it back in and varied the delay. My sensors all work if it is greater than 500ms. <much happiness!!>

Both the Tasmota 500ms and Arduino 600ms are within spec of the DS18B20 listed conversion time for 12-bits of 750ms. Probably there's another 100ms taken somewhere by the Tasmota software.

I'm puzzled over why the delay is commented out. It appears to me it is necessary and I'm interested in Theo's reasoning. Or have I just got slower sensors than have been used before??

[arendst]

Any delay is fatal for other tasks the device has to provide. I try to write the code without delays and return to the scheduler.

In the case of DS18x20 the delay was not needed as the Ds18x20Convert is called a second before the data is retrieved from the unit (Ds18x20Show).

This worked fine until rules came along. The rules handler polls every sensor in about 2 seconds by just executing Ds18x20Show without interrogating the Ds18x20Convert. This is why you see what you see.

I have to rethink some sensors data retrieval using rules...

In the meantime you might want to lower the TelePeriod time to get a Ds18x20Convert more often.

[kenmercer]

Duh - I had assumed that delay() was part of the scheduler without much penalty and I'm now clear why it's commented out! I am not clear what exactly a shorter TelePeriod will do but I've lowered it heaps from from the default 300 to 20s. I guess there'll now be a smaller chance of reading before conversion is complete but it will still happen? I'll let it run overnight. Deleting the 85's from the Domoticz log is a bit tedious. Cheers.

[arendst]

Just released an updated driver in the development branch.

Give it a try and let me know the results.

[kenmercer]

Haven't yet figured out what changes you have made but it's working fine this morning after a new compile and TelePeriod = 300. FYI there were no issues overnight using TelePeriod = 20. I'll check again this evening then close this issue. Many thanks!
Ken.