Its obviously wise to be wary of lockin - but it is also possible to take an overly simplistic view on avoiding vendor lockin and this can actually cost more in the long-run.

I’m currently a consultant for a cloud provider (AWS), but in the past I’ve been on the other side of the table - having to make technical and vendor choices where I’ve been the one worried about lockin. As a result I’ve ended up with a certain perspective and mindset that has served me well when it comes to managing potential lockin.

I’d like to share that with you.

tl;dr: To make better choices, ask your teams to add two things to their pro’s and con’s analyses:

• Likelihood (high / medium / low) of needing to switch in the future and why this might happen

• How we would switch if we had to and an estimate of the cost to do so.

Can We Just Avoid Vendors?

I have worked with customers who wanted to avoid potential lockin to AWS and so chose open-source or open-core solutions instead.

For example a customer I worked with here in South-East Asia was uncomfortable with the potential of being locked into the AWS cloud-native CI/CD tools and so instead selected self-managed on-cloud GitLab for version control and self-managed on-prem Jenkins for CI/CD orchestration. Now GitLab and Jenkins are both excellent tools but are we free from vendor lockin now? Well GitHub is a for-profit company who offer an open-core version of their product (but you’ll probably want to sub to GitLab enterprise) and Jenkins is an open-source project - both are vendors. Are we more or less locked into those vendors than we would have been with AWS if we’d used CodeCommit and CodePipeline? The truth is - we don’t know yet.

But what if we REALLY wanted to avoid vendors - we could build our own VCS and CI tools! But what would we build them with? Java vended by Oracle? Rust vended by the Rust Foundation? And what would we run these tools on? A Linux distribution we compiled ourselves from source? But where would we get those sources from - the Linux Foundation and the GNU project! And how would we compile them? Using gcc also from the GNU project!

Unless you literally want to build EVERYTHING yourself right down to the silicon (which you’ll be mining yourself), you cannot and should not even try to AVOID vendors. Instead you should select the RIGHT vendors and products. But the question remains: how do we select vendors that won’t lock us in?

What Even is Vendor Lockin Even?

What do we actually mean by vendor lockin? To be locked in means we’re stuck with a choice we made previously even when we’d really rather move to a different option now. How might we end up in this situation?

One way is if we sign up to a long-term or exclusive contract with a vendor. In the cloud world this is increasingly rare - for example AWS operates primarily on utility pricing where you pay only for what you consume. You can opt-in to longer term commitments with reserved instances or savings plans but even here you have flexibility to change your choices within those commitments. True contractual lockin is relatively rare today except from unscrupulous vendors.

Lockin could also happen if we have very specific functional needs that can only be serviced by one vendor. Normally this will be resolved over time as new vendors come in to compete with that incumbent and give us more choices and drive down the prices. Unless we want to become that new vendor all we can do is wait for the free market to take it’s majestic Adam Smithian course and supply us with new options.

To manage vendor lockin we need to focus on managing potential future switching costs.

The third and by far most common cause of lockin is where the cost to switch technologies is prohibitive either in terms of raw labour cost to execute the change, or where the effort to make the change represents an opportunity cost compared to some other improvement we could be making. To manage vendor lockin we need to focus on managing potential future switching costs.

Fortunately in addition to being the main cause of vendor lockin, switching costs are also the cause we can do the most to manage and avoid. But more on that in a moment.

Types of Lockin

Now that we recognize that vendor lockin is mostly just poorly managed future switching costs - can switching costs lead to other types of lockin aside from vendor lockin? Indeed they can - here are a couple of examples:

• Skilset lockin - I had a situation in a previous role where some rather stubborn developers insisted on building a critical component in Golang while the rest of our engineering org were .NET developers. This created a switching cost problem for us which we were forced to incur when those developers left the organization (now with Golang in their CV’s) and we were forced to rewrite that service in C# for maintainability.

• Standards lockin - when you bind your software to a standard or protocol you may be creating a future switching cost problem depending on how you architect your solution. For example if your application today exposes REST API’s but later you want to support GraphQL - how locked into REST are you? It depends on how you have layered the software behind that REST API.

We could go on, but hopefully the point has been made that it is not only vendor lockin but lockin in general is mostly the result of poorly managed future switching costs.

Managing Switching Costs

Most customers (and cloud consultants) will assess a choice based on a pro’s and con’s comparative analysis of the available options. Such an analysis normally pays attention to the functional capabilites of the options, the cost, compatability with existing team skillset, and fit with the technology estate of the organization.

