Yio Remote Community

openHAB integration


I’ve looked at HTML based stuff running in chromium, but it was really slow. I am aiming for a really fluid and responsive UI, that’s why I went down the qt route.

You can write stuff in javascript as well, but it will take more resources. I did write the Home Assistant integration in javascript, but with the help of @ChristianRiedl, I am moving it to C++ to save resources, thus prolong battery life.

However the remote is based on a Raspberry Pi Zero W, so if you swap out the SD card for your own thing, you can do it. Only thing you have to “migrate” is the hardware handling part.

I have quite a bit of things on my todo list, but if nobody pitches in with OpenHAB integration, I’ll install it and write the API communication for the remote. From that point on, adding components for light, blind, etc. will be easy.

I would greatly appreciate both of your efforts to support openHAB.



@TMToronto I wrote up some code for an openHAB integration. It seems like there’s only a rest API and the item states need to be polled. At least I couldn’t find any information about websockets.

Anyhow, polling can work. I’m going to keep working on the code as I have an openhab server running for testing.

There is really three (maybe four) ways of doing this - each with it’s own ad/disads:

  1. Go the polling route using REST api. Easy to put together at the cost of speed and you take on the whole mapping of items yourself
  2. Create your own websocket addon. Steep learning curve but you could emulate your existing websocket interface - mapping items then becomes either on the remote or on the addon side depending on how you do it.
  3. Go the way I did on the NEEO route - do a full addon. Very steep learning curve, lotsa code written but everything is pretty much automatic. The real stopper here is that (I think) it’s not very possible with the overall direction your going in with the remote (I maybe mistaken here) since the ‘integration’ would be pushing ui ‘stuff’ to the remote. That’s what I was kinda getting around when I spoke about an HTML interface since it would allow a very generic setup on the remote (where you could go either way [the remote is the ‘master’ or the integration is the ‘master’]). Doubt I’m getting my point across well …


How it is currently set up at the moment:
There is a general light entity for example. It has a GUI and communicates with high-level commands: for example turnOn, toggle, setBrightness(100) etc. The integration takes care of translating turnOn command so it’s understandable by the integration like openHAB or Home Assistant.

With this approach the whole remote will have a nice and unified look. Every light works the same way: turn on/off, dim, set temperature or color, no matter what system you use. This is true for most of the components. That’s why I haven’t even thought about loading HTML into the remote. However you could create a GUI element that could load external GUI stuff into the remote UI. But that would just look weird :slight_smile:

I understand the approach you are taking and it makes sense for you.

Personally - I want the remote to have a unified look with the rest of my system and alot of it is very dynamic (here is an example of a russound widget I put together on habpanel - I’d love to replicate it on a remote somewhere but alot of it is dynamically generated by the source system - impossible to setup in advance in a UI).

At any rate, I’m probably going to skip on YIO because I’m not going to really get what I need out of it but I’m more that happy to help you (or whomever) that wants to put together a openHAB integration (atleast in direction and technical help)…



The UI I am working on is fully dynamic as well. It changes based on the configuration and events. For example (if we stay at the light entity) if you have lights that is just on/off then it displays a switch if you have a dimmer you can dim, etc. The same goes for media players (just recently finished a mini version).

If you want the same look-and-feel like the widget you did, well yeah that’s another question. There’s built-in support for changing colors, not yet developed to user side yet. If you want different icons/etc you have to dig a little deeper into the code.

I have plans for creating a web-based configuration tool, where you could drag and drop together UI elements to create your own things. This is a VERY future plan, but I have it on my to-do list.

The YIO remote is not for everyone, it’s impossible to cater for all the needs, but I am trying to take all the feedback and integrate it to make it more appealing :wink:

Yep - that’s why I said I’m likely to skip this for now.

What I mean by dynamic is that everything on the screen is driven by the equipment. Example: the russound widget I mentioned before - the only ‘fixed’ screens (prebuilt) are the first few that are updated from events. The rest of the screens are ‘built’ by the equipment itself. Example: if I select pandora as a source on russound, russound gives me something like: I need a pageable list of 8 in size with 2 pages, the first in the list is ‘some name’, the 2nd is ‘some other name’, after the list - a button with ‘new station’ should be placed. If I then press the ‘new button’ - russound give me back: here is a label saying ‘New Station Name’, then an input box should appear, then two buttons with labels ‘ok’, ‘cancel’, etc. The API is very interactive - basically they built it so that you can control your russound from anything (keypads, phone, remote, etc) but you need the ability to dynamically create screens.

