Line numbers get weird because of how the code is structured, so unfortunately that line number doesn't get me close enough to debug.
Please share a screenshot of the actions page on your Rule Machine rule. Are you sure the saved code name is correct and is actually saved on the specific virtual device you are using? There should be a codes entry in State Variables.
There is a code entry on the virtual device and it works when I testLearnedCode. The events log shows the code is captured and working. It seems that saveLearnedCode is not actually saving the name which seems to be the problem.
What name are you using with saveLearnedCode? What does the codes entry look like after you saveLearnedCode and then refresh the virtual device browser page?
I have a guess; tell me if maybe you're missing a step here. This is described in more detail in my readme (first post in this thread):
Steps to learn, test, and save codes:
learnIR -> if successful, the Current States will update to "activity: code captured" and "learnedCode: 2600...."
testLearnedCode will send the learned code once. If it controls your device correctly, go to next step. If not, repeat prior step
saveLearnedCode to save the "learnedCode" to a certain name. Refresh the device page and look at codes under State Variables. It should appear in the list.
Only after all of those work will you be able to sendSavedCode (with the name as parameter) or push (with the name as parameter) in Rule Machine or elsewhere.
You can send any code by name that appears in the codes list on a particular virtual device. The available codes differs per device, based on what is saved in the specific devices State Variables.
It's failing at saveLearnedCode. When I complete all steps and refresh the page there is no codes list entry. In State Variables there is only devDetails and count.
I have tried several different names but none save. What is the correct way to name the saved code?
It should work with any string, but it's possible that the datatype doesn't like certain characters. They're stored as a Groovy Map (plus whatever Hubitat does with it when they flatten into State Variables), so any disallowed characters for the key name could potentially break that.
Hey @arnb, I'm not sure what this "Hub actions" category is based on, since there doesn't appear to be more documentation from Hubitat on what it means.
However, from a CPU perspective I'd focus more on the "% of total" than "% of busy". 0.1% utilization out of total uptime does not seem to be a cause for concern, regardless of the hub action count.
Are you seeing any performance issues with your hub, or are you just curious about these numbers?
Mostly curious about the devices using so much CPU time when they are doing nothing except Hub Actions.
Since I originally posted counts have gone up. For example the Master Bed rm went from 205,876ms to 207,803ms while device events was unchanged. I don't remember this happening when I tested this back when.
There's a scheduled task that does the hearbeat ping every 60 seconds to keep the Broadlink device from rebooting. Other than that, the driver is totally idle if you aren't executing commands.
I guess the ~31 pings between your screenshots may have taken up to a couple of seconds of CPU time in total. Doesn't seem too bad.
I remember delaying the code update when this was added to your code. Never noticed an issue prior to it being added. What happens if the Broadlink device reboots?
You could probably easily miss it. You might see the LED blink on the front of your Broadlink device. I have seen that with my RM3s when they boot (or reboot).
There's a small window where if you issued it a command that it may not receive it, and because it uses UDP there is no automatic retry. But I have never actually noticed that happening, so I assume the likelihood is vanishingly small. However, I wanted to include the fix to avoid the reboot just in case.
Hmm, perhaps that is why I have logic in my Mini-Split app to double issue each command with a 2 second delay because sometimes the command did not take on the initial attempt.
I also can't imagine the real Broadlink app doing a heartbeat ping from the cloud. Does it?
The Broadlink cloud pings the device, not the app. If you block internet access to the Broadlink device, it will immediately start rebooting every ~3 minutes like clockwork.
EDIT: to clarify, if you don't have the ping for RM3 (which my driver does), it will reboot. I haven't found a solution to RM4 devices, so they may still reboot occasionally if you block internet access.
This driver hasn't been updated very frequently lately, so hopefully it isn't too onerous for you to manage the code tweak to remove that line on your local installation.
I'll consider adding that whenever I make my next update, but I can't promise that I'll prioritize it. The driver page is already painfully cluttered with commands and preferences, and regardless I think some perspective is necessary.
It may feel good to see those types of numbers go down, but a device utilizing 0.1% of the CPU and 1% utilization across all devices in your hub seems like a pretty healthy operational state to be in.