Home Assistant - Stale & Unavailable Devices Cleanup#

This checklist tracks all stale, orphaned, and currently unavailable entities in Home Assistant grouped by physical/virtual device. Use the interactive checkboxes (- [ ]) to track your manual cleanup in the Home Assistant UI or via SSH.

Summary Stats:

• Total Devices / Groups: 5
• Total Affected Entities: 21
• Stale Restored Entities (Registry Orphans / Deprecated): 10
• Currently Unavailable Entities (Offline Hardware / Connection Loss): 11

Cleanup Methods#

1. UI Deletion (Recommended for Stale / Orphaned Entities):
   • Go to Settings > Devices & Services > Entities.
   • Filter by Status: Restored / Unavailable or search the entity ID.
   • Select the checkbox next to the entity and click Delete Selected (red button at top).
2. Device / Integration Reconfiguration:
   • If an entire device is decommissioned (e.g. old Meross Coop Door opener replaced by ESPHome), go to Settings > Devices & Services > [Integration] > Devices, click the 3 dots on the device card, and click Delete.
3. Companion App Cleanup:
   • On mobile devices, disable unused tracking sensors in HA App Settings > Companion App > Manage Sensors to remove them cleanly.

1. Meross Smart Plugs, Switches & Openers (1 Devices, 2 Entities)#

• Garage Driveway Lights (Meross Dimmer) (Garage — 2 entities — Unavailable / Offline)
  • light.garage_driveway_lights_meross_dimmer — Garage Driveway Lights (Meross Dimmer) (light) — 🔴 Offline / Unavailable
  • sensor.garage_driveway_lights_meross_dimmer_signal_strength — Garage Driveway Lights (Meross Dimmer) - signal_strength (sensor) — 🔴 Offline / Unavailable

2. Aqara, Zigbee & Matter Sensors (3 Devices, 17 Entities)#

• Aqara Motion Sensor (No Area — 5 entities — Stale Restored)

1 Meross Ghost Entity & VLAN Routing Fix#

1.1 The Issue#

When deleting and re-adding a Meross device, Home Assistant might refuse to connect and continuously restore the old ghost entity name while throwing a KeyError and AttributeError: 'NoneType' object has no attribute 'attach' in the logs.

1.2 Why it happens#

1. The Registry Ghost: When a device is deleted from the UI, Home Assistant sometimes keeps its UUID permanently trapped in the hidden deleted_devices and deleted_entities recycle bins inside the .storage registry. Whenever you re-add the device, HA automatically restores the old, corrupted data.
2. The Cloud Profile Cache: The meross_lan integration caches the Meross Cloud Profile. If you re-add a device to the Meross app, meross_lan may still use an expired offline cache (e.g., meross_lan.profile.xxxxxx) which lacks the new UUID or MQTT keys, causing a KeyError.
3. The VLAN Block: If Home Assistant is on a different VLAN than the IoT devices and HTTP (Port 80) is blocked, meross_lan cannot push the local MQTT configuration to the new device, leaving it “Unavailable”.

1.3 The Complete Fix & Automation Script#

Target SSH Host: root@10.1.2.200

🏠 Homelab Device Management#

1. Executive Summary & Architecture#

This document defines the Single Source of Truth (SSOT) Device Management Architecture for the Homelab environment.

To optimize speed, usability, and data integrity:

1. Google Sheets serves as the Primary User Entry Interface. Adding or editing devices in the spreadsheet is fast, accessible on mobile/desktop, and requires zero complex IPAM UI navigation.
2. NetBox (v4.2) serves as the Automated IPAM & DCIM System of Record. It is hosted on 10.1.2.202:8082 and reconciled directly from Google Sheets via terminal alias.

flowchart LR
    A["Google Sheets (User Entry)"] -->|Mac Studio Alias: netbox| B["sync_gsheets_to_netbox.py"]
    B -->|Non-Destructive Delta Sync| C["NetBox v4.2 (10.1.2.202:8082)"]
    C -->|API & Interoperability| D["UniFi UDM / Home Assistant / Pi-hole"]

2. Standard Operating Procedure (SOP) for Device Management#

A. Adding or Editing Devices#

