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 https://github.com/kylegordon/mqtt_esp8266_ds1820_arduino 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”:”homeauto.vpn.glasgownet.com”,”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.

Setting up the Squeezebox Receiver

I’ve got a variety of Squeezebox Receivers dotted about the house, playing synchronized music and audio on demand. Due to the lack of a remote control requirement (using the Android controller), I opted to get the receivers on their own. However, the setup procedure is highly dependent on the remote control.

To work around this, grab a copy of net-udap from https://projects.robinbowes.com/Net-UDAP/trac. Switch user to root, and then fire up ./scripts/udap_shell.pl. Switch the receivers into init mode by holding down the front panel button until it blinks red slowly. If you end up with it flashing red quickly, you’ve just reset it to factory defaults. No great loss, as the procedure is mostly the same.

Once in the UDAP shell, run ‘discover’ to scan the network for devices. After a while it will come back to the prompt, and ‘list’ will show you the discovered devices. Pick one to configure with ‘configure X’ where X is the item number.

I found that the factory installed firmware was pretty poor at doing DHCP. This may due to my lack of expertise with this equipment, or actual bugs in the software. Whatever it may be, I found the best option was to give it some static network address settings first, let it update, and then switch to DHCP.

Due to the high demands I place on my home network, I have GigE ethernet to every device. Wireless is solely for laptops and mobile phones. Consequently, the settings below are for a wired connection.

Remember… run this AS ROOT!!

set lan_ip_mode=0
set interface=1
set lan_gateway=
set lan_network_address=
set lan_subnet_mask=
set squeezecenter_address=


After you hit save_data, it will send the settings to the device, and the device will hopefully respond to confirm it. You should see “Raw msg:” followed by a hexadecimal dump. If that doesn’t appear, try save_data again after a short delay.

The flashing LED sequence will hint that it’s not configured, but it is. If it detects a firmware update is required, it will start pulling it down and installing it. It will indicate that this is happening by rapidly flashing the front panel LED a bright white colour until the process is complete. Once it’s in a safe state, and if it’s still not indicating its presence on the network correctly, pull the power connector out and reinsert and then visit the Logitech Media Server web interface. The device should then be listed in the player drop down.

Now that the device is on the network and working, it’s time to switch it over to DHCP mode. Yet again, hold down the front panel button until it slowly flashes red. Jump into the UDAP shell again, run a discover on the network, and then configure the device that it finds.

set interface=1
set lan_ip_mode=1


This probably also won’t give any visual indication on the front panel. Tail the DHCP server logs to make sure it gets an IP allocated. If it does, check the Media Server web interface again.

All being well, it should then be up and running using DHCP. Happy listening!

STS 130 Landing

Fantastic footage of the last ever night time landing of a Space Shuttle. STS-130 safely makes it to the ground, and the night time situation allows for great footage of the jets of flame coming out the APU exhausts at the tail root. The flames happen all the time, but are usually invisible during the day. Similar footage of STS-9 can be found over here.

Sure/Smartie LCDProc

Recently I’ve been looking at getting a computing device into the Land Rover. Short of buying a full sized 7″ touch screen, I opted to go for a slightly cheaper £20 4×20 LCD display. This was more to be proof of concept, and give me a starter to work on, before I decide whether or not to put a full sized screen in.

Ultimately, I purchased a SmartieLCD module from Ebay. It arrived, I plugged it into my laptop running Windows at work, and it worked first time. Now it was time to get it working with LCDProc!

Earlier on I had spotted that SmartieLCD in Windows used the Matrix Orbital DLL file. Sadly, when using LCDProc in Linux, Matrix didn’t work at all. It was time to go looking

Enthused by http://lists.omnipotent.net/pipermail/lcdproc/2009-July/013021.html, and manufacturers documentation, I decided to check out the CVS copy of LCDProc. The last ‘release’ was back in 2007, so if I was to get anything recent it would have to be from CVS

cvs -d:pserver:anonymous@lcdproc.cvs.sourceforge.net:/cvsroot/lcdproc login
cvs -z3 -d:pserver:anonymous@lcdproc.cvs.sourceforge.net:/cvsroot/lcdproc co -P lcdproc

Having a look around the source files indicate that Sure Electronics displays were supported, but not enabled by default. A simple ./configure flag would enable them, so it was time to get compiling. Firstly some support files have to be installed first.

sudo apt-get install libusb-dev autogen automake

After that, kick off the build process, and enable Sure Electronics support at configure time.

sh ./autogen.sh
./configure –enable-drivers=SureElec
sudo make install

Now that the software is installed, LCDd needs configured in order to send data to the LCD display.

sudo vim /usr/local/etc/LCDd.conf

In here, a few parts need changed –


And that’s it! Execute /usr/local/sbin/LCDd, and you should get a Clients: 0 and Screens: 0 on the LCD display.

All is good!

PS3 and Matroska? Could be soon…

Word is that the Matroska container format will be officially supported by DivX 7. Surely a good thing, as Sony have a deal with Divx to provide decoding software for the PS3. Maybe this will spell the end of having to transcode those ubiquitous MKV files for use on a PS3. With a due date of around January 2009, how long before the PS3 officially supports the MKV format? After that… roll on 1440p support 🙂 Continue reading “PS3 and Matroska? Could be soon…”