Server Inventory Methodology#

Purpose#

This method is used to create a complete, insurance-focused physical hardware inventory for every server. Every server must use the same collection order, the same checks, and the same note structure. A server is not considered complete because one source was inspected; all three methods must be attempted.

The inventory covers the physical server and its replaceable or insurable components only. Virtual machines, containers, software configuration, operating-system runtime metrics, temperatures, link state, drivers, PCI addresses, and firmware details are excluded unless they directly identify an insurable hardware component.

Home Assistant Database Management Project Plan#

First establish safe Recorder purge and repack settings. Then create and validate an export target for historical Home Assistant data.

Keep approximately 30 days of detailed history locally. Complete and verify the Recorder maintenance setup before starting the export work.

1. Configure Recorder Purge and Repack#

• 1.1 Set purge_keep_days to 30.
• 1.2 Enable auto_purge.
• 1.3 Enable auto_repack.
• 1.4 Validate the configuration and restart Home Assistant if required.
• 1.5 Confirm that automatic purge and repack are active.
• 1.6 Confirm that the database remains within the 30-day retention period.
• 1.7 Confirm that sufficient free space remains for maintenance operations.

Do not begin the export-target work until the Recorder purge and repack settings have been configured and verified.

GenDash Folder Migration#

1. Preparation & Freeze#

• 1.1 Create the new project folder at /Users/marc/Xcode/GenDash.
• 1.2 Confirm the destination folder is empty before copying the project.
• 1.3 Close Xcode and any other application that may be watching or editing the project.
• 1.4 Confirm there are no unsaved changes in source files, localization worksheets, or documentation.
• 1.5 Record the current Git branch and working-tree status.
• 1.6 Resolve or document the current Git file-watcher warning before relying on the status check.

2. Copy the Project#

2.1 Complete Copy#

• 2.1.1 Make a complete filesystem copy of the project into /Users/marc/Xcode/GenDash.
• 2.1.2 Preserve the .git directory, hidden files, package directories, symlinks, file permissions, and localization bundles.
• 2.1.3 Preserve the Xcode project, workspace, app source, widget source, resources, entitlements, property lists, documentation, scripts, and localization files.
• 2.1.4 Keep the original project folder unchanged as a rollback copy.

2.2 Copy Verification#

• 2.2.1 Confirm the copied repository contains GenDash.xcodeproj and its workspace.
• 2.2.2 Confirm the copied repository contains both the GenDash app target and GenDashWidget extension target.
• 2.2.3 Confirm the copied repository contains the GenDash Localizations, Images, Appliances, Generators, Manuals, and scratch folders.
• 2.2.4 Confirm the copied repository contains AGENTS.md, .agents, MISSION.md, .gitignore, and the string catalogs.
• 2.2.5 Confirm the copied .git directory identifies the same repository, branch, and remote configuration.
• 2.2.6 Confirm the original project remains unchanged after the copy.

3. Xcode Relocation Validation#

3.1 Project References#

• 3.1.1 Open the copied GenDash.xcodeproj from /Users/marc/Xcode/GenDash.
• 3.1.2 Confirm the project navigator contains no red or missing file references.
• 3.1.3 Confirm the workspace opens normally and uses the copied project.
• 3.1.4 Confirm the shared GenDash and GenDashWidget schemes are available.
• 3.1.5 Confirm the Xcode project, workspace, and schemes contain no stale absolute references to the old folder.

3.2 Build, Signing & Runtime#

• 3.2.1 Confirm the main app target retains its original bundle identifier, signing team, entitlements, and property list settings.
• 3.2.2 Confirm the widget target retains its original bundle identifier, signing team, entitlements, and property list settings.
• 3.2.3 Build the main GenDash target from the new location.
• 3.2.4 Build the GenDashWidget target from the new location.
• 3.2.5 Run the app and confirm the widget and Live Activity integration still function.
• 3.2.6 Confirm moving the source folder has not changed device or simulator app data, Keychain behavior, or CloudKit configuration.
• 3.2.7 Do not export or import localizations as part of the folder move.

4. Project-Internal Absolute Path Audit#

4.1 Path Audit#

• 4.1.1 Search the copied project for references to the old project location.
• 4.1.2 Separate Xcode configuration references from scripts and historical recovery files.
• 4.1.3 Confirm the Xcode project, workspace, schemes, entitlements, and property lists are path-independent.
• 4.1.4 Confirm every approved operational script now locates the repository from its own location or the new project path.
• 4.1.5 Test each retained project script from /Users/marc/Xcode/GenDash.
• 4.1.6 Repeat the audit until no required project workflow depends on the old project location.

5. External Scripts, Aliases & Launchers Audit#

5.1 Inventory#

• 5.1.1 Identify the definition and location of the pushgen command.
• 5.1.2 Check shell aliases, shell functions, startup files, and PATH entries for references to the old Antigravity folder.
• 5.1.3 Check symlinks, launch scripts, Automator actions, Shortcuts, LaunchAgents, scheduled jobs, and other local launchers that may invoke GenDash tools.
• 5.1.4 Inventory repository scripts that use absolute paths or assume the old project location.
• 5.1.5 Classify each script or launcher as active, required, optional, or historical.

5.2 Approved Changes & Validation#

• 5.2.1 Update /Users/marc/Scripts/MacOS/lock_gendash.sh so its GenDash localization and string-catalog paths point to /Users/marc/Xcode/GenDash.
• 5.2.2 Update /Users/marc/Xcode/GenDash/AGENTS.md so its localization workflow and locked-file paths point to the new project location.
• 5.2.3 Update /Users/marc/Xcode/GenDash/.agents/skills/gendash-architecture/SKILL.md so its project file links point to the new project location.

