We monitor quite a bit of “stuff” in Molly. Maybe too much stuff! Once the monitoring infrastructure was put in place, it was just too easy to add extra sensors and monitor more things.
In the previous post, Part 1, we described our prototype activities and the selection of technologies and software for the job. In this part, we review all the things we monitor, and touch on why and how we use the information. We also explore the data structure used to store the information in the database. In the next post, Part 3, we explore the implementation details further. For the nitty-gritty of each sensor used and details of its specific installation, take a look at the the individual posts for a specific area.
In the Beginning …
It was not long before we were buying all types of sensors and cables, setting them up and logging all of their information to the database. With this information we went on to create pretty Grafana historical graphs and real-time node-red dashboards. It was easy to add sensors, so we did.
It all started with logging the electricity being sent to the batteries from the solar panels. The battery sensor could also measure the electricity being consumed from the batteries. Knowing both the charging and consumption behaviours helped us work out if the batteries were working correctly. Then we wanted to track our location so we configured the GPS sensor in our Cellular modem to be a data source. We soon realized that the Cradlepoint modem was not very reliable, so eventually swapped the modem for a much more reliable dedicated GPS sensor. The Cradlepoint modem did have some other useful functions, including the ability to connect to the OBDII port on the truck. This allowed us to get information from the truck’s computer or ECU. Weather sensors were next, followed by general purpose input and output (GPIOs) for water tank levels and house controls like the water tank heaters and fridge. As other ideas came up, they were added. This all took time, with the new sensors being added when we found the time on a spare weekend.
Initially we would add sensors, get them up and running and acquire all the information possible and display everything. As we used the system, we refined our thinking. We tailored the dashboards and historical queries to our desires, based on what was important to us. Chnaging the displays changed what we put in the database. Bugs in the system were found and fixed. Code was enhanced to make the overall system more reliable. From this process of continuous use and change, the system not only improved, but a philosophy for our monitoring system started to organically emerge.
Monitoring Philosophy
Our monitoring systems can be thought of two systems working together. The first system is everything required to gather and log the information from the sensors, while the second system is everything required for viewing the information. And while monitoring encompasses both logging and viewing, it helps conceptually to make this division or logical separation when building the system. Also the important attributes of each system half are slightly different, so considering each independently is helpful. Over time the following attributes emerged.
For logging the key attributes are:
- Quiet
- Continuous
- Reliable
Of the three logging attributes above, probably the most important is that the system requires zero effort to operate. Stated another way, the logging should work without bothering us. This is what we mean when we say, it should be quiet. This allows us to focus on enjoying our travel and adventures and not spending time on making the electronics work.
The logging system must be always on and running continuously; the second attribute. We do not want the hassle of having to stop and start the system. We do not even want to hassle to check that it is running. Again, we want to comfortably enjoy our travel, and be confident that the system is working, even if there is no evidence that it is. To maintain confidence in the logging system, it has to be reliable, or at least be able to gracefully tolerate failures. Therefore, reliability is important and is also the third attribute. Quite a bit of effort went into making sure the system and software includes the necessary level of error checking, data validation and fault tolerance to ensure it is reliable.
For viewing the the key attributes are:
- Easy
- Useful
The primary device for the viewing real-time information is our Garmin Overlander. While the Overlander’s primary function is for driving navigation, its location in the cab and the center of the dash means it is always handy. And with a single button press from the Overlander main menu screen, we can open the viewing system. Once the viewing screen is open, a second single button press will switch displays to the one desired. This 2-button-press ease of use obviously allows us to find information quickly, but more importantly, it allows us to find information safely while driving. The information is displayed in large fonts which can be read at a glance. The menu buttons are large and easy to press, even when bouncing along rough roads.
The information displays are simple and only present only the most useful information. Over time we have discovered what is most useful to us, with the less useful information being removed from the displays. A computer can be used to view the more detailed information, including historical trends. We should be trying to look at detailed information while driving.
So, in a strange evolutionary loop, the information in the monitoring system is influenced by our logging and viewing attributes, yet these attributes emerged from the information we ultimately ended up with in the monitoring system.
So, What Data do we Monitor?
Our logs are structured into seven logical areas, as follows:
- Location. Obviously latitude, longitude and altitude, but also other information about the quality of the GPS location fix, the number of satellites in view, course and speed.
- Truck. The truck gets us from A to B, and it is good idea to keep an eye on how it is performing. The Engine Control Unit (ECU) directly provides many of the engine statistics, with other measures like fuel consumption being derived.
- Tires. We keep a close eye on tire pressure and temperature. Our tires work hard as they roll along the road, especially when on dirt tracks. Tires can be easily damaged. We also monitor signal quality.
- Batteries. Mainly the house batteries, but also the truck batteries. This allows us to manage our power usage and charging strategy.
- Solar. So we can make sure our generating capability is working. We also monitor the inverter/charger.
- Water. Fresh and waste water levels. Also pump running times, mainly to derive water consumption.
- Environment. The inside and outside temperatures, relatively humidity and barometric pressure. Also monitor the temperatures in our two fridge/freezers.
- Connectivity. We are not always in cellular coverage so we monitor the strength and quality of the cellular signal.
Each areas is in a separate part of the database, technically called a measurement. For sql users, a measurement is like a table. We can mix and match the information across these above seven areas. For example, we log our energy consumption, and later we might want to see if it changes with outside temperature. Not only can we associate any measurement with when it was made, but also with where it was made.
Most information is directly gathered from the sensors. However, in a few cases we calculate or derived some values and place them in the time-series database. For example, water consumption can be derived from the running hours of the water pump. And this is much more accurate than using the ultrasonic water sensors.
Database Structure
To allow for these more complex queries, the information needs a little structure in our time-series database. Influxdb supports both fields and tags, which serve slightly different purposes. Fields are a good place to store values from the sensors, while tags are used to store metadata about the values, like what sensor produced the value or what source is associated with the field values. This is especially useful when you have two instances of the same thing, like two fresh water tanks, as the field key is the same in both cases, but the tag values will be different so each can be queried independently.
In Molly the influx database will be stored on the computer. Ideally it would be stored on the Network Attached Storage (NAS) device because it has disk redundancy. And while Synology supports running Docker containers, it is not supported on our particular NAS model. Maybe we need the DS620slim?
In the meantime, the database can be backed up to the NAS with the followoing command, where the NAS is mounted in the home directory.
influxd backup -database Molly /home/stephen/mnt/mint/influxdb/backup-yyyy-mm-ddData Model
The following data models provides a good summary of all the information that is logged. The exact details may differ, and the following is illustrative, but close the real-thing
Measurements
|--- Location
|--- Truck
|--- Environment
|--- Tire
|--- Battery
|--- Solar
|--- Water
|--- Cellular Each measurement contains different fields, related to the items being stored.
Location
|--- Latitude [Degrees]
|--- Longitude [Degrees]
|--- Altitude [meters]
|--- Satellites in View [Number]
|--- Horizontal Dilution of Precision [Relative]
|--- Time of fix [hhmmss UTC]
|--- Velocity Made Good [KPH]
|--- True Course [Degrees]Truck
|--- Vehicle Speed [KPH]
|--- Engine Speed [RPM]
|--- Throttle Position [%]
|--- Engine Coolant Temp [ºF]
|--- Ignition Status [On/Off]
|--- MIL Status [On/Off]
|--- Fuel Rate [GPH]
|--- Battery Voltage [V]
|--- Misfire Monitor [On/Off]
|--- Fuel System Monitor [On/Off]
|--- Comprehensive Component Monitor [On/Off]
|--- Catalyst Monitor [On/Off]
|--- Heated Catalyst Monitor [On/Off]
|--- Evaporative System Monitor [On/Off]
|--- Secondary Air System Monitor [On/Off]
|--- A/C System Refrigerant Monitor [On/Off]
|--- Oxygen Sensor Monitor [On/Off]
|--- Oxygen Sensor Heater Monitor [On/Off]
|--- EGR System Monitor [On/Off]
|--- Ambient Air Temperature [ºC]
|--- Trip Odometer [km]
|--- Trip Fuel Consumption [gallons]
|--- Fuel Efficiency [MPG]
|--- Tank Filled Odometer [km]Environment
|--- Temperature [ºC]
|--- Pressure [millibars]
|--- Relative Humidity [TH%]Battery
|--- Volts [V]
|--- Amps [A]
|--- State of Charge [%]
|--- Time Remaining [hours]
|--- Time Since Last Full Charge [seconds]
|--- Depth of Last Discharge [mAh]
|--- Depth of Average Discharge [mAh]Solar
|--- Charge State
|--- Battery Potential [Volts]
|--- Generating Current [Amps]Water
|--- Tank Level [liters]
|--- Heater State [on/off]
|--- Tank Filled Run Hours [seconds]
|--- Pump Run Hours [seconds]Cellular
|--- Connection State
|--- rssi
|--- sinr
|--- rsrp
|--- rsrqLastly, each measurement has tags, to allow the fields to be retrieved. In our case we retrieve information based on the source or the name of the sensor. For example, all the temperature sensors are the same and therefore have the same sensor tag, but the source can vary and might be the Outside, House, Fridge or Freezer.
Tags
|--- Source
|--- Sensor
