Multiple DS18B20 resolution issue

[defender52]

Hello,

I have noticed unexpectable readings from 2 ds18b20 connected to the same 1-wire bus (1 common pull-up resistor 4.7k). All sensors are set to 12 bit resolution, but it seems that 2 of them ork at 8 bit. I've made a topic on forumand was suggested to raise an issue: https://www.letscontrolit.com/forum/viewtopic.php?f=5&t=7055

Thanks for you help, Alexander

[TD-er]

What build are you using?

[defender52]

mega-20190108, but i've tried several previous oneswith the same result.

[defender52]

Pardon,

the current biud in use is mega-20190926

[TD-er]

I know @uzi18 did make some changes recently in the Dallas code and I was under the impression he moved the resolution setting to the ESPeasy settings instead of storing them in the sensor.

[defender52]

I think this issue is not resulted from recent changes since January build worked similar.

[TD-er]

I think this issue is not resulted from recent changes since January build worked similar.

What I meant was; I had hoped it was fixed with recent changes.

[jimmys01]

This seems simple enought to fix. In the PLUGIN_INIT we have to re write the resolution to the sensor, just to be sure that it is in sync with the settings. Also please try to delete and re-make the tasks, perhaps this will resolve your issue for now until there will be a pernament fix. Also I havent noticed something.

[defender52]

Ok, thanks, I'll try. BTW what's your opinion about the behaviour and corresponding sensors addresses? (please see topic on forum for details)

[jimmys01]

See #2645

[jimmys01]

Do your sensor addresses start with 28-xx.....?

[defender52]

Yes:

[defender52]

Tried the build you provided - the same picture:

[defender52]

readings every minute

[jimmys01]

try with the one on #2645 and also go in each sensor and delete it and set it again. Or at least press the submit button on each task to "re-initialize" everything.

[jimmys01]

Please open the web log, let it run for a couple of minutes and sent us a copy.

[defender52]

Tried #2645 - no changes. LOG: 397553: EVENT: Clock#Time=Tue,15:05 404857: WD : Uptime 7 ConnectFailures 0 FreeMem 11760 WiFiStatus 3 406854: DS : Temperature: 11.81 (28-65-9-43-98-7-0-ce) 406857: EVENT: temp_guest_floor#temp=11.81 412788: DS : Temperature: 11.38 (28-ff-ec-dd-c1-17-4-34) 412792: EVENT: temp_dining1_floor#temp=11.38 428311: DS : Temperature: 11.00 (28-10-0-43-98-3-0-75) 428313: EVENT: temp_dining2_floor#temp=11.00 434857: WD : Uptime 7 ConnectFailures 0 FreeMem 9904 WiFiStatus 3 457553: EVENT: Clock#Time=Tue,15:06 464853: WD : Uptime 8 ConnectFailures 0 FreeMem 11408 WiFiStatus 3 466679: DS : Temperature: 12.37 (28-65-9-43-98-7-0-ce) 466681: EVENT: temp_guest_floor#temp=12.37 471626: DS : Temperature: 11.38 (28-ff-ec-dd-c1-17-4-34) 471629: EVENT: temp_dining1_floor#temp=11.38 488451: DS : Temperature: 11.00 (28-10-0-43-98-3-0-75) 488453: EVENT: temp_dining2_floor#temp=11.00 494853: WD : Uptime 8 ConnectFailures 0 FreeMem 10856 WiFiStatus 3 517553: EVENT: Clock#Time=Tue,15:07 524853: WD : Uptime 9 ConnectFailures 0 FreeMem 11168 WiFiStatus 3 526502: DS : Temperature: 12.31 (28-65-9-43-98-7-0-ce) 526504: EVENT: temp_guest_floor#temp=12.31 530468: DS : Temperature: 11.38 (28-ff-ec-dd-c1-17-4-34) 530471: EVENT: temp_dining1_floor#temp=11.38 548591: DS : Temperature: 11.00 (28-10-0-43-98-3-0-75) 548594: EVENT: temp_dining2_floor#temp=11.00 554853: WD : Uptime 9 ConnectFailures 0 FreeMem 11104 WiFiStatus 3

[uzi18]

@defender52 "debug" log level please, so we can check what we got from sensors, they don't look like 8 bit.

[defender52]