To make a pragmatic assessment of lockin risk we need to add two more things to that comparative analysis:

• Likelihood (high / medium / low) of needing to switch in the future and why this might happen

• How we would switch if we had to and an estimate of the cost to do so.

Now - we are able to compare options based on their future switching costs and the likelihood that we will need to incur those costs. This gives us a way to now objectively assess the “lockin” propensity for the options we have on the table.

Even more importantly - we are also now able to make an informed trade off of future potential switching vs immediate benefits. Sometimes it’s better to choose an option with potential future switching costs if it enables us to get a strategic advantage over our competitors today.

Example 1 - Cloud-Native vs Self-Managed CI/CD

TODO

Example 2 - TODO

TODO

You can get the Grafana dashboard code for this dashboard from here: dashboard.json

The details of the dashboard are very specific to my environment in terms of network interfaces and hosts so it’s not a drop-in solution, but with an understanding of how it works it’s trivial to customize it to your needs.

To recap - this dashboard shows network statistics pulled from my pfSense router by Prometheus via SNMP. Actually it also shows stats from key interfaces on my UniFi 24-port managed switch similarly obtained via SNMP.

There’s a bit going on here but there’s only three distinct types of content:

• Network traffic - showing the traffic in and out from an interface - this accounts for most of the panels
• pfSense State Table - the number of tracked states and the percentage of state table memory used
• Firewall Actions - showing the number of bytes passed or blocked across all interfaces

Let’s look at each in turn and how to customize the dashboard:

Network Traffic

In my dashboard there are several network traffic panels, which are all the same but just for different interfaces:

• bkk80router WAN
• bkk80router GREEN
• bkk80router PURPLE
• etc

As a side-note - many many years ago my first homelab firewall was based on Smoothwall where interfaces are usually described as GREEN, RED, etc. I still use that terminology out of habit although I’m considering changing it to improve the readability of my firewall rules. GREEN is LAN, PURPLE is trusted WiFi, BLUE is IoT WiFi,etc.

Each network panel shows octets (8-bit bytes) in and out with in colored blue and out colored purple and both plotted from a common zero axis but with independent vertical scales - this is so that when there’s a lot of traffic in one direction, you can still see the peaks on the other. It does mean you need to pay attention to the Y-axis scales which may not be to everyone’s liking but it’s how I want to see the data:

If you want both directions to use the same scale you can move the OUT metric to the left axis.

Note that I’m still using the now-legacy Graph visualization and not the newer Time Series visualization because although Time Series supports dual (actually multiple) axes, I haven’t been able to get get it to center zero yet but I will be updating my dashboard once I figure that out.

Each network panel has two queries, one for IN and one for OUT like this:

These queries are very similar:

# IN
irate(ifInOctets{job="snmp_pfsense",instance="10.80.2.2",ifIndex="2"}[5m])

# OUT
irate(ifOutOctets{job="snmp_pfsense",instance="10.80.2.2",ifIndex="2"}[5m])*-1

For IN we’re doing an irate() of ifInOctets and for OUT of ifOutOctets. We filter on the job and instance labels to get to the right device (in my case either my pfSense box or my UniFi switch) and then ifIndex (interface index) for the specific interface we want to monitor.

Note I am using irate() not rate(). irate() works off the last 2 metrics regardless of window size and rate() works off the entire window. If you prefer you could do a rate() of a small window - say 30s - e.g.:

# IN
rate(ifInOctets{job="snmp_pfsense",instance="10.80.2.2",ifIndex="2"}[30s])

The question is how do we know what to use for ifIndex? You can find out the index of each interface by querying for ifDescr in your Prometheus console:

Here we can see that, for example:

• re0 - my WAN interface is index 1
• re1 - my LAN interface (aka GREEN) is index 2
• re1.90 - VLAN tag 90 on my LAN interface which is my IoT WiFi network is index 11
• tun_wg0 - my WireGuard site-to-site VPN is index 7
• etc

Now that you know the index, it’s easy to adapt the queries above to show the data for the interface you’re interested in.

pfSense State Table

In the early days of my adoption of pfSense I had a performance issue that seemed to be correlated to a state table with more than 2% utilization - for that reason I wanted to have this in my dashboard.

I have two stat panels - one showing the number of states and the other showing the utilization of the state table:

The count of states is obtained from one of the pfSense-specific SNMP metrics:

pfStateTableCount{job="snmp_pfsense",instance="10.80.2.2"}

While the utilization is the percentage of the total size:

