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:
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.
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.
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.
As expected, the rule issues a "door open" notification. And beginning to wait for the door close event.
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?
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.
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!
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.
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.
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.
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)
Once a connector device is created (ex.: a virtual switch). This device can be used by all apps.
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?
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:
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.
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
@bravenel, curious if you have any thoughts on this... For the new Button Controllers app, I'm using Lutron Picos for controlling Hue downlights. I'm using the Advanced Hue Bridge Integration app so I can pull in Hue scenes too (which show up in HE as switches). I'd like to use the middle button "3" on the picos to cycle between imported scenes for each push of the button. Do you have any ideas what I can do on the programming end within Button Controllers to achieve that? Kind of like how you can do "Random color" when setting a color - a "random switch" from a list of a few pre-selected switch options?
