This is the forum archive of Homey. For more information about Homey, visit the Official Homey website.
The Homey Community has been moved to https://community.athom.com.
This forum is now read-only for archive purposes.
The Homey Community has been moved to https://community.athom.com.
This forum is now read-only for archive purposes.
Homey infrared
Annemarie
Member
Like Emile said on friday : "If your remote cannot be found, just let us know! We're on top of making our database as complete as can be."
To make this more easy for you and for us I made a google form. Have fun and thanks in advance!
https://docs.google.com/forms/d/e/1FAIpQLSfBB5gPhwLqYG4h9_ezY1w41swtRrNlgsHLtUdfPORfpj4YhA/viewform
To make this more easy for you and for us I made a google form. Have fun and thanks in advance!
https://docs.google.com/forms/d/e/1FAIpQLSfBB5gPhwLqYG4h9_ezY1w41swtRrNlgsHLtUdfPORfpj4YhA/viewform
Comments
If you, for instance, could start with the database that the harmony logic product line uses that would be great. But I guess that would cost you big money..
Or as been mentioned many-many times on this forum: make a central database where we can directly add, rate and change IR codes by HEX, Pronto.
Don`t underestimate the power of the community. Look at the app store. Also this will allow Athom to focus on other things.
Even if such databases exist, most of the time they do not contain enough information. Regular IR devices often use specific hardware to received their specific signal. Homey can't do that, since it needs to be able to send and receive EVERY type of signal. This means we have to do really advanced things in software that other product are able to do in hardware, like noise cancelling when receiving IR. To do this we need to have a solid understanding how the signal looks like: we can't really do many smart tricks with plain prontohex codes. We need to know the start pulse of a signal, what the 'words' in a signal look like, and preferably what carrier frequency the signal uses. Regular prontohex does not provide this information in a satisfactory manner.
Since we have comparable problems on 434 and 868MHz, we've decided to use the same way of defining a signal for infrared. The LIRC database is actually quite close to our format, so it was easy to make a huge database of LIRC-signals, but as mentioned earlier, the quality of these signals (mostly the quality of the metadata) is just too low.
Over the past few months I've been working on software that can convert a bunch of related prontohex codes to our internal signal definition format. This involves some machine learning, as well as just trying to fit 'known' formats of signals. It's the closest thing to actual magic I've performed: it recognizes data out of unrecognizable blobs of IR codes. I'm convinced that part works great right now, I can safely say that piece of software is the best tested software within all of Athoms' code, so we can convert almost any hex config to something Homey can receive properly, so that's great news
The manual learning part is tricky. What Homey receives is a raw version of the signal, which is pretty close to prontohex. There are some other complex things involved, but mostly, we try to run manually learned signals to the same converter we use for the prontohex sheets in the database, so the performance of Homey with manually learned signals is comparable to those of the database. When the software doesn't know what to do with the prontohex codes, and can't convert it to our signal definition (this may happen when you're using different remotes in one learning session, or when you just teach Homey a single button) we keep it as a prontohex signal internally. Homey can send prontohex pretty okay-ish, although our signal format works better. Receiving however is sheer impossible without the extra data Homey needs to do noise cancelling, filtering, and signal matching, so we disable that if we couldn't convert the raw signal.
So yeah, we're creating our own database, but that's mostly because we want to be able to receive IR in a generic way as well. Plus, that gives us a way to do a quality check on every signal we put in our database.
TL;DR: We went for quality over quantity this time. A full database in which no config works as expected serves nobody, so we want to make sure that signals that are in the database work great
This post turned out way longer than expected xD
Thank you so much for the in depth explanation. It is very much needed at this point and is very much appreciated.
- Since you can convert between HEX and your code a partially editable central database would be more than valuable. Limited code is still better than no code.
- The receiver side of Homey used to be exceptionally sensitive. It could receive a signal shot from an other room (with 1-3 bounce). Now homey only react to every 4th-5th a signal if we direct it straight to homey. If it 10° off-course (@ 2-3m) than the signal is never `received`. I don`t know if it is due the new noise cancelling but could you please restore that sensitivity? Perhaps the noise canceling could be reduced when not in learning mode.
- Would it be possible to see the received codes in homey and edit-fine-tune the properties there?
IR is still the most widely used control protocol (after dry contact)."Regular IR devices often use specific hardware to received their specific signal"
How are the Harmony Logitech devices doing this? Over the years they have build a HUGE database of devices.
Does it work as badly in the pairing wizard (if you press a button in the list view when selecting a signal from the database it should highlight the button in blue when pressed) compared to the flow triggers?
I don't think Harmony is centered around receiving except for their own internal protocol, their main feature is transmitting right? Transmitting is easier because you don't need all kinds of noise and echo cancellation, so it's much less of a challenge to get it right (although I have to say, I'm impressed with the Harmony Hub, their metadata and labeling in their database is quite good!)
By the way, I don't know if you guys have noticed, but the signals in our database sometimes provide discrete codes as well. For example, the Samsung Most Models configuration has an explicit Power On command, so you don't accidentally turn the tv off if it's already on
That is an other reason why it would be valuable to have an editable database so we can add discrete codes too (from harmony or other sources). So those too not having harmony can benefit from the discrete codes.
Unfortunately it's not working for my (only) AV input.. AV1/AV2 don't work for me.. not a dealbreaker, but it fits my Nintendo 64 flow haha
This is exactly my point. When using a 'received' card in a Flow, you can't afford to have to do it a few times to get it to work, that would be a bad user experience. Therefore, we have to do much more noise filtering and signal parsing than the Harmony on the receiving side. Pairing may be quite similar, but there just aren't that many products that do receiving 'in the wild' precisely for these noise cancellation reasons.
(If your interested and if he allows me to share his contact info that is)
EDIT: Just tried to learn one button of my Sony TV, just to try. When I test the flow, the action keeps on spinning... (not sure if the TV is in range, but shouldn't it get a green √ ???)
they are competitors on some level. It doesn't rule out they can offer each other something. Both being startups in a similar technology. Logitech will never sell their database that's for sure. And the other databases available are of poor quality.
I definitely understand if either or both are not interested. I'm just offering a way to get them in contact with each other. Who knows what could happen.
But I also have some IR-candles with a small remote (just on/off). Homey did notice my key presses, but when I try to switch the candles on or off, nothing happens.