How to test for Application Busy status

📐 Rule Machine®
1

I'm trying to trigger a rule and the debug shows the application is busy so it does not execute yet the user receives no notification the expected action ever took place.
In my case, I'm trying to execute a rule using the "cloud end point" trigger from outside my home so it's critical I know this executed. I know I can wait for X seconds and do a test on the device I expected to change state but I'd like to avoid that logic exercise and just test for application busy status, creating a while loop while it's busy.

How can I test for an application busy status?

Here is my log when the rule is triggered yet cannot perform any actions due to it being busy....

image
image1142×88 26.4 KB

Maybe this is specific issue to a garage door device type?

2

What driver is this device using? Is it custom? That message is specific to the driver so it will need to be updated to determine “busy” status.

3

The generic one:

image
image930×126 6.54 KB

4

Just to help us all understand a little more... When you say you're trying to execute a rule using a cloud endpoint, are you specifically referring to a Rule Machine 4.0 Rule? If yes, can you please share a screenshot your rule so we can better understand what you're trying to accomplish?

1 Like
5

Correct. I took the cloud endpoint URL and programmed it into a iOS shortcut so when I get home I can simple swipe down and use the iOS shortcut widget to open (or close when I'm leaving) the garage door. This is a FANTASTIC use of the cloud endpoint option in RE4 since HE doesn't support widgets on iOS yet.
Just testing now but creating a simple app to toggle the garage door. If it's open, close it. If it's closed, open it.

What I've noticed is that if I press the iOS shortcut and the garage starts to open, I have to wait an extraordinary long time for the app to "become available again" to re-close it. Even after the garage is full open and both the contact and door states (I've tested both) are open, I have to wait about 5-10 seconds to press the shortcut again (or execute the rule) before it takes due to the "busy" status.

Certainly I can program around this with a wait or delay statement but thought I might be able to test for that condition first. Really, I'm more interested in the why. Perhaps I need to study DTH's more to understand the busy condition?

image
image1532×498 35.3 KB

6

I don't know what garage door opener you are using but I do know mine has a delay to prevent the door from being triggered a second time inadvertently.

2 Likes
7

OK, so let's try taking the iOS Shortcut and RM4 out of the picture temporarily for a test. If you go into the Garage Door Opener Device details web page on your HE hub, you should have an Open and a Close set of command buttons, right? These execute the same commands that your RM rule is attempting to execute. Try clicking the OPEN button on the device, and watch the status of the device's attributes to observe their behavior. Once you get a feel for how the device responds/reacts, try clicking OPEN and then click CLOSE relatively quickly to see what happens. You may want to also have a second browser tab open to the live logs to observe any debug output from the device.

This may help you understand exactly what is happening.

If you'd like the iOS Shortcut to be able to check the status of the door before it issues a command, I would recommend using the Hubitat Maker API instead, as it should allow you to query the garage door device to retrieve all of its attributes and their values in real-time. You could then use this data to make the iOS Shortcut much smarter, and provide the user with instant feedback.

2 Likes
8

This was an AWESOME suggestion. Thank you @ogiewon. When I do that, I can confirm that it's not due to RM4, but it's in the DTH. I still have the same problem....after both the contact and door states are open/open...for some reason the DTH does not allow me to execute another command for up to 10 seconds even though everything appears complete (including the contact and door states of open/open). I'm guessing that's just the way it is as @zarthan mentioned.
I used Postman to run an info request via the Maker API during the few seconds this conditions exists and can't see anything I could test for an "ApplicationBusy" state. I'm ok with that. I'll put my logic in elsewhere, likely a delay for my error checking.

I really appreciate @ogiewon and everyone else who has helped further my understanding here.

My Postman response:

{
"id": "",
"name": "Generic Z-Wave Garage Door Opener",
"label": "Garage Door",
"attributes": [
{
"name": "contact",
"currentValue": "open",
"dataType": "ENUM",
"values": [
"closed",
"open"
]
},
{
"name": "door",
"currentValue": "open",
"dataType": "ENUM",
"values": [
"unknown",
"open",
"closing",
"closed",
"opening"
]
},
{
"name": "door",
"currentValue": "open",
"dataType": "ENUM",
"values": [
"unknown",
"closed",
"open",
"closing",
"opening"
]
}
],
"capabilities": [
"ContactSensor",
{
"attributes": [
{
"name": "contact",
"dataType": null
}
]
},
"Sensor",
"Actuator",
"DoorControl",
{
"attributes": [
{
"name": "door",
"dataType": null
}
]
},
"GarageDoorControl",
{
"attributes": [
{
"name": "door",
"dataType": null
}
]
}
],
"commands": [
"close",
"close",
"open",
"open",
"refresh"
]
}

2 Likes
9

Excellent! Glad this at least explains the behavior you've experienced.

1 Like