Server side geofencing with Owntracks, Node-Red and Domoticz


Where to start?

The first challenge was getting data from my phone on public networks to my private MQTT server. At home I run Mosquitto for handling any message brokering, particularly with Domoticz and Node-Red pushing messages around.

I won’t go into the details, but suffice to say I have Mosquitto at home, and Mosquitto on a server I rent in OVH. The one in OVH is TLS, and protected by a username and password. It is this server to which Owntracks is configured to push messages to.

In turn, the two Mosquitto servers are bridged, as per and in order for the topic to which the phone publishes to be available internally at home.

The end result of this is the periodic announcement of my phones location on my internal home network

mqttitude/bagpuss_thecat/galaxys2 {“_type”: “location”, “lat”: “55.9182683”, “lon”: “-4.2232088”, “tst”: “1457045018”, “acc”: “20.0”, “batt”: “48”}

From here, it gets ingested into Node-Red by firstly subscribing to the mqttitude/bagpuss_thecat/galaxys2 topic, then the JSON is parsed out, and then it’s processed by a couple of node-red-node-geofence nodes in order to determine if the phone is in a certain location or not. These simply return the msg.location.isat parameter if the device matches any of the geofences.

Depending on the status of the .isat parameter, I then use the multiple messages feature of node-red to send messages to each of my Domoticz switches to alter their state.

if ( msg.location.isat == "Home") {
var home = { payload:'{"idx":181,"nvalue":1}' };
var work = { payload:'{"idx":180,"nvalue":0}' };
} else if ( msg.location.isat == "Work") {
var home = { payload:'{"idx":181,"nvalue":0}' };
var work = { payload:'{"idx":180,"nvalue":1}' };
} else {
var home = { payload:'{"idx":181,"nvalue":0}' };
var work = { payload:'{"idx":180,"nvalue":0}' };
return [ [ work, home ] ];

As you can see from the above code, the Domoticz IDX of the switch to say that I’m at work is 180, Home is 181, and I can then use those dummy switch states in Domoticz to do additional logic within the home automation system.

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 notes


So I finally got around to using my two ESP8266 modules. This is just some notes that I’ve collected whilst working on them.

If you’re interested in the boot data, it uses a different baud rate from the main interface. It might be briefly caught if the right baud rate is chosen, ie

The esp-open-sdk from is perfectly functional, and all it takes is a ‘make STANDALONE=y’
Once compiled, ensure that esp-open-sdk/bin is in your $PATH, ie /home/bagpuss/src/esp-open-sdk/xtensa-lx106-elf/bin

To flash the ESP8266 from Linux, from works great. Just ensure you have sufficient privileges to write to the serial port.

Whilst nodemcu-firmware could be pulled from it’s just easier to grab the precompiled firmware from

Good pinout diagram here
Keep CH_PD pulled high all the time.
Pull GPIO0 to GND in order to enter flashing mode.
Power it up
./ –port /dev/ttyUSB0 write_flash 0x00000 ../nodemcu_latest.bin
Reboot it when done

When talking to it, at least with the original firmware, you need a serial terminal that does newlines and carriage returns. The Arduino serial monitor works well for this. With nodemcu installed, /usr/bin/screen works just fine.

After a flash of nodemcu, do a file.format() to clear the flash

Use luatool from to upload lua scripts to the device.

If the device isn’t responding, wipe and start again… this set of commands have repeatedly gotten out of a ‘bricked’ device state.

./ –port /dev/ttyUSB0 write_flash 0x00000 ../esp-open-sdk/esp_iot_sdk_v1.0.1/bin/boot_v1.2.bin
./ –port /dev/ttyUSB0 write_flash 0x00000 ../esp-open-sdk/esp_iot_sdk_v1.0.1/bin/at/
./ –port /dev/ttyUSB0 write_flash 0x01000 ../esp-open-sdk/esp_iot_sdk_v1.0.1/bin/at/
./ –port /dev/ttyUSB0 write_flash 0x7e000 ../esp-open-sdk/esp_iot_sdk_v1.0.1/bin/blank.bin
./ –port /dev/ttyUSB0 write_flash 0xfe000 ../esp-open-sdk/esp_iot_sdk_v1.0.1/bin/blank.bin
./ –port /dev/ttyUSB0 write_flash 0x00000 ../nodemcu_latest.bin

Go to Top