Oh, sorry. Here it is: 4394853: WD : Uptime 73 ConnectFailures 4 FreeMem 10528 WiFiStatus 3 4400239: DS: SP: b0,0,34,3,1f,c5,d4,83,d8,OK,6 4400239: DS : Temperature: 11.00 (28-10-0-43-98-3-0-75) 4400242: EVENT: temp_dining2_floor#temp=11.00 4417438: EVENT: Clock#Time=Tue,16:12 4424854: WD : Uptime 74 ConnectFailures 4 FreeMem 10840 WiFiStatus 3 4440360: DS: SP: b6,0,4b,46,7f,ff,c,10,35,OK,7 4440361: DS : Temperature: 11.38 (28-ff-ec-dd-c1-17-4-34) 4440363: EVENT: temp_dining1_floor#temp=11.38 4442410: DS: SP: c5,0,55,5,7f,7e,81,66,e0,OK,7 4442410: DS : Temperature: 12.31 (28-65-9-43-98-7-0-ce) 4442414: EVENT: temp_guest_floor#temp=12.31 4454853: WD : Uptime 74 ConnectFailures 4 FreeMem 10840 WiFiStatus 3 4460389: DS: SP: b0,0,34,3,1f,c5,d4,83,d8,OK,7 4460389: DS : Temperature: 11.00 (28-10-0-43-98-3-0-75) 4460392: EVENT: temp_dining2_floor#temp=11.00

[uzi18]

so in facts you have 2 sensors with 9 bit resolution, communication is ok and connected properly.

[uzi18]

@TD-er @jimmys01 ok I see, set Resolution is broken one more time in dallas plugin, maybe thats why you have problem

[uzi18]

will provide patch later

[defender52]

Thanks a lot.

[uzi18]

from your debug log:

4460389: DS: SP: b0,0,34,3,1f,c5,d4,83,d8,OK,7
4460389: DS : Temperature: 11.00 (28-10-0-43-98-3-0-75)
4460392: EVENT: temp_dining2_floor#temp=11.00
$ python
Python 2.7.16 (default, Mar  6 2019, 07:55:11) 
[GCC 8.3.0 20190222 (release)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 0x00b0*0.0625
11.0

setresolution function should work ok, I'm curious why resolution was changed in your test case

[TD-er]

Not sure how the sensor does keep its settings. Is it stored in non-volatile ram? Is it kept as long as the sensor is powered? Can the sensor crash and reboot? What does that do to the settings?

After all, there are lots of fake Dallas sensors out there. And not sure if buggy sensors + buggy code amplify the symptoms or cancel them out ;)

[jimmys01]

The default resolution after power on is 12 bit. The config registers are non volatile

[TD-er]

The default resolution after power on is 12 bit. The config registers are non volatile

Are you sure about the default? Why would anyone then try to set it to 9 bits?

[defender52]

I've got several sensors purchased from the other seller. I'll try them out on the same scenario tomorrow evening and report.

[jimmys01]

yes the power on default is 12 bit. There is also the possibility that the scratchpad is never properly written in the first place and this may have consequences?...

https://github.com/milesburton/Arduino-Temperature-Control-Library/issues/45 Perhaps related? The setresolutionpart of the source code and their DallasTemperature::writeScratchPad seem very similar and it also seems that they had the same issue.

[uzi18]

resolution depend on sensor, some new bought have 9 bits by default, should be stored in eeprom

we have fixed version of set resolution so it is better than arduino lib ;) maybe we found some kind of bug in sensor or sensor is not full featured clone? we read scratchpad 2x, then we write scratchpad, then we store scratchpad in eeprom and issue bus reset - it is not out of protocol standard

first things first - I need to prepare patch to store resolution in task configuration properly

[jimmys01]

Still their part of the code is copy paste to ours and they had this problem.

[uzi18]

no it is not, we have own, @TD-er did some cleanup and refactoring 3 months ago and i did not noticed he introduced one more function to address rom with bus reset inside :) On the other side it is hard to write something new in dallas area, so code looks similar

we have resolved eeprom writing from scratchpad and they not ;)

[uzi18]

@TD-er do you have any reference to fake dallases ?

[TD-er]

I do have 5 or 6 Dallas sensors and I have one in operation in my weather station. That last one was made by Shardan, so I guess that one is most likely a genuine one. The others I have are from DX/Ali/Banggood, so no guarantees about authenticity.

[uzi18]

here it is https://forum.arduino.cc/index.php?topic=544145.msg4299313#msg4299313 and here: https://forum.arduino.cc/index.php?topic=397240.0

[TD-er]

