Yio Remote Community

Future of YIO software

Some of you were asking what is happening with this project, so I thought I’d give you an update on what we’re up to.

Some of you contributed to the software and I cannot thank you enough for that. These guys dedicated their free time to help develop the software. However with even this help, it seemed that the rate of development was not fast enough. Simply, we couldn’t do more. And after some time the interest for contribution lowered.

Even though we communicated the DIY notion of the project, you joined and supported it, hoping the software will mature. I am grateful for the support, but at the same time also disappointed that we couldn’t develop the software in a tempo that we envisioned. We had big ideas, but last year was far from perfect on a lot of levels. And at the end it was only @zehnm and I working on the software in our free time.

What we have learned is that most of you just want to use the remote without having to touch any code. And this is fair. However the current setup was not geared towards this, being a DIY community based development.

We would like to create a great experience for the remote, make it more easy to use, so we decided to rewrite the app from the ground up. We have learned a lot during the development and realised that starting from scratch is inevitable if we want to create something that would fulfil the needs and is future proof.

Due to the lack of interest for contribution, we have been doing this behind the scenes for a few weeks now. We haven’t talked about it, because we don’t know exactly when it will be ready and didn’t want to give false promises. We are still doing it next to our jobs and life. When there’s an update that’s worth sharing, I’ll post about it. And when the new software is usable, it will be available to all of you to try and use, of course for free.

We have big plans with the new version of the software and hope that it will live up to your expectations. We are still convinced that YIO can be a powerful alternative. And we cannot thank you enough for your support and that you also believe in this project. That’s what keeps us going.

If you have ideas or any wishes what you’d like to see in the software, please share it here :slight_smile:

All my best,
Marton

12 Likes

Thank you Marton and thanks to all who have participated in the development and success of this project.
We do appreciate your effort, and I am personally sorry for not being able to give helping hand.
Looking forward for the new release when ever is it available.
Again, thank you for your hard work and for keeping this project alive.

Thanks @madf78! Also for hanging in there. I do think this new version is going to patch up all the missing features :slight_smile:

1 Like

Hi Marton, any hints you can give? You indicated in the past to consider development using node. That may enable many more people to contribute with drivers. Enabling node-red with MQTT could also open up for fast integrations with lot of available drivers.
Thanks
Jacques

Hi Jacques,

As I wrote at this point, I don’t want to promise too much, but we are looking into options to write integrations in node.js or Python to make it easier to customise it to your needs. Question is how it will impact battery life. Hopefully not significantly.

1 Like

Keep it going, although I don’t know any coding, but I am helping some translation work, and hope that one day the remote will become popular and easy to use.

1 Like

I’m with @donsuper. I’m no coder, but I do see the potential and therefore really hoping and looking forward to the new iteration of the YIO software. Keep up the good work!!

1 Like

What would get me going in terms of software is a solid Roon integration. We are not a huge number of users but we are not shy when it comes to paying for quality kit especially when it’s got roon baked in.

Roon labs have thier Nucleus and its crying out for a quality remote in my opinion.

Just my 2 cents :grin:

1 Like

Oh - this has me worried. I just managed to get hold of a kit for the YIO precisely because the software is open source.

I am a developer and want to work on the software.

Is this new version open source? Are you still going to allow the community to work on it?

The current version of the software will stay open source completely as it is now.
The new version will provide an open API, so you’ll be able to extend the functionality and write integrations.

Thanks Marton,

sounds promising. I presume it will run on both the current Yio and the new one?

Conrad

Yes, exactly. The new software will run on both remotes. Obviously there will be differences in features that are tied to hardware, like microphone and speaker, but everything else should be the same.

Hi Marton, is there any info on this? I am still not using my YIO V1 as the whole dev environment is for me too complex. Sticking with NEEO where thanks to the Meta driver you can relatively easily add driver (open source on e.g node-red or other node.js). For me this is a key criteria to jump on the beautifully designed YIO 2 hardware. Thanks Jacques

Hi, we’re still running tests and working on the core API. I cannot really say anything more at the moment, but you should be able to use the remote API from your nodejs server for example.

1 Like

Hi - I’ve recently discovered this project after searching around for various open source universal remotes. It looks very interesting, but I wanted to see if you have any appetite for moving the “state management” into a hub or dock, in the same manner as the Harmony remotes? My personal use case is to have several remotes sprinkled about which calls for a single device to maintain state. I’m a programmer and could help out if this model is of interest to you. Here are a couple of huge pros I see in favor of keeping the raspi:

  • Eliminates the screaming sounds coming from the remote’s battery as it is sucked dry
  • The USB ports on the raspberry can be used to add dongles as required, such as for zigbee or an nrf24 receiver (if you wanted to allow pairing of actual Harmony remotes)
  • The HDMI port on the raspi could be used to interrogate the system state via CEC to ensure that devices actually obeyed the commands they were sent. It might be possible to send input change messages via CEC, beyond simply “switch to me”, but I’m not sure.

Henry

Just to clarify - what I’m suggesting is keeping the raspberry pi, but moving it from the remote into a hub or dock.

Not just me who stumbled upon this project recently (I’m one of the NEEO backers and looking for an replacement with longevity in mind).

