I recently upgraded our house alarm system to the latest model from Verisure.
Pretty nice actually, the new system comes with a good mobile app, remote querying of both alarm status and status of the various sensors (smoke, movement etc) that are included in the system. Oh, the new system actually cost less per month too, compared to the old one. Go figure.
Being the geek that I am, I immediately wondered if it was possible to get hold of the sensor readings (temperature and humidity) that were shown in the mobile app.
Turns out it is pretty simple. There is a REST API which can be queried, and from there you get back all kinds of status for the system. With that data nicely structured in a JSON it’s then a breeze to send the data to a MQTT pub-sub broker for later use by whatever system that might need it. Easy in theory.
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.
For some time I have been thinking about how to improve the Sense development process as a whole. There is a lot of gathered experience and best practices from the wider software development community, but how can we apply this to Qlik Sense development?
I think more can be done though.
Looking at the concepts promoted in DevOps, it struck me that Sense development follows about the same phases as those in DevOps. Combining Sense and DevOps of course gives us….
The more I looked at it, the more I felt “wow – SenseOps really rocks!”
Continuing from the previous post about publishing data from Telldus Live to MQTT, here is small piece of related Node-RED code. It outputs a list of all (wirelessly controlled) 220V/mains switches I have linked to Telldus Live, using a Tellstick Net.
The background of the code was simply that I wanted a convenient way of getting a complete list of all devices (switches, dimmers, door bells, …) known to my Telldus Live account. When testing different devices, moving them around, renaming them etc, it is very easy to loose track of which device does what, and what their respective IDs are. This little function solves that quite nicely.
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.