pfStateTableCount{job="snmp_pfsense",instance="10.80.2.2"}/360000

360000 is hardcoded as it’s not available from a SNMP metric. I got this number from the pfSense console:

This does vary based on RAM so check your state table size and update as appropriate.

Firewall Actions

Firewall actions are shown on a two axis graph similar to the network activity graphs, with PASS traffic in blue and BLOCK traffic in purple.

The queries are:

# PASS
sum(irate(pfInterfacesIf4BytesInPass[5m]))

# BLOCK
sum(irate(pfInterfacesIf4BytesInBlock[5m]))*-1

Conclusion

This network dashboard gives me a high-level idea of what traffic volume looks like on my home network. If I see something interesting in this high-level view and want to know the details then the next step would be to take a look at the pfSense state table to see recently passed traffic, or run a packet capture in pfSense or remotely with Wireshark over SSH into the router.

Let me know if this helps you or if you notice bugs or have ideas to improve it. In the future I may do another update as I continue to enhance it for my needs.

I decided to design my stands around a mag-safe-style USB cable, and ended up grabbing three of these “elough”-brand cables:

As usual the design process started with taking a bunch of measurements of the cable and phone:

These measurements then were defined as parameters in Fusion360:

The modelling process was a bit finicky because of the 10-degree angle I needed to put on the stand bed, and the various cutouts I had to make for the cable track. The final design looked something like this:

Finally here’s the print in white PLA with 20% infill:

The tolerances on the cable channel and the socket for the magnetic plug were a bit tight on the first print, but after enlarging with a blade and a power drill I got it to friction-fit snugly into place:

Finally with the phone mounted in it:

The design came out great. The only issue is the base is very light given the small amount of plastic, so when you grab the phone the whole stand comes with it. Actually I had the same problem with my official Apple phone stand for my iPhone and just solved it with Blutac (of course) so I’ll probably do the same here.

The sources are available under the Apache License 2.0 from the GitHub project and a pre-built Docker image supporting armv7 and amd64 architectures is available from Docker Hub.

So far I’m using this in my homelab to measure transfer speeds between my two sites (BKK80 and HEA92) and from public servers in London, New York and Singapore to my two sites:

The install was uneventful and went according to the documentation so there’s nothing much to add there.

Their docs provide a sample Python script for reading the energy values via the I2C bus and this was also easy to get going. After getting the sample running I decided to put together a Prometheus exporter based on the script_exporter by Rico Berger. This is fully working now:

curl http://localhost:9469/probe?script=piups

# HELP script_success Script exit status (0 = error, 1 = success).
# TYPE script_success gauge
script_success{script="piups"} 1
# HELP script_duration_seconds Script execution time, in seconds.
# TYPE script_duration_seconds gauge
script_duration_seconds{script="piups"} 0.280330
# HELP piups_bus_voltage_volts The voltage supplied to the connected device(s)
# TYPE piups_bus_voltage_volts gauge
piups_bus_voltage_volts 5.208
# HELP piups_bus_current_milliamps The current drawn by the connected device(s)
# TYPE piups_bus_current_milliamps gauge
piups_bus_current_milliamps 136.805
# HELP piups_power_milliwatts The power consumed by the connected devices in milli-watts
# TYPE piups_power_milliwatts gauge
piups_power_milliwatts 737.561
# HELP piups_shunt_voltage_millivolts TBD
# TYPE piups_shunt_voltage_millivolts gauge
piups_shunt_voltage_millivolts 7.080

In my weather station dashboard I’ve added a side-bar showing the energy consumption of the station as queried every 15 seconds from the UPS board:

I have packaged my solution as piups_exporter on GitHub and the README in that project elaborates on how to get it setup, which is very easy.

It was only after I got my UPS board that I realized there’s a newer model than the one that I ordered - the EP-0136 “UPS Plus” which provides a lot more metrics - so naturally I’ve ordered one of those and once I have it I will come back and update piups_exporter to also ship those metrics.

Hardware

Overview

So here’s what the weather station looks like currently:

The new things are:

• PoE+ adapter and 3D-printed mounting bracket
• Replacement SSD enclosure and 3D-printed mounting bracket
• LED indicators for UPS board power, Pi power status and SSD activity
• SI1145 light sensor

The AS3935 sensor plugged in at the right isn’t connected yet - that’s just so I don’t misplace it.

PoE+ Adapter

