This commit is contained in:
@@ -1,42 +0,0 @@
|
||||
# Questions — v3 (current round)
|
||||
|
||||
Round v2 was closed out and removed 2026-09-02 by the parallel HA session.
|
||||
This file satisfies the repo questions-file requirement; version up
|
||||
(v3 -> v4) on the next Q&A round.
|
||||
|
||||
## Active question channel (founder-directed)
|
||||
|
||||
`~/PTKR.md` — 12 open items: GLPI API key, AI-staff identities,
|
||||
Vault-vs-Bitwarden for agent secrets, prometheus/grafana envs, VoIP carrier
|
||||
decision, PMG MX cut-over window, SITES access, October hardware window
|
||||
dates, Friday 2026-09-04 onsite coordination, #681 Cloudron 500s, nitrokey
|
||||
purchase, Cloudron packaging session scope.
|
||||
|
||||
## Repo-local questions
|
||||
|
||||
### Q1 — HA remote access: proceed with the Cloudron pairing now? (decision needed before Friday)
|
||||
|
||||
Adopted architecture (your 2026-09-01 ruling on #626): Cloudron HA = family
|
||||
frontend, pfv-bms = property brain, connected via HA Remote
|
||||
assistants/entities. Facts verified 2026-09-02 evening:
|
||||
|
||||
- Both instances at 2026.8.3 (above the 2025.7 pairing floor), Cloudron HA
|
||||
RUNNING, api token in ~/.creds/cloudron-ha.env, Tailscale path Cloudron ->
|
||||
pfv-bms proven (Kuma already monitors LAN hosts from there).
|
||||
- Risk on the table: tsys-cloudron Postgres wobbles the same day (#681 500s).
|
||||
If Cloudron degrades, FAMILY ACCESS degrades — pfv-bms itself is unaffected
|
||||
either way.
|
||||
|
||||
Options:
|
||||
|
||||
- (A) Proceed with pairing now (recommended) — additive and reversible; pfv-bms
|
||||
stays unexposed (Tailscale-only admin path); family accounts live on
|
||||
Cloudron only. Remaining steps: mint pfv-bms long-lived token (yours, or
|
||||
delegate to agent on approval), wire Cloudron-side integration, pair,
|
||||
add family accounts.
|
||||
- (B) Hold until Cloudron stabilizes — nothing lost except timeline; Friday
|
||||
family-access demo unlikely.
|
||||
- (C) Nabu Casa interim (~$6.5/mo) — fastest single-instance remote UI, but
|
||||
does not serve the multi-property global-instance goal you ruled on.
|
||||
|
||||
Answer inline (A/B/C + any conditions):
|
||||
@@ -0,0 +1,55 @@
|
||||
# Questions — v4 (current round)
|
||||
|
||||
v3 closed 2026-09-02: Q1 answered in chat ("cloudron postgres solved —
|
||||
wire up the remote access, hook first"). The deploy hook LANDED (#734,
|
||||
E2E proven); the pairing hit a wrong premise and needs a fork ruling
|
||||
below. Version up (v4 -> v5) on the next Q&A round.
|
||||
|
||||
## Active question channel (founder-directed)
|
||||
|
||||
`~/PTKR.md` — 12 open items: GLPI API key, AI-staff identities,
|
||||
Vault-vs-Bitwarden for agent secrets, prometheus/grafana envs, VoIP carrier
|
||||
decision, PMG MX cut-over window, SITES access, October hardware window
|
||||
dates, Friday 2026-09-04 onsite coordination, #681 Cloudron 500s, nitrokey
|
||||
purchase, Cloudron packaging session scope.
|
||||
|
||||
## Repo-local questions
|
||||
|
||||
### Q1 — HA instance pairing mechanism (blocks #626 family access; would like before Friday)
|
||||
|
||||
The 2025.7+ "built-in pairing" premise was WRONG — no such core
|
||||
integration exists as of 2026.8.3 (verified on both instances + HA core +
|
||||
docs; full research in #626 note). Options:
|
||||
|
||||
- **(A)** HACS custom `remote_homeassistant` on the Cloudron HA — full
|
||||
entity mirroring + control, matches the ruled architecture. Needs a
|
||||
founder file/HACS install on the Cloudron app (~30 min of your time;
|
||||
no agent API for Cloudron app files). Caveat: community reports of
|
||||
recent breakage (remote entities unavailable) — I'd vet the GitHub
|
||||
issues before committing.
|
||||
- **(B)** One-way API bridge — pfv-bms pushes ~20 key family states
|
||||
(temps, UPS, garage/artroom) to the Cloudron HA REST API + I build
|
||||
family dashboards there via websocket. I can build it entirely
|
||||
tonight; family gets read-only visibility; no control.
|
||||
- **(C)** MQTT broker on the VPS, both instances bridge — bidirectional,
|
||||
but a new always-on service + YAML on both sides.
|
||||
|
||||
Answer (A/B/C) + does family need to TOGGLE things at the property, or
|
||||
just see status?
|
||||
|
||||
### Q2 — gitea webhook allowlist (1-line + restart; unlocks instant deploys)
|
||||
|
||||
gitea silently drops webhook deliveries to CGNAT-range targets (SSRF
|
||||
`ALLOWED_HOST_LIST` default — no delivery attempt, no log line; restart
|
||||
doesn't help; that's why hook #10 never fired). Until it opens, the
|
||||
5-minute sha-watch net deploys everything reload-only — already live.
|
||||
|
||||
To open the instant path: Cloudron file manager → gitea app.ini →
|
||||
|
||||
```ini
|
||||
[webhook]
|
||||
ALLOWED_HOST_LIST = external,private
|
||||
```
|
||||
|
||||
then restart gitea. Say the word when done — I'll verify hook #10 fires
|
||||
end-to-end (it carries the full restart-mapping logic).
|
||||
Reference in New Issue
Block a user