Ds18b20 temp sensor - Custom OID help

Raspbianuser · 29 November 2023 08:29

So a few months ago I got this sensor working in Librenms. It was graphing just fine along with a tempsensor on a Pi. The Pi sensor was red and the aux sensor Ds18b20 was green. But since a update on either Librenms or raspbian the green graphs stopped graphing.

So I added a custom OID to the Pi and it kinda works, but it does not graph the temperature.

So there is at least two ways to solve this:

Pri 1: I would like to have the graph back on the same graph as the other temp sensor on the Pi

Pri 2: Get the custom OID to graph correct result.

Pri X: ./scripts/new-os.php - but I have no clue.

So sometimes the sensors shows up after a reboot, and sometimes not. So this is very strange.

This is the cronjob I had running in the past to make this sensor graph along with the device temperature sensor (RPi)

@reboot /opt/librenms/./scripts/github-apply 9740
@reboot /opt/librenms/discovery.php -h 6

0 * * * * /opt/librenms/scripts/github-apply 9740
0 * * * * /opt/librenms/discovery.php -h 6

And the sensor is working when I run a python script.
29/11/23@09:26:49 - -1.9 C

So what do I do make this work again? I know a user back in 2017 created a yaml-file, and I have asked him via dm to see if his is still working.

Raspbianuser · 29 November 2023 14:26

My /etc/snmp/snmpd.conf
The Ds18b20 temp sensor is mounted on the same RPi that is hosting Librenms.
Any errors in the snmpd-file?

com2sec readonly default myname
group MyROGroup v2c readonly
view all included .1 80
access MyROGroup “” any noauth exact all none none

agentAddress udp:161
extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.1 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.1
extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.2 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.2
extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.3 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.3
extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.4 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.4
extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.5 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.5
extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.6 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.6
extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.7 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.7
extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.8 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.8

Raspbianuser · 29 November 2023 19:33

In hope of some help…

My ./discovery.php -h 6 -dv -m sensors

https://p.libren.ms/view/3071bf03

Raspbianuser · 30 November 2023 12:59

So went out and bought a second DS18b20 temp sensor and soldered it to a second Raspberry Pi.
And I found another way to “install” it software wise, and low and behold the sensors shows up on the second RPi.

Now on the RPi with the issues of not showing any graph, I delete everything with my old setup on this temp sensor. And then I copy most of the settings from the second RPi to the first RPi, and nothing shows up in the Librenms graphs.

Here is the snmpwal output:

librenms@librenms:~/scripts$ snmpwalk -v2c -c community localhost .1.3.6.1.3.1.1
iso.3.6.1.3.1.1.1.0 = INTEGER: 1
iso.3.6.1.3.1.1.2.1.2.7.114.111.109.116.101.109.112 = STRING: "/bin/bash"
iso.3.6.1.3.1.1.2.1.3.7.114.111.109.116.101.109.112 = STRING: "/opt/scripts/gettemp.sh 28-00000e695099"
iso.3.6.1.3.1.1.2.1.4.7.114.111.109.116.101.109.112 = ""
iso.3.6.1.3.1.1.2.1.5.7.114.111.109.116.101.109.112 = INTEGER: 5
iso.3.6.1.3.1.1.2.1.6.7.114.111.109.116.101.109.112 = INTEGER: 1
iso.3.6.1.3.1.1.2.1.7.7.114.111.109.116.101.109.112 = INTEGER: 1
iso.3.6.1.3.1.1.2.1.20.7.114.111.109.116.101.109.112 = INTEGER: 4
iso.3.6.1.3.1.1.2.1.21.7.114.111.109.116.101.109.112 = INTEGER: 1
iso.3.6.1.3.1.1.3.1.1.7.114.111.109.116.101.109.112 = STRING: "-875"
iso.3.6.1.3.1.1.3.1.2.7.114.111.109.116.101.109.112 = STRING: "-875"
iso.3.6.1.3.1.1.3.1.3.7.114.111.109.116.101.109.112 = INTEGER: 1
iso.3.6.1.3.1.1.3.1.4.7.114.111.109.116.101.109.112 = INTEGER: 0
iso.3.6.1.3.1.1.4.1.2.7.114.111.109.116.101.109.112.1 = STRING: "-875"

And here is the script in /opt/scripts/gettemp.sh
My updated snmpd.conf

extend .1.3.6.1.3.1.1 romtemp /bin/bash /opt/scripts/gettemp.sh 28-00000e695099

#!/bin/bash
#
# Usage: gettemp.sh 
# e.g. gettemp.sh 28-021564b3ebff
SENSOR=$1
SLAVE="/sys/devices/w1_bus_master1/"$SENSOR"/w1_slave"
OUTPUT=$(/bin/cat $SLAVE | /usr/bin/awk -F 't=' ' { printf $2 } ')
echo $OUTPUT

