Geist Watchdog External Sensor Discovery Not Working

Old Issue

Since the last issue was closed I figured I’d open a new one and attach the relevant data. Geist released another new firmware (v3.4.0) and apparently a new MIB file with Vertiv???

Can someone that is way smarter than me take a look and see if I’m just missing something?

Discovery
https://p.libren.ms/view/dfcea0c2

Poller
https://p.libren.ms/view/65a213be

snmpbulkwalk
https://p.libren.ms/view/eaee4297

VERTIV-BB-MIB
https://p.libren.ms/view/4dfb753f#L2

(Imported from https://github.com/librenms/librenms/issues/10449, Original request by: @VanillaNinjaD)

I am experencing the same thing. I believe the issue is related to the fact that the geist-watchdog.yaml file references the sysObjectID as an OID shared by geist-imd. I would love to help, but I am not a developer. I attempted to see if I could figure it out on my own, but nothing I have tried is working. It always sees the device as geist-watchdog.

I was able to get the Vertiv PDU to start logging power data (mostly). However, I am not sure if it’s the correct method or not. I had to create customer definitions and modify geist-watchdog.yaml file under includes/definitions and changed the sysObjectID as the one included was too generic:

from

.1.3.6.1.4.1.21239

to

.1.3.6.1.4.1.21239.2

This may have broken the definition for the other Geist watchdog devices, but that’s not an issue for me because I don’t have any of those to monitor. Here are the custom files that I had to create:

Vertiv PDU Discovery YAML:

Vertiv PDU Definition YAML:

Vertiv PDU MIB (I called it VERTIV-V5-MIB and put under mibs/vertiv/):

I am having an issue where it is not picking up the 3 circuits for the Current values.

you should submit the changes in git hub a Pull Request.

Thank you. I have never done that before, but I believe it’s a well documented procedure. I am just not confident that it won’t break the other Geist devices. I’ll see if I can get the issue with only 3 of the circuits graphing data before I submit the changes.

Bumping this!

I’m revisiting this now with a fresh set of eyes and after rewriting all the definition and discovery yaml to be specific for the new unified VERTIV-BB-MIB I can poll and display all sensors both internal and external

How does the team suggest that I format my pull request since I believe the device OID is the same regardless of whether the firmware is new enough to require the VERTIV MIB? I don’t want to submit a PR that’s going to break all older Watchdogs

Is there a way to identify it as a different OS based on release version?

I submitted this PR and had a subsequent discussion there about (what I see now) is this issue. The problems for me are:

  1. Multiple sensors of the same type getting added via the yaml file
  2. The old GEIST-MIB-V3 defines an oid for the tempSensorTable that is not support for devices supporting GEIST-V4-MIB.

My “hack” was this, which remove the MIB-V3 and allows multiple sensors of the same type. I could have just as easily swapped the order of the MIBs, but that would leave a trap for someone needing the old support.

--- a/includes/definitions/discovery/geist-watchdog.yaml
+++ b/includes/definitions/discovery/geist-watchdog.yaml
@@ -1,4 +1,4 @@
-mib: GEIST-V4-MIB:GEIST-MIB-V3
+mib: GEIST-V4-MIB
 modules:
     sensors:
         temperature:
@@ -10,11 +10,13 @@ modules:
                     value: internalTemp
                     num_oid: '.1.3.6.1.4.1.21239.5.1.2.1.5.{{ $index }}'
                     descr: internalName
+                    index: 'internal.{{ $index }}'
                 -
                     oid: tempSensorTable
                     value: tempSensorTemp
                     num_oid: '.1.3.6.1.4.1.21239.5.1.4.1.5.{{ $index }}'
                     descr: tempSensorName
+                    index: 'remote.{{ $index }}'

In communicating with a Vertiv Application Engineer, he noted “In 2014 ITWatchdogs was manufacturing these [watchdog devices] and using a different MIB. If the firmware for a device is running 1.6 or previous it would be using an older MIB.” I am working on a PR that separates these devices into different sensors given their defined SNMP MIB support is incompatible with each other for the purposes of supporting external sensors. Until then, I have this patch in place.