97 lines
4.2 KiB
Markdown
97 lines
4.2 KiB
Markdown
|
|
> 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:
|
|
- [x] Govee app account email + password (thermometer readings require it):
|
|
|
|
**Agent (2026-09-02, later):** DONE — integration configured end-to-end
|
|
via REST config flow: your API key accepted, account
|
|
`coo@reachableceo.com` verified (2FA `2937`), MQTT connected. Result:
|
|
**zero devices** — the cloud account simply has none exposed. Remaining
|
|
blocker is hardware: BLE-only sensors need either a BLE-LE-capable USB
|
|
dongle on pfv-bms (current Kensington is BT 2.0, no LE) or a Govee hub.
|
|
- [ ] Model numbers of the sensors (decides BLE vs WiFi path)
|
|
- One-click cleanup: delete the disabled duplicate "Govee" entry in
|
|
UI → Settings → Devices → Govee (removes 2 ghost diagnostic sensors)
|
|
|
|
## 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:
|
|
- [x] 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
|
|
|
|
**Founder decision (2026-09-02): `public` accepted for tsys6.** Both
|
|
DRACs now answering SNMP; creds live in `~/.creds/idrac.env`.
|