The widget I put together is straighup angular html and creates the screens as needed (which was simple with angular).

Hope that’s helpful…

@marton Whats about openHab integration. Currently it is only an empty framework. I am not a deep openHab expert but sufficent, to implement the level of functionality as we have in home-assistant.
Shall I do it ?

On more idea related to the connected attribute of the entities. I think a “good” integration should only set the entities to connected state which are really discovered by the integration.

1 Like

I think you would make a lot of people happy @ChristianRiedl! Right, @TMToronto, @troberts? :wink:

You’re right about the connected attribute. Our idea is that with the web configurator you can select the entities you want to control with the remote. And the integration should check if those entities are available, and then set the connected attribute accordingly.

I would greatly appreciate any work you do that would allow me to use this remote with my openHAB setup.
Thank you,

That’s a great idea! One less TODO for me :wink:
I’m using openHab but had to setup home-assistant to get started.
Let me know if we need an openHab plugin for a better integration scenario. Java is my daily business at work. However, I haven’t done any development work in openHab yet…

I have now a working version of the openHab integration. But I have only a poor supported media player which I can connect to openHAB. Lights and Blinds are working fine, but openHAB documentation for media players is weak.

@TMToronto @troberts :
If you have connected a media player to openHAB I ask you to send me the JSON result delivered by
http://youripaddress:8080/rest/things”. Than I can hopefully improve media player support.

I can’t push the openHab integration to the dev branch, because I do not have the necessary rights.

I also can’t push changes to roon integration because of an error “1 approving review is requires by reviewers with write access”. ??

@ChristianRiedl I’ll send you my output of 2 connected Ikea Sonos speakers by private message. It contains too many serial numbers and stuff…

It should work now @ChristianRiedl!

I am not sure if I can be of help. I use a NEEO binding created for OpenHAB to use my Oppo 105 player, and I have not yet found a way to use either to control my BlueSound music players - currently I use the BlueSound app. My other uses are for my Big Ass Fan, Hue lights, and Somfy RTS roller blinds.

@zehnm @TMToronto

Regarding openHAB mediaplayer support : Main problem is that it is not standardized. Every openHAB device binding has different names for the same thing and every device has slightly different features.
My integration is reading at startup the things and tries to figure out what can be done. Of course only the commands attributes described in the entity documentation can be supported (see media player entity in https://github.com/YIO-Remote/documentation/wiki/developer-entity-types).

I have only a simple media device (frontier silikon) supported by openHAB. So I cannot really test features for other devices. But everybody who wants to use the openHAB YIO Mediaplayer combination and has a minimum understanding of REST api can figure out some things and tell me exactly what I have to implement.

You need to install in openHab the “REST api documentation” plugin (MISC).
You can easy list the things with the /things command.

Here you find things and its channels. A channel must be linked to an item to access its state and to send commands.

Sample :

    "linkedItems": [
    "uid": "sonos:zoneplayer:RINCON_347E5C32409001400:control",
    "id": "control",

In Sonos Plugin docs I can read, that “control” is read-write and used for things like play/pause/next/prev.

But in the docs I read also that “state” is used for this purpose.

Using the REST api documentation it is easy to access the current value of an item, and to send com mands to this item. And if you can describe me exactly which value an item like “control” delivers and which commands it understands than I can implement it.

The available commands are documented here : https://www.openhab.org/docs/concepts/items.html,
But the returned states are not always clear and especially which channel of the thing delivers it is not clear

1 Like

As a former NEEO user and long-time developer, I also dig any progress regarding OpenHAB support.

I always looked for a remote that would complement OpenHAB in terms of deployment and an end-user product that would blend with all integrations it provides.

troberts’s NEEO integration was a big milestone, took the remote to new level in terms of funcitonality and clearly showed what possibilities adding in a automation hub may provide.

I’m sad he’ll be skipping this, but I certainly hope the development will keep on, and willing to offer my resources in case needed.

1 Like

I’m still around just don’t have time for an endeavor like this. I have no problems helping someone if they want to take the lead however…


The openHAB integration is ready for testing by developers (dev branch). Currently implemented : LIGHT, BLIND, MEDIA PLAYER. When the UI will support more entity types, they will be implemented in the integration.