As a result, Vox Pupuli has come to the conclusion that we can no longer guarantee that our modules will work with Puppet Core or Puppet Enterprise. As I and others have said before, no one in the Puppet community wants to break compatibility as that only serves to fracture the ecosystem that has built up over many, many years. Unfortunately, Perforce is once again forcing our hand.

On top of that, it appears that sometime after March 21st, 2025 Perforce removed the page at https://www.puppet.com/ecosystem/contribute/trusted-contributors even though it is still linked to at https://www.puppet.com/ecosystem/contribute. You can see these for yourself thanks to the Internet Archive’s Wayback machine:

• The contribute page as of April 29, 2025
• The Trusted Contributor page as of March 21, 2025

Sadly, this is not all that surprising as it is in line with them not actually being receptive to working with the community. I know that sounds harsh, but it is the reality of the matter, and was made quite evident in the Zoom meeting between Perforce and Vox Pupuli on June 10th, 2025. Most, if not all, attendees from the community left that meeting totally flummoxed by the actions and attitude of Perforce’s leadership.

So, what does all this mean? Well, it seems another chapter in the story of a free and open source version of Puppet and its supporting tools has begun. Concretely, the README of each one of Vox Pupuli’s 177 modules that are published to the Puppet Forge will be updated to make it clear that we are unable to validate their compatibility with Puppet Core and Puppet Enterprise. This also means Facter is being forked and will be published to RubyGems.org as soon as a name is decided upon. Once that is completed, all testing and build pipelines will be updated to replace the puppet gem that won’t be updated beyond 8.10.0 with the openvox gem and to replace the facter gem with the yet-to-be-named alternative. Not too long after that, an additional update to each module is planned to remove the bits from its metadata.json that says it is compatible with puppet and replace that with the module’s openvox compatibility.

To be clear, the Vox Pupuli community is not actively planning to break compatibility with existing Puppet features, but cannot guarantee continued compatibility with software we can’t legally access. As such, we are simply trying to convey this so that each user of our modules and tools knows the reality of the situation.

Unfortunately, we have reached a fork in the road that we as a community have no ability to avoid: Perforce forked the open source project into private repositories and has made it clear that is where their efforts will reside, and that the original repositories under the puppetlabs namespace on GitHub are all but abandoned. Our two choices are to either accept that after roughly 20 years of being developed in the open under first a GPL v2 or later license and, since 2011, an Apache 2.0 license that the project is no longer truly open source and only available commercially now or to continue the open source development under the moniker OpenVox. We have chosen the only reasonable route, which is the same one Luke articulated so well in 2011, and it is up to Perforce to either join us along this journey or to continue down the other road. Here’s to hoping they choose to join us.

This post was originally created for the Vox Pupuli blog

• Nginx on a virtual private server (VPS) at Hetzner listens on ports 8333 & 9735 for TCP connections
• The stream proxy module forwards those connections to bitcoind and lnd over Tailscale
• The server running bitcoind and lnd uses the Hetzner VPS as a Tailscale exit node so that all outbound traffic is via the VPS

Here’s a technical breakdown of how I make that happen. My configuration is done via NixOS flakes, but the general process would work on anything using Nginx and Tailscale.

{ config, username, ... }: let 
  domain = "example.com";
  private_btc = "some-host.your-domain.ts.net";
in {
  networking.firewall.allowedTCPPorts = [
    8333 # Bitcoin Core
    9735 # LND
  ];

  services = {
    nginx = {
      enable = true;
      streamConfig = ''
        server {
          listen 0.0.0.0:8333;
          listen [::]:8333;
          proxy_pass ${private_btc}:8333;
        }

        server {
          listen 0.0.0.0:9735;
          listen [::]:9735;
          proxy_pass ${private_btc}:9735;
        }
      '';
    }; # end nginx
    tailscale = {
      enable = true;
      authKeyFile = config.sops.secrets.tailscale_key.path;
      extraUpFlags = [
        "--advertise-exit-node"
        "--operator"
        "${username}"
        "--ssh"
      ];
      useRoutingFeatures = "both";
    }; # end tailscale
  }; # end services

  sops = {
    age.keyFile = "${config.users.users.${username}.home}/.config/sops/age/keys.txt";
    defaultSopsFile = ../secrets.yaml;
    secrets = {
      tailscale_key = {
        restartUnits = [ "tailscaled-autoconnect.service" ];
      };
    };
  }; # end sops
}

Breaking that down a little:

