Thursday, 6 December 2018

Green Millhouse: OK Google, turn on the living room air conditioner

My Broadlink RM3 IR blaster has been working pretty well, so I thought I'd share how I've been using it with a couple of IR-controlled air conditioners in my house, to control them with the Google Home Assistant via OpenHAB.

The RM3 sits in a little niche that has line-of-sight to both these devices (a Daikin in the living room, and a Panasonic in the dining area). Using the RM-Bridge Android app, the fun2code website and the method I've documented over on the OpenHAB forums), I've learnt the ON and OFF codes for each device, and put them into transforms/broadlink.map:
PANASONIC_AIRCON_ON=D3ADB33F...

PANASONIC_AIRCON_OFF=13371337...

DAIKIN_AIRCON_ON=F00F00FAAFAA...

DAIKIN_AIRCON_OFF=F00D00FAAFAA...

The "basic" way of invoking the commands is by using a String Item for your IR-blaster device, and a Switch in your sitemap, like this:

items/remotecontrollable.items:
String RM3_MINI {channel="broadlink:rm3:34-ea-34-58-9d-5b:command"}

sitemaps/default.sitemap:
sitemap default label="My house" {
  Frame label="Aircon" {
    Switch
      item=RM3_MINI 
      label="Dining Area"
      mappings=[PANASONIC_AIRCON_ON="On", PANASONIC_AIRCON_OFF="Off"]
  }
  ...
}

Which gives you this:

... which is completely fine for basic UI control. But if you want the Google Home Assistant (aka "OK Google") to be able to operate it, it won't work. The reason for this is that the Switchable trait that you have to give the item can only take the simple values ON and OFF, not a string like PANASONIC_AIRCON_ON. So while it *might* work if you named your remote control commands ON and OFF, you're hosed if you want to add a second switchable device.
The best solution I could find was to set up a second Item, which is literally the most basic Switch you can have. You can also give it a label that makes it easier to remember and say when commanding your Google Home device. You then use a rule to issue the "command" to match the desired item's state. I'll demonstrate the difference by configuring the Living Room aircon in this Google-friendly way:

items/remotecontrollable.items:
String RM3_MINI {channel="broadlink:rm3:34-ea-34-58-9d-5b:command"}
Switch AC_LIVING_ONOFF "Living Room Air Conditioner" [ "Switchable" ] 

Notice the "label" in the Switch is the one that will be used for Google voice commands.

rules/remotecontrollable.rules:
rule "Translate Living Room ON/OFF to aircon state"
when
  Item AC_LIVING_ONOFF changed 
then 
  val isOn = (AC_LIVING_ONOFF.state.toString() == "ON")
  val daikinState = if(isOn) "DAIKIN_AIRCON_ON" else "DAIKIN_AIRCON_OFF"
  RM3_MINI.sendCommand(daikinState)
end

This rule keeps the controlling channel (RM3_MINI) in line with the human-input channel (the OpenHAB UI or the Google Home Assistant input). Finally the sitemap:

sitemaps/default.sitemap:
sitemap default label="My house" {
  Frame label="Aircon" {
    Switch item=AC_LIVING_ONOFF label="Living Room On/Off" 
  }
  ...
}

I quite like the fact that the gory detail of which command to send (the DAIKIN_AIRCON_ON stuff) is not exposed in the sitemap by doing it this way. You also get a nicer toggle switch as a result:



The final step is to ensure the AC_LIVING_ONOFF item is being exposed via the MyOpenHAB connector service, which in turn links to the Google Assistant integration. And now I can say "Hey Google, turn on the living room air conditioner" and within 5 seconds it's spinning up.

5 comments:

  1. Quick comment, you do not need the `;` at the end of Xtend code lines. Except for return
    Your rule could be made a bit simpler:

    rule "Translate Living Room ON/OFF to aircon state"
    when
    Item AC_LIVING_ONOFF changed
    then
    var daikinState = "DAIKIN_AIRCON_OFF"
    if (AC_LIVING_ONOFF.state == ON) daikinState = "DAIKIN_AIRCON_ON"
    RM3_MINI.sendCommand(daikinState)
    end

    This way if the item changed to OFF or NULL (Reboot,reset...), the aircon defaults to OFF

    OR

    rule "Translate Living Room ON/OFF to aircon state"
    when
    Item AC_LIVING_ONOFF changed
    then
    if (AC_LIVING_ONOFF.state == NULL) return; // Do nothing
    RM3_MINI.sendCommand("DAIKIN_AIRCON_" + AC_LIVING_ONOFF.state.toString)
    end

    ReplyDelete
  2. First of all, many thanks for taking over the development for the binding, publishing it to GitHub and your continuous improvements! I am really looking forward to see this integrated in openHAB. By the way: you can create PRs for their repo with [WIP] in the title and continue working as usual. This has the benefit that there are automated checks and builds for every commit you make. After you feel that the binding is ready for review you can simply remove the [WIP].

    I was on your GitHub page, unfortunately the issue option seems to be disabled, so I cannot create any issues there.

    Regarding this post: I don't like the described rule approach much. I mean - it works, but it is not that easy and intuitive to use. I thought it might be possible to directly use a switch item, although that will require some rethinking on how to "map" the broadlink commands to the switch.

    ReplyDelete
    Replies
    1. Hi - thanks for the comments. I'd actually assumed that the missing "issues" tab was because my binding's repo is a fork of the OpenHAB addons repo - I'll have a hunt to see if it can be enabled. It makes sense to use it if at all possible, the thread over in the OpenHAB forum is getting pretty crazy!

      Re: the rule approach - I completely agree, and I think this is probably an abuse of the rules system. But I could not figure out any other way to (as you say) "map" the commands to a switch. The documentation suggests some application of a regex transform should be possible, but I was unable to get anything I tried to work.

      Delete
    2. Maybe the issues tab is not enabled by default when forking some project. However you can enable it in the settings - there should be a tab next to the "code" "pr" etc. tabs where you can change that. The only thing I am currently thinking about is whether it makes sense to track the issues there. The other option would be to use the issues from the original addon repo, although the broadlink binding is currently not merged there, so it might confuse people and also makes finding issues harder. Either way - issue tracking would be nice :)

      Regarding the "mapping": I just thought about it again. The current problem seems to be that one needs to configure an item, although I guess openHAB does not expects items to be configured with config options. However openHAB offers a "bridge" thing (https://www.openhab.org/docs/concepts/things.html#bridges) which could be used to set up the broadlink device and after that one could create other things for the devices to be controlled by the broadlink device. Those things can have config options for inserting the codes and a switch channel to link an item to it. Will probably need some work and restructuring, though.

      Delete