According to the spec/livestream of the remote 2 an n:m (multiple remotes and docks in any combination) setup is possible. I don’t think keeping state between remotes is much different to docks (seeing that all is connected to wifi anyway).
The key benefit of moving the “smart” to the dock is power usage for me. The remote is using battery and therefore needs to be super efficient with power while the dock is mains powered. Note that “extensions” can always be added remotely via remote calls.
The biggest issue is latency as I have seen @marton mention in various places. That is because for many operations it would require an additional hop remote<->dock which is likely to add milliseconds at least (plus the chance of issues in the comms) compared to a local remote internal call which is microseconds. Again power usage is critical there so the comms to the dock don’t eat up the power saved (e.g. BLE would likely be fine while Wifi would likely not).

@marton as you found out creating an active open source product is hard esp. if it has key usability issues (like the short battery life). I’d still advocate to keep it open as much as possible (preferably open source but at least with an way of contributors joining easily). Much of it will depend if you are planning to keep it as hobby or turning it into a full time job.
Also re-writing an application is nothing new. One learns and at some point the current setup cannot be tweaked/developed efficiently further and calls for a fresh creation. It should happen too often but it happens even for well known major open source projects.

Hi @hberg32,

I know everyone is comparing this remote to the Harmony, but we are not doing the same thing. Many things changed since the introduction of the Harmony remotes and I think it’s time to adapt.

We have purposefully moved all the logic to the remote. Many cases people already use some kind of home automation hub (Home Assistant, Homey, openHAB, etc.) so introducing an additional one didn’t make much sense for us. It’s just an overhead that we didn’t want to introduce. In those cases where users don’t have a hub, the remote is plenty fast to control certain popular devices directly and decide on logic itself.

We used an ESP in the dock to cater for the IR learning and IR sending. It has more resources than this, so functionality could be added in the future, but because of our concept of having the “brains” in the remote, a raspberry in the dock would just introduce costs, that I think isn’t worth it at the moment and would require redesign and delay the project.

@andre

We are not using a Raspberry Pi anymore, so we have proper standby and deep sleep options to work with. Lowering power consumption is key and we’re doing a lot to make sure we can save as much battery life as possible. Like scaling back CPU frequency, when not much is happening, putting the CPU to sleep when it’s not used, etc. Also doing similar things with WiFi and Bluetooth, to conserve battery power.

Having smarts in the dock and using the remote just to display things will sacrifice user experience more than it would save battery life in my opinion. Just look at how these newly announced wall panels are using ESPs and having a laggy UI. Having to wait a second more for things to show up, or wait for communication to happen between the dock and remote quickly adds up in time.

Remote being the brains and using Wifi brings another advantage: range. Using RF to communicate between the dock and remote limits the range to whatever that can reach. However using WiFi gives you more freedom and you can maybe even use the remote in places where RF wouldn’t be able to reach.

It’s not a hobby anymore :slight_smile: It has been a full time job in the past 1-1,5 years and have invested a lot (time and money) to develop Remote Two. We still have decided to open-source parts of the applications (UI and web configurator) to provide more customisation options to the community.

1 Like

@marton

I think there is a group of potential users who would be interested in an more powerful/extendable “dock” in the future (e.g. either they need cec or usb at the dock location or they don’t have an HA setup [yet]). I was wondering already if I could get the electrical contacts for charging from you and then create two kind of docks, one more powerful and the other just for charging as DIY :wink: .
(but I suspect such an discussion might be better of in its own thread)

Yes, I knew that to be true for the remote itself and suspected as much for the dock too. Thank you for confirming that it is an ESP32 in the dock which gives me a good idea of potential capabilities of your dock :smiley: .
In terms of power envelope wifi is a lot more expensive than e.g. BLE and I’m wondering how much an API call to the remote will cost (e.g. comparing to an call to the dock and that relaying it to the remote over BLE). Yes, I know 15mA for 0.5s (probably too low for wifi) doesn’t sound much but it quickly adds up to the point that it consumes more than the cpu itself. Similarly I wonder if I can actually do an API call against the remote when in deep sleep (most wifi chips doesn’t wake up quickly and need multiple transmissions).

Possibly, I think that depends on an lot of details, e.g. how “smart” the remote is (e.g. worst case it is a frame buffer with touch + buttons to the best where pretty much all the ui is in the remote while all long running/expensive tasks are delegated to the dock) and what is used for the communication too.
Just to be clear, I’m not arguing for/against your choice and was just pointing out the key pros/cons.
As far as I care the remote and dock have to work as one to maximise the benefits to the user. Some things both can do (e.g. bluetooth), some make no sense to have in the remote (e.g. an HDMI socket for CEC on the remote is probably not what users would want) and some are more useful in the remote (e.g. having to get up to wave a rfid/nfc tag or [qr] code/symbol at the dock for an action is not that useful in many cases).

True, I guess that covers the case of taking a remote to another room without an dock present to either interact with something in that room or in the room the dock is located in.
Not sure how common that use case is and not sure how BLE would compete there (low power, low latency, extended distance, low bandwidth, mesh options).
On the wifi front it might make sense to pick wifi6 to take advantage of TWT even that most users will not have wifi6 at home yet. That may well be different in 2023.

I suspected as much :smiley: . Running an open source project generating an income is a lot more difficult than an active one. From that perspective I understand that you are not opening the “core” up currently. I’m glad you opened the API and UI and I’ll see how far I can get with that. I’ll be in touch if I need more in the future.

That reminds me of an question indirectly related. Do you have an image available I could run and API details yet so that I could get an early feel how the remote 2 will work? e.g. something I can put on an ESP32 and raspberry pi to simulate the remote 2 + dock and see how my use cases are covered esp. in terms of integration.

I don’t know if you did voted feature requests and/or bounties for functionality in YIO v1. That might be something to keep some traction in the future.