Sidequest: IR programming remote

[anotherjulien]

Hi all,

Let me embark you a a journey... A few days ago I used MyHOME_Suite to reprogram my outdoors Light/Motion sensor (Legrand 048834). Problem was that made it loose its Lux calibration.
In order to calibrate it you need an IR remote (Legrand 088230). I have one sure but could not for the life of me find where I had put it...
So I looked to buy another one! Surprise: you can't. It's not made anymore, and there's no second hand ones for sale, none...

All is well that ends well because I've found mine 🎉

But that left me thinking of how f*cked I would have been if I had not.
So now that I have it I'm wondering how I could now capture the IR codes it sends, and store them somewhere on this repository for posterity.
The idea would be to have something that could be replayed, by a universal remote, a FlipperZero or whatever.

Does anyone have any idea how to proceed with such kind of task ?

[Interstellar0verdrive]

I haven't tried any of this and have no way to test it, so this is just a few thoughts on the table rather than advice.

What I'd worry about in your place is capturing the raw timings rather than a decoded code, since decoders only know the protocols they know and Legrand's might not be among them. Ideas of things give you the raw pulse train: an IR receiver on an ESP32 with ESPHome's dump option, a Flipper in raw mode, or a Broadlink hub if one happens to be in the house already — the last one only if you learn through Home Assistant rather than the vendor app, I think, since then the code stays local and can be converted back to timings.

The other half is remembering what each capture means. The timings are the part nobody can reconstruct once the remote is gone; which button did what is the part nobody will remember in two years. Keeping them side by side, with the timings in something neutral rather than one tool's own file, would let a Flipper, ESPHome or LIRC each build their own from it.

Beyond that, only the obvious things you've certainly already thought of: capture each button more than once, and write down which button is which while the remote is still in front of you.

[anotherjulien]

The worst part is that the remote is not a simple multi-button one: it has a screen with something like a minimal OS.
So most of the remote is used to navigate menus inside it, and sporadically you have a multi-function button that (in context) turns into an "upload to sensor" button.
There is also an IR receiver in it, so you can also "download from sensor" in a few places.

[Interstellar0verdrive]

If the menus live inside the remote, then navigating them never leaves it — nothing goes out over IR while you move around, right?
What is actually emitted is only what the multi-function button sends on an upload, so the number of distinct transmissions worth capturing is small: one per upload action, not one per keypress. The interface is the part you can throw away.

The catch is that the emitted frame is presumably parameterised: uploading "threshold = X" and "threshold = Y" is probably the same message with different content. So the capture worth doing is the same upload repeated at several values — lowest, highest, a couple in between — and then the pulse trains compared against each other. If only a few positions change, the encoding becomes visible and any value could be built rather than replayed. If nothing obvious emerges, the handful of settings actually captured can still be replayed exactly as they are, which is already more than nothing.

The receiver you mention is what I'd want to pin down first, since it decides how much work this is. Is it used only by the menu entries that read from the sensor, or does an upload itself wait for the sensor to answer before it counts as done? If uploads are one-way, a capture is enough on its own. If they're a exchange, then replaying one means reproducing the timing of both halves, and the download direction has to be captured as well — from the sensor's side, which is a different setup.

Related, and only if the remote tells you: does it show anything after an upload that indicates it went through? That would give a way to verify a replay against a real sensor later on, which otherwise is hard to do.

For the calibration case specifically, the emit direction alone might well be enough: what you'd want in two years is the ability to push a known-good calibration back into a sensor, not to read one out of it.

[GreenGrassBlueOcean]

Hi @anotherjulien,

Capturing and preserving these rare calibration codes is a fantastic idea—especially since physical tools like the 088230 are discontinued, and losing calibration leaves people completely stranded.

However, regarding storing them directly in this repository: they should definitely be hosted in a separate repository or upstream database rather than in OpenWebNet-HA/MyHOME.

Here is why:

1. Repository Scope & Cleanliness:
   This repo is strictly focused on the Home Assistant integration for the OpenWebNet protocol over IP and Serial gateways (SCS bus). Storing raw IR captures, Flipper profiles, or hardware dumps is out of scope for the integration's codebase and adds unrelated assets to what should remain a lean driver.

2. Protecting the Core Integration:
   Hundreds of homes rely on this repository every day for their core lighting, heating, and automation. As a maintainer principle, keeping peripheral hardware sidequests and experimental hardware dumps in separate repositories keeps the blast radius of the core integration zero.

3. Discoverability (Where People Actually Look for IR Codes):
   Anyone searching for IR codes, Flipper Zero files, or raw pulse trains won't look inside the codebase of a Home Assistant OpenWebNet integration. They will look in:

   • Flipper-IRDB: The standard community database for Flipper Zero IR captures (under something like Miscellaneous/Legrand or Lighting/Legrand).
   • A dedicated GitHub Gist or personal repo: (e.g. legrand-088230-ir-remote) with raw timings, ESPHome configs, or .ir files.

Recommended Approach

Once you capture the signals (e.g. via ESPHome dump, Flipper raw mode, or Broadlink), please create a dedicated Gist or standalone repo (or submit a PR to Flipper-IRDB) and drop the link right here in this discussion thread!

That way:

• The data is permanently preserved and discoverable to the whole maker/automation community.
• Anyone in the MyHOME community looking for it in the future can find it immediately via this discussion thread.
• The core integration repository remains 100% focused on OpenWebNet.