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.

The Old Backnet


Spurred on by the Twitter discussion regarding the old Backnet network and Electron Club founding, I went for a rummage through some backups.

Fond memories of the Backnet Assigned Names And Number Authority, BANANA. Whilst I still use, I’ve expanded somewhat from the /27 to /24. My home network won’t fit on a /27 these days! Gordon is on, my parents on The legacy lives on a little, and still technically within the allocated BANANA range 🙂 to the rescue!

Like I say, these are from backups. The file this came from was last modified in 2004!

Current Address Allocations

The majority of these addresses also route to the Backnet network

GlasgowNet currently runs on the IP range, and we have as well for overflow usage.

We also use AS numbers 65088 – 65103 from the private AS numbers range defined by IANA

You can see the current routing table on one of the routers at the looking glass – AS65089 – Kyle Gordon – AS65096 – Justin Hayes – AS65090 – Neil McKillop – ICM – AS65092 – Colin Petrie – Kenny Duffus – Andrew Elwell – AS65094 – William Anderson – AS65091 – Gordon Pearce – AS65093 – Stinkpad – AS65095 – Matthew Keay

AWS IOT with Mosquitto


Amazon AWS recently released the IOT service, a utility for lightweight devices to create and consume messages on the internet, and also in the case of AWS to leverage the rest of their feature set, such as Kinesis, Lambda, S3, DynamoDB, etc.

Of course, I didn’t fancy using the AWS SDK to do this. I just wanted to get mosquitto_pub and mosquitto_sub working on the command line, so see how easy it would be to get plain old MQTT working with it. It’s not that difficult.

First off, create a working directory, and download the root CA file for your client to use

cd ~
mkdir aws_iot
wget -O rootCA.pem

Now that you have the root certificate, head to the AWS IOT console, sign up or sign in, and click on the “Create a Resource”, and then the “Create a thing” button. Give it a name, and optional attributes, and hit “Create”. Once the page loads, you can now select your new “Thing” and aim for the “Connect a Device” button. You can then choose which SDK to use. That’s up to you, but after you select it and hit the “Generate Certificate and Policy” button you will be invited to download three files – public and private keys, and a cert. Do so, save them in your working directory, and also somewhere safe if you plan on deleting the directory later. You can’t download them again.

Now you have to ascertain what your broker endpoint is. The AWS IOT UI isn’t the clearest on this, but it’s helpfully hidden inside the parameter “REST API Endpoint”. You’ll need to select a thing from the console, and it appears at the top right. It’s just the domain part of the REST endpoint, so “” becomes

Once you have that information, and have the certificate files in place, it’s a simple case of passing some SSL options to the mosquitto client tools.

mosquitto_pub –cafile rootCA.pem –cert dec39df945-certificate.pem.crt –key dec39df945-private.pem.key -h -p 8883 -q 1 -d -t ‘$aws/things/KyleG_Desktop/shadow/update’ -m ‘testing’

ESP8266 Links


What with the recent buzz around the latest ESP8266 chips, I thought I should compile a list of handy links here…

The manufacturer of ESP8266 –
Manufacturer discussion forum –

Community forum –
Lua based firmware –
Discussion regarding MQTT on the ESP8266 –!topic/mqtt/Uy985KUpG64
ESP8266 Github wiki –
Working GCC Toolchain –
Open source SDK –
Native DHT22 and LED I/O using Lua –

Buy one (UK) –

Updating Optiboot & CC3000 Firmware with an Arduino


Optiboot flashing in progress

I recently purchased a CC3000 wireless board to play with on Arduinos, with an aim to use it on an Arduino Mini Pro to control some LED lighting I have. Rather than purchasing through Adafruit as I possibly should have done, it was ordered through Ebay. This turned it into a bit of a learning experience!

The Adafruit library does a firmware check to ensure it’s the most recent version that they ship, however the version I purchased from Ebay was of a lower version, and subsequently the Adafruit library would refuse to run tests. Although this could be tweaked in the code, I didn’t fancy making that change and would rather have hardware with at least a firmware version equal to or higher than the one that Adafruit use. Onwards to updating the firmware of the CC3000!

If you were following Texas Instruments guide you’d be using one of their products to do the update. With only Arduinos to hand, I ended up trying out CC3000Patch sketch from Chris Magagna.

Firstly, two things should be noted about CC3000Patch

  1. It requires almost all of your flash space
  2. It needs newlines on the serial input

The flash space isn’t really an issue until you consider that both older versions of the Arduino bootloader and older versions of Optiboot will take up too much space. I was unable to flash CC3000Patch onto an Atmega328 with Optiboot from around January 2012, so I subsequently had to look at updating Optiboot before going any further.

I was using two Mini Pros to do the programming, and although the guides don’t really cover programming these the process is broadly similar. Hook up MOSI, MISO, SCK, IRQ, Reset, Power and some status LEDs, and then flash ArduinoISP to the host Arduino *before* connecting the target Arduino. I’d also highly recommend hooking up heartbeat, error and programming status LEDs to pins 7, 8 and 9 so that you can see what’s going on. Once you’re happy with that it’s flashed ArduinoISP correctly, and the heartbeat LED is pulsing quietly, *disconnect* the DTR line between your serial adaptor and the programming Arduino. This will prevent it from autoresetting just before the upload is triggered.

Next stage, plug in the target Arduino, and run “Burn Bootloader” from the Arduino IDE (I used 1.0.5). The *target* Arduino will reset, and programming LED on the programming Arduino will light up for a minute or so. Once it goes out, all should be good.

CC3000 being flashed

Optiboot on the Mini Pro, and time to try CC3000Patch again.

First off, make sure you wire up the connections correctly. It’s wise to use the Adafruit buildtest sketch at this point to make sure you have communication with the CC3000. If the firmware version is correct, it will tell you that… if it’s incorrect, it will also tell you that 🙂 The good thing is that you have communication with the CC3000 at this point, and you can move on to updating the firmware.

The documentation for CC3000Patch is fairly good, and all you need to do is compile and upload the sketch to the Arduino, and then follow the documentation. However, if like me you use screen to communicate over serial, you’ll need to use control characters to send newlines to the Arduino before it will start listening to your commands. ^V^J (that’s Control+v, Control+j) are your friends, and you’ll be driving the text menus in no time. I believe the Arduino IDE has a similar setting somewhere in the serial monitor window, although I’ve never used that feature.

All being well the CC3000 will be quietly upgraded to v1.24 (or later), and buildtest from Adafruit_CC3000_Library will then tell you what version of firmware you have. Handy hint also… the SSID is case sensitive 🙂

Go to Top