Yio Remote Community

openHAB integration

I’ve been watching this for a bit and I’m still contemplating whether to spend the time to create an addon or not for openHAB. The biggest issue is QT (which I confess I don’t know and really don’t have any interest in figuring out to tell you the truth). I know from another thread that you made the decision to go that route and I’m not arguing against it.

I was just hoping for an HTML type of interface because it would be simple to bring a boatload of already written stuff to it from openHAB (basically I’d have liked to load happanel onto the remote and use the hundreds of widgets already written for it).

So my question to you - is it possible to load an entirely different UI onto the remote?

1 Like


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…