Tracking Open Windows

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. :wink:

My wife has long accepted that there will be phases of our lives where I become disconnected from reality for some periods.


I agree that he's probably going to be good about it BUT, that particular package has No License and he's got a donation link.

1 Like

Yep. I shot him a message. I'd totes leave the donation link in there.

Just FYI...I've written a whole new app:

1 Like

Thanks @FriedCheese2006! I was able to get it installed and switched over my contact sensor groups to your app instead. I'm looking forward to syncing it up with HPM once you get it loaded on there/seeing where you take the app.

I plan on writing a RM5 rule with a global variable to track open windows factoring whether the rooms' doors are open or not. I'll post it once I get it written, in case anyone is looking to accomplish something similar.

1 Like

So, I think I can do an offshoot of my app specifically for this use-case pretty simply from the state it's currently in.

Just to be sure...this is what I think you're wanting.

  • Create a contact sensor group that includes the windows and doors.
  • User selects the door sensors.
  • If a door sensor is closed, don't count any sensors in that room as open.
  • Count normally outside of that.

Sound about right?

Yes, that sounds accurate. In my use-case with an open concept, some rooms' windows aren't behind any doors and are open to the common space that includes the stairway where the whole house fan is, so they'd be counted in the master count regardless. Some are behind one door, so if that door is open, include any open windows in the master count - if the door's closed, exclude them. And others yet (e.g., ensuite bathrooms) are behind 2 doors, so the bathroom's door and the respective bedroom's would both need to be open in order for those windows to be included in the master count.

So you'd need to tie window contact sensors to either 0, 1, or 2 doors.

Ok...that's probably a little too niche since it'd be very specific to your layout.

My thoughts were to have a second select for the door sensors. I would iterate through that list to get the room names as assigned in HE for the closed doors. I could then use the room names to just ignore the state of any window sensors in the same room.

I'll chew it over, but I don't think there's an easy, programmatic way to account for all those scenarios without getting RM involved. I could get you halfway there though.

Yeah, one could probably base the coding of a new app off the coding you used for your app, but this doesn't exactly fit the use case of your Sensor Groups+ app. App coding is still a little over my head. Until then, I should be able to piece it together in RM.

Alright, let's give this a try. For each group of windows, you can select the door sensors that should correlate. If any door is closed, then the window sensors will not be counted and the virtual device will be treated as "closed" and the open count will be set to 0. I don't think this will 100% solve your use case, but it should get you about 80% there. It should let you just use the child devices in RM, so if you need to move sensors around, you won't have to touch the rule. This will also account for the situation where you want to check more than one door for a room.

Install via HPM using the URL option:

Manual Install:
App -
Device -

That would work perfectly for how I want to use this app with my whole house fan automation.

If a door to a room is closed, then the window being open is irrevelant, and should not be counted as an open window.

If that could be a preference in the app it would be even more perfect.

See my last post. are way too fast for me. :slight_smile:


That is awesome.

Just to be clear, this doesn't care about what room the doors/windows are in, it just "pairs" the doors and windows that are selected and ignores any open window(s) if the associated door(s) are closed.

So one instance of the app is required for each room where I want to use this pairing.

Could this be automated to use Room assignments w/out too much thrashing of code on your part? E.g., select doors and windows (or rooms, if that's easier) and then parse the door/window combinations in each room automatically. So only one instance of the app required w/all the doors and their related windows in it.

That would save me having to group all the indvidual "room pairs" together in another instance of your app to create a master device that reports the overall status of all selected windows/doors for the attic fan automation to not run if everything is closed. I could also just select all of the virtual devices in my rule and check for all open status of the virtual contacts.

That make sense? I get it if that would require way too many code changes and maintenance headaches. :slight_smile:

I'm sure it's possible but the amount of logic that would have to go behind it would make this a little more ambitious than I'm capable of at this point. It would also narrow down the functionality a little. Like @nathaniel.knautz mentioned. There may be extra doors you want to check for certain windows that aren't assigned to the same room.

I think a close option would be to emulate what Bruce did in RL when you could just tick a room from the list and it would auto-select sensors in that room. I'll have to look into that (since it may be handy for the main app anyhow).

1 Like

That would be a nice enhancement.

I get that the other request is not in the cards now, and it really isn't a hurdle or anything. Thanks for this app, super useful!

I couldn't find this in HPM (might not have refreshed yet...?), but was able to manually install it just fine. I agree with you, the only way tying it to Rooms would be similar to how it's setup with RL, where it pre-populates the respective windows and doors, but then you can add others. I'm not sure if your logic could differentiate between what contact sensors are for windows and which are for doors though - seems to be more headache than it's worth. It's not an issue to me to have to manually check which windows and doors you want to apply to the group.

I haven't fully set things up to test it completely, but I do have a few questions based on my first trial:

  1. Did you mean for this to be a new app or to be a sub-app under your Sensor Groups+? I had to install it as it's own app. That's fine by me, just didn't know if that's how you wanted it setup.
  2. When installing the app and being prompted to create a sensor group, it's being added as an app and then a virtual device... but in order to create multiple groups, you have to create multiple instances of the app. Can you rework the app to create one app and then the different room groupings are created underneath that app? That would make it much cleaner on the UI. See below photo for reference.

FWIW, if the coding doesn't matter on your end, I could see this being just another child-app of your Sensor Groups+ app.

  1. To minimize on confusion, I'd rename it "Whole House Fan Sensor Groups+" and not "Attic Fan Sensor Groups+" - an attic fan is installed on the exterior of your roof to help pull hot air/humidity out of your attic. A whole house fan is mounted on the ceiling of the floor below your attic to pull air from the house out through the attic. A small nuance, but could create confusion down the line for others trying to find your app.

Download the Hubitat app