SNMP Interface missing data
![[Deleted User]](https://community.infrasensing.com/applications/dashboard/design/images/defaulticon.png)
[Deleted User]
I've got a v5 sensor gateway running firmware 4.1 connected to a sensor hub. All probes are visible and configurable in the web interface.
Probe connections are as follows:
I understand that the built in temperature probe fora v5 sensor gateway consumes SNMP OID .1.3.6.1.4.1.17095.3.1.0 - .1.3.6.1.4.1.17095.3.4.0 and likewise any other probes conneted via the built in gateway probe connectors would logically follow. I also understand that the sensor hub publishes its OIDs outside what the current published mib documents. As others in the forum have suggested, I perform an snmpwalk on the entire .1 base oid to get a full picture of what's provided. The sensor hub appears to publish it's data beneath .1.3.6.1.4.1.17095.11.1 - .1.3.6.1.4.1.17095.11.16. Even if you don't connect any probes at all, these oids still exist but simply return a "-" string; thus 1-16 seems to be an arbitrary hard limit. I was configuring my SNMP poller of choice (in my case cacti) and noticed that I was missing temperature/humidity probe E. This means that I have 6 (number of temp/humidity probes) * 3 (readings per temp/humidity probe) + 1 (wet/dry sensor) = 19 OIDs needed which cannot be satisfied with a cap of 16. Since there is no currently published mib documenting this, there is no way to know this prior to purchase. This also means by my guess the arbitrary limit of OID .1.3.6.1.4.1.17095.3.1 - .1.3.6.1.4.1.17095.3.16 with each sensor consuming 4 oids each means you could get 3 probe sensors back maximum (because you have to remove 4 oids for the built in SGWv5 built-in). This means you couldn't connect two temperature & humidity probes to the built in ports and get all the data back. I would test this myself, but I've already got my gateways configured and collecting data in production. Is there something I've missed that should have been connected or configured differently in order to provide this missing data?
The only solution I can come up with is to downgrade firmware from 4.1 to 3.30. This drops the dew point metric and makes the math work out with an arbitrary cap of 16 (6*2+1=13). However, I'm very not happy with that answer because that's not what I was sold. Additionally, there wasn't documentation that I can find to suggest this arrangement shouldn't work.
If this really is a bug needing to be fixed, please consider publishing a snmp table instead of an arbitrary, denormalized set of oids across two branches with different substructures. This would remove the arbitrary limits and still provide a generic interface like you do currently. If you want to go for the most desirable solution, create different snmp tables for each sensor type. That way you can document in the mib what the expected values and structure should be, provide the correct snmp datatype of GAUGE instead of STRING, as well as provide temperature data back in both F & C at the same time. Note: the two suggestions here are neither mutually exclusive nor incompatible with your current layout for backward compatibility reasons.
Probe connections are as follows:
- Internal Temperature
- Sensor Hub
- Port 1: Temperature & Humidity Probe A
- Port 2: Temperature & Humidity Probe B
- Port 3: Temperature & Humidity Probe C
- Port 4: Temperature & Humidity Probe D
- Port 5: Open
- Port 6: Water Contact Probe B
- Port 7: Temperature & Humidity Probe F
- Port 8: Temperature & Humidity Probe E
I understand that the built in temperature probe fora v5 sensor gateway consumes SNMP OID .1.3.6.1.4.1.17095.3.1.0 - .1.3.6.1.4.1.17095.3.4.0 and likewise any other probes conneted via the built in gateway probe connectors would logically follow. I also understand that the sensor hub publishes its OIDs outside what the current published mib documents. As others in the forum have suggested, I perform an snmpwalk on the entire .1 base oid to get a full picture of what's provided. The sensor hub appears to publish it's data beneath .1.3.6.1.4.1.17095.11.1 - .1.3.6.1.4.1.17095.11.16. Even if you don't connect any probes at all, these oids still exist but simply return a "-" string; thus 1-16 seems to be an arbitrary hard limit. I was configuring my SNMP poller of choice (in my case cacti) and noticed that I was missing temperature/humidity probe E. This means that I have 6 (number of temp/humidity probes) * 3 (readings per temp/humidity probe) + 1 (wet/dry sensor) = 19 OIDs needed which cannot be satisfied with a cap of 16. Since there is no currently published mib documenting this, there is no way to know this prior to purchase. This also means by my guess the arbitrary limit of OID .1.3.6.1.4.1.17095.3.1 - .1.3.6.1.4.1.17095.3.16 with each sensor consuming 4 oids each means you could get 3 probe sensors back maximum (because you have to remove 4 oids for the built in SGWv5 built-in). This means you couldn't connect two temperature & humidity probes to the built in ports and get all the data back. I would test this myself, but I've already got my gateways configured and collecting data in production. Is there something I've missed that should have been connected or configured differently in order to provide this missing data?
The only solution I can come up with is to downgrade firmware from 4.1 to 3.30. This drops the dew point metric and makes the math work out with an arbitrary cap of 16 (6*2+1=13). However, I'm very not happy with that answer because that's not what I was sold. Additionally, there wasn't documentation that I can find to suggest this arrangement shouldn't work.
If this really is a bug needing to be fixed, please consider publishing a snmp table instead of an arbitrary, denormalized set of oids across two branches with different substructures. This would remove the arbitrary limits and still provide a generic interface like you do currently. If you want to go for the most desirable solution, create different snmp tables for each sensor type. That way you can document in the mib what the expected values and structure should be, provide the correct snmp datatype of GAUGE instead of STRING, as well as provide temperature data back in both F & C at the same time. Note: the two suggestions here are neither mutually exclusive nor incompatible with your current layout for backward compatibility reasons.
This discussion has been closed.
Comments
serverscheck.com/sensors/firmware2.asp?v=5
For release notes, kindly check the following:
serverscheck.com/sensors/firmware_release.asp