HAIR: Admin UI for your Infrared Network - Capture, Store and Trigger IR Devices

[Andres_Arenas_Velez]

Thanks for your prompt reponse, yes I see a NEC protocol in front of the command and toggle it to PRONTO. Cheched with 2 and 3 on both protocols and nothing happened. I see the deivce led blinking, but its not working.

[DAB-LABS]

Thanks for running all that and reporting back, the detail helps a lot. The LED blinking tells us the RM4 is firing, so the code is going out fine, it’s just not landing on the fan. I’ve got a hunch, and it might actually be a bug I’ve already reported upstream.

Here’s my barber to explain it.

Here’s what looks like it’s happening. When HAIR hands your code to the RM4 to send, the RM4 shrinks every part of it by about 7% on the way out. That’s an old bug in the Broadlink library’s timing math, not in your codes and not in HAIR’s conversion, both of those are fine. Your AC is easygoing and doesn’t mind a slightly-off code, so it works. The fan is pickier, and a 7%-short code just gets ignored. That’s also why flipping to RAW and bumping the send count changed nothing, the shrink happens right as the RM4 transmits, after all of that.

There’s a clean way to prove it: send the original code straight through the Broadlink integration, skipping HAIR, so it goes out full size with no shrinking.

Developer Tools, then Actions, pick remote.send_command, target your Broadlink remote, and for the command put b64: followed by the fan’s Power code (the JgBoAAAB... base64).

If the fan responds to that but stays dead through HAIR, your codes are good and the RM4’s timing is the culprit, which is exactly the bug DAB reported. If it does nothing either way, then the downloaded codes just aren’t right for your fan, and the fix could be learning your own.

Give it a go and let us know which way it lands.

~ DAB

[Andres_Arenas_Velez]

Hi, yes, the codes work using remote.send, I actually use them and have a fan entity wrorking with ARSmartIR. But the project is now archived, and it’s clear the future of IR is trough you integration. By the way, is there a manual or something, thare a re lots of buttons and terms that don’t make much sense just looking at them, but is an awsome job you are doing.

[DAB-LABS]

Thanks for running that test, and it confirms that this is the bug in the Broadlink core software.

I have opened an issue with the maintainer, and I am in constant communication with the infrared team at Home Assistant.

Two ways to get that fan going in HAIR meanwhile: keep driving it with remote.send / ARSmartIR like you are, or point HAIR at a non-Broadlink blaster if you have one (an ESPHome board, say), which doesn’t do the shrink. Once the Broadlink fix lands, the RM4 will just work too.

Hopefully we can fix that at the core level, as Broadlink has a large install base.

And thank you, that means a lot, especially with ARSmartIR winding down. On a manual: the closest thing right now is the README on the repo, it walks through each tab and what the pieces do, though it’s a lot to take in at first. If you tell me which buttons or terms threw you, I’ll make sure they get spelled out better.

It takes a village, thank you.

~ DAB

[Andres_Arenas_Velez]

Well, there’s no rush, Its working with the other integration and I can see HAIR is grouing to unify all the efforts. Thank you for that!. I don’t have any orhter blaster yet, I’m actually moving and planning to add another 2, but not sure what to buy. I’m planning on buying this https://www.athom.tech/blank-1/esphome-rf433-ir-remote-controller … seems solid and add bluetooth.

[Andres_Arenas_Velez]

Well I can confirm my Airco is fully functional, I created the classe-mtdb-12cf-q-2.perfect-fit.wig.json. How can I Share it?

[DAB-LABS]

There’s a lot of users reporting that they enjoy that one, but if you get it, update to the latest firmware.

3.0 was misconfigured and was piping RF into the IR side.

~ DAB

[Andres_Arenas_Velez]

I’ll do as soon as I get it, thanks. Now I hace a new issue, i’ll report it here but, If you want, I can make the report on github.
The climate entity is not storing the state (The Matrox Cell), so when I reboot home asistant is off and the fan seed is null.
Here are the current states:

climate.master_bedroom_classe_airco
State: cool
hvac_modes:
  - 'off'
  - cool
  - dry
  - fan_only
min_temp: 17
max_temp: 30
target_temp_step: 1
fan_modes:
  - high
  - medium
  - low
current_temperature: null
temperature: 23
fan_mode: low
matrix_cell: 'cool / fan: low / 23'
assumed_state: true
friendly_name: Classe Airco
supported_features: 393

After I restart Home Assistant:

climate.master_bedroom_classe_airco
State: off
hvac_modes:
  - 'off'
  - cool
  - dry
  - fan_only
min_temp: 17
max_temp: 30
target_temp_step: 1
fan_modes:
  - high
  - medium
  - low
current_temperature: null
temperature: 23
fan_mode: null
matrix_cell: null
assumed_state: true
friendly_name: Classe Airco
supported_features: 393

