If the Motion sensor is reporting temps and has been below the threshold for more than 5 minutes, what would keep this Wait for Event from being satisfied? The Lumins threshold triggers this every day lately ....when I'd really prefer the lowered temp taking precedent.
Why 3 things controlling this? Redundancy; because this is on solar and the power budget is stretched when the fans shut down as soon as they aren't necessary.
Would you post the whole rule and the logs? The triggers could be important in understanding what's happening here.
Boatload of stuff I don't have time to "scrub" from the rule at the moment so I can't cut & paste that.
But note the log makes reference to both the Lumins and the Sunset being primed to trip this.... but I guess the Temp hasn't reported as of yet.
Edit2: Hummm, maybe this has more to do with the temp device itself and relevant settings....State Variables vs Actual State and the reporting setting
EDIT3: Just changed battery in device and temps have dropped 10 degrees in the mean time. Sensor reflects that but Rule is still sitting there unphased.
Just to be clear, dropped 10 degree and < 82? Turn on logging for this device so temp changes get logged too.
Will do.
Rule still waiting on Lumins or Sunset threshold but ignoring the temp being <82
Is the following meaningful ?
"
No event subscriptions are set.
"
I was just going to ask if you're past sunset. Where did you get the Event Subscriptions?
I would make a test rule of just the Wait action. Turn on logging, open Live Logs in a new tab, and Run Actions to see if that alone works.
Not past sunset yet...
The No Event Subscriptions msg was on the App's Status page.
But you encouraged me to lift the hood in some places I haven't looked and I'm seeing some hiccups that need sorting out.
I'm just going to deconstruct things as you suggest. Isn't the first time I've tripped over Wait for Events, and Required Expressions.
Actually, I'm never quite sure if I'm not causing some of the Required Expression trip ups by editing a rule while it's during it's active period.
OK, this follow up question really belongs over in Drivers or Devices as it relates to what an Iris iL07_1 is reporting....but I'm going to throw it in here as it may be key to this "Wait for Event" that wasn't working as expected.
If the sensorTemp: when I JUST looked was 54....
But the temperature : under current states is 83 (which actually is correct)
And then when I went back and looked again...the sensorTemp : correctly reflected the current state temperature of 83, so it updated...but was 54 for HOURS when it shouldn't have been?
WHAT IS GOING ON? How do those two relate? When and by what criteria does the State Variable update?
Observing this rule in action right now, the fans have been triggered on some hours ago with the motion/temp sensor exceeding 82 (EDIT - I meant 85) but the greenhouse temp has now dropped below the 82 threshold in my Wait for Event statement.
So I have TWO such sets of what's shown above that have occurred in the last hour.
Couple notes:
the lumin sensor is way too chatty and I need to switch to a driver that's been written with some control over the increments as that fine detail of reporting is not necessary
the report of a value UNDER my threshold of 200 as another condition of the Wait for Event is bogus as there is no way that went that low at this time of day...and the dang value in (parens) isn't even below 200 !?
The Wait for Event conditions of lumins AND temperature appear to have been triggered and gone into a 5 minute wait/check again period.
NOW.... I WONDER if #3 and either the overlap of the Wait period has caused some conflict...OR...the checking of the numbers to let the Wait expire isn't happening as expected.
Note that bogus trip of the lumin check aside, the temperature below 82 should have been validated awhile ago and I don't get why it's showing up in the log fairly coincident with when the lumins false trip is... As I said this has happened TWICE in the logs.
EDIT: just as a note of what I did since yesterday on this rule; took out the TIMEOUT set on the Wait for Event statement and I manually cleared a Required Expression Private Boolean that wasn't as it should be. And of course the rule restarted for the day from scratch.
Do yourself a favour and create / Clone a copy of this rule that uses virtual devices and manually go through the motions of triggering things the way you expect, and check the behaviour.
I think this is a red herring. Current states are a misnomer for device attributes. Those are the only ones that matter for rule triggering on… device attributes. See the docs for details.
Yeah, I hear yah....being lazy on creating a sandbox rule but should.
Gotcha on the Current States, good to know. Thanks.
OK, before I bug off and go break this down into pieces I can more closely watch....let me throw this out there after yet another "set" of relevant Wait for Event loggings.
Maybe the lumin reporting is buggy, it has satisfied this Wait for Event statement in the past...but let's just say it's buggy due to the device or the driver. EVEN WITH THAT why the heck isn't that temperature event "waiting" ending and then satisfying the statement ...and letting things progress in the Rule? It is as if there is some interplay between the Wait times that I'm not accounting for or perhaps shouldn't be there?
It is strange that you get a message that it reported < 200. What does the events tab of the device page reveal ? Might be useful to include device logs.
You are not showing enough logs here to see that, as the temp event is satisfied at 16:26 so it would complete the "stay" no sooner than 16:31.
I think you might be on to something. Here's a mockup of your rule:
and here are some logs, including device logs:
Haven't tested exhaustively but it does seem like the "stays" are interfering with each other somehow. The first wait on temp never completed, even after 5 minutes - there was an illuminance event that occured in the interval. There was no such event during the second wait on temp and the "stay" did complete and so did the wait.
That RM log message on the illuminance event reads weird - the device definitely did not report < 200.
I made this simple test rule and can duplicate what you're seeing.
I used Run Actions to get the Wait started.
I set the VTS to 68 to start the 2 minute wait. I then set the illuminance to > 200 and it killed the 2 minute wait. I updated the rule just to put a timestamp in the logs. I'd say this is a bug.
Thank you guys for running those rule tests...yes, my log wasn't a full dump but I thought I was clear that this pattern has been repeating through the afternoon with no resolution ! The dang lumin reporting was SOOO copious it made copying the pertinent parts a hassle.
So Hot Dog!
I'm not going to jump to conclusions here...but maybe "it's not me" this time!
P.S, Yeah, the lumin reporting never showed being under 200.
I have had this rule running w/o issue for at least one growing season. That said I probably ignored what really triggered the Wait for Event as there were three things that could do it and one always seemed to do it at least by sundown. I think I noticed the problem recently when I walked in and the fans were on when it was too cool for them to still be on. I since added a "who shut the fans off" notification to help me notice who took precedent in control.
I'm only a release behind on that subject hub right now so that has been a recent upgrade/change.
In the test rule, it doesn't matter which one of illuminance or temp is waiting to "stay", the other seems to be able to cancel it.
A possible workaround is to avoid this sort of "nested rule". The three events in the Wait can be extracted and set up as triggers of a new rule (this is my preferred method as I find it easier to debug).
Another thing : you didn't show your rule triggers; the problem manifests itself without, but be mindful that if the rule re-triggers, that will cancel any waits.
Well, scratch that idea. I got curious and tried it, but got the same behaviour:
Perhaps this is expected behaviour? (although the reported < 200 message is confusing if that's the case)
The Rule's Trigger is that temp going >85 , and the rule is locked by a Req Exp on a Priv Bool T/F test.
As for avoiding a "nested rule" I get how that un-bundles things for debugging...yet at the same time when one is trying to write a simple rule (which this is a pretty simple rule from the coding standpoint) and the statement construct provides for "bundling the test options"...well, that seems pretty neat & KISS to me.
That said, I TOTALLY GET that it puts the onus on the system builder to handle A LOT of different contemporaneous dependencies and inter-dependencies, and behind the scenes it IS complex. So you could argue that it's easier for them to just KISS and not offer such complexities...but...to offer the option and then have some nuances that we gotta always be checking the fine print (about not invalidating) makes one continually revert to avoiding the construct in the first place for fear of using it/building with it wrong.
Well, to give you guys some followup for your time invested....
I pulled the plug on the Wait for Event and went to Wait for Expression after doing some reading in the forum and docs. I still don't have a complete understanding of what was afoot with the first rendition of the rule.
Nor do I fully appreciate the nuances of how an Expression "condition check" differs from an Event "triggering the condition" in this application....but the Wait for Expression is working with the three conditions sharing a 3 minute Duration (stays that way). No TimeOut possible so I am relying on one of those three conditions which is fine, that's why there are three.
Today's cycle of fan on to fan off. mid-afternoon by the temperature threshold criteria. worked just as I need it to.
I think we've discovered something that either needs further documentation in RM or we've found a bug. But you've already hailed @The_RM_God, so we'll just consider that flag raised.
Thanks again for the dialogue and the test runs!
Download the Hubitat app
