RosCard Open Source Clarification — Architecture, Limitations, and What Actually Enables Customization
We discussed this topic internally with our engineering team and want to provide a clear technical explanation to help everyone understand how RosCard, the remote client, and Home Assistant interact within the Astrion system.
Core Principle
RosCard is a configuration definition tool, not the control engine.
Its responsibility is limited to:
-
presenting configuration interfaces
-
collecting parameters
-
generating configuration data
-
defining UI structure
It does not execute device commands or contain control logic.
Where the Real Control Happens
All actual remote-control behavior is implemented inside the RemoteOS Android application running on the Astrion Remote.
The workflow is:
-
User configures a card in RosCard
-
RosCard generates a structured configuration file
-
RemoteOS parses that configuration
-
RemoteOS executes commands based on its internal logic
There is a strict data protocol between RosCard and the client application. The client only recognizes predefined fields and schema formats.
Why Open-Sourcing RosCard Alone Has Limited Impact
Even if RosCard were fully open source:
Users could modify
-
UI layout definitions
-
configuration schema
-
parameter presentation
-
card styling
Users could NOT modify
-
command execution logic
-
device control behavior
-
rendering engine capabilities
-
hardware interaction
-
protocol handling
If someone changes configuration structures or adds unsupported fields, the client will simply fail to parse them, and the card will not function.
So open-sourcing RosCard does not equal full customization of system behavior.
Rendering Limitations Are Client-Side
The visible interface on the Astrion Remote is rendered by the application-layer rendering engine inside RemoteOS, based on RosCard’s generated configuration.
That means:
The real constraint for themes, layouts, and UI innovation is the client renderer — not RosCard.
For example, features such as:
-
fully custom themes
-
new UI component types
-
non-standard layouts
-
animation systems
-
advanced interaction models
require new capabilities in the client engine, not changes to RosCard.
If the client does not support a feature, modifying RosCard cannot enable it.
Why We Continue Iterating Instead of Open-Sourcing Immediately
RosCard is still under active architectural development. Open-sourcing its current state would:
-
expose unstable schemas
-
create version fragmentation
-
cause compatibility mismatches
-
increase support complexity for users
We want to avoid a situation where community-modified configurations stop working after system updates.
What Actually Enables Advanced Customization
Real extensibility comes from official feature support in the client application, such as:
-
new UI component libraries
-
dynamic theme engines
-
layout system extensions
-
renderer performance upgrades
-
new interaction models
These require coordinated updates between:
-
configuration generator
-
rendering engine
-
protocol definitions
-
runtime logic
How Users Can Request New Capabilities
If you have specific needs, we strongly encourage you to share them. After evaluation, we can implement them through official system updates.
Possible supported expansion directions include:
-
additional card component types
-
richer visual customization options
-
theme systems (colors, fonts, radius, spacing)
-
advanced layout engines
-
performance-optimized rendering paths
Key Takeaway
RosCard defines the interface.
RemoteOS executes behavior.
The rendering engine defines what is visually possible.
Open-sourcing RosCard mainly affects configuration flexibility, not system-level functionality.
We truly appreciate the thoughtful technical discussions from everyone. Feedback like this directly influences our development priorities and helps us build a more powerful and flexible platform for the entire community.
@all