hi Chris
To pick up again on this topic, here is an example of what I was alluding to.
Attached is an extemely contrived demo of passing "show ap debug client-table" from AirRecorder to a python app using ZeroMQ (aka ZMQ).
The demo serves only to show the messge passing using the ZMQ "push/pull" pattern (see https://learning-0mq-with-pyzmq.readthedocs.org/en/latest/pyzmq/patterns/pushpull.html) - what you then do with the message could be any number of things.
For example: save it to a SQL database, pass to some other tool (splunk, RRDtool, elasticsearch/kibana, kairos/grafana etc.), merge multiple CLI commands together (i.e. convert bssids to AP names), calculate deltas/rates and generate an alert/syslog message if out of bounds, make a graph for a webpage, pass to a GUI etc.
There are two parts, firstly an AirRecorder instance (and something for it to talk to, i.e. a controller) and secondly the python app which accepts messages from AirRecorder using ZMQ. Note that it may be necessary to install "pyzmq" - the app will throw a warning if this is the case.
The attached zip file contains the following files
ar_zmq_demo/
assoc.cmd - airrecorder command file
1.2.3.4.txt - sample credentials file (which needs to be renamed and edited)
zmq_pull.py - python (2.7) demo of handling CLI commands over ZMQ
usage.txt - usage steps for the demo
I have also included the latest AR .jar file, with the following MD5 sum of the JAR in the zip file
545b9e53f3d890d8dd36c41521cf3388 AirRecorder-1.3.11-release.jar
*note* this demo app will run "show ap debug client-table ap-name <>" against every AP on the controller every 10 seconds. This is not really something that should be done on a production controller without being aware of the risks/impact etc.
regards
-jeff