I have a RM pro+ Firmware 57. A different RF remote relay has a similar issue. Happy to post the test here in case it helps someone else.
debugauthResp = 070000006760AF056760AF056760AF059ED32575000000000000000000000000
debugscanResp = 0000000000000000000000000000000000000000000000000000000000000000ABC60000000007000000000000000000000000009D270C00A8C0274FB9770F780000000000000000000000000B180B18160D170C170D0A190B18160D160D0B18170C0B180B19160D0B180B18160D170C170C0B180B190B18170C170C0B180A18
From now on I'll remove the repetitive same responses
RF Relay
debugsweep successful: freq = 0
debugparseRF resp = 1A000000000000000000000000000000
debugparseRF resp = 19000000000000000000000000000000
Had to redo the sweep as the Broadlink locked up and got this result from the RF Relay
debugparseRF resp = 1A000000000000000000000000000000
debugparseRF resp = 19000000000000000000000000000000
debugparseRF resp = 1E000000000000000000000000000000
debugparseRF resp = 1B000000000000000000000000000000
After this sweep Learnt
260022000009B51E1D0B091F091E1E0A1E0A1E0A1E0A1E0A0A1E091E0A1E1E0A1D0B09000D05000000000000
260016000004621E091F1D0B091E0A0001331D0B1E0A09000D050000
260021000002F21E0A1D0B1E0A091F091E0A1E1D0B1D0B091E0A1E091F1D0B091F09000D0500000000000000
260015000B1D0B091E1E0A091F091F1D0B091E0A1E19000D05000000
260020000008080B1D0A1E0A0A1E0A1E0A1E1D0B1D0B091E0A1E0A1E1D0B091E0A000D050000000000000000
Pressed cancel and it is trying to cancel sweep but didn't succeed
After a while powered off and on did a new sweep
debugparseRF resp = 1B000000000000000000000000000000
debugsweep successful: freq = 0
debugparseRF resp = 19000000000000000000000000000000
debugparseRF resp = 1E000000000000000000000000000000
debugparseRF resp = 1B000000000000000000000000000000
learnt:B20534001F0B1E0B0A1E1E0B0B1F0B1F1E0B0A1F0B1F1E0B1E0B1E0B1E0B1E0B0B1F0B1E0A1F1E0B1E0B0B1F0A1F0A1F1E0B0A1F0A00013400000000
which tested ok
I pushed this feature live in v0.9.4. I wanted to post here with some introductory instructions. This documentation will eventually live in the readme.
I use it to configure multiple devices in my setup with a single command call, which makes writing automations simpler.
I also prefer that the sequence itself is edited as a string, which I find faster to iterate on compared to building that same logic in either of the rule or flow execution engines that I use.
All of the previous features still work. You can sendSavedCode and push with a single code name.
The sequence feature is also accessed using push. The string contents define the sequence like this (you must use the whole line, including the sequence: part:
term can be any of code, delay or repeatN, in any mixture and order.
value is:
the saved IR or RF code name (for code)
number of milliseconds up to 5000 (for delay)
a saved IR code name (for repeatN, where you also replace N with the number of repeats of that IR code).
You can have as many entries as you want in a given sequence.
Use this carefully because once you start executing the sequence it will keep going until it completes.
When one sequence is executing the driver won't let you start another one, but there is no limitation on sending a single code while a sequence is executing.
This can lead to unexpected behavior, and I would recommend trying to make sure that you don't run any other commands while a sequence is executing.
I just checked in v0.9.5, which adds a periodic keep-alive ping in the driver for RM3 and RM Pro devices.
Prior to this fix, Broadlink devices totally isolated from the cloud would reboot every 3 minutes or so.
In order to activate the fix you need to update the driver code and then hit Initialize on your virtual devices.
I am still investigating to find the equivalent fix for RM4 devices, but in the meantime this is really only a cosmetic issue because the device and Hubitat driver will recover automatically without noticeable downtime.
I noticed that they were reconnecting to my network frequently after I blocked WAN traffic, and I eventually found this protocol workaround online in another integration.
It works perfectly for my RM3 Minis to prevent reboots, but to be clear even before this I wasn't actually seeing any issues with sending codes even in my relatively aggressive testing.
Nobody that I saw has figured out the equivalent RM4 bits yet, so I am trying to track that down myself.
A while back and prior to using your driver, I had occasional commands issued with no mini-split response. I was thinking perhaps when a command is issued while the device is rebooting, it would be ignored, but I do not block my RM3s from the WAN.
Well, you wouldn't be affected by this particular issue if your device wasn't blocked and was still getting the cloud ping packets.
However, if the driver command went out to the device at just the right instant while it was rebooting for some other reason, it would indeed just get dropped. The device uses UDP which doesn't have any retry mechanisms built in if a packet is missed.
The window to miss would be really small, though. It seems to take only a couple of seconds to reboot and you'd have to get fairly unlucky to hit that window. Not impossible, but I'd be surprised if you saw it frequently enough to notice it.
It might be more likely that there was IR interference occasionally or that the AC sometimes needed to get hit with the IR blast twice for some reason (I have seen some "sleepy" behavior with some of my IR devices, for example sometimes needing to wake up a screen with any old command before the specific one I want to send with have its effect).
Hi. First thanks for developing this @tomw. I successfully am using the driver which works well with my RF controlled lights.
Scratching my head though: what attributes of it are exposed to the platform so I can use rule machine to control it? Looked through many action types in rule machine yet the virtual device doesn’t show up with switch/dimmer/button properties.
Use device type Actuator to select the device, then use a custom action (or custom command) to actually execute commands, like sendSavedCode or push, in your automations.
I'm having a strange issue with the remote driver that may have more to do with my browser than the driver but either way.... any help would be great.
After running the Learn IR command, the device page becomes unresponsive and nothing I do will bring it back. Every time I back out to the device list and go back to the device, it hangs and Chrome eventually shows me a message saying I can wait or kill the page. I rebooted HE, even rolled back firmware. The only way I could access the device again was to create a second Virtual remote device, but then as soon as I ran the learn IR command the same thing happened to that one too.
I finally thought to try loading the page in Edge and everything works fine, so its not HE, it's my browser. But it's still strange and a bit inconvenient. I also dumped the browser cache, didnt help.
And just to make sure I understand where it is hanging -- how far into learning, testing, and saving do you get before you leave the device page and then encounter the hang? Or does it hang even before you leave the device page?
Very peculiar behavior, but unless you're doing a Save Preferences somewhere in the process, there is basically no interaction between the web page and the driver, other than updating attributes in Current States.
Have you seen this behavior with any other drivers or virtual devices?
sorry, this is Chrome my primary browser it's happening on. I've never seen this behavior before on any other device, very rarely on any other web page.
When I do a Learn IR command, the command works, shows the string of IR as numbers, then whatever I press nexts hangs the page, and that device is permanently hung. Like I said before, even rebooting HE won't bring that device back. Opening a new tab to that address doesn't help. It really seemed like it was HE and that device that were the problem. Very odd.
At first I was just trying to delete the device, but under these circumstances I couldn't find a way. Without access to the device page, I'm not sure you can delete a device.
Very interesting. When you say that anything that you press next will hang the page, do you mean any device command buttons on the page? Or literally anything else (clicking away to other areas of HE like the Apps section, for example)?
Are you able to copy/paste the hex code before it hangs? I wonder if there is anything unique about it, like being very long or something. I'm grasping at straws here. I have put long hex codes in attributes of unrelated device pages that are much longer than the remote codes tend to be, so I doubt that is the issue.
How did you delete the device and recover once it was in this state? Did other devices work properly in the meantime?
I've only created two virtual remote devices so far, but both times I was trying to test the learned IR so I probably clicked TEST LEARNED and nothing happened.
I finally got control and was able to delete the extra device by opening up in Edge, something I rarely do.
I'm clicking around through other devices right now, nothing else seems to be broken, just the Virtual Remote devices.
Ok, let me poke around in Chrome to see if I can reproduce this. Which Broadlink remote are you using?
EDIT: I tested my RM3 Mini with Chrome (Version 104.0.5112.102 (Official Build) (64-bit)). I was able to learn codes 4-5 times, and I could test, save, and delete them. I could also sendSavedCode with one that I had saved on the device.
Can you tell me more about anything that comes out in the Logs or that shows up in the device attributes when it is in this state? If you hit Initialize on the device page, does it recover or change anything on the device page?
