Add support for new sensors on Firebrick 9000 models.

[cjsoftuk]

Adds voltage and temperature monitoring for the Firebrick 9k

Work in progress with the testing.

Please note

Please read this information carefully. You can run ./lnms dev:check to check your code before submitting.

• Have you followed our code guidelines?
• If my Pull Request does some changes/fixes/enhancements in the WebUI, I have inserted a screenshot of it.
• If my Pull Request makes discovery/polling/yaml changes, I have added/updated test data.

Testers

If you would like to test this pull request then please run: ./scripts/github-apply <pr_id>, i.e ./scripts/github-apply 5926
After you are done testing, you can remove the changes with ./scripts/github-remove. If there are schema changes, you can ask on discord how to revert.

[cjsoftuk]

@Jellyfrog - This is now, I hope, ready to go. If there's any feedback/comments, etc, I'll address them on Tuesday next week, UK working hours.

There are LibreNMS users out there with new Firebrick 9000-series so it would be good to get this in (and then one of my customers can also switch back to not running a custom LibreNMS install).

[cjsoftuk]

@murrant and or @PipoCanaja - I think you had a look a previous Firebrick MRs for me. Are either of you able to take a look at this one and look at getting it moving?

[murrant]

This looks like it makes things pretty specific to hardware, increasing the chances things will break in the future. What is the gain?

[cjsoftuk]

@murrant - The Firebrick 9000 is a family of devices that are all the same hardware, but subtly different software.

It is relatively specific to the hardware, but that's largely down to the fact that it's a class of hardware with many software flavours all of which have these sensors. I am in talks with the Firebrick devs to put the limits in a table nicely.... but they can't say when that'll be done at this point. In a few years (being realistic) we can likely condense this into a much shorter and easier to read definition once the vast majority of devices in the wild are running new enough code to have limits in the table (which is currently the missing link here).

[PipoCanaja]

Agreed, it's indeed hard to read, but I think the point is that YAML is better than PHP specific code OR Custom MIB. So if one wants to monitor these devices, seems that this PR approach is the one and only option.

[PipoCanaja]

LGTM

[cjsoftuk]

Thanks @PipoCanaja - I agree it's not the nicest way to do it, but when you're dealing with a device with an SNMP server that was initially written many many years ago which isn't top of the developers' priority tree, you get fun little issues like the missing limits in the table. As I say, at some point, I can hopefully get the Firebrick devs to put the necessary features in for us to get limits out of the table as well as the actual data and this will add scope for simplifying this.