1. networking.firewall.allowedTCPPorts opens the firewall ports needed for bitcoind and lnd
2. services.nginx configures two ngx_stream_proxy_module instances within the streamConfig section that route traffic to the backend using the dns name from Tailscale
3. services.tailscale enables Tailscale on the VPS and configures it as an exit node.
4. sops configures SOPS to securely store secrets

And that’s it on the VPS. For the backend, you could be running a variety of different options from Umbrel to Nix Bitcoin to the services manually configured on a variety of operating systems. Settings those up is best left to a different post, but the keys that relates to this setup are:

• that where ever they run uses the VPS as an exit node
• the services listen on for connections incoming via Tailscale
• the services advertise the IP of the VPS as their public address

Note: the links to Hetzner and Tailscale in this post are referral / affiliate links. The Hetzner one is mine and the Tailscale one is from Jupiter Broadcasting’s Linux Unplugged podcast. I’ve used the JB link because Chris Fisher, Alex Kretzschmar, Brent Gervais, & Wes Payne have taught me about much of what’s here through their podcasting.

So, here’s an updated tl;dr on Puppet as an OpenSource project: a fork is absolutely coming now. There was a “town hall” today in which Perforce Software made it quite clear they are going to claim they want to work with the community while not actually doing so. As a result, those of us who have been following this closely reassembled, determined there was no longer hope of really working together, and that it was time to move forward accordingly. Perforce also made it clear no community thing could use the brand mark / trademark “Puppet” as well, thus the naming discussion has started (the linked GitHub org will be renamed as soon as a name is decided upon). Additionally, governance discussions are underway as well. More will be shared about this as soon as we have come to a decision. In the mean time, some thoughts on the subject are at https://github.com/OpenPuppetProject/planning/issues/7.

To be clear, none of us in the Puppet community wanted to take the fork route. Our hand has been forced by the actions of Perforce and hollow sounding promises that seem aimed at placating people. Personally, I’m really sad things have spiraled into this pit of near despair. Hopefully the community will prevail in our quest to have a truly open solution like we had prior to a couple of months ago, but with the added benefit of being directly controlled by community members.

This post is my personal take on things.

This post was originally shared on LinkedIn

The question I was presented with is in reference to the “net1” interfaces in the diagram. After checking that there were no Network ACLs or Security Group rules preventing the communications, and ensuring that the Internal Route Table contained the two internal /24 subnets, it became clear that the problem was somewhere on the operating system configuration side of things. Time for side-by-side terminal sessions ssh’ed into each instance.

Out of habit, I first checked that there were no iptables rules preventing pings on the internal interfaces and found an explicit allow for icmp, so that wasn’t the issue. Next, I checked the output of ip route and saw there was no route to the other subnet… base-level problem found! Now to figure out what to do about it. First, I tried adding a rule based on the network interface: ip route add 10.5.2.0/24 dev net1 on Instance 1 & ip route add 10.4.2.0/24 dev net1 on Instance 2. Not surprisingly that didn’t work. At this point, I knew I was forgetting something simple diagnostic wise, but I couldn’t put my finger on it. Fortunately, one of my teammates mentioned tcpdump and that jarred my memory.

With the manual routes still in place, I fired up tcpdump -i net0 on Instance 2 and then tried pinging from Instance 1 both with ping -c3 10.5.2.10 and ping -I net1 -c3 10.5.2.10… nothing was received. As I was relaying this to my team I saw something interesting pop up in the tcpdump output:

$ sudo tcpdump -i net1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on net1, link-type EN10MB (Ethernet), capture size 262144 bytes
09:41:43.433307 ARP, Request who-has 10.5.2.10 tell 10.5.25.1, length 28
09:41:43.433322 ARP, Reply 10.5.2.10 is-at 06:4f:8d:b9:b9:e3 (oui Unknown), length 28

This made me realize that Amazon uses the .1 address as the gateway in each subnet! With this new-found knowledge, I deleted the routes I had previously added and replaced them with these: ip route add 10.5.2.0/24 via 10.4.2.1 on Instance 1 & ip route add 10.4.2.0 via 10.5.2.1 on Instance 2. Put another way, ip route add <subnet in other AZ> via <.1 in the locally attached subnet>. BOOM! Everything works now… and the fix turned out to be a simple one that, in hindsight, should have been obvious. To make the new routes persistent, I added them into the Puppet code that manages each instance.

And that’s it. The key here was discovering that the .1 is the gateway and adding a simple route.

Edit 2024-06-03: Another coworker pointed me to https://docs.aws.amazon.com/vpc/latest/userguide/subnet-sizing.html which actually documentes this along with the reserved adderess for DNS on each subnet (.2 on a /24). Like so many things, this is easy if you know where to look…

