I'm trying to track the number of windows that are open to then use with a rule for my whole house fan... They require a certain number of windows to be opened to allow enough airflow to prevent back-drafting. So, I only want the fan to turn on if X number of windows is open.
I'm thinking I can use a global variable to do this, but I can't figure out how to setup the rule. I have contact sensors on all of my windows (Ring Alarm integrated with HE), so I want if a window opens, add 1 to the global variable "Open Windows". This is easy enough for one window - contact changed triggers the rule, if the contact is open, add 1 to global variable, else if closed, add -1 to global variable. However, I don't want 34 rules to accomplish this...
Does anyone know how to best write this without needing 34 rules? How I initially thought to write the rule (see below photo) isn't working... Since the rule is triggered by contact changed, when any of the windows are opened or closed, right now it's checking if any of the windows are open, unless I'm closing the last window, there's at least one window open keeping that condition true, so even if I close a window, it's saying yes, there are windows open, and adding 1 to the global variable instead of subtracting 1.
Any help would be appreciated... I really don't want to write 34 separate rules for each window to add/subtract from the variable of their own accord...
If you use a hub variable, one approach would be using two rules: one rule triggered on any sensor opening that adds 1 to the variable, another triggered on any sensor closing that subtracts one. (Technically, you can do this in one rule, too, with a "changed" trigger and then look at the value of the built-in "value" variable with a conditional actions.)
Do note that this approach has a small amount of fragility to it: if the hub is rebooting, shut down, etc. when the window is open or closed, your count will be off. It looks like your rule above accounts for this with a sort of "backup condition" that sets the variable to 0 when all are closed. That might not be a bad idea, and it could be a third rule.
Honestly, this would probably be a bit cleaner with a custom app and it should be pretty simple to write, but the above is the first thing that comes to my mind if you want to use built-in options. webCoRE (not built-in, of course) could also do this and a bit more elegantly since I think there are ways to count device states directly, an issue we're sort of working around with RM here.
So, with permission from dman, I was able to get his contact group app updated to track how many sensors are open/closed.
The device will show how many sensors are open/closed. The sensor itself will show open when any monitored sensor is open and closed when all contact sensors are closed.
I've only did some quick testing, so let me know if you use it and it goes weird.
In action (I just opened a window and closed it to show the updates):
I used the actuator capability, so you can use any of the states in RM:
Nice, thanks! It seems to be working. To me, this is a valuable feature that others would likely use - it would be nice if it were updated in HPM - not sure if he's maintaining that anymore now that he's no longer an active HE user?
FWIW, I may still use the RM5 route, because then I can add more logic to exclude windows that may be open in rooms that have doors closed, as the closed doors would greatly reduce potential airflow being provided. But, I was able to recreate my RM5 apps with the updated code you provided, so there's definitely merit to it. See below, if anyone's curious:
He isn't. His permission was to fork his repo in github and make the updates. This is literally the first time I've done any of this, so maybe later for HPM.
I think to do this with an app would make the most sense to lean on the room assignments in HE. Maybe I can figure that out.
Agreed. It'll get a bit lengthy in RM5 to accomplish what I'm hoping, so an app would be better. I'm not sure how much utility there would be for other use cases other than something like this with a whole house fan, but I'm sure someone would find it useful.
I suppose a workaround in the meantime could just be to create several window groups within Device Groups and then just use RM5 for adding up rooms' windows that don't have doors closed... Hmm... That'd probably be cleaner than trying to flush it all out in RM5 with a Global Variable.
You could consider opening a [Release....] thread in the Code Share section (giving appropriate kudos to Dman of course, similar to what CSteele did w/HPM) so folks can find your updated version of his app and bug you about adding more and more and more features to it).
I may go that route, but I really need to pick through the rest of the app to figure out what all is going on. I ran through it yesterday just to figure out this one use case.
It's not...I've spent some time digging through it and it's all pretty straightforward. The issue is going to be the HPM side. Dominick still has it published, so, if I try to publish it, there will be two . So, I gotta get that figured out.
HPM has a hard coded URL to the Master Repository. I replaced that. That meant nothing of Dominic's remained as far as HPM itself was concerned. (Obviously his code is still available on his github, just HPM itself no longer knows that.)
So the HPM case is not useful for changing maintainers of a Package.
I'd have to study the problem to document it. There's a lot of nuances but I think the big step is to prepare the "New Code" and get it in a Repo that the (new) current maintainer "owns." I'd also suggest a Name Change be considered because the cached repo of the old code is not going to just go away.
HPM's Db of packages is keyed off the Repo URL and that's a big issue in these kinds of transfers. UnMatch becomes a friend I think.
I already have it forked off and started down the rabbit hole of getting the package manifest built. That's when it dawned on me to check Dominick's repo and saw his was still there (and it was still listed in HPM). My thought was to just copy the code to a new repo with a new name to break all ties, but don't wanna thief his code without permission, so I'm waiting to see if he's cool with it.
I expect he'll be OK w/that, given he was OK w/CSteele taking over HPM. AFAIK he's moved on to Home Assistant and ain't coming back.
And if you are partnered up w/anyone I think it's only fair to warn them about the rabbit hole you may be diving into, and your resulting reduced availability.
. So, I gotta get that figured out.
