PFVCluster/HomeAssistant/needfromcharles.md

Working ask-file; knowledge docs live on Discourse: https://community.turnsys.com/c/vp-techops (audit log: https://community.turnsys.com/t/298)

needfromcharles.md — open asks from the agent (2026-09-01 night session)

Answer inline below each item; the agent checks this file before asking again.

1. Minisplit (Midea/Carrier) — blocks #614

Your login charles@turnsys.com was rejected by all three Midea cloud backends (SmartHome / Midea Air / NetHome Plus). Likely a Carrier-specific backend or a different account.

• Exact app name on your phone that controls the minisplit:
• Account email that app uses (if different):
• (If MSmartHome-family) password for that account:

2. Govee — blocks #620 device data

Cloud API sees zero devices (suspect BLE-only sensors).

• Model numbers of your Govee temp sensors / lights:

• Govee app account email + password (thermometer readings require it):

  Agent (2026-09-02): both accounts received, stored 0600 in ~/.creds/govee.env. But us.govee.com is a JS app the agent can't drive. One human click needed: log in at us.govee.com → "Apply for API Key" → paste the key here (or append GOVEE_API_KEY= to ~/.creds/govee.env).

3. HomeKit codes — blocks #619 (ecobee + front-door lock)

• ecobee HomeKit setup code (8-digit, on paperwork/box if not the unit):

• Front-door lock brand/model: cant you figure it out from dhcp table?

  Agent (2026-09-02): checked — active 192.168.1.x leases have no lock-brand MAC OUIs (every lease accounted for: ecobee, TP-Link extender, Amazons, iPhone, Cisco phone, Dell, sectestbed/preprod VMs). HA has zero lock entities (of 273) and Z-Wave JS none. Lock is almost certainly BLE-only (typical for HomeKit locks) — DHCP cannot name it. Need: brand, or just the 8-digit HomeKit code from the vendor app.

• Lock HomeKit code (if visible in its vendor app settings):

4. Emporia Vue 3 — blocks circuit-level power + BTU loop (#623/#614)

• Ordered? ETA:

5. Decisions (yes/no)

• UniFi mDNS/multicast setting change may briefly re-provision APs (short WiFi blip) — OK to apply tonight?

yes. apply to one ap at a time.

• Re-enable HA core watchdog (was disabled to break the boot loop; box has been stable since)?

yes.

• Uninstall the crash-looping community SSH add-on (a0d7b954_ssh)? (core_ssh on 22222 is the keeper)

yes

• k8s rebuild tonight or next session?

i am doing in other session

6. Friday onsite (#629 — unchanged)

Dongle manual/app check · minisplit nameplate photo · ecobee + lock codes (if not provided above) · Tripp Lite USB reseat (#372) · Emporia CT install.

7. Small hygiene

• Re-enroll Pi-hole TOTP in your authenticator (secret in ~/.creds/pihole.env) — password already rotated.

8. UniFi controller API key (added 2026-09-02) — blocks proper mDNS fix [#619]

UniFi Network 9 removed the classic API. Please create an Integration API key: UniFi UI → Settings → System → Advanced → Integrations → API Keys → Add.

• Paste the key here (or ~/.creds/unifi-api.env):

9. iDRAC/IPMI credentials (added 2026-09-02) — blocks #625

Both OOB ports are live but predate Redfish; IPMI (623/UDP) is the only data path. Temp + power monitoring for tsys6/tsys7 needs one of:

• iDRAC root password for both, or

  Agent (2026-09-02): creds worked — BOTH iDRAC SNMP agents now live. tsys7: community set to kn3lmgmt (verified). tsys6: agent enabled, but fw 1.41 refuses racadm community changes (stays public). Pick one:

  • flip it in the iDRAC6 web UI (needs a TLS1.0-capable browser), or
  • upgrade iDRAC6 firmware (1.41 → 2.9x) then racadm set, or
  • accept public on the isolated OOB LAN for now