1. Open the Google Sheet inventory (Devices tab).
2. Add or edit any row (Location, Name, Serial, MAC, IP, Type, Brand).
3. Open your Mac Studio terminal and type:

   netbox

4. Outcome: The script fetches your spreadsheet, securely sends the inventory to NetBox on 10.1.2.202:8082, and updates your network records in seconds.

B. Retiring or Deleting a Device#

• Option 1 (Archive / Keep Record): Change the Location column in Google Sheets to Z-Inactive.
  • Behavior: The sync script automatically skips all Z-Inactive rows during import, removing the device from active NetBox IPAM while preserving historical records in your spreadsheet.
• Option 2 (Permanent Delete): Delete the row from the Google Sheet and run netbox.

3. Work Completed#

During the system implementation, the following key engineering milestones were achieved:

Master Plan: UNAS Pro SMB Usage Inventory#

This document outlines the proposed step-by-step strategy to perform a comprehensive audit and inventory of all workloads, computers, virtual machines, Docker stacks, and scripts utilizing SMB shares from the UNAS Pro (10.1.2.2) NAS.

HP6_UNAS_Pull_Backup.sh is the current backup script for HP6TrueNAS (10.1.1.16). HP1Cloud is the current name for VM 217 at 10.1.2.219. HP8_UNAS_Pull_Backup.sh is retained as the legacy filename for the active HP7TrueNAS pull job.

UniFi UNAS-Pro Pool Migration Strategy: Pool 1 (SSD) to Pool 2 (HDD)#

This document defines the operational plan, safety protocols, database update queries, and verification steps to migrate all shared folders from Storage Pool 1 (SSD - Degraded RAID5) to Storage Pool 2 (HDD - Healthy RAID5) on the master UniFi UNAS-Pro NAS (10.1.2.2) while preserving all access rights, Samba configurations, and TrueNAS backup operations.

The checked commands in this historical migration record now use the current identity HP6TrueNAS at 10.1.1.16; the node was formerly HP7TrueNAS at 10.1.1.17.

📜 Scripts Management#

Workstation Sync Shortcut: To automatically backup all your scripts and custom terminal aliases configuration (staging and pushing your entire ~/Scripts/ repository):

pushscripts

This will stage all modified files in ~/Scripts/, commit, and push updates directly to GitHub and your NAS (without running Homebrew operations).

MCP Configuration Sync: MCP configuration is maintained in a separate repository, ~/.mcp-config, linked to git@github.com:marcoue/MCP-Config-MacOS.git. Use:

pushmcp   # Commit selected MCP master files, compile through the post-commit hook, and push to GitHub
pullmcp   # Pull MCP changes; the post-merge hook recompiles client configurations

These commands do not operate on ~/Scripts and do not replace pushscripts or pullscripts.

UniFi UNAS-Pro Master Backup Strategy: Native Rsync Daemon (Pull) Architecture#

This document defines the complete operational standard, architecture, schedule matrix, node-by-node configuration reference, and disaster recovery procedures for backing up all shared data from the master UniFi UNAS-Pro NAS (10.1.2.2) across the fleet of 5 TrueNAS SCALE storage nodes (HP1, HP2, HP3, HP6, HP7). It is designed to be sufficient to fully reconstruct the entire setup from scratch.

The former HP7TrueNAS node (10.1.1.17) is now HP6TrueNAS. The storage dataset, SMB shares, and backup script have been renamed to the HP6 identifiers.

Scripts Management Migration Plan#

This document is the master architectural migration plan for establishing /Users/marc/Scripts as your primary local master Git repository, linked to git@github.com:marcoue/Scripts.git, with automated mirroring to the UNAS-Pro NAS (/Volumes/Software/Software/Scripts/) and automated pull execution by remote TrueNAS/Linux/Proxmox nodes.

1. Executive Summary & Architecture Goal#

🎯 Primary Master Architecture#

1. Master Repository: /Users/marc/Scripts on your Mac SSD is your primary master repository for editing, testing, running, and managing all homelab scripts.
2. GitHub Remote: Linked to git@github.com:marcoue/Scripts.git on branch main.
3. Automated NAS Mirroring: A Git post-commit hook automatically syncs committed scripts from ~/Scripts/ to /Volumes/Software/Software/Scripts/ on UNAS-Pro.
4. Remote Server Pull Execution: Remote servers (HP1, HP2, HP3, HP7, HP8, Proxmox, Linux) pull their scripts from UNAS-Pro (Software/Scripts/) on their scheduled runs.