Every spring, my wife and I get really excited about all the pretty plants and flowers that we can decorate our yard with. We also generally grow some vegetables and/or herbs. The problem with this is that we live in Georgia in the US and it gets freaking hot and humid here during the summer. The oppressive heat makes us not want to go outside to water the plants. Combine this with a little bit of traveling and you have a recipe for mostly dead plants during the latter part of the growing season. Well, this year we decided to not only acknowledge this reality, but to do something about it. You see, I’m a bit of a home automation nut and my wife knows it. She was shopping on Amazon and came across an inexpensive drip irrigation kit for gardens and decided to buy it for a raised flower bed we were already planning to setup this year. When it came in, she showed it to me and said “now I just need you to make it come on automatically.” As you might be able to guess, I was more than happy to take up that challenge. I spent a couple of days doing research to find a solution that fit within these self-imposed parameters:

• any smart devices must not require internet access
• the solution had to be able to be controlled via Home Assistant
• all parts had to be relatively inexpensive both individually and when combined together
• I must be able to use multiple instances of the setup so that it can be applied to multiple places in the yard

What I came up with was a zigbee-based water valve with a built in timer and a soil moisture sensor that connects up to the weather station I already had. With these two items I can ensure that we only water the plants when they need it. I also got a 3-way manifold to go on my spigot on the side of my house so that I could connect two valves and one regular garden hose.

The picture below shows the irrigation kit and the soil sensor. The larger tubing snaking through the middle is 1/2” diameter. The smaller tubes are 1/4” and connect to the sprinkler heads (the blue-topped things). Each sprinkler has a little spike under it to keep it in place and is adjustable so that you get just the right amount of water out of each one. The bright green thing with a white disk in the center of it is the top of the soil sensor.

Here is what it looks like with the sprinklers on:

A couple of things to note in the picture above are that the sprinklers each water right near the base of a plant and that the soil sensor gets watered as well.

Parts list

Below are links to each item I used. Many of these are affiliate links so if you happen to buy something I’ll make a few buck by you using the link.

• Carpathen Drip Irrigation Kit for Garden
  • I bought two of these and we ended up with parts left over.
• SASWELL Irrigation Timer SAS980SWT-7-Z01
  • This is, like so many devices on Amazon, made by Tuya. The zigbee connectivity works just fine with Home Assistant’s Zigbee Home Automation (ZHA) as does the on/off functionality. The other niceities, unfortunately, don’t work. Still, on/off is all that is needed for this project and does not require the use of the Tuya zigbee gateway that comes with the device.
  • As a bonus, the kit comes with a quick disconnect coupler that can connect to the bottom of the time or to a hose and the other end goes on 1/2” drip tubing. Of the three different fittings I tried, this is the easiest to use and the only one that didn’t leak.
• Orbit 62009 3-Way Plastic Hose Faucet Valve Manifold
  • This one had great reviews and seems to work really well. As a matter of fact, it had much better reviews than the brass ones. In addition to the three connections along the bottom that can be turned on and off individually, the left and right end caps also come off and can be used.
• Dixon Valve TTB75 PTFE Industrial Sealant Tape
  • The other name for this is “Teflon Tape” - I used it on each of the fittings to make sure leaks are avoided.
• ECOWITT WH51 Soil Moisture Sensor
  • I have this connected to my Ecowitt GW2000 Wi-Fi IoT Hub that came with my ECOWITT Wittboy Weather Station GW2001.
  • The entire kit works perfectly with Home Assistant 100% locally.
  • It also supports up to 8 of the soil moisture sensors.
• HOUYA U Shaped Garden Stakes 4 Inch 40 Pack Drip Irrigation Stakes Galvanized Landscape Garden Staples
  • We got these to hold the hoses in place between the timers and sprinklers.
• Utility Hose 5/8 in. x 15 ft. Light Duty (from Home Depot)
  • I am using one of these to go between each timer and sprinkler kit.

Assembly

The key to making all these parts into a solution that doesn’t require me to manually turn the water on or off is Home Assistant. Before we get to the automation part though, below is how I put those parts together and integrated them into my Home Assistant.

Step 0: Home Assistant

If you are reading this and don’t yet have Home Assistant then I suggest checking out Home Assistant Green - here is how they describe it:

Ready. Set. Go. — The affordable Home Assistant Green is the easiest way you can start using Home Assistant. It’s plug-and-play and comes with Home Assistant already installed.

I got one for my parents and it is quite nice and really affordable. If you are in the US, I suggest buying from CloudFree if they have it in stock. It’s a small business that I have bought from several times and really like.

