Leveraging the Community

Astrion
, ,
1

Unlock community development — a proposal to accelerate Astrion

One of the biggest reasons Home Assistant succeeded is that it leans on a huge community of developers. Astrion has the same opportunity, but right now the pace of change is the bottleneck — and that’s not a criticism of the team. With a small dev group and a hardware QA cycle, every change is expensive and slow. That’s exactly the kind of constraint a community can absorb.

Two ways forward (not mutually exclusive)

  1. Revert to Android + the HA Companion App — the approach [@brad sanders] has championed. It’s a genuinely good path, but it runs into the hardware limitations of the Astrion.
  2. Unleash the community to build and extend cards directly. This scales with people, not with your QA budget.

The problem today is that option 2 is effectively closed to outside developers.

Why it’s closed today

  • It isn’t a proper repository — there’s no source published, only a minified bundle.
  • I tried to build something simple: a more accessible navigation card (the current view-switcher dropdown is hard to reach on the remote). It renders and works perfectly in a desktop browser, but will not render on the remote. I even registered it under an aiks--prefixed type to test the theory — still nothing.

The remote seems to render only a whitelisted set of card types baked into the firmware, so no community card can reach the hardware. A motivated developer hits a wall on day one.

What would change that

In rough priority:

  1. Ship an opt-in “developer firmware.” Being opt-in handles the safety/QA concern by definition. It would render any card whose type is prefixed aiks- or roscard-, letting developers build and test on real hardware without touching the stable firmware.
  2. Publish as much source as possible, plus documentation of the functions/API the remote itself exposes to cards — the rendering contract, supported actions, and current limits. Without this, every developer is reverse-engineering blind.
  3. Make this a real open repository — source, build instructions, and contribution guidelines — so the community can submit fixes and new cards as PRs. (The issue templates are already there; the source isn’t.)
  4. Define a path for community cards to be reviewed and merged into the official whitelist, so good contributions can graduate from the developer firmware into the stable release.

This isn’t that much upfront work - but it could explode the opportunity. Your risk, just like unfoldedcircle, haptique and others, is that you can’t deliver powerful enough product before the next wave of software and hardware arrives. This is the Hail Mary that gives you really good shot at the WIN!

The ask

I’m not asking for a finished platform — just the opt-in firmware and the API docs would unblock a lot of us immediately. I’m happy to be a first tester: I have a working nav-card ready to go the moment the firmware will render it.

2 Likes
Nav Card Request
2

Agree completely, more momentum will be gained by leveraging on the community.

3

Hi everyone,

Thank you so much for your great enthusiasm for our remote control. We truly feel honored to see so many of you willing to join and be part of this ecosystem.

Regarding the open ecosystem, we did seriously consider it in the early stages. However, due to current technical limitations, we are not yet able to fully open all content to the public. In a while, I will publish a dedicated post explaining why we cannot fully open it, and to what extent we will be able to. We warmly welcome everyone to join the discussion when that time comes.

In addition, if you have any other suggestions or ideas, please feel free to share them with us. The Sanytron team would like to express our sincere gratitude once again for your support and attention.

Wishing you all a great experience!

4

This is a show stopper for me. Your current cards a very limited and you won’t let the community help out. I was told I would have access the development source. Sad!

5

Hi dubbing,

Welcome to our community! If you have any questions or suggestions, feel free to share them with us.

Regarding community participation in development, we’d like to clarify. We didn’t address this earlier because the ROS cards are configuration-only and cannot be open-sourced for community development.

However, after recent internal discussions, we’ve made a technical shift. Instead of focusing solely on developing ROS cards, we are now working on integrating HA’s native web-based cards and will be opening up our physical button API. This will allow community members to develop their own cards and UI, and link them with our physical buttons.

This is our vision—to maximize the ability for everyone to build and customize within the existing ecosystem, and to help expand the Astrion ecosystem further.

If you have any additional suggestions, please don’t hesitate to let us know. Thank you!

6

Think we need to be honest though.

The good part about the roscards is that they worked with the limited horsepower of the remote. Efficiently. The bad side as noted above, is a locked ecosystem.

You are on the right path.

  1. Unlock all the buttons, with a lightweight HA card. (HA–>HW interface)

  2. Repurpose the lightweight roscards to use that same HA–>HW Interface.

  3. Open it up to community dev. Many HA cards will be too heavy to work nicely with the HW. But by abstracting the HW button support, the community will develop, at speed, a lightweight Astrion card library.

s.