6. Final Sign-Off#

6.1 Sign-Off#

• 6.1.1 Verify the active file-locking aliases resolve to the updated script and no active external configuration still references the old project path.
• 6.1.2 Record the changed files and the rollback method before marking the migration complete.
• 6.1.3 Mark the migration complete only after the original folder is no longer needed as a rollback copy.
• 6.1.4 Remove the original folder only as a separate, explicitly approved cleanup action.

7. MacBook Air Migration (Secondary Computer)#

7.1 Preflight#

• 7.1.1 Confirm the MacBook Air’s current GenDash project location, Git branch, working-tree status, local-only commits, and remotes.
• 7.1.2 Confirm the GenDash and Scripts migration commits are available on their remotes before pulling them to the MacBook Air.
• 7.1.3 Confirm /Users/marc/Xcode/GenDash does not already contain a project and preserve the current Air folder as a rollback copy.

7.2 Repository Relocation#

• 7.2.1 Choose the relocation method: move the complete existing checkout when local-only state exists; use a fresh clone when the checkout is clean and fully synchronized.
• 7.2.2 Create the new folder and relocate or clone GenDash into /Users/marc/Xcode/GenDash, preserving .git when moving the existing checkout.
• 7.2.3 Pull the latest GenDash changes in the new location.
• 7.2.4 Verify the branch, history, remotes, tracked files, and working-tree status.

7.3 Xcode and Script Validation#

• 7.3.1 Open the GenDash project or workspace from the new location and confirm both schemes and references are available.
• 7.3.2 Build the main app and widget once from the new location.
• 7.3.3 Pull or clone the /Users/marc/Scripts repository on the MacBook Air and confirm genl, genu, gens, and genx use the updated locking script.
• 7.3.4 Confirm pushgen remains unchanged because it serves the separate Obsidian/Hugo workflow.
• 7.3.5 Confirm no active workflow on the MacBook Air still depends on the old project path.

7.4 Sign-Off#

• 7.4.1 Keep the original MacBook Air folder until the new setup has passed validation.
• 7.4.2 Remove the original MacBook Air folder only as a separate, explicitly approved cleanup action.

Home Assistant - Cloudflare Pages Build Usage#

1. Project Objective#

Add a simple Home Assistant sensor that shows how much of the Cloudflare Pages monthly build allowance has been used.

The sensor should answer:

How many of my 500 Cloudflare Pages builds have I used this month?

2. Project Scope#

The project will deliver one Home Assistant entity:

sensor.cloudflare_pages_builds

The sensor will show:

• builds used this month;
• builds remaining;
• percentage of the monthly allowance used;
• usage by Pages project;
• the current reporting month;
• the time of the last successful update;
• whether the information is current or unavailable.

This project does not include a dashboard, automation, custom integration, HACS component, or unrelated Home Assistant changes.

Backup Strategies#

1 Backrest & Restic Google Drive Backup#

2026-09-01 Not used anymore

Encrypts TrueNAS/DSM network shares with Restic and stores them in Google Drive through Rclone. See Backrest & Restic Google Drive Backup Setup.

2 Proxmox PBS Backup to Google Drive#

2026-09-01 Not used anymore

Synchronizes the deduplicated PBS datastore from the UNAS-Pro NAS to Google Drive through MMDocker and Rclone. See Proxmox - PBS Backups via NAS with to GDrive.

Frigate Installation Project Plan#

codex resume 01a010cc-f385-7fb1-bda6-375f3a85e303

UniFi Protect remains the primary NVR. Frigate will be an additional detection and classification layer. No installation or configuration should begin until the read-only validation phase is complete.

1. Project Objectives#

1.1 Functional Objectives#

The system will detect animals using Frigate motion detection, object detection, tracking, and zones.

It will distinguish coyotes from chickens, dogs, cats, deer, raccoons, foxes, and unknown animals. The initial tuning priority is avoiding missed coyote detections; false positives can be reduced afterward.

Local AI Camera Detection Documentation#

codex resume 01a01163-4a3e-7cd2-b780-30eef5e8f62d Continuation: codex resume 01a01b8f-a60c-7f01-9173-c4c189929d3b

This document describes the working local visual-classification implementation and the information required to recreate it. It is documentation, not a task list.

1. Purpose and Design Principles#

1.1 Purpose#

The system adds a second-stage visual classifier to the existing UniFi Protect and Home Assistant installation.

UniFi Protect remains responsible for recording video and detecting broad event categories such as animal, person, or vehicle. Home Assistant receives the Protect event, obtains an image, sends it to a local vision-capable Ollama model, evaluates the structured result, records the decision, and sends a notification only when the objective-specific policy accepts the result.

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)

UniFi VPN Management#

1 OpenVPN#

1.1 Client Profile#

The verified iPhone client uses OpenVPN Connect with these settings:

• Profile name: marcoue.ddns.net [OpenVPN Server]
• Server hostname: marcoue.ddns.net
• Username: marcoue
• Password: Saved in the OpenVPN client; do not document it here.
• DDNS provider: No-IP (ddns.net)

The profile uses the hostname rather than a fixed IP, so the iPhone profile normally does not need to be edited when the ISP address changes.

The OpenVPN listening port and the exact UniFi port-forward rule were not captured in the available documentation. Verify those values in the UniFi Network application if the VPN still fails after DNS is corrected.

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