Step 1: Weather Station & Soil Sensor

For me, step 1 happened back when I got the Ecowitt GW2001 Wittboy Weather Station as a gift. I have it connected via the Ecowitt integration. I do not use Ecowitt’s cloud at all. Under “Weather Services” in the Ecowitt’s configuration interface, I use the “Customized” to send data to Home Assistant. I also choose to send my station’s data to Wunderground, which I was able to configure on the same page.

When I got the Ecowitt WH51 Soil Moisture Sensor, I put a battery in each one and it connected right up to my station. For my own sanity, I went into both Echowitt’s interface and Home Assistant’s and renamed the sensor immediately after connecting before adding the second one.

Step 2: A Zigbee Network

Step 2’s prerequisite was me already having the Zigbee Home Automation integration setup. Personally, I use a PoE Zigbee coordinator from https://tubeszb.com/ - I am on my second one (I messed up the first one, no fault of the device) and have recommended them to everyone I know. They are really really good and provide a much more reliable setup than any of the USB based coordinators.

I also use Sengled Smart Plugs to ensure I have a very reliable Zigbee network all around my house. I have two such plugs on the side of the house that has the spigot on the outside.

Step 3: The Spigot and Manifold

Step 3 was to take the manifold outside along with the teflon tape and connect it to my spigot. I used a set of pliers opened up wide to get a good and tight seal between the spigot and manifold after wrapping some tape around the spigot’s threads.

Step 4: Water Timers / Valves, Hose, & Stakes

I took each Timer outside one at a time and put batteries in them. I then held the button down to start pairing and each showed up right away in ZHA. Once each was connected, I screwed it onto the manifold. I then turned the spigot on and made sure I didn’t have any leaks.

I then attached a 15’ long 5/8” light duty utility hose from Home Depot to each. I ran each hose to the bed that would be watered and then used the U shaped garden stakes to keep the hose where I put it.

Step 5: Sprinklers

This all started with my wife finding the Carpathen Drip Irrigation Kits, and assembly ends with putting it to use. I attached the quick disconnect fittings from the timer kit to the utility hose and the 1/2 drip hose after applying some teflon tape. She and I then worked together to lay out the 1/2” hose and then to route all the 1/4” hoses from the junction blocks to sprinklers or to T’s that then have a pair of sprinklers attached. This part is doable solo, but was much easier with a second set of hands. One thing we learned the hard way was that we needed something that would easily cut through the hoses… if you don’t already have something for this, maybe order a hose cutter from Amazon with your other parts or grab one from a local auto parts store.

Step 6: Test Flow and Adjust Sprinklers

Last, but not least in this section was to go and turn the timer on by pressing the button on it. Once water stats flowing you can adjust each sprinkler by loosening or tightening the top of it and/or repositioning it. When finished, turn the water back off.

Note: the timer seems to have a built in turn off function after roughly 10 minutes of being on. This surprised me the first time it turned off, so I thought I’d share.

Automation with Home Assistant

Update 2024-06-29

I have now created a Blueprint that makes it easy to use the automations described below. I have one instance of the blueprint associated with each flower bed. The blueprint also allows you to account for needing to water each bed separately as I have found that there isn’t enough water volume when watering them at the same time. This is accomplished via the Pre-actions section of the blueprint like shown here:

The screenshot shows a 1 minute delay as the first part of the pre-action. This is to give the other instance of the blueprint time to start running. The other instance has similar valve checks for the dahlia bed, but no delay. That one will water first and then this one will water when its finished. If I add a third valve, I may have to change the logic here. On the plus side, you can put any logic you want in this section.

Original Automation Information

We are still tweaking the exact watering frequency and durations, but the automations I setup should work for just about anyone. Here’s the overview of my Home Assistant automation:

The Triggers

Here are the two things that will trigger the automation:

The “41” is a soil moisture reading of 41%. In each trigger I have set an ID so I can reference it in the actions later.

The Conditions

These are the guard rails I have put in to control when the watering happens:

The first condition check to see if the date is an even number. This makes it only water, at most, every other day.

The second condition has two parts, only one of which has to be true.

• The first part checks if it is between 8am and 1pm. This is after everyone is out of bed and before the heat of the day. It also checks to see if a helper I have setup, and will describe shortly, says it is likely to rain or not.
• The second part simply checks it it is between 5:30pm and 7:30pm. This is after the heat of the day and before our kid goes to bed. It does not check the likelihood of rain as the forecast may or may not be right and if it hasn’t rained by 5:30pm then I am fine with doing the watering.

The Actions

If the conditions pass, here is what actually gets done:

