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

Heating control


Recently I mentioned monitoring the house with wireless sensors dotted around the place. It uses node-red to average the temperatures, and come up with a synthetic value that gets reported back to the home control system, Domoticz.

Next stage is to control the heating.

The heating system in my house is a very old design, and there’s simply a plug for the heating pump, and a plug for the boiler. When the heating is commanded to turn on by the control device (so old it’s not even a thermostat) downstairs, it really just connects these two plugs to a mains supply. The boiler and pump then turns on, and warmth ensues.

My chosen method of automation is simply to keep the heating ‘on’ all the time, and have some sort of device plugged in to the plugs in order to turn them on and off remotely. I want this to be completely retrofittable, so we can remove or change it at a later date without massive amounts of rewiring.

My initial thought was just to use a couple of LightwaveRF appliance modules, but I had a USB controlled dual relay floating around that I long planned to control the TV with, but never quite managed to get around to. Additionally, and conveniently, up the loft there’s a laptop that I use for transcoding the satellite feed to IPTV (with TVHeadend), so it was a simple case of hooking the USB board up to that laptop and getting some software on to it.

Also, to make it a bit safer, and along with the retrofitting feature, I opted to put the relay board into a little dual gang enclosure, and wire in some 13A sockets that I had in the garage.

The end result is a little deamon called mqtt-usb-relay that sits and listens for MQTT messages and then act upon them to turn the USB connected relays on and off. It subscribes to the /raw/`hostname -f`/usb-relay/#, topic, and simply takes the last component of the topic as the relay number to control, and the message as the state to turn the relay to.

Now, doing this ‘correctly’ would involve parsing the JSON output of the 3rd party mqtt.js script for Domoticz, but I decided to keep things simple and to use the On and Off Actions built into Domoticz to trigger simple mosquitto_pub events.

To do this, just create the dummy switch in Domoticz, and in the On/Off Action field, stick in commands similar to this.

script://///usr/bin/mosquitto_pub -h -t /raw/ -m 1

Job done. The heating can now be controlled from Domoticz. It’s not extensive control over zones or power levels of the boiler (although I have an idea for that), but it can certainly command the ‘MORE HEAT’ desire, and maybe one day I’ll install wireless TRVs on the radiators.

Household temperature monitoring


I’ve had it in my mind to control the heating of the house via the computer for a while now, but my first requirement was always to monitor the environment, so the computer can at least make an informed decision about whether the heating is *actually* required.

A while ago I purchased an RFXCom transceiver for my home automation needs, and it’s been one of the best decisions I’ve made with regards to home automation. Not only can it transmit and receive LightwaveRF signals, it can also do Byron, Nexa, X10, Oregon Scientific, and a whole tonne more.

I subsequently discovered these dirt cheap Imagintronix humidity and temperature transmitter devices, which you can buy for £7 each. The temperature sensor needs to be calibrated against a known source, and you then apply the difference to the device as it is picked up in Domoticz. It’s all rather simple, and you immediately have a source of temperature data that can be used. I took a variety of these sensors, and put one in each room, and rather quickly gained an overview of the house from within Domoticz.

Room temperatures

Next up was the desire to average out these temperatures per zone. We have a very simple heating system with only one zone, so it was a simple case of averaging all the temperatures to get one value that we can notionally call the ‘Average house temperature’

The issue here is that Domoticz can’t do that sort of simple calculation. It has a Blockly engine built in to it, but I didn’t see any way of making do simple calculations. However, there was a way around that…

I already use the mqtt.js script from to publish MQTT messages from Domoticz, and Node-Red to do some other MQTT management things, so it was just a case of getting Node-Red to do the work instead, and then to JSONify it and push it back into Domoticz.

[{"id":"b75445a3.48abb8","type":"function","name":"JSONify","func":"msg.payload = '{\"idx\":46,\"svalue\":\"' + msg.payload + ';0;0\"}';\nreturn msg;","outputs":1,"x":495,"y":463,"z":"d5caab33.2a3558","wires":[["a4bce105.5b432"]]}]

Sorted, there’s now a dummy temperature sensor in Domoticz with IDX 46, and Node-Red emits a MQTT message with the appropriate JSON content for Domoticz to pick up and use with the temperature sensor.

Average temperature

Next step is to actually use that data…

Go to Top