New App Features in 2.2.8

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

What, are you on vacation? We've gotten so spoiled here I expected a new release, fixing the bug and adding 2 new features by now! After all, it's been almost a whole 30 minutes!
:scream:

1 Like

There is indeed a bug, it fails to cancel out the Wait for Conditions when there is a duration involved, thus confusing the following Wait for Event. This is now fixed for release 2.2.9 -- now in beta, due out next week most likely.

14 Likes

Is it just me? I find it so satisfying when a bug is discovered because
A. It means I’m not crazy or stupid after all.
B. I know the Hubitat folks will solve it quickly, so all good.

Double win. :smiley::smiley:

10 Likes

Because you've made it better for all of us! Very Cool!!!

5 Likes

Could someone explain or demo how to use a connector? I want to write a rule that is triggered by a change to a variable. I could do this in RM4 but based on the release notes, I need to use a connector now. I'm not sure what that is or how to use it.

Let me see if I can explain this…

A connector is a device that was created as a variable and is linked to it. Changes to the connector change the variable and vice-versa.

To generate the connector device, in Rule Machine, within the area to create variables, click on “Create” under the “Connector” column and select the device type you want to use (Ex.: Switch)

image

Once a connector device is created (ex.: a virtual switch). This device can be used by all apps.

Does that help?

Let me suggest you wait a just a few days for Release 2.2.9, where you will be able to do that again.

9 Likes

Woo Hoo - Bruce said "a few days"!!!

2 Likes

I can’t say that it helps a whole lot but I appreciate the help none the less.

So a connector maps 1 to 1 to a variable?
If so, can they be named the same thing so that it’s easy to associate them together?
If they do map 1 to 1, what is the point?

1 Like

I can wait for the new version.

I can’t wrap my brain around the purpose of connectors. What is the advantage to them vs triggering off of variable changes? Are connectors just a work around until RM5 allows triggering off of variable changes or is there something more to them that I’m not understanding?

A connector gets a name that is the same as the variable name by default:

Screenshot: Variable connector device list

Above, my variable names are things like hubVarDateTime1. I've never done this, but it does appear to let you rename them--like you can any device--but it sounds like you don't even want to do that.

If you're not sure what kind of connector to make (it doesn't matter for many cases--just as long as it generates the events you need and in a way the rule can "process"), I'd suggest sharing more about your variable and the ways in which it can be changed.

1 Like

Connector also allow you to put them in your dashboards. And they provide a way for sharing hub variables via hub mesh.

3 Likes

No advantage, if anything a slight disadvantage because if your using a connector that didn't need to be created the hub has to do some extra work (that would be tiny BTW). The reason for a connector is to be able to use that variable in other apps that don't support hub variables yet. They also allow you to change the variable outside of the app i.e. dashboard

Download the Hubitat app