1-wire, Node-Red, Domoticz & Grafana


Recently I posted a shiny graph of my garage temperature after I’d put a car with a hot engine in there. The spikes were fairly pronounced, and it was possibly to see where I’d left the door open whilst I worked on the car, before going for a test drive in the evening.

I was subsequently asked…

tl;dr 1-Wire -> ESP8266 -> MQTT -> Node-Red -> MQTT -> Domoticz -> MQTT -> Node-Red -> InfluxDB -> Grafana

It starts out simply enough, with a string of DS18B20 1-wire sensors hooked up to a WeMos D1 Mini NodeMCU board. On that board, there’s a copy of flashed onto, and it scans the bus periodically, reads the values, and publishes them to an MQTT broker. Each ROM ID (1-wire device) gets its own topic, and a plain number is published to the relevant topic.

My home automation controller of choice is Domoticz , and it likes a particular flavour of JSON being published on the /domoticz/in topic. This is where Node-Red steps in to do a translation.

[{“id”:”aa0d4469.8e7458″,”type”:”mqtt in”,”z”:”d5caab33.2a3558″,”name”:”esp8266 on temp/#”,”topic”:”temp/#”,”qos”:”2″,”broker”:”66a92c76.9956d4″,”x”:117,”y”:349,”wires”:[[“5f4ec201.7bbdac”]]},{“id”:”5f4ec201.7bbdac”,”type”:”function”,”z”:”d5caab33.2a3558″,”name”:”Device to IDX”,”func”:”temp = msg.payload/16;\nrom_id = msg.topic.split(\”/\”)[1];\n\nmsg.payload = {};\nswitch (rom_id) {\n case \”28b8c81d300e5\”:\n msg.payload.idx = 186;\n break;\n case \”28ac871d300e4\”:\n msg.payload.idx = 187;\n break;\n}\nmsg.payload.rom_id = rom_id;\ntemp = temp.toString();\nmsg.payload.svalue = temp;\n\n\nreturn msg;”,”outputs”:1,”noerr”:0,”x”:347,”y”:348,”wires”:[[“71da0e3.d7e8ff”]]},{“id”:”71da0e3.d7e8ff”,”type”:”mqtt out”,”z”:”d5caab33.2a3558″,”name”:””,”topic”:”domoticz/in”,”qos”:””,”retain”:””,”broker”:”66a92c76.9956d4″,”x”:535,”y”:349,”wires”:[]},{“id”:”66a92c76.9956d4″,”type”:”mqtt-broker”,”z”:””,”broker”:””,”port”:”1883″,”clientid”:””,”usetls”:false,”compatmode”:true,”keepalive”:”15″,”cleansession”:true,”willTopic”:””,”willQos”:”0″,”willPayload”:””,”birthTopic”:””,”birthQos”:”0″,”birthPayload”:””}]

In short, this flow subscribes to all messages on temp/#, takes the payload and topic, and formulates a JSON message with the correct IDX. The IDX is the unique ID for a virtual device (in this case, a temperature sensor) in Domoticz. The JSON message is then published on /domoticz/in, where it is consumed by Domoticz and used for its own home automation purposes.

Now, every value of every device in Domoticz is also published on /domoticz/out. I use this for a few MQTT to Python services I run, but I also have another Node-Red flow that takes the Domoticz JSON messages and inserts them into InfluxDB. This flow was taken from here and relies on the node-red-contrib-influxdb node.

The rest is plain sailing really – there’s a Grafana install that is configured to use InfluxDB as a datasource. Grafana can extract the data using the IDX that’s mentioned above, and will display it in a nice fashion.

SELECT mean(“svalue1”) FROM “domoticz” WHERE “idx” = ‘171’ AND $timeFilter GROUP BY time($interval) fill(null)

Job done.

MQTT to Zabbix Gateway


For a while now I’ve been wanting to try and monitor home automation parameters by using Zabbix. I already use it to monitor, graph and alert on servers and services at work and at home, so it was a logical extension to use it for home automation. I hope to deploy TinyTX sensors around the house, and by using my mqtt-rfm12b gateway I *should* be able monitor and alert on their battery voltages when things start to run a bit low. Firstly though, something is required to push the data from MQTT to Zabbix.

The first thing that you’ll need is a working Zabbix instance. This is somewhat outside the scope of this blog post, and the documentation is fairly good. You’ll need a host configured, so add one and give it a name, or alternatively use localhost that I think Zabbix comes preconfigured with.

Clone my mqtt-zabbix repository, and you’ll find a XML Zabbix template that can be imported into your Zabbix install (import via Configuration -> Templates). It won’t do anything drastic other than 10 or so Zabbix keys.

Once the import is completed, Configuration -> Templates will contain a template called “Template App MQTT”. This has the 10 items, all of which can be edited to suit. The important part is the “Key” – which must match what you put in the keys.csv later on. Simply put, when Zabbix receives data with a specific key, it gets stored against the item with that key defined. It’s not terribly complicated 🙂

If you’re happy with Zabbix and the template import, follow the mqtt-zabbix README to get the rest of it installed. It’s really just a glorified script with some init scripts. Put all the files in the right places, edit keys.csv to match between your MQTT topic and your Zabbix key name, and start the application.

mqtt-zabbix subscribes to the root wildcard topic at /# so possibly isn’t very efficient on systems with massive amounts of traffic, but for home use it’s quite sufficient. I may change this method of working at a later date. In the meantime, the moment something arrives at your topic it will be forwarded on to Zabbix. A log of the event will also be found at  /var/log/mqtt-zabbix.log and it will tell you if the key was successfully inserted or not.

To view your data in Zabbix, click on the host, click on Latest Data, and it should be listed under – Other -. You can then choose the graph option on the right, or you can edit your own custom graphs and include the MQTT items.

Automated Kitchen Lighting


Recently I decided to make some changes to the kitchen. It started off with a strip of warm white LEDs, and I thought “Wouldn’t it be cool if…”. I’ve now lost count of the number of guests asking how it works 🙂

There’s a variety of components at play here. Firstly, there’s a Raspberry Pi, followed up by a simple IRF530 MOSFET, a PNP transistor to pull it low, a PIR sensor, and a strip of LEDs.

[flickr id=”8433770006″ thumbnail=”small” overlay=”true” size=”large” group=”” align=”right”]


It’s a a PIR sensor from Seeedstudio that I bought on a whim a while back. It handily runs off of 5v, and returns a 3.3v TTL compatible signal upon detection of movement.

On the Raspberry Pi, I have my own Python app, mqtt-gpio-trigger, running. It continuously monitors pins that are defined in the config file, and in the event of a change of state of any of them it will publish a message to a predefined topic, with the pin number as the final component of the topic, and the message contains the state of the PIN. Simply subscribe to that topic to watch whatever pin on the Raspberry Pi.


A strip of warm white LED lights are attached to pin 18 of the Raspberry Pi, via the IRF530 MOSFET. There’s a bog standard NPN transistor to help saturate the gate of the MOSFET, and it’s pin 18 as that’s the only pin on the Raspberry Pi that does hardware PWM. Using any of the other pins subjects you to vagaries of the CPU.

Controlling pin 18 is mqtt-pwm-lights, another one of my scripts. It simply sits and runs, and subscribes to yet another MQTT topic. When it receives a message with a value between 0 and 512, it fades the lights to that value. Due to the NPN transistor it’s inverted, so 512 is off, and 0 is on. A minor annoyance, but the home automation controller handles that.

In the middle

Producing the show is a small script that isn’t public. All it does is listen for MQTT events and reply with canned MQTT messages in return. It’s a stopgap measure until I find a better home automation controller. The main role of the script at the moment is to listen to events from the PIR, start a timer when triggered, and publish a lighting level request. When the timer expires, the lighting level returns to normal (ie, off)

So that’s it. Ambient automated lighting for the kitchen, and worktop lighting, all rolled into one.

Thinkpad X201S Fan Control


I noticed the other day (it was kind of hard to not notice, to be honest) that my laptop shut down abruptly when it overheated. This shouldn’t be the case, as the thermal controls on the mainboard should have spun up the fans.

After some poking around, I found that with the default ‘auto’ fan control, the top speed of ‘level 7’ only spins the fans around 4000RPM, even though when the feedback loop is disengaged (echo level disengaged > /proc/acpi/ibm/fan” they can spin up to 7000RPM, and bring the temperature down from the critical 100C mark.

This bug report suggests that something is completely amiss with the kernels thinkpad_acpi module, and nobody really knows why. The end result is that fans spin too slow on the Thinkpad range of laptops. This can, however, be resolved with a couple of edits and an additional package. The following instructions were tested on Ubuntu 12.10, most likely work exactly the same on all Debian versions and derivatives, and can be adapted for use on other Linux distros as well.

Firstly, enabled userland control of the Thinkpad fans with the following command –

echo options thinkpad_acpi fan_control=1 >> /etc/modprobe.d/thinkpad.conf
rmmod thinkpad_acpi
modprobe thinkpad_acpi

This will enable the new settings for your current session, and all future sessions too.

You should now be able to set the fan speed manually with commands such as –

echo level 0 > /proc/acpi/ibm/fan
echo level 7 > /proc/acpi/ibm/fan
echo level disengaged > /proc/acpi/ibm/fan
echo level auto > /proc/acpi/ibm/fan

The key bit here is to remember that ‘disengaged’ equates to ‘127’ on the grand scale of speeds.

Next step is to install the thinkfan package, and enable automatic startup –

apt-get -y install thinkfan
sed -i s/START=no/START=yes/ /etc/default/thinkfan

Now, as above, the default fan speeds are too slow. So even if thinkfan commands a level 7 fan speed, it won’t be fast enough to keep your hardware cool. To make it run up to full speed, you have to disengage the feedback loop and let it run in failsafe mode. Don’t worry though, thinkfan will bring it back into ‘auto’ mode once temperatures are back to normal, so you can have normal battery life and normal noise levels once your compute process is complete.

Edit /etc/thinkfan.conf, and at the end adjust the endpoint for level 7, and insert a new line for fan speed 127. My thinkfan.conf is as below –

(0, 0, 55)
(1, 48, 60)
(2, 50, 61)
(3, 52, 63)
(4, 56, 65)
(5, 59, 66)
(7, 63, 66)
(127, 66, 32767)

Save thinkfan.conf, and start thinkfan with this

/etc/init.d/thinkfan start
Once 66C is passed, it will enter disengaged mode, and run at full speed until it reaches 66C or below again.

My aging quad core i7 2.13GHz laptop will happily run BOINC now, at 97C, so I say it’s working 🙂

OWFS Server on The Raspberry Pi


Quick and simple this one is. I have a DS9490R (internally it’s a DS1490F) one-wire bus master attached to my Raspberry Pi. 4 DS18B20 temperature sensors are hanging off the bus, and I’d like to access them from the home automation server.

On the Raspberry Pi, or the server/device that’s hosting the 1-Wire bus:

apt-get install owserver ow-shell
modprobe ds1wm
echo “ds1wm” >> /etc/modules

Edit /etc/owfs.conf such that the following parameters are entered. I’d advise commenting out the rest (at least, the rest of the server: directives)

! server: server = localhost:4304
server: usb = all
server: w1
server: port =

Restart the 1-Wire server

/etc/init.d/owserver restart

All being well, the following command should output a listing of all the devices on the bus.

owdir -s localhost:4304 /

On the remote server, simply use the following command to read the data.

owread -s /28.DDBF1D030000/temperature

Go to Top