Hi all, I am trying to write a RM rule that would do the following:
Monitor if my windows get opened (all with contact sensors) -- during Day mode only
If a window is open for at least 20 minutes, tick the window off -- nothing else to do -- just make a note
If a window is not open for at least 20 minutes by 2pm send me a notification that says: "you haven't yet aired room %device%"
Repeat the notification every hour until the end of Day mode unless I do open the room's window for at least 20 min
Send me a summary notification at the end of the Day mode that tells me which rooms I have aired and which I have not
I am assuming I need to start with a window open trigger and then do wait until event (window closed). Then ideally I would like to be able to compare that lapsed time and do a conditional and if a condition has been satisfied, do a boolean =1 and if it hasn't been satisfied keep the boolean at 0. If a boolean is 1 stop the rule from turning on for the rest of the day (until Evening mode starts). Nullify the booleans for each window at the end of the Day mode ready for the next day. Also, I suspect I would need to create a separate rule for each window as having all windows in one rule might get super complicated.
However, I'm getting stuck right at the beginning when I need to use the 'timer' to start counting minutes from when the windowsis open until when it's closed.
Am I thinking about it in the right way or is there a better way to do what I want to do?
Here's one idea to handle this part. If you trigger based on the sensor opening, something like this should get you the "for 20 minutes" part:
Wait for events: Contact sensor closed --> timeout 0:20:00
IF (Contact sensor is open) THEN
// We know it stayed open for 20 minutes
ELSE
// It was closed before 20 minutes
END-IF
Keep in mind that the above is quite dependent on your trigger: any trigger cancels an in-progress wait (and everything after it), so again this is written with a trigger of "sensor opened" in mind. With just that, however, it won't handle the situation where the mode is day but the sensor is already opened (and you'd actually need a way to not do the above if it isn't day mode; the above is, of course, just a portion of what you'd need for all of this). I can think of a couple ways around that but am not sure how "elegant" either is; you may already have some ideas, depending on how you've already started up setting up this rule, assuming you have.
If I understand correctly, this would essentially mean that the 'already open' window situation would be simply ignored (if I add 'Exit Rule' statement right at the beginning covering all non-Day modes). If the window was open for 15min in the Morning mode, and 10min in the beginning of the Day mode (total of 25min), then closed, this wouldn't be recorded by this rule. So I would still get the notifications, etc. until I opened the window for the second time for 20min (the rule would think it's the first time). I think I can live with that.
However, what you pointed out made me think a bit harder about another rule I have -- our 3 year old often comes to sleep in our bedroom in the middle of the night. When she does, she doesn't shut the door of her room behind her and given her room thermostat is at 22C and the hallway is at 18C, the thermostat in her room is going bananas for the rest of the night. So I set up a rule that is triggered by her room door being open, then waits 20 min (but I didn't do the 'timeout' command that you taught me, just simply 'delay' for 20min) and check again if the door is still open. If it is, then turn her room thermostat to 18C.
This rule is impacted by the same problem that you described of the door being open at the time of the Night mode starting. However, the consequence of getting this edge case wrong here is that the thermostat keeps heating at 23C for the whole night rather than simply not doing the initial 'room airing' count. So I might have to think a bit harder about how to deal with this edge case issue and apply to both of these rules.
I have only started to think about it. With the rules I have been writing so far I could simply start to write them and just finish right then. In my 'programming days' (C+, C#, Stata, SAS, R, SQL, etc.) I would just start writing stuff out and testing, but I feel like with the Rule Machine and the pain of clicking through all the options & drop-downs to create the rule, I am better off starting a notepad first and typing out the logic before moving to RM.
Keep in mind that you don't have to use Rule Machine to get custom automations in Hubitat: you can write a custom app. If you have a lot of rooms and would be writing the same rule several times (I agree that it's probably easiest to do this all in separate rules), then that's normally when I start thinking about writing a custom app instead. Hubitat's docs for this are unfortunately a bit lacking, but the app development environment is nearly identical to that of the "classic" SmartThings environment, both Groovy, and might be a good place to start: SmartApps — SmartThings Classic Developer Documentation (that and lots of examples you can find here of Hubitat apps).
Are there any obvious flaws / errors in the above?
What's a better way to put together those hourly notifications? What I currently have will result in a lot of 'na' for those devices that really should be excluded from the notification message itself, but I couldn't figure out a better way to do it...
If you have a lot of rooms and would be writing the same rule several times (I agree that it's probably easiest to do this all in separate rules), then that's normally when I start thinking about writing a custom app instead. Hubitat's docs for this are unfortunately a bit lacking, but the app development environment is nearly identical to that of the "classic" SmartThings environment, both Groovy, and might be a good place to start: 
