Im part of testing control system integration with a driver for RTI control systems.
We have found some features not supported by the API.
Here is some points from Dan at Habitech in UK:
We’ve built an RTI control system driver that talks to Roon Core directly over MOO/1 on port 9150 — same architecture as the Control4 driver, no middleware layer. It’s been out in customer hands for a few months and we’re starting to get the same handful of feature requests back from dealers and end users. Most of them turn out to be things the API doesn’t currently support, so I thought it was worth sending them through rather than just telling everyone “Roon doesn’t expose that”.
The two big ones, in order:
-
A sort parameter on the browse load call.This is the one that comes up every week. Customers see “Date Added (newest first)” working in the Roon Remote app and assume it’s a setting they can pass through to our driver. It isn’t — the public browse API only returns alphabetical, with no knob to change it. If we could pass something like sort: “date_added” (and ideally also recently_played, most_played, year) on a load request, we could match what the official remote already does. Even just exposing the three or four sort modes the Remote app uses would be enoug h.
-
Metadata on browse rows.Right now browse items come back with title, subtitle, optional image_key, and not much else. If we had access to date_added, play_count, last_played, and year on the row data — opt-in via a load flag so we don’t bloat payloads for callers who don’t need it — we could implement client-side sort and filtering for things sort alone wouldn’t cover. This would also unlock UI features like “show year next to album title” which dealers ask for regular ly.
After those, in roughly descending order o f impact:
-
A library_activity or discover hierarchy that exposes the same content the Remote app’s Home / Library Activity screens use (New Releases, Recently Added, recommendations). Today extensions look bare next to the official app because that whole surface isn’t re achable.
-
Raise the per-call load page size cap. We currently chain load calls in chunks of 100 to fetch a few-thousand-album library, which is a lot of round-trips. Allowing 500 per call (opt-in) would cut load times noticeably on bigger l ibraries.
-
A subscribe_library_changes service so we can push-update when albums/artists are added or removed, rather than polling. Same pattern as the existing zone and queue su ■■ criptions.
-
Per-hierarchy search — being able to scope a query to albums or artists rather than getting everything mi xe d together.
-
A batch image endpoint. Scrolling a 100-item list with thumbnails fires 100 separate HTTPS requests against the Core. Batching even 20 at a time would help.