New App Features in 2.2.8

Well yes but we have this already with time and mode based triggers

2 Likes

The missing ingredient was events for variables. Without an event, you can't do a trigger or a Predicate Condition. Time things are scheduled, not really events per se. Mode changes are a location event. Starting in 2.2.9, variable changes will also be location events.

9 Likes

Another RM 5.0 minor bug. Under ACTIONS / DEVICE REFRESH, I am unable to refresh my Generic Z-Wave garage door opener, although the device does have a refresh function. It doesn't show up in the list of devices to refresh.

The opener includes a sensor which occasionally gets stuck between states, I'm using app code to sense the stuck state through a timer, then refresh the opener if necessary. I checked Legacy RM, as I didn't have this in my previous code, the same issue also existed under RM 4.1

What driver are using for this device? If it is a community driver, it may need a slight tweak to be seen properly by Hubitat’s Apps.

The driver must have Capability "Refresh". Just having a Refresh command won't bring it up in RM.

1 Like

It's the standard Hubitat Community driver "Generic Z-Wave Garage Door Opener".

Yeah, that driver lacks the Refresh capability. I'll point that out to the engineers.

2 Likes

@demillerusn - in the meantime, you can choose the RM "Run Custom Action" for this device, which should allow you to call the 'refresh()' command.

2 Likes

Fixed in next release

5 Likes

Great - thanks! I'll run the custom action in the meantime.

1 Like

What should happen if the condition is false before the duration command executes?

What I am finding is the wait for duration never concludes even though the power was >= 300 for the specified time. If I preceed the duration command with a wait for condition command to ensure the condition is true before executing the duration command then it does work.

In real life when this rule starts running the power is in the 100s for a period of time before increasing to 400.

You should turn on Action and Event logging, it will show what is going on.

It will wait for the conditions to become true. Then it will wait for the duration. The condition has to remain true for that entire period, or it just starts over waiting for it to be true.

1 Like

@bravenel, I’m taking this idea one little step further, adding a wait for close event so I can report the door being closed after it remained open for awhile (see below).

This rule generates a second “door left open” notification when the door is closed after remaining open for the full duration. Am I doing something wrong or is this a bug? Log is below as well.

Log

If you close the door before the duration is up then the door is closed and then you get the first notification then it's on to the second wait, so it doesn't wait and reports the door closed, again. You could put a IF door is closed before the first notification. That should do what you want.

Sorry I don’t understand this. Can you help me understand? I thought the Wait for Duration, as written, will keep trying to wait for the door to remain open for the full period of time before the rule continues its processing. And, if the condition goes false before the time is up, then the Wait for Duration tries to start again. That’s my understanding from this comment:

Because it was wrong. You are right, it's a duration, so it will only continue once the door stays open for 30 seconds.

So if you open and close door in less than 30 seconds it waits at the duration. The open triggered the rule so it's waiting for it to stay open for 30 seconds. When you open it again it retriggers and cancels the wait.

So if it stays open for 30 seconds it will give you a notification. It will then wait for the door to close. Once closed it will get give you the door is closed.

Yeah okay, that's exactly what I expected. And it is also how the rule performs. So all good there.

Yes, that's exactly what I thought too. However, when I let the duration complete before closing the door, it notifies "door left open", as expected. But then, when I close it, it gives me "door left open" again. Totally mysterious. What you're describing above is exactly what I would expect. But that's not what happens. I get a second "door open" notification and no "door close" notification. I'm stumped. I've added a log below in case any sleuths want to take a look.

Look at the log below.

Here's my interpretation using the numbers as reference:

  1. Door opens triggering the rule, then it waits to see if the door stays open for full duration, but then I close it before the duration is over, so the rule waits. All good so far.
  2. I repeat #1 just to make sure -- door opens which retriggers the rule but I close it before the duration is exhausted so the rule waits again. Still good.
  3. This time I open the door and wait the full duration. As expected, the rule retriggers, but this time the Wait for Duration resolves truthfully. Still good.
  4. As expected, the rule issues a "door open" notification. And beginning to wait for the door close event.
  5. I close the door so the wait for event is over ,as it should. But then, to my utter confusion, the rules sends a "Door Left Open" notification. What am I screwing up? Or is this a bug?

That does not appear right. If I get a chance a bit later I will try a test and see if I can duplicate.

Appears to be a bug I got the same thing. I used a virtual contact and only 30 seconds. I first opened and closed within 30 seconds and that worked. I then opened and left the contact open for the 30 seconds. That worked. I then closed the contact, and I got a notification the door was open. So it's a bug or we both don't understand how it supposed to work.

Rule:

Log:

It appears as though the the Wait for Event fired the wrong actions when it was satisfied. I will investigate...

4 Likes