Here just to say thank you for this.
Been looking for a way to get my HE to work with my rm without having to involve another link in the chain.
Working great so far and the logic you used is quite smart. Great job and thanks again :).
Just wanted to add my thanks to @cybrmage for the work of making this driver. I bought a Mini3 to use with a Lasko ceramic space heater:
https://smile.amazon.com/gp/product/B000TTSXNI/
While I had a Zooz Zen 15 to turn power off and on, I still had to hit the power button on the heater or remote to get it running so it couldn't be truely automated. I wasn't sure the Mini3 would work since I wasn't able to locate any codes for this heater to use with an IR blaster on a Raspberry Pi and my attempts at learned codes didn't work. The Mini3 worked fine using IHC and the Hubitat driver from cybrmage was a breeze to get working.
Why do I still have the Zen 15 on it? The heater has a pretty high draw even when not providing heat. I guess it takes a bit of power to wait for an IR signal and run the thermostat on the Lasko. I'd rather spend that $5 per month on other smart home devices than give it to the power company.
I have just posted an update to the driver AND the first BETA of the management application.
It is available in the first post.
3 Likes
Nicely done bro. I like the sync'ing of codes idea. What do you think of the idea of creating virtual child devices under each device for each remote? You could then say, create a device for an AC unit, assign the appropriate codes for the switch on/off. You could then present that to something like google/alexa.
2 Likes
I created a simple rule to manage my heater and used a virtual switch as the trigger for the rule. I then exposed the virtual switch to Amazon Echo Skill in Hubitat and can now control on/off via voice.
A brief description of what the management application does in the first post of this thread would be a good idea.
Aye, I've done that as well, but if you had a device presented you could do more than just trigger via on/off.
The link to a .Zip file makes this much easier to use! Thanks for this! Looking forward to receiving my Broadlink devices so that I can start using this!!!
Sébastien
1 Like
I had no choice... A post can be at most 60K... The driver is 57K and the app is 31K...
2 Likes
Has there been a change to the device driver that now prohibits use of hostnames instead of IP addresses?
I've got DNS resolution on my LAN, and would rather not configure all my devices with fixed IPs. However, with v 0.31 of the driver I'm seeing the following error in the logs:
2020-01-23 02:48:46.749 am [error](http://hubitat/device/edit/552)java.lang.NumberFormatException: For input string: "rm3-mini-office" on line 220 (updated)
There has been no change... The driver has NEVER supported hostnames.
Hmmm... OK.... I guess that what happened was:
- initial configuration with IP address (driver v. 0.20)
- Changed driver preference to use hostname
- no DHCP change, device continued to work
- added additional RM devices via hostname your new application -- no manual IP entry
- moved devices (DHCP supplied addresses changed, hostnames remained, DNS updated)
- UDP timeouts & error message reported above
Would you consider a feature request to specify the device via hostname or IP?
The application does not support manual addition of devices... If you added the device in the app, it would use the IP address determined from the discovery process and not the hostname (because the devices do not report their hostname in the discovery process).
Also, the devices (drivers) that you manually install (a Standalone device) are totally separate from the devices (drivers) that are installed by the application (a Child device).
It's rather trivial to have the application update the IP address for the devices it has configured, as it runs the discovery process each time the device configuration section is entered... (This feature has been added to the next release, v0.32).
As the underlying UDP system relies on the device IP and MAC addresses (there is a function to get MAC address from IP address, but not a function to get IP from hostname), adding hostname support is less trivial... It is something I will look at adding, but not in the immediate future.
New release - V0.32 - Available from the first post.
That doesn't make much sense....but, given the timestamp on that post, I'm surprised it's even close.
I meant to say something like "added additional RM devices via your new application -- no manual IP entry needed"
@cybrmage, I just received my BroadLink RM pro+, installed the application (V0.32) and driver without any problems and started learning codes.
There are some codes that I need to remove. I have followed the process, and initially it worked, but now they won't remove themselves. I get the following messages in the log:
[app:428]2020-01-23 20:03:45.074 debug no code to edit
[app:428]2020-01-23 20:03:44.798 debug Removed Stored code: [HunterFan-Low]
I rebooted, they were still there. Tried removing them again, but no luck...
Any recommended next steps?
Sébastien
Those log entries are correct. The "Remove stored code" button short-circuits the edit process... Clicking the button deletes the code then reloads the edit page... which then determines that there is no code for it to display and redirects to the code management display.
The codes are stored in a state variable. State variables are stored, by the system, to a database. Rebooting will never remove a code... (unless you have a corrupt database... but that's an entirely different problem)
And, where exactly is "there"? Do they still display in the list of available codes? Are the still showing in the drivers codeStore?
I've tried to replicate the problem and can not... So I will need some more logs... Please turn on "debug" and "verboseDebug" on the main page, and try to delete the code(s) again, and post the entire log of the process (everything from "(CodesPage) params [null] editing [false] adding [false] newCodeName [null]" on...)
As a workaround, you can rename the codes that won't remove (ie: "deleted1", "deleted2", etc)... You can then use the desired name for a new code... You can then delete the codes once the app problem is resolved...
Ok... I've been able to replicate the issue...
And... It's not a bug... it's a FEATURE...
Really... It's a feature...
You have configured your device and started learning codes... You then used the Sync" function to send the codes to your device. So far, so good...
You then decide to remove a code... You click on the code, then click on the "remove stored code". The app then removes the code and returns to the code management page... Here's where things go wrong...
Every time the app loads the codes management page, it imports the stored codes from each of the configured devices. This import process restores the code that you just deleted.
SO... I should probably make the automatic code import an optional feature...
To work around this, go to the device management page... That page will show your configured device(s) with the number of stored codes. Click on the configured device. The device edit page will open. Click on "Remove Stored codes", then click on "Done". You can then go back to the Remote Codes page and will be able to delete the code.
Once you have learned all the codes you need... You do NOT need to "sync" the codes to your devices...
One of the "features" added to the device driver with the release of the application (and not yet documented) is the ability of the driver to load a stored code from the application.
IE: You start with no codes stored in your device or the application. You learn a single code, named "Test1" and then sync it with your device. You then learn a code named "Test5" but you do not sync it with your device. You then you issue a sendStoredCode command and pass "Test1" as the codeName (using the driver or RM). The driver finds that it has a code named "Test1" and sends it to the device. You then issue another sendStoredCode command and pass "Test5" as the codeName. The driver does not find a stored code for the name "Test5", which would, in a standalone device, be an error. With an application child device, the device asks the application for the code, retrieves the code data from the application and sends it to the device.
Soooo..... You are seeing an artifact of the development process... The driver was developed first, so needed code storage... then the application was developed, which made the on-device code storage obsolete.
New release - V0.33 - Available from the first post.
Well, after reading your description, I tend to agree that there is definitely an underlying feature! 
It makes sense - I ran into this only after syncing.
I am now getting an error when attempting to follow the above step (Still in V0.32):
Unexpected Error
An unexpected error has occurred trying to load the app. Check Logs for more information.
Error: Cannot get property 'devTypeName' on null object
The logs show:
[app:428]2020-01-23 21:51:41.976 [error]java.lang.NullPointerException: Cannot get property 'devTypeName' on null object on line 524 (editDevicePage)
[app:428]2020-01-23 21:51:41.916 debug editing activeDevice: [null]
While waiting for your reply, I programmed another device in the unit using the ihc app on my iPhone, might that be the cause of the new error?
