#IR timings
buoyant sigil
So I checked with Anna from flipper
I think we don't really have a proper DB, just some community sourced signals for the universal remote bit. And there's not a lot. The numerous "flipper irdb" repos are just someone else converting files from the actual irdb (an old project) to the flipper format
Existed before flipper
i'd recommend to have your own mechanism to submit and gather ir/rf signals though, maybe as a part of your new device registry project? The existing DBs are huge but not well organised, lots of useless and unconfirmed stuff. Can definitely help as a starting point though
deft bluff
This is the one the Flipper community uses and is linked from various community websites https://github.com/Lucaslhm/Flipper-IRDB/
not official, but a community resource
I suggest we can approach it as follows:
- we still allow our own files (duh)
- but we also allow code identifiers that map into Flipper-IRDB (we bundle that into our package).
get_codes("Flipper-IRDB/TVs/LG/tv.ir")
I don't want us to start gathering all IR codes of the world and have another 1000 PRs / day on our queue ?
buoyant sigil
I don't want us to start gathering all IR codes of the world and have another 10...
I mean at that point you'd have a new language leader setup, as in, donating IR codes would be the same as donating Korean intents, I would have no clue if it's true
But even if we're scared of that, just offloading that to another repo/maintainer also doesn't sound like the right thing to do
deft bluff
No one has any way to verify anything unless you have the device
There are two discussions I guess. One is to embed that project and second is where to send our community to contribute
deft bluff
If we can standardize the whole world on device database that be great. However it's a lot of work to ramp up
deft bluff
Circling back to opening post. We should migrate to the flipper standard and not make something new
buoyant sigil
adhering to existing standards is always nice
Maybe a good moment to check how they do RF before we merge the whole thing
deft bluff
Already did and adjusted
Also want to simplify IR python classes because of that https://github.com/home-assistant-libs/infrared-protocols/issues/15
We over engineered it
half wren
I've left comments on both the proposal to drop the Timings dataclass and the PR to replace python classes with text files.
Just loading LG TV codes instantiates 1326 instances.
I don't think this happens. What am I missing?
The class is there to make code properly typed and easier to read.
We should just ship a small wrapper around the Flipper-IRDB
And never support air conditioners? 😄
as I've mentioned in the PR, defining codes is the least of our worries and can be done easily both manually or using an LLM. Also, the flipper format is much more verbose than ours.
Also, I think
power = make_lg_tv_command(LGTVCode.POWER)
is much nicer and idiomatic than:
codes = get_codes("lg/tv")
power = await codes.load_command("POWER")
(and does no i/o eheh)
bleak adder
Not sure if you've seen this: https://github.com/smartHomeHub/SmartIR. It has its own json based database
half wren
if I'm reading the files correctly, those are hardware-specific raw sequences, which only work with a specific hardware (i.e., a broadlink one would not work with esphome unless there's a converter)
bleak adder
it has one json definition per target and it supports multiple controllers..
tulip ruin
SmartIR supports multiple controllers in theory, but in practice all the contributions are tied to the native format of the controller the user who contributed it was using. This is largely a byproduct of the way the remote platform is designed without consideration of portability (as the original intention seems to be use as a learning remote, and ability to send arbitrary commands from outside seems to have been hacked on afterwards).
Has the decision to drop Timings like this been properly considered? I have spent effort making both emitter and consumer custom integrations since the 2026.4.0 release, and it leaves a bad taste in my mouth that these are going to break suddenly with the release of 2026.5.0 with no deprecation period.
buoyant sigil
Has the decision to drop Timings like this been properly considered? I have spen...
If we'd deprecate this we'd do this properly ofc
tulip ruin
It seems the change has already been made though, in the 2.0.0 infrared-protocols library with a corresponding change in HA to use that version of the library in the dev branch (which I assume is going to end up in 2026.5?)