So what can I do?

Raspbianuser · 30 November 2023 13:50

Here is the dashboard side by side of the 2

192.168.1.100 is a client of Librenms and have the same sensor soldered onto it. And 192.168.1.50 is the host of Librenms and have the same sensor, same settings everywhere execept for the sensor serial number.

This the snmpwalk from 192.168.1.100

[email protected]:~ $ snmpwalk -v 2c -c community 192.168.1.50 .1.3.6.1.3.1.1
iso.3.6.1.3.1.1.1.0 = INTEGER: 1
iso.3.6.1.3.1.1.2.1.2.7.114.111.109.116.101.109.112 = STRING: "/bin/bash"
iso.3.6.1.3.1.1.2.1.3.7.114.111.109.116.101.109.112 = STRING: "/opt/scripts/gettemp.sh 28-00000e695099"
iso.3.6.1.3.1.1.2.1.4.7.114.111.109.116.101.109.112 = ""
iso.3.6.1.3.1.1.2.1.5.7.114.111.109.116.101.109.112 = INTEGER: 5
iso.3.6.1.3.1.1.2.1.6.7.114.111.109.116.101.109.112 = INTEGER: 1
iso.3.6.1.3.1.1.2.1.7.7.114.111.109.116.101.109.112 = INTEGER: 1
iso.3.6.1.3.1.1.2.1.20.7.114.111.109.116.101.109.112 = INTEGER: 4
iso.3.6.1.3.1.1.2.1.21.7.114.111.109.116.101.109.112 = INTEGER: 1
iso.3.6.1.3.1.1.3.1.1.7.114.111.109.116.101.109.112 = STRING: "-2312"
iso.3.6.1.3.1.1.3.1.2.7.114.111.109.116.101.109.112 = STRING: "-2312"
iso.3.6.1.3.1.1.3.1.3.7.114.111.109.116.101.109.112 = INTEGER: 1
iso.3.6.1.3.1.1.3.1.4.7.114.111.109.116.101.109.112 = INTEGER: 0
iso.3.6.1.3.1.1.4.1.2.7.114.111.109.116.101.109.112.1 = STRING: "-2312"

Raspbianuser · 1 December 2023 13:41

Beginning to think Librenms are having issues with temperatures bellow 0C.
The sensor was working couple of minutes ago when I had it on top of a switch, and it showed 5C, then I moved it outside the storage cabinet, and it spiked to 4 million C while python gettemp.py gives me this:

01/12/23@14:40:58 - -0.9 C
And the sensor has vaninshed from Librenms again.

Raspbianuser · 1 December 2023 19:48

Well, after further testing I think this is the bug, Librenms as far as I can see does not handle temp sensors going from +C to -C very well. I just moved the sensor on top of a switch and it’s showing up in the graphs again. And the python script states this now:

> pi@rpi2:~ $ python temp.py 
> 01/12/23@20:39:09 - 9.6 C

And as one can see on top left image the sensor showed 4294965.7C awhile there, before it went away from the graphs, but it was still available in the python script.
The last image shows the temp as 9.2 C when I put the sensor on top of the hot switch.

Raspbianuser · 1 December 2023 19:59

Posted a bug report here:

github.com/librenms/librenms

Librenms temperature graphs spikes and disapears during winter climate

opened 07:58PM - 01 Dec 23 UTC

Raspbianuser

### The problem I have soldered a temp sensor (DS18B20) to my Raspberry Pi, and… a couple of weeks ago the graphs disappeared all the sudden. And I thought it was due to the the latest relasese. But after some testing it was the weather. The RPi stationed up on our loft here in Norway and it's quite cold. Hence I monitor the temperatures. So I moved the sensor on top of a Unifi switch inside a "data rack" and the temperature graphs came back. And to be sure, I have this python script that I use to check if there is something wrong with the connection or whatever, and the sensor has been online the whole time, but not able to graph. So in conclusion, Librenms can't handle temp graphing going from + Celcius, to - Celcius as far as I can document here. https://community.librenms.org/t/ds18b20-temp-sensor-custom-oid-help/22954/7 - Images and further documentation can be seen here. At least at the latest post, disregard the first ones as I thought I had other issues. ### Output of ./validate.php ```txt =========================================== Component | Version --------- | ------- LibreNMS | 23.11.0-13-g7630983b5 (2023-11-30T18:54:50+01:00) DB Schema | 2023_11_21_172239_increase_vminfo.vmwvmguestos_column_length (274) PHP | 8.2.12 Python | 3.9.2 Database | MariaDB 10.5.21-MariaDB-0+deb11u1 RRDTool | 1.7.2 SNMP | 5.9 =========================================== [OK] Composer Version: 2.6.5 [OK] Dependencies up-to-date. [OK] Database connection successful [OK] Database Schema is current [OK] SQL Server meets minimum requirements [OK] lower_case_table_names is enabled [OK] MySQL engine is optimal [OK] Database and column collations are correct [OK] Database schema correct [OK] MySQl and PHP time match [OK] Active pollers found [OK] Dispatcher Service not detected [OK] Locks are functional [OK] Python poller wrapper is polling [OK] Redis is unavailable [OK] rrd_dir is writable [OK] rrdtool version ok ``` ### What was the last working version of LibreNMS? _No response_ ### Anything in the logs that might be useful for us? _No response_