The first part sends me a message in Telegram with the name of the bed that is about to be watered. The ID from earlier is how it knows which one to tell me about.

The second part uses the ID from earlier to turn on the sprinkler of the same name.

The third part tells it to wait for 8 minutes on Sundays, which will happen roughly every other week, or for 2 minutes every other day. This makes it so that it is a good soaking once every 2 weeks and a light watering the rest of the time.

The fourth part turns off the sprinkler.

The fifth part sends me a notification again that tells me the watering has ended.

Supplemental Automation

Since my watering is time-boxed, I needed a way to make the sensor readings from the soil sensors update during that time window. What I came up with was simply triggering a reload of the Ecowitt integration:

I set the triggers for this automation to be the same as the beginning of the two time windows in the conditions of the other automation.

Is it going to rain?

When going through the conditions in the first automation, I mentioned having a helper to tell me if it is going to rain. What I have created for this is a pair of “Helpers” in Home Assistant.

The first is a template sensor that gets the hourly forecast for the next 10 hours and records the max percentage chance of precipitation.

The second is a toggle, aka input boolean, that I set via an automation that runs at 7:01am each morning (just after the start of the hour before my first watering time window):

The 10 hour range mentioned just above covers the 7am hour through the 4pm hour. This means the toggle is set before the time window opens and looks ahead until just before the second time window.

Code

The code for all of this is too much to include in a blog post, so I’ve posted it all to GitHub at github.com/genebean/home-assistant-examples/tree/main/automated-plant-watering

Do be sure to see the update above where I converted most of this into a blueprint.

Closing

This has been exciting to setup! I am really looking forward to seeing how it works this year, and maybe expanding the setup to cover a few more areas. One idea I have for the future is to use one of these timers on a rain barrel for some plants that are a little farther from my house… if that happens I’ll try to remember to post about it too.

In Home Assistant 2024.4, this note was in the “Backward-incompatible changes” section of the release announcement

The previously deprecated forecast attribute of weather entities, has now been removed. Use the weather.get_forecasts service to get the forecast data instead.