According to the datasheet, byte 5 should read 0xFF and byte 7 should be 0x10. In our cases they are 0x7E or 0xA5 and 0x66, respectively. The ones reading 0x7E in byte 5 give noticeably more noisy temperature reading than the ones reading 0xA5.

That's a simple test I would say. Maybe not state it directly it is a fake, but log that there are inconsistencies found.

[uzi18]

@defender52 is it possible for you to change 2 problematic sensors for different ones? and please do one more time debug log - thanks

[uzi18]

According to the datasheet, byte 5 should read 0xFF and byte 7 should be 0x10. In our cases they are 0x7E or 0xA5 and 0x66, respectively. The ones reading 0x7E in byte 5 give noticeably more noisy temperature reading than the ones reading 0xA5.

That's a simple test I would say. Maybe not state it directly it is a fake, but log that there are inconsistencies found.

"Suspicious sensor detected" ;)

[defender52]

Unfortunately not, since it is integrated deep into concrete plate. (( LOG: log.txt

Is that enough?

[Misiu]

According to the datasheet, byte 5 should read 0xFF and byte 7 should be 0x10. In our cases they are 0x7E or 0xA5 and 0x66, respectively. The ones reading 0x7E in byte 5 give noticeably more noisy temperature reading than the ones reading 0xA5.

That's a simple test I would say. Maybe not state it directly it is a fake, but log that there are inconsistencies found.

"Suspicious sensor detected" ;)

@uzi18 so original Dallas sensors should always return the same values on byte 5 and byte 7? Does this mean that this "rule" can be used to verify if we have a genuine sensor or a fake one? Maybe ESPEasy could check that and at least print some info in the log? This would allow two things:

• would inform the user that their sensor can be fake and he may have inaccurate readings or other problems
• would allow using ESP Easy as a DS18B20 tester, to see if ones we have are genuine (or at least return values as the genuine ones)

[uzi18]

https://datasheets.maximintegrated.com/en/ds/DS18B20.pdf

[Misiu]

Bartku (@uzi18) so byte 5 and byte 7 should have values from the datasheet. As @TD-er wrote this would be the simplest test (I didn't notice his comment). So maybe this two bytes can be checked and when any differences found a log entry saying that maybe the user doesn't have a genuine sensor should be added. What do You think?

[uzi18]

Yes, will add this info to log

[jimmys01]

those registers can change while the sensor is in operation. they have those values when the sensor is powered on. Also counterfits can have those values to. There is no sure way that you can know if you have a counterfit sensor by just looking in the registers. Also this applies to the DS18B20 sensor and not to the others of the same family.

edit. @defender52 Have you tried to lower the resistor you use (default is 4.7k)? You can go up to 2K. I dont think that it will make a difference but just to make sure.

[uzi18]

maybe it is possible, we can try to reset sensor and read initial values

[TD-er]

There are lots of topics online about fake Dallas sensors. Just came across this one: AliExpress / EBay / China market fake DS18B20 Sensors

[uzi18]

"They always respond as they are parasite-power" have also found something like this on one of our users log and they were connected with 3 cables!!

[Misiu]

@TD-er I have some genuine sensors and some clones from Ali so I can compare them. I always used 3 cables connection and 4,7k resistor and I had no problems before (except for no communication issues, then I throw the sensors away). I'll try to connect 2 genuine and 2 clones sensors (I wish I could connect more😅 ) and I can send the log if that would help.

[TD-er]

This is also a nice post about fakes

I can't prove they are fake, but they don't behave like any of the 14 other DS18B20 I have, two different batches of 7 each.

When I test them, it is impossible to have more than three of them connected to the same bus. I can have all of the other 14 I have one the same bus, and I can have 3 of the ones I got from Banggood in addition. Regardless of how I connect them, I can not have more than 3 of them connected at the same time. Only 3 (no other DS18B20's) is OK, 4 or more does not work. None of the DS18B20 on the bus is recognized if I have more than 3 of this batch.

And one report dating back to 2015

And a way more descriptive report of fakes: https://github.com/UnifiedEngineering/T-962-improvements/issues/114 (suggesting different resistor values to make them work)

Again link to the topic mentioned before: Discussion on fakes refusing to write settings with example code to check for fakes

[uzi18]

@Misiu ok will try to prepare test build for you so we will lern how to detect original/genuine 4M build will be ok for you?

[Misiu]

@uzi18 I use Wemos D1 so 4M is fine :)