This post is no longer relevant, new Broadlink remotes are now fully supported in HA
Ok - before I start a few points:
-
This is a kludge. Broadlink have released new RM4 IR remotes and updated RM3 Minis so that they only work with their cloud based API. This set of automations attempts to work around the fact these devices are not supported in Home Assistant by using IFTTT webhooks and the IFTTT Broadlink connector.
-
If I am lucky, someone with more skills than me will see this and hate it so much they rush out and build an integration for the new Broadlink remotes.
-
As far as I am concerned, it goes against why I like Home Assistant - for the most part HA encourages and uses local control of devices. I am not a big fan of cloud based solutions.
-
I created it because I wanted control of my air conditioners from HA. I have an older RM3 Mini that works perfectly well with HA using the local API, I bought a new RM3 and a RM4 in the hope that I could use them for 2 more a/cs but they don’t work…
-
I use SmartIR for my original air conditioner, it’s a great custom component that makes setting up the older Broadlink IR remotes a breeze, and includes a library of dozens of supported devices so you don’t have to learn IR codes. The link for SmartIR is below. If you have a supported remote I highly recommend it.
To use SmartIR as the climate control component for this exercise, you still need to set up the Broadlink components.
Start by adding the RM4 or new RM3 to your network and account using the Broadlink app.
Once you have done that, set up the air conditioner you want to control in the broadlink app and make sure all the controls and commands work as expected.
Make a note of the IR remote’s MAC and IP address. Set up your DHCP server so the remote address is reserved, it needs to remain unchanged.
Add the remote to the switch section in configuration.yaml:
switch:
- platform: broadlink
host: 192.168.0.171
mac: '24:df:a7:34:95:6d'
type: rm_mini
friendly_name: "Kitchen IR"
Note the type: entered doesn’t matter.
Install the SmartIR custom component if you haven’t already:
Add the new remote to SmartIR:
smartir:
climate:
- platform: smartir
name: Kitchen AC
device_code: 1282
controller_data: 192.168.0.171
temperature_sensor: sensor.kitchen_temperature
humidity_sensor: sensor.kitchen_humidity
Choose a device code that matches your air conditioner, or at least look through the device files to find one that matches the capabilities of your a/c.
My air conditioner looks like this:
Next you need to configure IFTTT in HA:
Lastly (for HA anyhow) add some new automations to your automations.yaml:
# Automations for unsupported attribute states are for where the SmartIR climate frontend does not match Broadlink IFTTT connector
# They reset the attribute back to the vakue it was before the unsupported atteribute was selected
# Unlike SmartIR, IFTTT Broadlink requires explicit turn on - will only trigger when climate card moves from off to any other state
- alias: 'kitchen_ac_setmode_on'
trigger:
- platform: state
entity_id: climate.kitchen_ac
from: 'off'
action:
- service: ifttt.trigger
data_template: {"event":"kitchen_mode_on"}
# Unsupported a/c modes
- alias: 'kitchen_ac_setmode_unsupp'
trigger:
- platform: state
entity_id: climate.kitchen_ac
to: 'dry'
action:
- service: climate.set_hvac_mode
data_template:
entity_id: climate.kitchen_ac
hvac_mode: "{{ trigger.from_state.state }}"
# Supported a/c modes.
# Note the 2 sec delay is to allow turn on to complete before setting mode on startup
- alias: 'kitchen_ac_setmode'
trigger:
- platform: state
entity_id: climate.kitchen_ac
to: 'off'
- platform: state
entity_id: climate.kitchen_ac
to: 'cool'
- platform: state
entity_id: climate.kitchen_ac
to: 'heat'
- platform: state
entity_id: climate.kitchen_ac
to: 'auto'
condition:
condition: and
conditions:
- condition: template
value_template: "{{ trigger.from_state.state != trigger.to_state.state }}"
- condition: template
value_template: "{{ trigger.from_state.state != 'dry' }}"
action:
- delay: '00:00:02'
- service: ifttt.trigger
data_template: {"event":"kitchen_mode_{{ states('climate.kitchen_ac') }}"}
# Unsupported temps (those either not supported by IFTTT or out of my desired range)
- alias: 'kitchen_ac_settemp_unsupp'
trigger:
- platform: state
entity_id: sensor.kitchen_climate_temp
condition:
condition: template
value_template: "{{ state_attr('climate.kitchen_ac','temperature') in [16, 17, 26, 27, 28, 29, 30] }}"
action:
- service: climate.set_temperature
data_template:
entity_id: climate.kitchen_ac
temperature: "{{ trigger.from_state.state }}"
# Supported temperatures
- alias: 'kitchen_ac_settemp'
trigger:
- platform: state
entity_id: sensor.kitchen_climate_temp
condition:
condition: template
value_template: "{{ state_attr('climate.kitchen_ac','temperature') in [18, 19, 20, 21, 22, 23, 24, 25] }}"
action:
- service: ifttt.trigger
data_template: {"event":"kitchen_temp_{{ state_attr('climate.kitchen_ac','temperature') }}"}
# Unsupported fan modes / speeds
- alias: 'kitchen_ac_setfan_unsupp'
trigger:
- platform: state
entity_id: sensor.kitchen_climate_fan
to: 'quiet'
action:
- service: climate.set_fan_mode
data_template:
entity_id: climate.kitchen_ac
fan_mode: "{{ trigger.from_state.state }}"
# Supported fan speeds
- alias: 'kitchen_ac_setfan'
trigger:
- platform: state
entity_id: sensor.kitchen_climate_fan
to: 'low'
- platform: state
entity_id: sensor.kitchen_climate_fan
to: 'med'
- platform: state
entity_id: sensor.kitchen_climate_fan
to: 'high'
- platform: state
entity_id: sensor.kitchen_climate_fan
to: 'auto'
action:
- service: ifttt.trigger
data_template: {"event":"kitchen_fan_{{ state_attr('climate.kitchen_ac','fan_mode') }}"}
These will of course need to be modified for your supported and unsupported modes, temperatures etc.
By unsupported, I mean things your a/c can do, that SmartIR knows about, that the Broadlink IFTTT connector can’t do. For instance my a/c has a fan mode called “quiet”. SmartIR adds this to the thermostat card, but IFTT can’t use it, so if the “quiet” mode is selected an automation will reject that and revert to the previous selected mode, or temperature, or whatever…
Lastly, once you have tested IFTTT and webhooks with some of the examples, you need to do the tedious exercise of adding all the events generated by the automations to IFTTT. The Broadlink connector doesn’t have templating or variables, so one IFTTT Applet is required for every possible command.
Here are mine, you should be able to work out what each of them do:
Al this took a couple of days to get working, along with testing and trying to allow for all events and use cases, but it now works seamlessly.
My RM4 works identically from HA to the SmartIR controlled RM3 Mini. When you are using the cards, the behaviour is the same, with the exception of the values reverting if you select unsupported options.
I really just did this to see if I could - but I am pleased with the result.