(@gjohansson-ST - #110761) (documentation)

I had a heck of a time finding docs on this, so I have compiled what I did here.

Base weather integration

I am using the Tomorrow.io integration to get forecasts, but what I have done should work with any weather provider.

Current Conditions from Weather Station

I have made a custom weather entity that pulls current conditions from the weather station in my back yard and forecast data from the Tomorrow.io integration. The integration is known on my system as weather.tomorrow_io_leaky_cauldron_daily.

Custom Sensors

To make this work, I first needed to make sure my configuration.yaml contains this line:

template: !include templates.yaml

I then edited templates.yaml and added this:

- trigger:
    - platform: time_pattern
      minutes: /15
  action:
    - service: weather.get_forecasts
      data:
        type: hourly
      target:
        entity_id: weather.tomorrow_io_leaky_cauldron_daily
      response_variable: hourly
    - service: weather.get_forecasts
      data:
        type: daily
      target:
        entity_id: weather.tomorrow_io_leaky_cauldron_daily
      response_variable: daily
  sensor:
    - name: Weather Forecast Hourly
      unique_id: weather_forecast_hourly
      state: ""
      attributes:
        forecast: ""
    - name: Weather Forecast Daily
      unique_id: weather_forecast_daily
      state: ""
      attributes:
        forecast: ""

This creates two sensors: one with the hourly forecast data and one with the daily forecast data.

Custom weather entity

Next, I needed to return to configuration.yaml and add this:

weather:
  - platform: template
    name: "Home + Tomorrow.io"
    unique_id: home_plus_forecast
    condition_template: ""
    temperature_template: ""
    temperature_unit: "°F"
    humidity_template: ""
    attribution_template: "Home weather station + Tomorrow.io"
    pressure_template: ""
    pressure_unit: "inHg"
    wind_speed_template: ""
    wind_speed_unit: "mph"
    wind_bearing_template: ""
    forecast_hourly_template: ""
    forecast_daily_template: ""

The parts of this that have weather.tomorrow_io_leaky_cauldron_daily in them are pulled from the Tomorrow.io integration while the parts that start with sensor.outdoor_weather_station are pulled from the Ecowitt integration that equates to my weather station.

The result of this is shown below:

1. Service reads an authorization url from the podcast’s rss feed
2. Service generates a onetime token
3. Service calls authorization url with token & rss feed as parameters
4. Website hosting authorization url verifies it’s the home / host of the feed
5. Website has user log in
6. Website presents user a confirmation page
7. If user confirms, website inserts the token into the <podcast:txt> tag
8. Website publishes updated rss feed
9. If website supports it, it sends a podping to notify watchers of the updated feed
10. Website sends a success response if the feed is updated and a failure response otherwise

User interaction is done at this point. The service still needs to see the updated feed, but that is beyond the bits I want to talk about here.

This entire flow could be integrated into PowerPress and be completely transparent to the user who installs the plugin in WordPress. Nothing about this flow requires the user to configure anything they haven’t already configured if running PowerPress today because:

• PowerPress already knows what podcast(s) it is hosting
• PowerPress already manages xml tags within the rss feed for the podcast(s) it hosts
• WordPress already knows how to authenticate someone before allowing them to get to any administrative pages
• WordPress plugins have the ability to create new REST API endpoints (see the WP OAuth Server plugin for an example of this)

Given that to operate PowerPress a user must already know how to log into WordPress, this can be a seamless enhancement to PowerPress if it implements the following:

• a new REST API endpoint that would be called by the service mentioned above. It would need to receive and process the parameters defined in the podcast namespace’s specification.
• an administrative page that is presented as the confirmation dialogue. This page would have to process both an affirmative response and a disapproval response from the user
• the insertion of the provided token in the <podcast:txt> tag
• the sending of the success or failure response to the requesting service

Every other aspect of this flow already exists in PowerPress or WordPress itself.

If PowerPress adds this functionality, the user gains the ability to prove they own a podcast by doing nothing more than having an up-to-date PowerPress plugin installed, logging into WordPress, confirming they want to proceed, and waiting for the updated feed to be seen by the service.

I don’t think it can get much easier than that.

At first, it seemed that it had somehow gotten zapped (aka hit by a power surge). Upon digging a little more into the device I found that I could power it via a USB cable. Interestingly, that not only made the device boot up, but also made the ethernet connection work again. This seemed odd because I’d think that anything that fried the PoE aspect of it would have fried the entire ethernet board. With that in mind, I started poking around on my UniFi switch and noticed that there was a power setting for the port that said “off” where the others said “PoE+.” I removed the usb power cord from the coordinator, crossed my fingers, and toggled the setting back to “PoE+.” Amazingly, all was well!

The really odd part to me was that my UniFi access points that are also powered by the same switch were fine. My best guess as to what happened is that the antenna on the coordinator attracted some of the electricity in the air from the nearby lightning strike and the switch protected itself (this is a total guess though). Regardless of how it happened, I know two things now that I didn’t before finding this setting:

• all my equipment survived the storm
• if ever I have another device that won’t power up that was working via PoE, I should check this setting

Here’s hoping I don’t have a reason to need to remember this anytime soon!

Just in case…

Going on the assumption that my theory of what happened is even remotely possible, I am seriously thinking about getting a Ethernet Surge Protector from UniFi to put in-line between my coordinator and the switch. They are only $12.50 and seem well worth it. The catch is that I am going to have to have a drain wire installed so that there is a place for any absorbed surge to go. I already have plans to have a contractor I know out soon to do some other work so I will ask him about doing this too. If it isn’t cost prohibitive I am going to move forward with the extra protection of my equipment.

I’m seriously considering redoing my Home Assistant setup from scratch now that I know what we actually use and what’s just cruft… anyone else done this?

As expected, there were a variety of opinions. Surprisingly though, there was an overwhelming consensus that redos after having used Home Assistant for a whe were a good thing.

After reading all the comments and thinking about things more, I’ve decided I want to download all my backups, copy out several bits of yaml, export some other settings, and then take the plunge. In my “Introducing My Home Assistant Setup” post I said I’d be following up with one that breaks down all my automations. This new decision is going to delay that a bit. Instead, I’m going to start by chronicling my journey through rebuilding my setup.

Prep Time

Before I actually wipe everything and start over I need to do some prep work. This includes:

• analyzing what bits we actually use
• downloading all my backups
• screenshotting everything so I can reference it later (dashboards, integrations list, add-on list, etc)
• exporting the yaml of each dashboard
• exporting the yaml of each automation and script
• exporting all of my config files
• screenshotting and exporting all of my Node-RED flows
• exporting all the yaml from my ESPHome devices
• exporting any needed bits from my Tasmota and WLED devices
• exporting settings from my addons

Naming is Hard

I’m also going to take some time and define a new naming convention for everything while I can still see a full list of devices. I’ve found that having well named devices makes so many things simpler, especially dashboarding.

Next Steps

After doing all the backups, my plan is to wipe everything and reinstall Home Assistant OS. I already boot my Pi from an external drive, but the process for doing so has changed since I set things up. For this reason, I plan to double check everything to ensure I’m following current best practices, which may mean I have to utilize Raspberry Pi OS as an intermediary step for firmware updates.

Once Home Assistant is reinstalled I’ll start adding devices and automations back slowly and methodically. This methodical process may well result in wanting to reset things an additional couple of times, and that’s okay. I’d much rather have a little extra down time now than be unhappy after everything has been added back in.

A couple of extra changes

Changing Zigbee Software

One planned change in particular might be the cause of some redos: I’m going to be switching from ZHA (Zigbee Home Automation) to Zigbee2MQTT (z2m). Though I’ve used both before, I didn’t discover z2m until after I’d set everything up at home. I like it a lot more and think I’ll put it to use as part of the redo.

Adding Z-Wave

We’ve also been planning to start using a couple of Z-Wave devices and I think now is the time to finally do so. As part of this, I’m thinking I’ll use the Z-Wave JS to MQTT add-on. It won’t surprise me any at all if I need to try a few different times to get things just right.

Timing

I’m planning to do all the prep in the next few days and the actually kick off the redo. I’m strangely looking forward to this.

How it started

In September of last year I bought an Aqara Water Leak Sensor off Amazon. I placed it between my washing machine and hot water heater in the garage and connected it to Home Assistant via ZHA (Zigbee Home Automation) integration and my Zigbee Coordinator. I then added it to a dashboard that shows me information about the garage and the status of my washer and drier. Finally, I tested that the sensor worked as advertised and that the proper state showed in Home Assistant. Everything checked out… yay for being proactive!

Uh-oh…

Fast forward to the first Friday of February. My wife is on her way to her car in our garage. When she starts down the stairs from our kitchen she hears an odd noise and sees a lot of water on the floor. The water is a concern, but not totally unexpected as our garage has flooded before and it had been raining hard. The odd noise and the fact that there is steam in our garage while it’s somewhere around freezing outside is actually much more disturbing. She looks out back and sees that our sump pump is still working, which means it’s likely not the issue we’ve had before. At this point calls me and tells me what she sees and then goes back to investigating.

After getting dressed appropriately, I head down and am equally confused and perplexed. We determine that the steam and noise are coming from behind the washer and drier so I decided to climb atop our drier to get a better look. It turns out both are the result of a leak in a plumbing joint near where the hot water hose connection for our laundry is: high pressure hot water is spewing from the joint. A moment or two later we find the shutoff valve for where water goes into our hot water heater and turn it off. The leak stops and we can start assessing what’s happened and the damage.

Having had leaks before, one of the first things that comes to mind is “what is this going to cost us?” It’s about this time that I remember two things:

1. I have a leak detector sitting in the flooded area, which means I should be able to determine how long the water has been pouring out into the floor. This will help satisfy some the curiosity related to “is this going to be expensive.”
2. I never set up any alerts to tell me when the sensor detected a leak… 🤦‍♂️ Yeah… oops.

I opened up the Home Assistant app on my phone and pulled up the sensor. It had, indeed, worked as designed and clearly showed that the leak started at about 11:30pm the night before… it was currently about 7:30am.

It’s at this point that I’m really wishing I hadn’t forgotten to have Home Assistant tell me if the sensor detected water. I set a reminder on my phone to rectify that later in the day and then start removing the water via a push broom (they are surprisingly good at this task, by the way). After moving some things to dry ground and pushing lots of water out the door of our garage, the immediate crisis is over. Now to figure out the root cause and get it fixed.

Keihan to the rescue!

We are blessed to know an amazing gentleman named Keihan who is a General Contractor and operates his own business focused on residential repairs and upgrades. He and his crew have done almost every bit of work to our house since the day we bought it. So, naturally, my first call after getting the standing water out of our garage was to him. I left a voicemail with all the details about what was going on that morning, and included that I had noticed some sporadic high pressure in our faucets recently.

After checking things out, Keihan determined that the water heater itself was the likely root cause of both the high pressure that periodically showed up in my faucets and in what caused the leak. We made a plan to replace it on Monday and to collect some data over the weekend about the water pressure in my house via a mechanical gauge he attached to the spigot where our water hose would normally be connected. The gauge had an extra needle that would record how high pressure spiked. Keihan asked me to check it periodically and let him know if it spiked much.

All the pressure

A few hours later, I noticed that the pressure had spiked to about 90 PSI. Street pressure is only about 80 PSI and the regulator for the house is less than that, so this was a little concerning to us both. I dialed the observation needle back down to the current pressure so that we could see if this was a one-off spike or if there was a pattern. I checked again around 8pm and was greeted with this:

I sent Keihan this photo showing that the pressure had spiked to nearly 120 PSI and he decided we shouldn’t wait until Monday as this much pressure could easily expose other weak areas in my house’s plumbing. He said he’d be out the following morning, Saturday, to replace the hot water heater. Did I mention that he’s awesome?

Water heater time

Saturday morning came and so did Ro, a long time employee of Keihan’s. Ro got right to getting the old water heater drained and prepped for removal. A little bit later, Keihan arrived with the surprisingly hard to acquire new water heater. You see, it was supposedly in stock at the local big box home improvement store… but no one could find it. The next closest store showed to have three of them, so it was off to there. Apparently they were having some inventory difficulties too as it took them an entire hour to find even one unit. Fortunately, they did find it. At any rate, the new hot water heater was at my house and they were ready to get it installed. The old one had well exceeded its life expectancy (which is something I didn’t know I needed to watch for) and had developed significant amounts of rust that was already starting to clog the attached pressure tank. One thing was for certain after seeing all the rust and learning the age of the old water heater: it may or may not be the only problem, but it was for sure some of it and truly needed replacing.

More monitoring

With the new water heater installed and all the air flushed from the lines, all that was left was to keep an eye on the gauge to see if the issue was fully fixed or just partially fixed. The following day, Sunday, I checked the gauge and, sadly, it had spiked above 120 PSI. I let Keihan know and he said Ro would be out the following day to replace the house’s pressure regulator.

Monday

Monday came and so did Ro. He let me know that water was going to be cut off to the house for a little while and then went to work. In what seemed like no time, he was back at the door letting me know he was all finished.

Thankful

I have said it before, and I will say it again: I am really thankful that we have access to such a good and reliable contractor. By lunch on Monday everything had been completed and life could return to normal.

But what about those missing alerts?

The last thing I want is to have a repeat of the 🤦‍♂️ moment where the reason we didn’t know about a water leak was that I had simply neglected to make Home Assistant tell us. Thus, it was time to create a new automation.

I though about what I really wanted this alert to do and came up with this as a baseline: it should alert us in a way that we won’t miss, regardless of the time of day or night that it goes off, and regardless of us being home or away. There is one catch to this: it also should not terrify my toddler.

“SOS - Water detected in garage”

Enter my new Home Assistant automation entitled “SOS - Water detected in garage.” This automation is triggered any time the leak sensor has been wet for at least one minute. The delay is simply to avoid false alarms and to allow enough time to quickly pick the sensor up if something is spilled near it.

If triggered, the following actions are taken in order:

1. Text messages are sent to my wife and I via Twilio that simply say “Leak detected in the garage.”
2. Turns on overhead lights. This includes pretty much every light switch in the house that is not in our toddler’s room.
3. Turns off overhead lights
4. Turns on overhead lights
5. Sends a “critical” notification to my wife and I via the Home Assistant app that is installed on each of our phones. This alert contains the text “Water has been detected in the garage” and plays an audio clip with the same message. Of note here is that critical alerts are never silenced, show up on Car Play, and show at the top of your list of alerts.
6. Sets the volume of the Sonos speakers in our bedroom, kitchen, and living room to 30% and combines them into a groups
7. Uses text to speech (TTS) to speak “Attention, attention, attention, a sensor in the garage near the washer is wet”
8. Wait 10 seconds
9. Repeat steps 2-8 up to thirty times

Right now, to make it stop you’d have to go find the automation and turn it off. I plan to improve this by making the notification to our phones “Actionable.” This will allow us to acknowledge the alarm from the notification. Upon acknowledgment the actions listed above will cease.

Another sensor and reliability enhancement

One thing that was added as part of getting the new hot water heater was a pan beneath it that is intended to catch water in certain scenarios and route it to a safe place. This is great, but also means that the leak sensor sitting next to my washer is no longer sufficient to tell me about everything I’d like to keep an eye on. The solution: add a second leak sensor.

I hopped back on Amazon and ordered another Aqara Water Leak Sensor to place in the pan under the water heater. The only problem with this plan is that the pan is metal… and metal is great at blocking or interfering with wireless signals. To combat this, I also picked up a SONOFF S31 Lite 15A Zigbee Smart Plug. This plug acts as a Zigbee router, which means that if it were to be plugged in near the sensors then they’d have a strong signal even with the pan causing interference. It just so happens that I had an open place for such a plug in an outlet under my work bench about 10 feet away.

Both the sensor and the plug have come in and have been added to my Home Assistant setup. The new sensor has also been added to the automation that watches for leaks. Here’s to hoping that that automation doesn’t ever actually need to be triggered.