I had some more fun with Lua on the ESP8266 wifi modules. These things are so cheap and so versatile that I have already reserved a dedicated subnet for sensor nodes in the house.
The latest ESP8266 projects are a temperature logger for the water temperature of the central heating and a meter reader for water consumption.
The NodeMCU Lua firmware has native support for onewire, making it trivial to add some DS18B20 temperature sensors. A bit of Lua glues these to a TCP socket and outputs the sensor values when a TCP connection is made. This way it is very easy to grab the sensor values from MRTG.
MRTG Then generates pretty graphs like the one below. In this graph the red line shows the hot water from the central heating boiler, the blue area is the return water temperature.
The code behind this is too dirty to publish, some cleaning up needs to be done first. The water usage logger is a better example.
The water usage logger uses a reflective infrared sensor mounted on the water meter. The water meter has a disc with a reflective part that the sensor can detect, giving an impulse per liter of water used.
The impulse output of the sensor is connected to a GPIO on the ESP8266, the ESP8266 increments a global counter on every impulse received. It also listens for TCP connections, when a connection is received it emits the measured values in the format that MRTG expects for external scripts. Thus making it easy to gather the values from MRTG using nothing more than netcat.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
On a TCP connect the ESP8266 emits something similar to this:
402 0 1915768749 ticks node-12341234
This is exactly the format that MRTG uses, making MRTG side of things very simple:
1 2 3 4 5 6 7 8 9 10 11 12
The gas and electricity meters still pose a bit of a problem, the infrared sensors have a had time picking up a signal from those. For electricity
I’ll probably add one or two kWh meters with an S0 output behind the meter provided by the utility company. This is easier and probably more reliable than trying to read the meter optically.
Graphing many more values using MRTG will probably also demand too much from the Raspberry Pi that now does all the graphing. A cusom solution using RRDTool will probably be a better solution.