1. The Challenge: Too Much Information, Too Little Interaction
A modern Home Assistant installation can expose thousands of entities, hundreds of automations, and dozens of dashboards. That richness is the point of a local-first smart home. But it also creates a design problem that a phone or tablet does not have to solve in the same way.
A handheld physical remote is not a general-purpose computing surface. It is picked up for seconds, often without the user’s full visual attention. If it tries to mirror the full Home Assistant interface, it becomes slow to scan, hard to learn, and easy to put down.
The first Astrion generation started from a narrower question: what does a dedicated physical interface actually need to show, and what should it deliberately leave out?
That question shaped every architectural decision that followed.
2. Why We Didn’t Build Another Companion App
The simplest way to ship a “Home Assistant remote” would have been to wrap the Home Assistant Companion App in a handheld shell. We chose not to, for a structural reason rather than a philosophical one.
Home Assistant already does the hard work of integrating devices, maintaining state, running automations, and managing authentication. Rebuilding that inside a remote would mean duplicating a moving target. Every new integration, every change to the entity model, every auth update would need to be mirrored.
More importantly, a remote that behaves like a phone app tends to reproduce the phone’s interaction cost. The user still navigates a dashboard, searches for a control, and context-switches between the physical device and the mental model of an app.
Astrion needed to be downstream of Home Assistant, not a second frontend for it.
3. The Architecture: Home Assistant, RosCard, and Astrion
Astrion’s architecture separates three responsibilities that are often collapsed into one:
| Layer | Responsibility | What it does not do |
|---|---|---|
| Home Assistant | Device integrations, entity states, automations, scenes, scripts | It does not decide what the remote should show |
| RosCard | Selects, organizes, and formats the entities and controls that matter for the physical interface | It does not own device discovery or low-level hardware control |
| Astrion | Presents the configured interface, handles touch and physical buttons, sends user intent back to HA | It does not scan the network or manage integrations |
RosCard is not a dashboard replacement. It is a configuration and interaction layer that sits between the full Home Assistant environment and the limited surface of a handheld device. It connects through Home Assistant’s official WebSocket API, subscribes to state changes for bound entities, and formats that data for Astrion’s display and interaction model.
The practical consequence is straightforward: the user configures what matters in RosCard, and Astrion loads that configuration instead of scanning the home. The remote does not need to know that a light is Zigbee, that a TV is controlled through an integration, or that an automation is running on a different protocol. It receives the selected entities and the interaction semantics, and it renders them.
This is why Astrion can remain focused even when the underlying Home Assistant instance is sprawling.
4. Configuration Instead of Device Discovery
One of the less obvious architectural choices is that Astrion does not perform device discovery.
In a phone or tablet app, discovery is often expected: the app scans, finds devices, and builds a local inventory. On a dedicated remote, that model creates two problems. First, it duplicates work that Home Assistant already does better. Second, it forces the remote to carry the complexity of every integration and protocol.
Astrion instead starts from curation. The user opens RosCard, binds the entities and actions they actually want available on the physical device, and saves the configuration. The remote then loads that configured surface.
This has a visible effect on the interaction model. The remote is not a searchable index of everything in the home. It is a deliberately narrowed control surface. That narrowing is what makes physical buttons meaningful and touch interactions predictable.
Community feedback reinforced this direction. The recurring requests were less about discovering more devices and more about making the selected devices, activities, and controls easier to organize and use.
5. What the Community Changed
Astrion did not evolve through internal specifications alone. Some of the most important lessons came from people who had spent months configuring the HA100, integrating it into their homes, and comparing it with other control systems.
One experienced Home Assistant user shared a particularly useful perspective. He had built activities that powered on a Roku, adjusted the lighting, launched YouTube, and navigated Astrion directly to the appropriate TV controls. The result was close to what he wanted, but achieving it required several Home Assistant scripts and workarounds.
He also found that physical buttons did not always behave consistently with the controls configured in RosCard. Some commands worked through the configuration interface, while the remote still reported that certain button assignments were missing.
His feedback highlighted three areas where the architecture needed to mature.
From device controls to activities.
People do not usually think in terms of individual entities when operating their homes. They think about what they want to do: watch a movie, listen to music, or prepare a room for the evening.
An activity should therefore be more than a collection of shortcuts. It should connect the desired environment, the devices involved, and the controls the user needs next. Ideally, the interface should also respond to that context, presenting the relevant controls as the activity unfolds.
Home Assistant remains responsible for executing the underlying automations and device commands. Astrion's role is to make the resulting experience easier to operate.
Physical buttons need context.
A physical button is most useful when its behavior makes sense in the current situation. Play/Pause should control the active media device. Navigation keys should behave consistently with the interface being displayed.
This raised a broader design question: how should button assignments relate to the active device, page, or activity? The answer cannot simply be a longer list of fixed shortcuts. The physical interaction layer needs to become more context-aware.
Configuration should not become another project.
RosCard was designed to give users control over what appears on Astrion. But flexibility alone does not guarantee a good experience. Even technically experienced Home Assistant users can find it unnecessarily involved to create a polished activity, assign buttons, organize pages, and configure shortcuts.
The challenge is to make configuration more visual and intuitive without taking away the flexibility that makes Home Assistant valuable.
Other feedback pointed toward a possible hybrid approach: bringing selected elements of Home Assistant dashboards closer to Astrion's dedicated controls, while preserving reliable physical-button interaction.
These conversations changed how we evaluate progress. Adding another feature is not necessarily the same as improving the experience. The more important question is whether the user can move from an intention to the right interaction with less effort.
6. Astrion Pro: Extending the Original Architecture
Astrion Pro is the next step in that architectural evolution. It is not a replacement for HA100, and it is not a spec-sheet upgrade for its own sake. It is what happens when the original interaction model is kept intact and the hardware platform is allowed to support more of the scenarios users actually described.
The differences are hardware-bound, and they are deliberate.
| Area | HA100 | Astrion Pro |
|---|---|---|
| Chip platform | MTK6580 | MTK6762 (octa-core Cortex-A53) |
| OS | Android 8.1 | Android 12 |
| Memory / storage | 1 GB / 8 GB | 3 GB / 16 GB |
| Wi-Fi | 2.4 GHz | 2.4 GHz + 5 GHz |
| Bluetooth HID | Not supported by the Android 8.1 framework | Supported — can act as a Bluetooth HID input device for compatible hosts |
| BLE Host | Not supported |
Supported — can scan for and connect to compatible BLE peripherals |
| IR capability | IR emission with supported code-library integration |
IR emission and local IR learning through Astrion Home (38/56 kHz dual-carrier)
|
The hardware changes are important, but they are not the whole story.
Community feedback showed us that the next stage of Astrion would require more than additional processing power. Activities needed a closer relationship with the controls presented on screen. Physical buttons needed more flexible interaction logic. Local control methods, such as infrared learning and Bluetooth HID, needed to fit into the same overall experience rather than exist as disconnected features.
Astrion Pro provides a stronger platform for this direction.
This does not mean every requested capability is already implemented, or that HA100 owners are being left behind. We intend to continue improving the software and RosCard experience for HA100 within the capabilities and limitations of its hardware platform. Some hardware-dependent features, however, will naturally remain exclusive to Astrion Pro.
The screen, battery, dock, enclosure, and physical dimensions are shared with HA100. Astrion Pro does not claim a better display, longer battery life, or a different industrial design. The extension is inside the platform: more headroom for complex RosCard views, dual-band Wi-Fi for congested networks, and the local connectivity needed for IR learning and Bluetooth HID.
That is the point. The architecture stays the same. The capability envelope widens.
Astrion Pro gives us more room to explore capabilities that the original hardware cannot reasonably support.
7. Beyond a Single Ecosystem
Home Assistant remains the strongest capability source for Astrion, and the current product is built around it. But the architectural separation—Home Assistant for integration and state, RosCard for selection and formatting, Astrion for physical interaction—is not inherently tied to a single protocol or platform boundary.
The separation between integration, configuration, and physical interaction gives us a foundation to explore other control systems in the future. Making those connections practical will still require dedicated integration work, but the interaction model does not have to be reinvented each time.
Astrion Pro does not currently ship with a public third-party SDK or a generalized open control API. We want to be clear about that distinction: an architecture that leaves room for future integrations is not the same as an already-open development platform.
For now, Astrion remains a focused physical interface for Home Assistant, extended with the hardware needed for richer local control and more demanding household scenarios. The open direction is a design principle, not a marketing label.
8. From Technology to Interaction
The more capable a smart home becomes, the less the user should have to think about the technology underneath it.
Astrion’s architecture reflects that belief. Home Assistant holds the complexity. RosCard curates it into something a physical device can present. Astrion turns that presentation into touch and tactile interaction. The user expresses an intent, and the interface does the translation.
HA100 established that model. Astrion Pro extends it with the platform and local capabilities that community feedback made visible.
The goal is not to make Astrion the brain of the home. It is to make it the interface between people and the intelligence already present in their environment.
Explore Astrion Pro: View Astrion Pro — $329
Learn more about the RosCard architecture: RosCard Architecture — How Astrion Talks to Home Assistant
Join the discussion: Sanytron Community Forum
The Architecture Behind Astrion: From Home Assistant to a Physical Control Interface