search

enesbcs / rpieasy

Easy MultiSensor device based on Raspberry PI
GNU General Public License v3.0
162 stars 33 forks source link

Dallas Temp sensor read errors and incorrect readings? #245

Closed Budman1758 closed 3 years ago

Budman1758 commented 3 years ago

I have (currently) 4 home made security cameras that have a PI Zero and a homemade hat on them that provides power, a couple transistors and a Dallas temp sensor on it. The transistors control a fan for cooling the camera housing and to switch an IR array on and off. These "hat" boards originally had an ESP-01 module on them to control those functions. The Dallas sensor is there to monitor the camera housing temp and the fan is switched on or off based on temperature in the housing. When the ESP was controlling things I never saw any read errors or problems with temp readings at all.

I recently modified the boards to eliminate the ESP and use the PI to control these things. (When they were first built RPIEasy did not exist.)

On all 4 of these boards I get lots of "read errors" and (I think) incorrect readings for the Dallas sensors. For instance I see the exact same temp reading for many cycles (30 second interval setting) and read errors. If I manually trigger the fan most times the temp reading will stay the same for several cycles even though I know for a fact the temp is changing. This is consistent on all 4 of the of the boards I have modified.

I am using GPIO 13 set to "1-Wire" and the default 1-wire pin is set to "Default" in the pinouts and ports page. Using that particular pin as it was the easiest to rewire the sensor to.

Not positive but there seems to be an issue with the plugin. Please let me know what info you need to help troubleshoot this.

Web log doesn't show much even when set to "debug developer" I can probably get the console log but not quite sure how to access it.

enesbcs commented 3 years ago

There are not so much things to debug, as RPIEasy Dallas pluing only parses values returned by the Linux kernel dallas driver "w1-gpio", nothing more. Device names can be checked by command line: ls /sys/bus/w1/devices

If a device name reported for example 28-0000071cbc72:

cat /sys/bus/w1/devices/28-0000071cbc72/w1_slave

https://jumpnowtek.com/rpi/Using-DS18B20-1-wire-Temp-Sensors-with-the-Raspberry-Pi.html

I guess i can add some debug output to the plugin to let it know what values returned on read error, i guess it will be CRC error.

TD-er commented 3 years ago

I have updated the ESPEasy code for the Dallas plugin a while ago (half year??? no idea, time flies) and it was rather tricky to get it right. Not sure how it is done on the Pi, but if it needs to bit-bang the GPIO pin then I can understand why it is not working well. The timing is rather critical and on a non-real-time environment like Linux, the task may be switched several times. If the Broadcom chip used on the Pi does have a dedicated section to support 1-Wire, I guess it might differ which pin you use. So maybe you can have a quick search on the supported protocols of the used Broadcom chip?

Budman1758 commented 3 years ago

I don't have any clue as to the reasons but I can say that its currently working pretty poorly. I'm only sampling the sensor at 30 to 60 second intervals.

enesbcs commented 3 years ago

Not sure how it is done on the Pi, but if it needs to bit-bang the GPIO pin then I can understand why it is not working well. The timing is rather critical and on a non-real-time environment like Linux, the task may be switched several times.

Indeed, precise timing is not something, that a Linux based device can provide. Broadcom has no dedicated 1wire support, the official kernel driver uses bitbang magic, and there are nothing that can be faster on Linux than a kernel driver. Although its reported that w1-gpio driver in different kernels works differently.. so if it is working, avoid kernel upgrades. If it is not working, try downgrade.

enesbcs commented 3 years ago

I don't have any clue as to the reasons but I can say that its currently working pretty poorly. I'm only sampling the sensor at 30 to 60 second intervals.

You could see kernel driver messages by executing this linux console command:

dmesg | grep w1

Budman1758 commented 3 years ago

This is starting to look like I have some crap sensors. I will get some genuine ones and go from there.

uzi18 commented 3 years ago

There are lots of fake sensors on the market, please try to avoid Chinese crap and buy something from farnell/mouser/digikey

Budman1758 commented 3 years ago

There are lots of fake sensors on the market, please try to avoid Chinese crap and buy something from farnell/mouser/digikey

Indeed. After checking this page out it looks like ALL of mine are fake.

Budman1758 commented 3 years ago

Got new sensors but will be a while B4 I can rework the boards to fit the new ones. Closing this for now. Will re-open later if necessary.