I have a few these PoE+ adapters in my parts cabinet so I just threw one on to see what would happen with power being supplied by my UniFi 24 port switch. It worked, but after about 5 days the system lost power.

After fully recharging the batteries via the barrel jack I hooked up my Ruideng USB in-line multimeter to determine that when the UPS board is already fully charged it draws about 1 milliamp from the PoE+ adapter:

Even though the Pi is running and drawing around half an amp:

In other words the UPS is driving the board off batteries even when connected to power. Eventually it hits a threshold and starts charging again, but apparently not effectively enough because eventually the batteries run flat and the system dies. In short - this is not a UPS, it’s a powerbank.

I have ordered a 52pi UPS board. I believe it’s a better unit - but it’s really hard to tell from the data sheet so has to be tested. This board has a built-in RTC (a nice-to-have for my application) and a power meter so you can read draw and battery level via I2C which will be cool if I can get that to work. Ideally I will read those values and export them to Prometheus.

Replacement SSD Enclosure

On Tuesday morning last week I woke up to a dead weather station. From the Prometheus-exported host telemetry I could see that it went offline around 2:20am local time.

Through a process of elimination I determined that it was the interface board in the SSD enclosure that had failed and that the SSD itself was fine so I ordered in a new Orico brand enclosure. This one was a different size to the original so I had to print a new bracket for it:

LED Indicators

Eventually this thing is going to be mounted in a cabinet on a pole in a field, so it would be helpful if the power and HDD lights were easy to see. Fortunately Raspberry Pi supports breaking out LED’s so it was a 5 minute job to add external power and HDD activity LED’s. I also connected a LED to one of the JST outputs on the UPS board to indicate when the board is supplying power:

Endurance Test

Even though the current UPS board is no good, I ran an endurance test to see how long these two 18650 cells could run the host for and the result was just under 16 hours.

Once I get the replacement UPS board I will re-run the endurance test, but this is already a very good indicative result - being able to survive a power outage of more than half-a-day will make this a very robust system.

Sensors

I added one new sensor in this iteration. Originally I was going to add the I2C lightning sensor which was already in my parts bin but during the week last week the GY/SI1145 light sensor came in so I hooked that up instead.

I broke out the I2C bus to a breadboard and reconnected the BME280 plus added the SI1145 - blue is data and orange is clock:

Verified connectivity and found the SI1145 at 0x60 while the BME280 is still at 0x76:

pi@hea92weather01:~ $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- 76 --

Then added the code to read the SI1145 and include it in the Influx line protocol message published to MQTT:

import SI1145.SI1145 as SI1145

...

#
# GY1145 / SI1145
#

si1145 = SI1145.SI1145()

...

# SI1145
lightVisible = si1145.readVisible()
lightUV = si1145.readUV()
lightIR = si1145.readIR()

# Publish
influx = "weather,station=" + weather_station_id + " " + \
	"humidity=" + str(humidity) + \
	",pressure=" + str(pressure) + \
	",temperature=" + str(temperature) + \
	",visible=" + str(lightVisible) + \
	",uv=" + str(lightUV) + \
	",ir=" + str(lightIR)

And added some panels to my weather station dashboard in my main Grafana instances:

Data Plane

Overview

Most of my time on this iteration was spent on the data plane. The improvements here were:

• Handle SIGTERM
• MQTT Auto-Reconnect
• Containerized the sensor-reader Python script
• Added a custom bridge network to connect the three Docker Compose stacks
• Added an on-prem MQTT broker and InfluxDB storage
• Configured the edge MQTT broker to bridge to the on-prem MQTT broker
• Connect Grafana to use the on-prem InfluxDB instead of edge InfluxDB
• Connected my Home Assistant instance to MQTT and added visualizations
• De-hardcode sensor-reader

The data plane now looks like this:

Handle SIGTERM

In order to be a good container citizen I added support for SIGTERM and SIGINT Linux signals - this is the skeleton for signal handling:

class SensorReader:

	def __init__(self):
		self.stopped = False
        
	def run():
		while not self.stopped:
            # Process sensors
            sleep(1)

	def stop(self, signal, frame):
		print("Stopping SensorReader")
		self.stopped = True
        
def main():
	sensorReader = SensorReader()
	signal.signal(signal.SIGINT, sensorReader.stop)
	signal.signal(signal.SIGTERM, sensorReader.stop)
	sensorReader.run()

if __name__ == "__main__":
	main()

This was adapted from a post but I’ve misplaced the reference.

MQTT Auto-Reconnect

