Following up on previous posts (here and here) about the Butler family of tools being Dockerized, here is another one on the same topic:
Butler SOS can now be run in a Docker container.
This is good news as it makes it a lot easier to set up real-time monitoring of a Qlik Sense enterprise environment, compared to the previous (still working, btw) method of installing Node.js and then running Butler SOS on top of Node.
Following up on the previous post about pulling sensor data from sensors in a Verisure alarm system, here is a slightly more hardware focused post.
One use case that the new Verisure alarm system does not handle nicely is machine-to-machine notification when the alarm is disarmed (turned off). Such notifications are sent to the mobile app – so the data exists somewhere. The problem is that it’s all undocumented and thus hard to build something on top of.
Let’s hack a solution instead – be aware, some soldering required….
This one is long overdue, but finally here: Butler SOS v2.0
The new version is an almost complete re-write of v1.0. Changes are plentiful and include
All warnings and errors stored by Sense in its log database are now pulled into Butler SOS, from where it can be graphed and acted upon. This is a big deal, as it was previously not possible to get notifications or alerts when errors or warnings started to pile up in the logs.
Operational health metrics are still pulled from Qlik Sense, but this is now done directly from the QIX engine rather than via a hard-to-secure virtual proxy.
Using certificates for authentication with Sense removes potential security issues with v1.0.
Config file is now YAML instead of JSON. More human readable and with inline comments.
Config file now allows for more fine-grained control of Butler SOS.
Several bugs fixed, especially around sending metrics to MQTT.
The readme file on GitHub has all the details, here are some screen shots to get you started though:
I was recently in Helsinki, giving a talk at a QlikDevGroup event. Great event, great crowd. The topic was SenseOps and Butler SOS, and I showcased the lamp above as an example of a funky, but still relevant way to monitor user activity in a Qlik Sense Enterprise environment.
A person in the audience asked how the map works. I claimed it was super simple, costing less than USD 10 to build (assuming you already have a suitable enclosure) and uses just four wires hooked up between some pre-made modules. Time to prove it.
The four wires part might have been a slight exaggeration… but it depends on which wires you count – right?
I got somewhat distracted from the idea of breaking up the existing Butler software into smaller, stand-alone micro services.
Or rather, an idea came to mind. An idea too good not to explore…
The healthcheck API of Qlik Sense provides basic metrics for both the Qlik Sense engine itself, and the server it is running on. Things like CPU load, available RAM, number of connected users and what apps are loaded into the Sense engine.
The idea behind Butler SOS ( SOS = SenseOps Stats) is very simple:
Get the healthcheck metrics for all servers in a Sense cluster. Then send the information to MQTT for immediate, real-time use cases.
It is directly aimed at bringing better features to the monitoring step of SenseOps – please visit SenseOps.rocks for more info on SenseOps.
Butler SOS is nice and sending data via MQTT make the health metrics available in for example Node-RED. Node-RED has some basic graph options, but not anywhere near those offered by Grafana. Grafana is very, very cool… A live demo is available here – do check it out – it is very nice indeed.
Creating real-time dashboards in Grafana is greatly simplified if the data is stored in some kind of time series database. Influxdb is an obvious choice. It is open source, installation is very easy, and there are good Node.js libraries that make it trivial to insert data into a Influxdb database.
Thus – Butler SOS also sends the Sense health metrics to an Influx db of choice.
Only need Influxdb and not MQTT? Or the other way around?
No problem, the Butler SOS config file include options for independently turning on/off sending of data to MQTT and Influxdb.
Just to get your interest – this video shows what Butler-MQTT can be used for. All the pieces are included in the Github repo. The concept of a reload dashboard can be very useful if you have long running (hours!) reloads. Instead of relying on Sense’s own reload log window, you can get an easy to understand visual feedback from a reload dashboard.
The video shows
A reloading Sense app (upper left). The app has two nested loops (date and country), with half a second delay in each.
Within each loop a status message is sent to Butler-MQTT (bottom left), which forwards the message to a MQTT server running on localhost.
A Node-RED dashboard picks up the MQTT messages and render a dashboard showing the progress of the running reload.
The “Sales” line chart deserves some comment too.
In the outer loop in the app’s load script, the script calculates sum(sales) for that particular loop iteration. That value is then sent to a MQTT topic, and then plotted in the dashboard.
This way you can get an immediate, visual feedback on the actual data produced by the reload. Not by any means always needed – but it can also be very, very useful.
The goal of the previously described Slack proxy project was to allow posting of messages from Qlik Sense load scripts to Slack (great instant messaging platform!). The project has however developed into something larger and slightly more ambitious, integrating other connections than Slack. The original project name “Slack proxy” has become less and less relevant, and the project has thus been renamed to “Butler”.
As of right now (May 2016), Butler’s feature set include
Send messages from Sense load script to Slack
Send/publish MQTT messages from Sense load script (i.e. outbound MQTT).
Sense reload failures as emails, and to Slack.
Sense audit events (session start/stop and connection open/close) to Slack and to MQTT messages.
Create new directories on the Sense server’s (where Butler is running) disks.
Get disk space info, for disks on the Sense server where Butler is running.
A real pain point when developing sensor nodes that are scattered around a building (or a country or the world!) is the updating part. How do you get new firmware onto the devices?
The cell phone manufacturers were early to investigate the options, but from my days in that industry I know first-hand how challenging it was to send new firmware to tens or hundreds of thousands of devices. Lot’s have happened since, today a system update for tens of millions of Android or IOS devices is no big deal, you just make sure your phone is plugged into power before starting the upgrade. Leave it overnight, and next morning you have the latest (and hopefully greatest) version installed.
Looking specifically at the ESP8266, it does have drawbacks in terms of power consumption (it’s hard to get the power consumption down for a device that needs 3-4 seconds to wake up from sleep, connecting to a wifi network and send its sensor readings – but improvements are possible). On the other hand, its wifi connectivity means Over The Air (OTA) updating is possible.
Having a bunch of ESP8266’s lying around, I looked into the options for doing OTA on ESP8266.
Telldus has a set of nice little gadgets (“Tellstick”, for short) that both allow you to control remote switches over radio (433.92 MHz), and to read sensors transmitting on that same frequency. Telldus also has a backend service, Telldus Live, which offer Tellstick users scheduling features (turning lamps on/off at certain times, or when certain conditions occur), as well as showing the latest sensor readings.
The above is at least true if you have a Tellstick Net, which connects to your home network and sends device and sensor data to the Telldus Live service. You can also achieve the same thing with the non-connected Tellstick models, and an always-on computer running Telldus’ software.
Anyway – let’s assume that Telldus Live can see your switches, sensors and other connected devices. Would it not be cool if you could bring all that data into Node-RED, and from there create whatever feature you dreamt of.
How about sending an SMS when the garage door is still open, but your presence data indicate that you have left for work? Easy.
Or the opposite: Send a tweet to your Node-RED server, which will then fire off an event to Telldus Live, turning a switch on, and by doing so closing the garage door? No problem.