I wrote an integration for Broadlink IR and RF universal remotes.
It works with RM3 Mini, RM Pro, and RM4 Mini/Pro devices. All functionality is local-only (no interaction with internet or cloud required).
The code and readme are available here:
You can also install via HPM (search for "broadlink").
The process for learning, saving, and generating codes is straightforward once you get the hang of it. Please review my readme in detail for instructions on how to use both the driver and code management app.
Thanks to @arnb and @Sebastien for all of their testing, feedback, and suggestions!
Quick note -- I added several functions to help migrate from a previous integration, which was very popular but has been abandoned for a couple of years.
There is a function provided to import codes from the previous integration. Details on how to use the importCodes command are in the readme.
I also supported some additional commands that were used by an HVAC app and others in the community.
Apps that utilized the prior driver should mostly work (possibly with very minor modifications required).
Be sure you check the readme to avoid any confusion about which commands are recommended for new usage with my integration.
I have been stuck with one RM4 Mini not supported by the (discontinued) driver you mentioned... and another one that could not be successfully added due to errors (I have two RM3 Minis that have worked fine with it for years).
To add to Tom’s note above. I have a Fujitsu mini-split and have been controlling it exclusively with Hubitat for a bit now. @tomw did some great work to ensure that it would still work with this new Broadlink integration as its device manager.
Using version 0.23 of the HVAC manager with one small code change, I continue to be able to control my mini-split.
The change required was on the child app code, on line 777. It must be updated to point to this driver instead of the previous Broadlink (Beta) one:
In Bold is the change required, but the line above can also replace the current line 777.
Once the Broadlink app/driver is installed, and the code change above has been made, I was able to go to the existing “RC HVAC Manager (Beta)”’s child app and just select this Boradlink driver. (With the change, the old one won’t appear, but the new one will.) After this, everything worked as before.
@tomw... Hit an error. I followed the Manual Installation Instructions and added the Virtual devices (for the two I already had working using the old stuff). Entered their IP addresses and their status went to idle.
Went to the Broadlink System Manager and selected "Save codes from virtual devices into this app."... I was not thinking about the fact they were new virtual devices and I would not be able to import the codes from the old ones. But, I get an error displayed instead:
Error: Ambiguous method overloading for method java.util.LinkedHashMap#leftShift. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [interface java.util.Map] [interface java.util.Map$Entry]
The logs show:
groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.util.LinkedHashMap#leftShift.
Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
[interface java.util.Map]
[interface java.util.Map$Entry] on line 259 (method pullCodesPage)
Thanks for the stress testing. Should be a quick fix.
In the meantime, you can import codes from your old setup into my integration through either the virtual devices or the app (which you can then replicate out to other devices as needed).
EDIT: @snell, your bugfix is now in the app code on GitHub. I didn't bump the HPM version, so anybody there can either Repair or just pick it up on the next Update.
Now I have to find the RM4 I stuffed away in a box once I figured I could not use it...
Imported the code update and now I can use that page without issue for the three devices (I added the 3rd Mini I had sitting in). Thanks! Waiting until 8am when they should trigger a couple robots... No idea where that RM4 is though... not anywhere I thought it might have been. Oh well.
I don't expect this to be a priority as it one may be a lot of work, and two may not be in the interest of a large group.. But I just realised (the obvious that I over sighted until now) that half my integrations of broadlink are using Rf and the other half is using IR..
Now the challenge here is that the IR side is mainly for my couple of split AC in the house which I use the thermostat driver that the deprecated broadlink integration implemented as a seperate driver that had libraries of AC commands (rather than learn every combo which is a large exercise plus complex/lengthy rules to implement). I'm assuming this lies outside the future vision of this implementation?
Give it a try to see if it works with your system. You have to edit one line in the HVAC manager child app code and then you'll be able to re-target it to a "transmitter" virtual device based on my driver.
Well, it controlled the robot(s) just like the old stuff did and was easier to deal with. Now I can finally delete that driver, app, and devices and rely on a currently maintained one.
It has several bugfixes reported by users. Thanks for all of the early feedback!
I also added a new feature in the app to rename saved codes. It's on the code management page.
You can rename codes saved in the app (including those saved in from a virtual device or imported directly into the app). Then you can sync the renamed codes out to your virtual devices as needed.
Note: If you manually installed, this update requires you to also update the bundle before you update the app. HPM will handle the full update automatically.
Is it possible to import codes from external sources, by example, IR hex codes contained in a sheet, perhaps copying and pasting somewhere? I have a Denon receiver and would like to use some discrete commands contained in an Excel sheet I downloaded from Denon site.
Thanks. Different styles. Like I mentioned I almost never use HPM and mostly just to add my driver stuff IN because some users ask for them to be that way. Oh well.
Couple points of APP feedback:
Is there any way to make the triggers for performing a command (like Rename selected code) be buttons and not radio buttons? Maybe this is a limitation of apps (I do not write them)... but it seems very odd to have radio buttons that basically perform a quick action.
Is the Import hex codes field supposed to remain populated with whatever was last imported? Mine has not cleared out yet... but obviously I no longer care now that they ARE imported. I would be looking (if I needed to) to import the next batch of codes, not looking at this one.
Few points of driver feedback:
Could the device's MAC address be provided as a state/event? This way it could be used by other apps/rules to check on the device. Maybe using something like an hourly network client check.
What does the "count" state variable mean in the driver?
Does any of the data returned provide the device type so we could have that shown somewhere to make life a touch easier (even as a state variable)? Help identify the RM 3 Mini vs the RM 4 Mini, etc...
Plus, not something you have control over... wouldn't it be nice to have dynamic commands in the drivers so if someone enables the RF in preferences then the RF commands would show (but not before)...
The Hubitat app UI framework is really limited. I'll spare you the details, but "normal" app buttons weren't able to give me the user experience I was hoping for -- with the workflow being able to interact with and navigate between pages of the app quickly to move codes in multiple directions for multiple devices.
Radio buttons were the best way to achieve what I wanted, and they work well even if they look a little bit weird. You can spend a lot of time and code making the app UI only a little bit better, so this is where I ended up. I'll take another look now that the core functional features are there in the app.
Is the Import hex codes field supposed to remain populated with whatever was last imported?
Not specifically, but I left it there because I didn't want to be over-aggressive in clearing it, just in case the input was still useful even though it might be gone from the clipboard. I think a good medium would be to clear it when Done is pushed (on installed/updated), but to leave it during an active app session. I'll make that change in the next version.
Could the device's MAC address be provided as a state/event?
Are you looking for a visual check or something you can interact with in your code? If it's visual, the MAC is in State Variables (it's a member of devDetails)
What does the "count" state variable mean in the driver?
Nothing useful. It's just an increasing count that gets applied to the device API messages. It's a count of every packet sent since the last Initialize on the virtual device.
Does any of the data returned provide the device type
The device has an ID, which is stored in devDetails in State Variables. But otherwise the names aren't identifiable from the device itself.
They frequently release new versions of the same products but with changed IDs, and trying to provide a lookup of other info based on ID is part of what caused the old integration to rot quickly. So, I chose not to try to display a name, since it doesn't really make a functional difference anyway.
EDIT: forgot one:
Plus, not something you have control over... wouldn't it be nice to have dynamic commands in the drivers
Select a Transmitter device", required: false, multiple: false, submitOnChange: false
Should be a quick fix.