My original MQTT implementation was bare bones. I’ve added code based on some helpful articles from Steves Internet Guide to track connection state and leverage Paho MQTT’s built-in auto-reconnect functionality:

		#
		# Configure MQTT CLient
		#

		def mqtt_on_connect(client, userdata, flags, rc):
			if rc == 0:
				print("Connected to MQTT broker")
				client.connected_flag = True
			else:
				print("Failed to connect")

		def mqtt_on_disconnect(client, userdata, rc):
			print("Disconnecting reason " + str(rc))
			client.connected_flag = False
			client.disconnect_flag = True

		client = mqtt.Client(weather_station_id)
		client.on_connect = mqtt_on_connect
		client.on_disconnect = mqtt_on_disconnect
		client.connected_flag = False
		client.username_pw_set(broker_username, broker_password)
		client.connect(broker_host_name, broker_port)
		client.loop_start()

		while not self.stopped and not client.connected_flag:
			print("Waiting for connection")
			sleep(1)

         while not self.stopped:

			if (client.connected_flag):
                
				# Read sensors and publish to MQTT

				sleep(15)

			else:
				print("Connection lost.  Waiting for reconnection")
				sleep(5)

		client.loop_stop()
		client.disconnect()

This now means if the local MQTT broker goes down, sensor-reader will retry until it can connect again and the sensor readings will flow once again.

Containerize sensor-reader

The daemon that reads sensors and publishes the values to MQTT is called sensor-reader and it’s implemented as a simple Python3 script. To Dockerize this I just had to create a requirements.txt to enumerate the packages that I had previously installed manually:

RPi.bme280
paho-mqtt
SI1145

Then created a simple Dockerfile based on the official Python image:

FROM python:3.9.5-buster

RUN mkdir /app
WORKDIR /app

COPY main.py ./
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

CMD [ "python3", "./main.py" ]

I initially wanted to use the alpine-based image but there is a problem running it on 32-bit RPi OS without privileged mode, so I fell back to the Debian Buster based image instead.

On first run I got this error:

pi@hea92weather01:~/als_sys_host_031_hea92weather01/sensor-reader $ ./run.sh
Traceback (most recent call last):
  File "/app/./main.py", line 92, in <module>
    main()
...
FileNotFoundError: [Errno 2] No such file or directory: '/dev/i2c-1'

Which was solved by mapping that device through when running the container:

sudo docker run \
    -it --rm \
    --device /dev/i2c-1 \
    sensor-reader:latest

After successfully testing the image I created a docker-compose config for easier startup:

version: "3"
services:

  #
  # SensorReader
  #

  sensorreader:
    image: "aleisium/sensor-reader:latest"
    restart: "always"
    devices:
      - "/dev/i2c-1:/dev/i2c-1"

Custom Bridge Network

I intentionally have three separate docker-compose stacks - the reason for this is that I want to be able to easily start and stop the MQTT broker, the local InfluxDB storage and the sensor-reader independently. This could also be achieved by having a single stack with convenience scripts to selectively stop and remove containers, and I may yet do that, but for now it’s nicer having separate stacks.

The problem with separate stacks is if you make them communicate via the physical eth0 interface, connectivity is lost when the network cable is pulled.

To solve this I created a custom bridge network in Docker and connected the three stacks to it.

The bridge is created with the script network/up.sh:

#!/bin/bash

sudo docker network create --driver=bridge --subnet=10.12.1.0/16 weather0

Then each of the three stacks are connected to that network - for example, sensor-reader:

version: "3"
services:

  #
  # SensorReader
  #

  sensorreader:
    image: "aleisium/sensor-reader:latest"
    networks:
      - "weather0"
    restart: "always"
    devices:
      - "/dev/i2c-1:/dev/i2c-1"

networks:
  weather0:
    external: true
    name: "weather0"

On-Prem MQTT Broker

I established a new “central” MQTT broker on a VM under ProxMox. I also now have an InfluxDB 1.8 instance with a Telegraf agent that reads from that central MQTT and stores measurements on-prem.

The central MQTT, Influx and Telegraf configs are separate from my weather station GitHub but I’ll be adding a similar config soon to make it easier for others to re-use.

Edge MQTT Bridge to On-Prem MQTT

I’m using the venerable Mosquitto MQTT broker which supports bridging - meaning an instance of the broker can be instructed to act as a client to another broker to read and / or write messages.

I added the following bridge config to broker/config/mosquitto.conf for the MQTT broker on the weather station:

