This Web page, all data collection and graphs are controlled by a Linux/GNU server (Ubuntu Server headless, latest LTS release). All of this project started with the main pool temperature graph, so I could monitor the pool temperature during boring meetings at work, and skip out early if the pool temperature was looking good.
Not an HTML expert so this page is not my best work, particularity when compared to the page I wrote to get you here.
The temperatures all run on a Dallas-Maxim 1-wire system (actually data+GND, practically data+GND+VCC). Each temperature sensor consists of a DS18S20-PAR sensor or equivalent. Cabling is all standard 4 conductor phone cable terminated with standard RJ-11 phone jacks. Sensors are connected in parallel and tied into a 6 port commercial 1-Wire hub based on the DS2409 which is then connected to the server via a commercial USB interface DS9490. Server temperatures are collected directly from the sensor module by scripts running on the home server.
Every 5 mins the server runs a custom Perl script (via a CRON job) that reads each temperature sensor (and the server temperatures) and stores the values in a RRDTool database. A Perl module is used to interface with DS2409 utilizing software from the OWServer project (direct read). Will likely move away from Perl and the OW server in 2020 because OWServer it is no longer developed or well supported. With the 1-Wire protocol patents expiring several years ago, the protocol is now built into the Linux kernel and is accessible in a device file tree (see GasPi below).
At 1 min past each hour, and half hour, another Perl script is run that generates the graphs from the RRD database using RRDGraph, and loads the graphs to the web server.
Each sensor is soldered to 3 of the 4 phone cable connectors, and the end of the cable terminated in RJ-11 connector. After checking to ensure a good soldering joint, I apply several coats of shellac to the bare connectors. Once dry I coat the cable sheaving, conductors and sensors in aquarium grade silicone and seal with heat shrinking. Only about 1/4 of the sensor is actually sealed in silicone, the remainder is left exposed to ensure good contact with the ambient surroundings.
The pool sensor is actually immersed in the pool water/ice. The same process is used, except that after shellacking, the entire assembly is placed in a plastic tube (a tube that is used on the stems of roses) and filled with silicone. his seems to be holding up well in the pool water so far. Not surprisingly, the sensor when sealed up like this, has about a 5 minute time delay response to temperature changes as opposed to a exposed sensor. Not much of an issue for pool water which tends to have a long response time to temperature changes anyways.
A commercial 1-Wire based AAG Humidity Sensor TAI8540 (obsolete) is used, which is based on a DS2438 (DAC) and a HIH-3610-A sensor (humidity).
A commercial 1-Wire Pressure sensor, the AAG TAI8570 (obsolete) is used which is also based on a DS2438 and a linear voltage based pressure sensor.
These are connected and communicated with, by the server in the same way as the 1-Wire temperatures.
A TED5000 (obsolete) is used to monitor household power and voltage. It utilizes a CT on each of the live phases between the electrical meter and the main panel breakers. The data is processed within the TED5000 device every 1 secs, hosting its own web page as the device is also connected to the LAN.
Every 5mins a collectd daemon running on the home server pulls and parses the TED5000 XML file to obtain the power and the voltage values. Those values are placed in a separate collectd RRD database, and the graph prepared from that RRD databse using the same Perl script as the temperatures.
Accuracy is stated at +/- 1 W of power, and "2%", but it is not clear if the 2% is related to voltage accuracy or what. Accurate readings of the voltage with a decent commercial volt meter would indicate that the TED5000 reads almost consistently 0.5 volt high. The voltage graph is not corrected for this. Power seems very accurate compared to the readings from a commercial "Kill a Watt" device.
Overtime you can actually look at the power graph and based on the power signatures identify which loads were running at a certain time. More recently (Dec 2019) the 8kW spikes that may be seen at 19:30 weekdays, or any time on Saturday/Sunday is the 240v 33amp EV charger kicking in.
Pulled by collectd every 5mins using it's built in modules for this data. Graphs from the collectd RRDTool Database are generated within the same home server Perl graph script described above.
Deployed Feb, 2020
A custom designed, 3D printed "tipple bucket" based rain gauge was deployed in the fall of 2019. The "tipple" uses a small magnet which swings past a custom designed Hall Sensor circuit that generates a pulse that is recorded by a modified commercial 1-Wire based AAG DS2438 counter sensor (obsolete). The sensors and small circuit are isolated from the weather, as the Hall sensor reads through a plastic case which contains all the electronics inside the rain gauge. The tipple was calibrated manually and is accurate to 0.53mm of rainfall. A MKII version is on the books for this Spring 2020 to clean up the support structure, and to rebuild one of the 3D models from scratch since I had to butcher it up pretty bad based on a deign on Thingiverse.
Phase I (with MKI hardware) was deployed in late Fall 2019. Basically a Raspberry Pi IV, with a PIcam, a POE hat, a custom breadboard hat that contains the sensors: inside box temp, outside box temp, outside humidity (DHT22) and LED controls, all contained in a custom 3D printed box installed under my side deck. Phase I has the RPi reading the sensor values every 5mins, loading them into a local RRDTool database, and locally generating graphs which are then moved to common folder on the server. The sensor data collection, RRDTool databse loading and RRDGraph creation are written in Python with the intention of moving away from Perl for all server scripts in 2020. Data collection utilizes the now built in 1-Wire device tree in the Linux kernel with is directly accessed by the current new Python program. On the server side the same Perl graph script as previously described also moves these remote generated RPi graphs to the Web server.
This all just secondarily however to the main function with is to take a picture of my gas meter display every 15 mins and load that picture to the server for OCR (optical character recognition) processing, preparing for Phase II. Phase II is to write a Python program to read the gas meter value based on the meter display. As of Feb. 2020 the program works about 70% of the time correctly reading the meter and generating a value which will eventually find its way into a RRDTool database and be plotted. Current issues to be resolved: Learn Python!, early morning sun glare on the meter confuses the OCR algorithms, the machine learning algorithm still needs to be tuned or changed because it has issues distinguish between "6" and "8", blowing snow/rain sometimes obscures the meter face messing up the OCR algorithms. MKII hardware is on the books for this summer to move the DHT22 sensor away from the RPi enclosure because I think the outside temperature is reading high, picking up some heat from the RPi box, add a pressure sensor to the sensor mix (for Outside Pressure), and to design a better box lid as the current lid is affixed with electrical tape in my haste to deploy before winter.