Raspbianuser · 6 December 2023 12:09

So a little update.

There has been filed an issue over at net-snmp and they mention lmsensors. So I went back to my librenms setup and looked for lm-sensors, and I did not have it installed. So I did install it using apt, and running sensors returns this:

pi@librenms:~ $ sudo sensors
rpi_volt-isa-0000
Adapter: ISA adapter
in0:              N/A  

cpu_thermal-virtual-0
Adapter: Virtual device
temp1:        +23.8 C  (crit = +110.0 C)

w1_slave_temp-virtual-0
Adapter: Virtual device
temp1:         -3.3 C

So the temperature is showing correct using lm-sensors, now what?
snmpwalk from another RPi:

snmpwalk -v 2c -c community 192.168.1.50 .1.3.6.1.3.1.1
iso.3.6.1.3.1.1.1.0 = INTEGER: 1
iso.3.6.1.3.1.1.2.1.2.5.116.101.109.112.49 = STRING: "/bin/bash"
iso.3.6.1.3.1.1.2.1.3.5.116.101.109.112.49 = STRING: "/opt/scripts/gettemp.sh 28-3cb9e38162b8"
iso.3.6.1.3.1.1.2.1.4.5.116.101.109.112.49 = ""
iso.3.6.1.3.1.1.2.1.5.5.116.101.109.112.49 = INTEGER: 5
iso.3.6.1.3.1.1.2.1.6.5.116.101.109.112.49 = INTEGER: 1
iso.3.6.1.3.1.1.2.1.7.5.116.101.109.112.49 = INTEGER: 1
iso.3.6.1.3.1.1.2.1.20.5.116.101.109.112.49 = INTEGER: 4
iso.3.6.1.3.1.1.2.1.21.5.116.101.109.112.49 = INTEGER: 1
iso.3.6.1.3.1.1.3.1.1.5.116.101.109.112.49 = STRING: "-3312"
iso.3.6.1.3.1.1.3.1.2.5.116.101.109.112.49 = STRING: "-3312"
iso.3.6.1.3.1.1.3.1.3.5.116.101.109.112.49 = INTEGER: 1
iso.3.6.1.3.1.1.3.1.4.5.116.101.109.112.49 = INTEGER: 0
iso.3.6.1.3.1.1.4.1.2.5.116.101.109.112.49.1 = STRING: "-3312"

PipoCanaja · 6 December 2023 16:42

Hi
I don’t really understand what OID you use here. Does not look like LM-Sensors to me. :
1.3.6.1.3.1.1.2.1

Could you try to snmpwalk lm-sensors mib directly (assuming it is correctly installed). Look at SNMP and LM-SENSORS to properly configure/install it.

1.3.6.1.4.1.2021.13.16

Raspbianuser · 6 December 2023 19:43

I’m sorry, not my intention be confusing!

This is my snmpd.conf as of now, and it shows what I have been testing in the last weeks/months.

#extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.1 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.1 
#extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.2 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.2
#extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.3 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.3
#extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.4 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.4
#extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.5 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.5
#extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.6 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.6
#extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.7 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.7
#extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.8 therm /bin/bash /opt/snmpmoni/bin/ds18b20.sh -g iso.3.6.1.4.1.50083.100.4.1.1.1.7.8
#extend .1.3.6.1.4.1.50083.100.4.1.1.1.7.1

#test - this one is working
extend .1.3.6.1.3.1.1 temp1 /bin/bash /opt/scripts/gettemp.sh 28-3cb9e38162b8

#Test 2
#extend .1.3.6.1.2.1.25.1.8   /bin/sh  /home/pi/test_ds18b20
#pass .1.3.6.1.2.1.25.1.8   /bin/sh  /home/pi/test_ds18b20
#Test 3 
#pass .1.3.6.1.2.1.25.1.10 /bin/sh /usr/local/bin/snmp-ds2-temp
#pass .1.3.6.1.2.1.25.1.9 /bin/sh /usr/local/bin/snmp-ds2-temp

And this issues was mentioned in the github for lm-sensors and perhaps that confused me as well. But I never had lm-sensors installed before yesterday. At least as a debian package, but perhaps I had some libraries via perl/python or something.