connection central
address 10.80.2.60:1883
remote_username hea92weather01
remote_password password
topic # out

This causes the weather station to forward all messages it receives to the broker at 10.80.2.60 using the specified credentials. In this syntax # is not a comment marker but a wildcard indicating “all” messages.

References:

• mosquitto_conf Documentation

Point Grafana to On-Prem InfluxDB

As I use Grafana Provisioning for infrastructure-as-code of my telemetry stack, I just had to commit the address change to the data source definition in Git:

apiVersion: 1

# list of datasources that should be deleted from the database
deleteDatasources:
  - name: "hea92weather01"
    orgId: 1

# list of datasources to insert/update depending
# what's available in the database
datasources:
  - name: "hea92weather01"
    type: "influxdb"
    access: "proxy"
    database: "weather"
    user: "grafana"
    password: "password"
    url: "http://10.80.2.60:8086"

Then re-launch the telemetry stack.

Home Assistant Integration

Defined a connection to the central MQTT broker in Home Assistant’s configuration.yaml:

mqtt:
  broker: "10.80.2.60"
  port: 1883
  client_id: "bkk80ha"
  username: "bkk80ha"
  password: "password"

Added sensors to subscribe to values of interest from MQTT:

  - platform: "mqtt"
    name: "HEA92 Temperature"
    state_topic: "weather/hea92weather01/temperature"
    device_class: "temperature"
    unit_of_measurement: "°C"
    value_template: "0"
  - platform: "mqtt"
    name: "HEA92 Humidity"
    state_topic: "weather/hea92weather01/humidity"
    device_class: "humidity"
    unit_of_measurement: "%"
    value_template: "0"
  - platform: "mqtt"
    name: "HEA92 Pressure"
    state_topic: "weather/hea92weather01/pressure"
    device_class: "pressure"
    unit_of_measurement: "mbar"
    value_template: "0"
  - platform: "mqtt"
    name: "HEA92 Visible Light"
    state_topic: "weather/hea92weather01/visible"
    device_class: "illuminance"
  - platform: "mqtt"
    name: "HEA92 UV"
    state_topic: "weather/hea92weather01/uv"
    device_class: "illuminance"
  - platform: "mqtt"
    name: "HEA92 IR"
    state_topic: "weather/hea92weather01/ir"
    device_class: "illuminance"

Finally added some cards to a dashboard in Home Assistant:

Further elaboration is available in the README.md.

References:

• Home Assistant MQTT Broker
• Home Assistant MQTT Sensor

De-hardcode sensor-reader

Finally as a move towards making my weather station stack easily re-usable by others, I started parameterizing some of the hardcoded values in sensor-reader and moving them to environment variables so that they can be passed through the docker-compose file:

  sensorreader:
    environment:
      - "WEATHER_STATION_ID=hea92weather01"
      - "BROKER_USERNAME=hea92weather01"
      - "BROKER_PASSWORD=password"
      - "SAMPLE_INTERVAL=15"
    image: "aleisium/sensor-reader:latest"
    networks:
      - "weather0"
    restart: "always"
    devices:
      - "/dev/i2c-1:/dev/i2c-1"

Next Steps

The next improvements are:

• Processing of light readings into meaningful values
• Improve documentation and scripts to make it easier for others to re-use my configuration
• More sensors
• Test the new UPS board when it arrives
• Enclosure for the electronics
• Trial field deployment (on our condo balcony)

A few weeks back we renovated our balcony in Bangkok and as part of that exercise I completely re-installed the drip irrigation system that waters our many plants.

In the original install I had the flexible pipe just running along the tiles behind the pots. The problem with this that the pipe becomes a dirt trap, collecting soil particles and leaves behind it. For the re-install I wanted to get the pipe off the ground and thought maybe I could fabricate some clips to hold it under the lowest level of the balcony railing which would also put it somewhat out of sight as an added benefit.

I took some quick dimensions of the pipe and the railing:

Then sketched the shape in Fusion360 - this took all of 5 minutes:

It took 3 or 4 iterations of printing and testing to get the shape dialed in. The adjustments were reducing the inner dimension to make the clip hold onto the railing tightly, and progressively thickening the shape and increasing infill to make it stronger.

Here’s the test of the one that became the final version:

With the model finalized I printed 14 of them out and did the final installation:

The result was good. The clips are strong and haven’t deformed after being under load for a couple of weeks now, and the irrigation pipe is now mostly out of sight and more importantly is off the tiles making it easier for us to keep the balcony clean.

