Help with temp probe returning XML

[manahmanah]

Hello,

I'd like to put my new environmental monitor Allnet ALL3000 under cacti control.
The box has only HTTP access, no SNMP, but it can return the status of its 8 probes in XML format.
I'm an absolute beginner with cacti scripting, can you please point me to the right tutorial (or to a ready-made script, if there is any)?

Thanks

[floaty]

Hi, recently I got myself an Allnet 3419.
Was kind of bamboozeled, because I was thinking it supports snmp ... but no
Data is only delivered in JSON format ( ... couple of years are gone since manahmanah's post) maybe they switched from XML to JSON.
Never did anything with either of both, ...
Key skill needed: build a proper json-filter to grab the data from the device (or any other JSON-source).
Looks scary when you're a complete newbie (like me), but in the end: it's fun.

Thing to do:
1.) grab data with curl
2.) filter with a json parser (1. & 2. in one step)
3.) define cacti a 'data input method'
...
4.) make a datasource template
5.) make a graph template

To parse the json-data I've used 'jq'.
Since I am not in the position to hand over a "best-practice-vademecum" I've just attached a txt-file and some pictures which may illustrate how I got my cacti-graphs ... hopefully it's helpful for someone.
These are not intended for ready to use - just examples (with lots of space for improvement).

sincerely
floaty

json-2-cacti#3.PNG (62.49 KiB) Viewed 2986 times

[Osiris]

Yup, that's the way.

[floaty]

just checked distributor web-site ... no bamboozelization ! ... there is a loadable snmp-modul !
.
.. but you have to request it (o'really ?) on the vendor-site ... ... reading before coding
.
https://www.allnet.de/de/allnet-brand/p ... anfordern/
.
jeez ... ... json-knowledge by accident

[netniV]

Sounds like you have this in hand. You've got the steps for making a script server script and how to obtain the info from the vendor. Hopefully they won't have made it too difficult for you. My only thought is that this will likely not work with our standard interface graphs since they use the SNMP data source, but you could probably make a copy of them and adjust the data source.

[floaty]

My json-based data input method works fine ... so far (I'm still waiting for vendor-reply to get the snmp-module).
... the only issue I have with my json-method:
The allnet-probe has multiple sensors connected.
My data-input-method pulls the json-data which contains the data from all sensors and all sensordata are represented in the output-fields of the data-input-method.
But every graph I've generated, triggers the data-input-method separately ... not a big deal, but kind of a unwanted redundancy.
Maybe I took the wrong turn somewhere, when I generated my datasource- or graph-templates ?!
Is there a way to update all datasources and then use these updated datasources for different graphs without triggering the data-input-method ?

[netniV]

I would implement a local cache and refresh it once per polling cycle. That why you don't have to keep querying the device for the same data back.

[floaty]

Yepp ... that seems the only way ... I did that with another set of graphs where data is grabbed on a remote machine.
Is there a function inside cacti to realize that ? ... or do I have to use an external thing, like a daemonized shell-script to realize such a cache ?

[netniV]

You could use Cacti's script server scripts to do it, you just need to check the time of the cache at the moment its run to determine if its out of sync.

[floaty]

just for the record ... received the snmp-module from allnet ... which makes it possible to use cacti's snmp-oid-template and makes local caching expendable and graphing of sensor-data real easy.
guess the json-implementation on these devices is just a bit plain, on other devices it's possible to pull data with a defined json-filter (sharpened my new skills )
so snmp seems the way to go here.

example for power-grid freqency:

Code: Select all

spooky@bazooky:~# snmpbulkget -v2c -cpublic 192.168.67.100 1.3.6.1.4.1.19935.18 
iso.3.6.1.4.1.19935.18.1.0 = INTEGER: 1
iso.3.6.1.4.1.19935.18.2.1.2.1.65 = STRING: "/usr/sbin/allnet/sensor_read_float"
iso.3.6.1.4.1.19935.18.2.1.3.1.65 = STRING: "18"
iso.3.6.1.4.1.19935.18.2.1.4.1.65 = ""
iso.3.6.1.4.1.19935.18.2.1.5.1.65 = INTEGER: 5
iso.3.6.1.4.1.19935.18.2.1.6.1.65 = INTEGER: 1
iso.3.6.1.4.1.19935.18.2.1.7.1.65 = INTEGER: 1
iso.3.6.1.4.1.19935.18.2.1.20.1.65 = INTEGER: 4
iso.3.6.1.4.1.19935.18.2.1.21.1.65 = INTEGER: 1
iso.3.6.1.4.1.19935.18.3.1.1.1.65 = STRING: "49.4010"
spooky@bazooky:~# 

... reattached the json example at my original post ... must have been something wrong with it.
guess for the allnet-snmp-module itself it is the wrong place to publish ...
-
-

snmp-module.png (32 KiB) Viewed 2984 times

[floaty]

... in fact ... snmp is so easy that I forgot to pimp my graph-templates
.
.

cap-view-php-2019-08-22-18_04_17.png (130.2 KiB) Viewed 2980 times

[netniV]

Nice one!, You should attach your template here for others to pick up on.

[floaty]

All made with the standard-snmp-oid graph-template.
The OID can differ from device to device. It's possible to attach different sensors and there is also a bus-extender availaible.
Seem's the OID of a single sensor corresponds with the bus-id of the sensor ... so the standard-snmp-template is the best choice here.

[floaty]

so far no complaints ... neither with the json grabber nor the snmp-module ...
... but winter is coming
.

all-right.png (506.08 KiB) Viewed 2828 times

[Osiris]

I like that stretch approach it would be interesting to see that as a native feature. Not to stretch the height, just the width.