And my point of testing the sensors (lm-sensors) to show the results was to show that it could display temps below 0 C.

sudo sensors
rpi_volt-isa-0000
Adapter: ISA adapter
in0: N/A

cpu_thermal-virtual-0
Adapter: Virtual device
temp1: +25.7 C

w1_slave_temp-virtual-0
Adapter: Virtual device
temp1: -3.0 C

Thus making the idea of lm-sensor gauge32 issues faulty, and maybe it was an Librenms issue anyways!
I have no idea were .1.3.6.1.3.1.1 came from! I have been everywhere to look for oid/mibs for this sensor.

And here is the results of the snmpwalk -v 2c -c community 192.168.1.50 1.3.6.1.4.1.2021.13.16 like you said:

iso.3.6.1.4.1.2021.13.16.2.1.1.1 = INTEGER: 1
iso.3.6.1.4.1.2021.13.16.2.1.1.2 = INTEGER: 2
iso.3.6.1.4.1.2021.13.16.2.1.2.1 = STRING: "temp1"
iso.3.6.1.4.1.2021.13.16.2.1.2.2 = STRING: "w1_slave_temp-virtual-0:temp1"
iso.3.6.1.4.1.2021.13.16.2.1.3.1 = Gauge32: 26254
iso.3.6.1.4.1.2021.13.16.2.1.3.2 = Gauge32: 4294964421

python results on the same sensor at the same time:
06/12/23@20:37:32 - -2.9 C

snmpwalk localhost .1.3.6.1.3.1.1 results at the same time: -note no Gauge32 issues
iso.3.6.1.3.1.1.1.0 = INTEGER: 1 iso.3.6.1.3.1.1.2.1.2.5.116.101.109.112.49 = STRING: "/bin/bash" iso.3.6.1.3.1.1.2.1.3.5.116.101.109.112.49 = STRING: "/opt/scripts/gettemp.sh 28-00000e695099" iso.3.6.1.3.1.1.2.1.4.5.116.101.109.112.49 = "" iso.3.6.1.3.1.1.2.1.5.5.116.101.109.112.49 = INTEGER: 5 iso.3.6.1.3.1.1.2.1.6.5.116.101.109.112.49 = INTEGER: 1 iso.3.6.1.3.1.1.2.1.7.5.116.101.109.112.49 = INTEGER: 1 iso.3.6.1.3.1.1.2.1.20.5.116.101.109.112.49 = INTEGER: 4 iso.3.6.1.3.1.1.2.1.21.5.116.101.109.112.49 = INTEGER: 1 iso.3.6.1.3.1.1.3.1.1.5.116.101.109.112.49 = STRING: "-2875" iso.3.6.1.3.1.1.3.1.2.5.116.101.109.112.49 = STRING: "-2875" iso.3.6.1.3.1.1.3.1.3.5.116.101.109.112.49 = INTEGER: 1 iso.3.6.1.3.1.1.3.1.4.5.116.101.109.112.49 = INTEGER: 0 iso.3.6.1.3.1.1.4.1.2.5.116.101.109.112.49.1 = STRING: "-2875"

sudo sensors result at the same time:

w1_slave_temp-virtual-0
Adapter: Virtual device
temp1:         -2.9 C

So the STRING: “-2875” is correct, but Librenms does not compute!

Hopefully this will clears things up!

tippenring · 10 December 2023 16:50

I wish I could be of more help. Unfortunately I’m just letting you know I’m having the same issue with Mikrotik devices that are outdoors. The issue is a signed integer problem. 1 degree below 0 returns a 2^32-1 value, which LibreNMS ultimately reports as 2^32-1 (4294967295) degrees.

tippenring · 10 December 2023 19:36

I’m just starting to look into how to correct this issue for Mikrotik polling myself. My OID returns a Gauge32 value. Not sure where to go from here yet, but I plan to spend some time trying to figure it out.

~$ ./snmpwalkmt.sh 172.16.12.19 .1.3.6.1.4.1.14988.1.1.3.100.1.3.14
iso.3.6.1.4.1.14988.1.1.3.100.1.3.14 = Gauge32: 9

Raspbianuser · 10 December 2023 20:42

Yeah, hopefully someone will fix this issue!

tippenring · 30 January 2024 04:05

FYI, Mikrotik updated their MIB to indicate an integer value rather than gauge32 in 7.12. This fixed it for me.

snmp - changed “mtxrGaugeValue” type to integer;

Raspbianuser · 30 January 2024 08:01

Yeah thats great news! But nothing has changed as far as I understand over at GitHub - net-snmp/net-snmp: A SNMP application library, tools and daemon yet. And I have asked here as well if there are any progress.

system · 29 April 2024 08:02

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.