If the light turns off, the wait starts waiting until it turns on again, but so does the rule’s trigger. So when it turns on, the rule will re-trigger, and it will start waiting again.
But when the wait stops waiting, the next line will be the one that notifies the door is open, which it might not be, if I've closed it and not opened it again in all that time. So I still have to put in a test around that action. That kind of leaves me back with similar logic to my original rule which I wasn't happy with. It seems to my eyes as if the more complicated one actually gets more to the nub of what I am trying to represent. But adding that "has become and stayed above" for illiminance and temp to basic rules would fit my needs like a glove!
Do you use webCoRE?
There are options within WC for this type of scenario.
Just some of the options available for illuminance.
Give it a try - you’ll see if it will work (keep the sensor in a lit area, then put it in a dard area for a maybe 30 minutes, then a lit area again for more time than your trigger is set).
I expect that it will work as is. I use this in some of my rules and have not had any issues. Please post a screenshot of the rule you used to test if you don’t mind.
Will do. With a different illuminance sensor though as the fridge one is glued in place now 
1 Like
I haven't got into webcore at all yet, but it's something I should experience at least once!
Or just set the timeout to a few seconds and test it with the one in the fridge…
I used to use it all the time but I have converted most pistons to RM.
There are some though that are just a lot easier to do with WC.
Could you trigger on change of illuminance and temperature?
Then...
If Illuminace is > xxx and temperature is > yyy then
delay 10 minutes
warning
else if "both go to closed and cold, cancel delay
I'm not sure my RM code is correct but I think the logic will work for you.
Well in theory it looks like your idea should have worked. In practice it didn't as the rule retriggered every time there was a slight fluctuation in luminance.
The english wording of the rule rather confuses what it seems to actually do, which is why I resisted accepting it. In real life if you did what the rule seems to say in english, you'd make a date with someone for half past eight, and decide that you're not going to wait longer than 15 mins if they're late. If you get there and they're already there, you don't wait at all, you go straight to the restaurant with them. If they turn up after 5 mins your wait is over, and you go off together. The way the rule is actually behaving is you get there at half past eight and they're already there. You say "no sorry I said I'd wait 15 minutes, so we'll stand here for that time then we can go eat". Then you check they're still there 15 mins later (in real life they'd be gone)
I'll try tweaking the reporting of the device to larger changes, see if that works out better without compromising accuracy
1 Like
In action, I can't get this to work for reasons of limitations in the test device and its driver. It strictly reports all the readings at the report interval I set. If I set too long, it doesn't trigger in a timely way, set too short and it triggers too often - automatic trigger on amount of change doesn't seem to override report interval like I thought it was meant to. I'm going to need an intermediate virtual switch, which will turn on every time the device reports over 20 lux, and off each time it reports less. and then have the rule test whether the switch is on or off. However, the actual device in the real fridge may not have that problem so I could move on to testing that now.
I like the intermediate switch idea!
change the trigger to illuminance changes
then for the actions:
if illuminance > 20 then
delay 10min (cancelable)
notify phone (cancelable)
else
canceled delayed actions
endif
i'm doing something with a few doors i have and it works great (had to upgrade from SA since it would conflict with multiple opens)
My current test plan is I have a virtual multi-sensor called VirtualFridge. Whenever the real sensor reports anything at all, a rule sets the VirtualFridge contact status to Open if the lux is > 20 and Closed if less. If the real sensor temp is over 10 it sets the VirtualFridge temp to 50, otherwise to 5. That means for both light and temperature there will only be two states, and they won't change (ie create an event) unless my purpose actually needs one.
VirtualFridge is used as the trigger, but once the notification rules are running they test the readings of the actual sensor to work out if the situation is being remedied or getting worse.
1 Like