It remains to be seen if these PLA prints last long-term being exposed to the rain and sun - will be interesting to check back in on them in 6 months.

This was an improvement in that the box held more files and could be stored in a cupboard of the way - however accessing the files was kind of a problem because they were just jammed in together so it was hard to flick through them, and if you took too many files out at once the remaining ones would start to slide around in the container.

Recently I had the idea to 3D print some rails to hang the files inside the box - and it worked out better than I expected.

Here’s a brief rundown of the project.

Container

The container I have is a 40 litre “Micron” brand - it is the absolute perfect size for the Ikea Summera drop files. I recently found exactly the same container at HomePro under the “Stacko” brand for 299 baht.

Rails

After a few iterations of measuring, eyeballing and trial-and-error test prints I came up with this profile for the rails:

I extruded the rails out with end-stops, and cut holes for M4 bolts and captive sockets for the hex nuts:

Given the length, I split the rail body in two to fit on my 300mm square CR10S printer bed. I printed them with brims for adhesion and tree supports for the minimal amount of support that was required in the overhangs of the hex nut sockets - the print quality was gorgeous:

I decided to print face plates to go on the outside, rather than having the heads of the bolts directly against the outside of the crate, both for some additional robustness as well as for aesthetics. Unfortunately I elected not to use brims this time and two of the parts warped but I didn’t reprint them as I didn’t want to wait.

Initially I thought glue would also be a good idea, and I did actually use superglue but it barely adhered - ultimately bolts alone would have been more than enough. In fact half as many bolts would have been enough. Here’s the first rail installed:

Here’s the empty container now with both rails installed:

Test file deployment:

Label Tabs

The Ikea files come with plastic labels that clasp a little perforated tear-off card, but somehow I ran out a while ago - more 3D printing to the rescue.

I took some measurements and recreated the tab shape in Fusion360:

Then printed a bunch of orange and black tabs. I made these only 0.6mm thick so they’re quite flexible meaning they’re easy to slip into the slots on the drop files:

This roll of 1,100 50mm by 20mm self-adhesive labels was 185 baht on AliExpress:

Finished Product

With the rails installed and the files tidied up and labelled, my file access problems are a distant memory and the final result looks great!

Improvements I’d consider if I was doing this project again would be:

• Reduce the number of bolts - it’s currently way overbuilt in terms of load capacity
• Skip the glue - bolts are enough
• Revise the faceplate design to incorporate a cover to hide the bolts for improved aesthetics
• Always use brims when printing long flat thin delicate parts!
• Get a label printer to raise the bar on label quality - I may yet get a label printer and redo all the labels.

Today’s update covers:

• Base platform (a Raspberry Pi)
• BME280 sensor integration for barometric pressure, humidity and temperature readings
• Data plane built on MQTT, Telegraf, InfluxDB and Grafana

A goal of this project, in addition to building an actual weather station, is to provide my configuration as a reusable artifact upon which others can build their own similar projects. To that end, my code and documentation are on GitHub and licensed under GNU GPLv2.

Architecture

My goal state architecture is as follows:

In summary

• The weather station should have it’s own MQTT broker and local storage so that if network comms are interrupted, measurements are still captured and are buffered to be sent out once comms are restored.
• An on-prem MQTT bus will bridge measurements from the weather station at the edge into the internal network from where they can be fed to other locations
• For now measurements will just be stored in another InfluxDB instance on-prem to feed into Grafana dashboards on my existing telemetry stack alongside other dashboards that are populated from Prometheus such as my UPS monitoring dashboard. Later I may also pipe measurements from that on-prem MQTT broker up to AWS.

This weekend I got all the major components on the weather station itself in place and added a dashboard to my Grafana instances to pull metrics directly from the station’s local InfluxDB.

Sensors

The full suite of metrics that the station will eventually monitor are:

• Wind Speed (Misol anemometer)
• Wind Direction (Misol wind vane)
• Temperature (BME280 sensor)
• Humidity (BME280 sensor)
• Barometric Pressure (BME280 sensor)
• Air Quality (TGS2600 sensor)
• PM 2.5 (PMS5003 sensor)
• Sunlight (visible, UV-A, UV-B via a GY1145 sensor)
• Lightning Strikes (AS3935 sensor)
• Rainfall (Misol rain gauge)
• Gasses (MQ-2, MQ-3, etc, etc - around 5 of them)
• Ground Temperature (DS18B20 sensor)
• Ground Moisture (generic capacitive sensor which will probably corrode out in about 3 weeks)

