i want it to alert me when slider is open (stays open) and ac is running for a set time like a half hour or hour.
the following rule i think will work if they open the slider when the ac is running and will alert me after a time (set to 5 minutes now for testing) if the ac does not turn off.
however, it will Not work in the case when the ac was not running when the
also i dont think this will work in general if i say set it to an hour as the ac will cycle on and off.
has anyone wrote such a rule.. maybe a counter variable set how many times itis running in the hour?
By a 'slider', you mean a contact sensor on a sliding door?
I think you're also saying you ONLY want the rule to run IF both the contact sensor is OPEN for 30 mins AND the AC has been running for 30 mins within the same window--is that correct? Assuming both, this should do it:
Im worriwdes about if the ac cycles on/off and unless i'm mistaken your rule wont work if the slider was say opened early in the morn when cool and ac doesnt run but then slider is left open all day and eventually the ac starts running?
While I certainly agree with hubitrep that this could be done with two rules, it's become something of a goal for me to optimize all of my rules by minimizing false-positive triggers and consolidating rules where possible. To that end, this single rule would work per your requirements:
This rule won't fire unless both of your (required expression) conditions are true (AC running AND zone open)
Subsequently, the OR'd triggers need only consider event longevity (stays that way)--this will eliminate most false-positives and ensure we catch either component in the trigger set
The AND'd conditions within the actions ensure that both event longevities are true before acting
i found another problem with your rule the time since event stuff doesnt work as it does not reset when the state of the attribute changes so for instance it will still show a long time if the temp turns off or the slider closes.. see my rule i tried it has a long time since it opened but there is a close after it,.
I don't think so. Remove the required expression and change both triggers to conditional triggers with the correct condition picked from the required expression and then it might work.
Required Expression false removes the trigger subscriptions. So for example when the contact goes open, the trigger subscription is restored but you missed that event. So it will never trigger.
This is what I suggest for triggers:
thermostat cooling and stays - only if contact is open
contact is open and stays - only if thermostat is cooling
That's why I opted for the arbitrary 'changed' event. Are you sure that doesn't work? I thought I'd used this repeatedly though, granted, 'time since event' conditions are touchy.
I think this does assuming it preserves the additional 'action' logic to test both longevities. Without that, the rule won't enforce the minimum 30-minute overlap window (which I think is what the OP is after).
... why will the the 'required expression' prevent the triggers from firing? As you stating that 'stays that way' triggers will fail if they have a counterpart required expression?
therms are only updating every 15 minutes as the are t9s in the cloud thus the weird times
its not for kids its for condo rentals in fl.. nothing pisses me off more than seeing slider left open for hours and ac running... it usually ends up with ac overflowing the shutoff valve and me getting charged 150 bucks for the condo agency or ac people to come out and flush out and restart the system.. grrr.
Making up signs to warn them ac may shut up if slider left open.
for now i will just get a warning and make a manual determination if i should raise temp or set therm to off.. Eventually i may automate.
There's still the issue that the Time Since Event conditionals could be satisfied after the trigger fires, but your rule won't catch that.
I'd withdraw my conditional trigger suggestion - looking at your rule I recalled that the condition is only evaluated once, before the stays - and go back to the two rules idea (which is what I use, FWIW, to stop a room's baseboard heater when the window is open for X time):
The Wait for Expression action is only needed if one "stays" timer is longer than the other. The times set in the rules above are just for testing obviously.
EDIT: Never mind, Wait for Expression doesn't work in this context with Time Since Event... needs an event to complete the wait. Rule above still works if you don't need the timers to be different.
There are two things I'm aware of that can affect the behaviour of time since event:
The event history size - although for discrete attributes it shouldn't be an issue, unless...
If some app (they are rare to my knowledge) has subscribed to the device attribute with state change filtering turned off, then there can be successive events of the same attribute value. They can even overflow the event history and make the last state change disappear from it.
It's usually fairly straightforward to understand what is going on by looking at the device event history in the device details page.
