Are you using Astrion:
- Only on your local network?
- With Nabu Casa?
- Through VPN or reverse proxy?
Let’s discuss:
- Stability
- Latency
- Setup complexity
- Security considerations
Your experience can help others decide.
A device like the Astrion should be almost entirely local, with any remote communication handled externally or being purely optional.
For example if I want to control a remote device over the internet, I can have the remote ask HA to do that, secure local communication then any cloud or wan control is handled by HA under the users control.
if I want to control the Astrion remote (if and when we get two-way control for selecting scenes/cards/pages from external control), I can ask HA remotely to ask Astrion Locally.
For a remote that aims to be a HA controller, HA should be the central control for as much as possible.
A competing product got one thing quite wrong when they implemented their web API, it was all through their own server with insecure HTTP GET endpoints that anyone with the URL could trigger. I’d like Sanytron to learn from that and make any public or cloud based systems optional, with a local option always available.
1 Like
Hi Faceman 
This is a really important point, and I think you’ve articulated the core architecture principle very clearly.
We fully agree with the direction you’re describing:
1. Local-first is the correct foundation
Astrion is fundamentally designed to be local-first.
That means:
-
core control logic should run locally
-
HA remains the primary orchestration layer
-
device responsiveness should not depend on cloud connectivity
-
WAN/cloud should always be optional, not required
This is not just a preference — it’s a design constraint we agree with.
2. Home Assistant as the central control plane
Your model is exactly how we also think about it internally:
-
Astrion = interaction layer (input/output device)
-
Home Assistant = orchestration brain
-
External systems = optional extensions via HA
So yes:
remote control, WAN triggers, automation flows should all pass through HA when possible
Astrion should never bypass user-controlled logic for external communication
3. Remote access model (important distinction)
We also agree with your architecture example:
If control is needed outside the local network:
-
HA should handle secure remote access (VPN / Nabu Casa / user-defined methods)
-
Astrion should still only speak locally to HA
-
no direct “cloud-to-device bypass” should be required for core functionality
This preserves:
-
security
-
auditability
-
user ownership of control flow
4. API design philosophy (very valid warning)
Your example about insecure HTTP GET endpoints is exactly the kind of anti-pattern we are actively avoiding.
We are aligned on:
-
no unauthenticated action endpoints
-
no direct “trigger by URL” behavior
-
no mandatory vendor cloud routing for core functions
Any external API surface we design will follow:
-
explicit authentication
-
user-controlled exposure
-
local availability first
-
optional cloud relay only if explicitly enabled
5. Two-way control (Astrion ↔ HA)
This is also something we strongly agree with:
When implemented, it should be:
-
HA can instruct Astrion (change page / card / scene)
-
Astrion can report state back to HA (page, activity, battery, etc.)
-
all through local channels by default
This enables exactly the “coordinated system” you described without breaking locality.
6. Summary
Your framing is very aligned with our internal direction:
Local-first core
HA as orchestration brain
Cloud/WAN optional and user-controlled
No insecure or bypassable control endpoints
Fully reversible and auditable control flow
Really appreciate you raising this so clearly — these architectural discussions are exactly what helps ensure we don’t drift into convenience-first design at the cost of control and security.
This feedback is going straight into our design review notes 
1 Like