Feature request: add support for UFO-R11 controller

[boardlord1]

Hi, great to see this fork!

Could you please apply this pull request to support this zigbee controller?

https://github.com/smartHomeHub/SmartIR/pull/1137

[litinoveweedle]

Hello @boardlord1 , thank you taking this issue to my notice. I check other cross referenced PR and I am more inclined to used other implementation as it seems to me more complete PR1778.

Mentioned PR1178 was tested with Tuya1201 / Moes Universal Remote. Is this also compatible with UFO-R11? I am asking as I see that PR1137 uses MQTT transport and PR1778 using zha quirks. One of the issue with the implementation in PR1137 seems to be that it uses different code format and therefore all distributed codes will therefore probably not work.

[boardlord1]

Hi, the reason I asked for the this PR is that I'm using Zigbee2mqtt as my zigbee backend, not ZHA - thus, mqtt would be a must...

For the moment I added this through hand-editing controller.py based on the PR, but that wouldn't be practical to do after each update

[litinoveweedle]

Thank you for reply, I understand your motivation. I can add both support (MQTT/ZHA), but I need to know if you can use out of the box codes distributed with SmartIR with the MQTT implementation. If not I will need to check if the codes can be translated automatically from the default SmartIR format to the format required by the UFO-R11 controller. My motivation is to allow to use codes distributed with SmartIR natively with any controller implementation.

Can you please clarify this for me? Thank you.

[boardlord1]

The only difference I've noted between this and the existing support for MQTT-based controllers is the need to use "ir_code_to_send" before the actual IR code. By using Zigbee2mqtt to learn codes and adding them to a json, and if I set the controller type to ufo r11 in it, everything works fine

[litinoveweedle]

Yep, using Zigbee2mqtt to learn codes for you device would work. The question is about the codes stored in the Broadlink format and distributed with SmartIR. This would raise a lot of issues if the out of the box delivered codes will not work with the provided controller.

[boardlord1]

By the same token, a Broadlink controller couldn't make heads or tails of a json with Xiaomi or MQTT codes ;) One always has to look at the json to see which controller it is for. Most are for Broadlink, but that's because it's the most popular controller.

But, I've found this - might be of use.

https://gist.github.com/svyatogor/7839d00303998a9fa37eb48494dd680f

[litinoveweedle]

Ok taking back previous statements, you are completely correct. The encoding in the recorded json data file has to match the one supported by the controller. I just created branch for ZHA zigbee implementation and I will merge MQTT support as well.

[boardlord1]

Thanks so much 🙂

[litinoveweedle]

One more question. I read original discussion and I am not completely sure, if this comment is not valid. This implementation is just slightly modified MQTT requiring prefix and could be handled by existing MQTT controller if mqtt_prefix parameter will be added to controller_data... What do you think, is this worthy of dedicated controller or would be extending MQTT controller more versatile future proof implementation?

[boardlord1]

Json is so picky when it comes to formatting... I baned my head a number of times editing them 🙂

So I agree with this comment: https://github.com/smartHomeHub/SmartIR/pull/1137#issuecomment-1857156795

[litinoveweedle]

OK, I understand. I merged the original PR into branch, before merging into master and releasing it I would like to ask you to test it. Just replace controller.py, restart HA and test the functionality. Thank you

[litinoveweedle]

Also would you please mind sharing your smartir configuration to be used as example in the docs? I would say it shall be same as MQTT....

[boardlord1]

Thanks, I've just tested controller.py from your branch aimed at supporting this IR blaster, and worked perfectly!

This is just a quick json I've hacked together, learned the on/off codes for my AC (used the fan platform to get a simple on/off button):

{
  "manufacturer": "Test",
  "supportedModels": [
    "Test"
  ],
  "supportedController": "UFOR11",
  "commandsEncoding": "Raw",
  "speed": [
    "low"

  ],
  "commands": {
    "off": "CUMRQxFbAmYGKgJAAUAHQAPAAeATC8Ab4AMHQAvAA0ABwAtAB+AHAeADE0ALwAPgFwHAJ+ADBweUFEMRQxEqAkATQAFAB0ADwAHgEwvAG+ADB0ALwANAAcALQAfgBwHgAxNAC8AD4BcBwCcLZgYqAmYGKgJmBioC",
    "default": {
      "low": "CUkRSREqAmcGKgJAAUAHQAPAAeATC8Ab4AsHQBPgBwNAAUAT4A8B4BsbQCPgCwMHihRJEUkRKgJAG0ABQAdAA8AB4BMLwBvgCwdAE+AHA0ABQBPgDwHgGxtAI+AIAwIGKgI="
    }
  }
}

And this is my entry in the Home Assistant config:

fan:
  - platform: smartir
    name: UFO Test
    unique_id: ufotest
    device_code: 9997
    controller_data: zigbee2mqtt/MOES Remote/set

I only have the full suite of codes for my AC in Broadlink format, but I'll most probably take the time to re-learn them for this IR Blaster as it being battery-powered is so much more convenient.

[boardlord1]

Maybe just a small tweak to the documentation 🙂 With Zigbee2mqtt, you need to set "controller_data:" to "zigbee2mqtt/FRIENDLY_NAME/set", where FRIENDLY_NAME is how the IR blaster is called in the Zigbee2mqtt GUI

[litinoveweedle]

thnak you, updated.

[boardlord1]

Oops, noticed that it's still not correct, sorry 🙂

See the Zigbee2mqtt support page for this IR blaster: https://www.zigbee2mqtt.io/devices/UFO-R11.html

In "zigbee2mqtt/FRIENDLY_NAME/set", FRIENDLY_NAME refers to the name you set for the device within Zigbee2mqtt