v1 Build

Hardware

This weekend my focus was getting the base platform bedded down and stable, along with integrating the first sensor.

I put it together from the following components that were in my parts cabinet:

• Raspberry Pi 3B
• X705 UPS Board with two 18650 lithium batteries installed
• Transcend 128GB M.2 SSD in a USB-C enclosure
• Various metal stand-offs, bolts and nuts
• Hoco brand silicon sleeved short USB-C and micro-USB cables

I also 3D printed a bracket to mount the SSD onto stand-off posts to secure it to the platform.

I won’t go through the full build - if you’ve done anything with Raspberry Pi’s there’s nothing complicated here.

The only challenge I encountered was that initially I tried to power the Pi via one of the JST outputs from the UPS board and it was persistently undervolting. After switching to micro-USB the UPS board seems to provide enough power to drive the Pi with the attached SSD with not a single undervolt event. I’ve had this UPS board for a while and I don’t recommend it - there are a lot better options available these days.

Even though the UPS board isn’t the best, it does provide the assurance that if the mains power supply fails the station will continue to run for at least a couple of hours (an endurance test is TBD).

Sensor

I had to solder the breakout pins onto my BME280 but after that connecting it up was easy thanks to the Raspberry Pi Weather Station project guide which I followed pretty much exactly for this part.

Software

Getting the software up and running took a while mostly because I realized that Influx 2 doesn’t offer an official arm7 Docker image and so went off on an Ubuntu Server 20 64-bit LTS tangent for a while. In the end I came back to 32-bit Raspberry Pi OS with Influx 1.8 because I found the Ubuntu Server distro really slow on my Pi 3.

I won’t explain every little thing because it’s actually documented in detail in the README.md in my GitHub repo, however to summarize the build process:

• Setup base OS - in my case this involved enabling SSD boot because I definitely do not want to run my weather station off a SD card
• Setup Docker, Docker Compose, I2C
• Setup few Prometheus exporters so that the weather station host itself can be monitored by my existing telemetry-stack - given that I’m also using Telegraf to ship weather station measurements, I could potentially replace the Prometheus exporters with Telgraf and save some CPU and memory - will consider that
• Clone my weather-station repo

Then to start everything up:

# Launch the MQTT broker
cd mqtt-broker
./start.sh

# Launch the local InfluxDB instance with Telegraf data shipper
cd ../local-storage
./start.sh

# Launch the Python script to read sensors
cd ../sensor_loop
python3 main.py

Note I’m currently running this from inside a tmux session so I don’t need to nohup it. I will be wrapping the sensor_loop script in a Docker image soon so that it’s easier to manage as a service. My sensor_loop script BTW is based off the sample code from the previously mentioned Raspberry Pi Weather Station project guide which is recommended reading if you want to do something like this.

Dashboard

Finally I added my weather station as a datasource in Grafana and created a dashboard. Naturally I’m practicing infrastructure-as-code so the datasource was defined in my Grafana provisioning config as follows:

apiVersion: 1

deleteDatasources:
  - name: "hea92weather01"
    orgId: 1

datasources:
  - name: "hea92weather01"
    type: "influxdb"
    access: "proxy"
    database: "weather"
    user: "grafana"
    password: "password"
    url: "http://10.80.2.31:8086"

I created the dashboard through the Grafana UI but then exported it into my Grafana git repo so it can also be provisioned on launch. The dashboard, which is not that exciting yet, looks like ths:

The saw-tooth nature of the temperature and humidity readings is because the station is sitting in my home office and so it’s showing the fluctuations as the air conditioner turns on and off. It’s amazing how immediate the temperature change is when you can observe it in tenths of a degree as the BME280 offers.

I also found it interesting that the BME280 is reading the air pressure as anywhere from 1001 to 1005 milli-bars - this is plausible since much of Bangkok is actually below sea-level! Although where I am is about 15 meters above sea-level.

Next Steps

The next things to do are:

• Tuning and improvements on the edge InfluxDB including tuning retention window settings to keep as much data as possible without exhausting the SSD capacity.
• Setup the MQTT bridge to get data off the station and into my main network where it can be further routed.
• Setup the on-prem InfluxDB instances to accumulate the data.
• Update my Grafana config to use the on-prem InfluxDB’s instead of the edge InfluxDB.
• Add the next sensor which will probably be the lightning sensor since I have one in my parts box, it’s also I2C so should be easy, and we’re just entering rainy season in Bangkok and there’s a lot of lightning to detect!