Mastering Matter: Seamless Smart Home Integration with Network Segmentation

I’ve been intrigued by the idea of integrating devices with Matter for some time. My smart home setup includes a pair of SwitchBot Hubs, some Govee lights, and an air purifier. Each of these devices comes with its own dedicated app, and while some offer integration with Home Assistant, the process often comes with limitations—such as requiring devices to be connected to the main network.

The primary reason I hadn’t yet migrated these devices to Matter was my desire to maintain network separation for IoT devices, even when using Matter.

Network Segmentation Challenges

Previously, I set up an IoT VLAN where devices on this virtual network are isolated from the main network. Devices like my phone, computer, and Home Assistant server, which are on the main network, can still access the IoT VLAN. However, this setup presented a few hurdles for Matter integration:

1. IPv6 Requirement: I hadn’t enabled IPv6 on the IoT VLAN to reduce the attack surface for potential network threats. Unfortunately, Matter requires IPv6 for communication, so enabling it became a necessity.

2. Local Network Limitation: Home Assistant’s Matter implementation only scans the local network for devices. Since my Home Assistant server resides on the main network, it couldn’t detect Matter devices located on the IoT VLAN.

First Attempt and Challenges

I explored solutions, including this guide on setting up Home Assistant across multiple VLANs. While I managed to connect Matter devices to Home Assistant, this configuration caused my non-Matter devices to become unavailable. Upon inspection, I realized that Home Assistant had designated the IoT VLAN as its default network. This occurred because Home Assistant appears to sort networks by IP subnet, and my IoT VLAN (10.0.15.0/24) was prioritized over my main network (172.16.1.1/24).

Given that the IoT VLAN blocks connections to other networks, this default setting broke many of my integrations. Frustrated, I reset the virtual machine to its previous state and decided to revisit the problem later.

Seamless Local Control: Integrating WeatherFlow with Home Assistant Across VLANs

I've been pleased with my Home Assistant setup for some time now. One of my main focuses has been achieving local control. This ensures reduced latency for device commands and maintains functionality for state updates and commands even without an internet connection.

I've successfully transitioned many devices to local control using Zigbee, Z-Wave, and ESPHome, but not all integrations have been straightforward. A notable exception has been the WeatherFlow integration for my Tempest weather station.

WeatherFlow offers two types of integrations. The first relies on the cloud, where the weather station sends data to the Tempest cloud service, and the WeatherFlow cloud integration then pulls this data into Home Assistant at intervals.

The second method utilizes the fact that the Tempest weather station broadcasts weather state changes via UDP on the local network. The local WeatherFlow integration in Home Assistant listens for these broadcasts. However, my setup had the Tempest weather station on a different network VLAN than my Home Assistant server. Since UDP broadcasts typically don’t cross VLAN boundaries, this local integration wasn’t working.

I had multiple reasons for placing the Tempest weather station on a separate VLAN. Primarily, the default behavior of sending frequent UDP broadcasts can lead to significant network traffic, especially impacting wireless networks. Additionally, I segment my network for security purposes, preventing devices on the Tempest's VLAN from scanning or connecting to computers on more secure VLANs.

Unlocking Raspberry Pi Potential: Navigating Network Booting Challenges for Enhanced Performance and Reliability

I've set up several Raspberry Pis around our house for various projects, but one recurring challenge is the potential for SD card failure due to heavy file system writes. To mitigate this, I've transitioned some of my Raspberry Pi 4s to boot from USB drives, but this limits compatible cases.

Backing up these SD cards or USB drives can be cumbersome, yet essential in case of failure. Recognizing that Raspberry Pis since the 3 B model can boot from the network, I decided to utilize my Proxmox server to host the boot server.

Initially, I explored Piserver, the official solution from the Raspberry Pi Foundation. Setting it up involved creating a VM and booting from the Raspbian distribution iso. While it provided a straightforward interface for booting devices from the network and selecting distributions, it fell short of my needs.

Empowering Your Home's Power Protection: A Deep Dive into UPS Monitoring and Integration

Our household relies on several Uninterruptible Power Supplies (UPSs) to safeguard our network equipment and computers. A crucial aspect of maintaining these UPSs is monitoring their batteries to determine if they need replacement.

For UPSs located near desktop PCs, monitoring battery status is straightforward. These UPSs can typically be connected via USB, allowing us to use monitoring software to check battery health.

However, monitoring UPSs situated in network racks is more complex. Some UPSs only offer serial or USB ports, requiring a computer to directly connect and retrieve battery status. Alternatively, certain UPSs feature a network port and cloud connectivity, enabling them to upload status data to the cloud for remote viewing.

We have an APC UPS with cloud connectivity, which facilitates notifications for significant status changes through their Smart Connect service. Despite its benefits, this solution has drawbacks for our specific needs. Firstly, there's no integration with Home Assistant, preventing us from automating devices based on UPS status, such as shutting down devices during power outages when battery levels drop below a certain threshold. Secondly, reliance on a cloud connection means that if our internet goes down, the automations wouldn't function.

Empowering Family Legacy: How I Transitioned to Self-Hosting with Gramps Web

For several years now, I've been maintaining a genealogy website containing information from both my and my wife's family history. One of my main objectives has been to ensure this wealth of information is readily accessible not just for our extended family, but also for our children whenever they want to look into their roots.

 Initially, I hosted this website through a paid hosting service, utilizing TNG. While this setup served its purpose adequately, my recent acquisition of a Proxmox server prompted me to explore the possibility of self-hosting. Given this shift, I decided to transition to open-source software, as it would grant me greater flexibility in making adjustments as needed.

In my search for suitable open-source genealogy software, I came across Gramps Web. Its user-friendly interface and compatibility with the Gramps genealogy desktop software caught my attention.

Mastering NAS Storage: Unveiling Hidden Challenges and Solutions

Today, I'm diving into a little adventure I recently had with our trusty 6-drive Synology NAS, boasting a whopping 73TB of storage space. Now, who wouldn't be excited about that, right? But there are some challenges.

I couldn't help but notice that our storage space was getting full. Curious, I delved deeper into the matter. One of the primary functions of our NAS is serving as storage for our Plex DVR. However, despite our occasional recordings, the storage was filling up faster than I expected.

So, I decided to do some spring cleaning, starting with deleting some recordings. But here's the kicker - the space wasn't budging. I decided to peek into the file system, and there it was: a bunch of files in the #recycle folder within our shares.

Turns out, there wasn't a default schedule for emptying the recycle bin on our Synology NAS. This meant all those recordings, along with any other files, were being kept indefinitely.

Unlocking Seamless Integration: Navigating Unexpected Hubitat Device Queries and VLAN Challenges for a Smoother Home Automation Experience

During my network debugging efforts, I came across an intriguing observation related to the two Hubitat devices on our network. The logs below illustrate the unexpected mDNS queries they generated:

1. Query for Airplay Devices

12 0.788177995 192.168.55.11 → 224.0.0.251 MDNS 130 Standard query 0x0000 PTR _airplay._tcp.local, "QM" question PTR Hubitat._hubitat._tcp.local

2. Query for web servers:

14 0.791018733 192.168.55.11 → 224.0.0.251  MDNS 127 Standard query 0x0000 PTR _http._tcp.local, "QM" question PTR Hubitat._hubitat._tcp.local

Surprisingly, the Hubitat devices were seeking Airplay and web server devices, even though I only utilized them for Z-Wave and Zigbee devices, and have not installed the Airplay application. This behavior caused issues, as the queries and responses were transmitted across VLANs, leading to a flood of broadcast packets during high query volumes.