🔄 Data & Deployment Flow#

  [Mac Workstation] (Primary Master Workspace)
   └── ~/Scripts/ (git@github.com:marcoue/Scripts.git)
        ├── MacOS/
        ├── Linux/
        ├── Proxmox/
        └── TrueNAS/
             │
             ├── (git commit)
             ▼
        [Git post-commit Hook]
             │
             ├── (rsync auto-mirror)
             ▼
  [UNAS-Pro Master NAS] (Distribution Mirror)
   └── /Volumes/Software/Software/Scripts/
        ├── MacOS/
        ├── Linux/
        ├── Proxmox/
        └── TrueNAS/ (Exposed as Rsync Module: root@10.1.2.2::Software/Scripts/TrueNAS/)
             │
             ├── (Rsync pull on schedule)
             ▼
  [Remote Nodes: HP1, HP2, HP3, HP7, HP8, Proxmox, Linux]
   └── Local Execution of Version-Controlled Scripts

📂 1.1 Filesystem Standard & Disaster Recovery Protocol#

1. Standard POSIX Filesystem Path:
   • The destination path /Volumes/Software/Software/Scripts/ (and subfolders MacOS/, Linux/, Proxmox/, TrueNAS/) is a standard, plain-text directory tree residing on the mounted Software SMB share (smb://10.1.2.2/Software). There are zero proprietary databases, hidden hooks, or custom file structures on the NAS.
2. Mac Auto-Mount Convenience (Login Items):
   • To ensure the SMB share is always available for Git post-commit auto-mirroring, add /Volumes/Software to macOS System Settings > General > Login Items.
3. macOS Reinstall / Disaster Recovery:
   • Reinstalling or replacing macOS on your Mac Studio has zero effect on UNAS-Pro or TrueNAS servers. The NAS files remain intact, and TrueNAS backup cron jobs continue executing without interruption.
   • To restore your Mac workstation repo after a fresh macOS install:

     # Step 1: Clone master repository from GitHub
     git clone git@github.com:marcoue/Scripts.git ~/Scripts
     
     # Step 2: Re-install 1-line Git post-commit auto-mirror hook
     cat << 'EOF' > ~/Scripts/.git/hooks/post-commit
     #!/usr/bin/env bash
     if [ -d "/Volumes/Software/Software/Scripts" ]; then
         rsync -av --delete --exclude='.git' --exclude='*.log' /Users/marc/Scripts/ /Volumes/Software/Software/Scripts/
     fi
     EOF
     chmod +x ~/Scripts/.git/hooks/post-commit

2. Complete Script Inventory & Mapping#

The following table lists all existing scripts found across your NAS repository (git@github.com:marcoue/Scripts.git) and local Mac folder (~/Scripts/), mapped to their final category subfolders:

UNAS-Pro Backup Migration Plan: SMB (Push) to Native Rsync Daemon (Pull)#

Antigravity Chat: agy –conversation=4c0c9b6d-2722-4fd6-a4aa-638c75ab46f4

This document is the complete master migration plan for transitioning the UNAS-Pro backup strategy from the UniFi Drive UI-managed SMB (Push) setup to a Native Rsync Daemon (Pull) model.

Because the UniFi Drive UI natively supports Rsync server settings and shared folder modules, migrating to Rsync requires configuring your TrueNAS SCALE servers (HP1, HP2, HP3, HP6, HP7) to pull the backups directly from the UNAS-Pro Rsync daemon over TCP port 873.

Complete UniFi Firewall Rules Architecture & Security Analysis#

VERDICT: [VERIFIED] EXCELLENT HARDENING & ZERO CONFLICTS FIREWALL AUDIT SCORE: 98 / 100 (Grade: A+) A comprehensive, empirical audit of all Linux kernel firewall chains (iptables and ipset) on the UniFi Dream Machine Special Edition (UDM-SE) confirms that your network firewall architecture is correctly ordered, free of logic errors or shadowed rules, and effectively enforces zero-trust boundaries between untrusted endpoints, corporate work devices, server clusters, and management interfaces.