And the current fan speed in blank.
Another thing I noticed is that, when HAIR creates the entity, theres nowhere to provide the current temperature. I am controlling the change of states using an Automation, but stil, the climate entity should know about that, maybe also the humidity if available.

For the moment I created an Automation to keep the attibute updated:

alias: Airco - Update current temperature of MB Airco
description: >-
  Airco - Updates current temperature of climate.master_bedroom_classe_airco
  from RM4 Mini.
triggers:
  - entity_id: sensor.rm4_mini_01_temperature
    trigger: state
  - entity_id: climate.master_bedroom_classe_airco
    attribute: current_temperature
    to: null
    trigger: state
conditions: []
actions:
  - action: python_script.hass_entities
    data:
      action: set_attributes
      entity_id: climate.master_bedroom_classe_airco
      attributes:
        - current_temperature: '{{ states(''sensor.rm4_mini_01_temperature'') | float(0) }}'
mode: restart

-Andrés.

[DAB-LABS]

All this great feedback, thank you so much!

I have this on the road map to retain the data after a reboot. Give me a bit to put it in. I’ll let you know when it’s done.

Temperature and humidity levels are not something we will have in our device, as IR is one-way communications. Users will continue to have to pipe that information in from another sensor.

~ DAB

[Andres_Arenas_Velez]

“I get it, but since you built the climate device, it feels a little incomplete without the current temperature (especially since the attribute is already there, just always null). I can work around it by injecting the value like I showed you, but it would be cleaner to just let us set a sensor to feed it, the way SmartIR does. Still, it’s your project and it’s looking great so far!”
About the initial values, it would be great! since I shutdown/restart @3am for backup and then the climate controls don’t work since the device is “off”. I’ll fix it in the meantime what an automation to turn it on on reboot. Im also will try with another fan I have, different brand to see if importing for that one works. I read this sankey don’t even work with generic remotes, maybe I’ll have some luck with the other one.
-Andrés.

[DAB-LABS]

Interesting, tell me how you see that working? Where would you expect to set that?

~ DAB

[Andres_Arenas_Velez]

When you use a tile card (or more info) with the climate entity you will see the current temperature right away. It’s part of the generic thermostat template, and tht way you can use the climate temperature to get the room temerature right away. Its just for have all the values on the same place where it make sense.

[DAB-LABS]

That makes sense. How would you see setting it in the UX?

~ DAB

[corenovaleet]

this is feeling way to complicated, read me is about a year long,

[DAB-LABS]

IKR!

IR is nuanced and HAIR gives you a lot of levers.

I do have plans for tutorials and videos. Bear with us as we build out the bones and plumbing, first…

Ultimately, we will create individual integrations, over time, for often-used IR devices, which are going to be dead simple integrations.

~ DAB

[Andres_Arenas_Velez]

Could a configuration option in the device. Next to the : you often see a cog icon to configure options. There, I will let the user specify either the entity that provides the current temperature or a template field, so the value can be extracted from any source, such as an attribute of another entity.

[DAB-LABS]

I like that idea. I’ll add it to my to-do list along with power monitoring…

~ DAB

[tim.plas]

Re power monitoring as on/off feedback:

Could you also consider other sensors, to provide the feedback in other ways? For example, I’m currently about to set up an IMU or tilt sensor to detect whether airco louver has opened, to get my on/off feedback for automations.

I’m wondering if you could accept anything presented as binary, like a binary sensor template that interprets some physical sensor such as power usage, tilt angle, light sensor, etc.

[Nuuki]

@DAB-LABS

Pick “Other” as the type and HAIR doesn’t make a fan or climate entity at all. You get a remote entity and nothing that claims a state or a room, which might be the remote.fan you were hoping for. The typed ones (fan, AC, light) are what create the fan.something with all the state assumptions, and that’s the part it sounds like you’re avoiding since you derive state yourself from power and sensors.

Every device also gets a pressable button per command in the UI. They don’t hold state, they just fire the code, so you can disable or ignore them, but they do show up.

It fits how you already work. HAIR keeps the codes grouped and named, your template entity stays the source of truth for state and availability, and you fire at it by name with remote.send_command.

That worked great. In my old approach I would target an emitter remote entity and include the device and command, and with HAIR I would target a device specific remote entity. That’s no problem at all, and indeed using the per command buttons is arguably much nicer, as no need to remember the command string.

[Nuuki]

@DAB-LABS

Do you think if I gave devices the ability to query power usage to derive on and off states, that that would be beneficial?

Yes, but I would probably advocate not to get too locked in on power. For example my TV has an integration, but allowing it to turn the TV on involves leaving it with high background power draw, hence why I turn on now using IR. So in that case, the state of the media entity would be a very practical and meaningful source for TV state.

So as a new feature I think it would be fine to stick with power, but if you can build it in just a way that allows for more flexibility than that (e.g. allowing linking a binary_sensor) over time, that would be ideal.