Is there a place for adding allowing prediction override conditions? Entering/Leaving zones, Boolean Helpers, Sensor Values/Conditions?

[gbosky]

TLDR:
It would be great if there were a few options to allow "override" conditions that I know as the user are absolute truths and feel like I still have control over the occupancy. I am not saying that the area prediction/threshold hold sensor should go away but just added to. Maybe once I do get settled, monitor, and tweak it, the prediction will be great where I wouldn't need overrides at all, but having that option would make me more confident as I work it out for my setup.

As a newer user, I wish there was a better balance of prediction giving that fluid feel and having control. I was hesitant to go with it as it seems complicated to trust the prediction, daunting to learn adjustments/tweak, and it "learning" with time because I didn't want to feel like I am losing control of the occupancy automations (even if it can be temporary through learning phase).

---

First I want to start off that I am new to this integration and my previous problems is what led me here. I am excited to begin using this, find how it fits in my smart home, and see where development goes into the future. I thought it would be good to provide some insight to what my issues were and if there seems to be a fit with this integration for a solution because I don't think it solves everything I was looking for.

I recently installed new light switches with motion sensors to pair with the motion/mmWave sensors that I am already using. I love having the motion sensors built into the light switches for being discrete, no battery, more motion data, etc. However, The issues I began to realize is how I can coordinate those with my automations and other sensors without building a huge list of conditions or triggers. The light switches are not always in the most ideal locations either so I started building a blueprint to hopefully provide simplicity to some of the detailed logic but I realized it was probably not the best way to do it.

That's when I found this integration on the HACS store and knew it was what I was trying to do (and more). The statistical approach sounds like a great approach for using multiple sensors and ability to include different kinds to dial in occupancy.

I still have to go through my testing and learning phase (excited to see the results with time!), but from the early results I am still worried about actually using it for automations, especially on the initial "rising edge" of entering a room or the helpers I use to hold occupancy. Now I could build my automations directly with sensors I want triggering that initial change and hold conditions, but I began to wonder if that logic could also be another data point of interest the algorithm to calculate on (like the wasp sensor condition). I mean if I have the helpers or enter zones configured the way I understand them, why would I not want them to be absolute truths? I think leveraging the logic of those individual/group sensor conditions and the users input should be useful too.

I have 4 specific situations that I was trying to solve with my blueprint and curious what others think and how this integration could help (or provide a solution or two)

1. In my living room I have a few zones configured with a mmWave and have a specific "entrance zone" around the couch. When the first person enters, I have the lights turn on, then if no one is in the room the lights turn off. But I also have a condition that if main room zone is still occupied, when another person enters the room don't turn on the lights in case there is a movie scene playing (to put it simply).

   • I want occupancy to start every time motion is detected in the entering zone first, without considering all the other possible sensors. (possibly have the prediction as a fall back if entering zone was missed but evidence shows occupancy is predicting high) Ideally this would be both for speed and reducing false detections. For example if other sensors are showing evidence but the entering zone isn't, I think it should still have the heaviest weight on that initial "rising edge" to pull it off Cleared

2. My office has 4 different motion sensors, PIR, mmWave, mmWave with zones, and mmWave in the light switch. Each one experiences its occasional error detection, but also covers the shape of the room (with some overlap) so I was trying to coordinate 2 or 3 of them to avoid false detections but not sacrifice too much speed on initial detection of real occupancy.

   • So far the occupancy probability has been working great but the "ramp up" time past the threshold isn't exactly ideal. Maybe dialing in the threshold will help too. I am conflicted if I should use an entrance zone or not within the integration. Should it learn those behaviors or entering or just go with the mmWave sensors "all zone occupancy" without zones provided individually?

3. My basement door is always closed but if it opens, its occupied every time. Door shuts again and it should be occupied for a delay of walking down the stairs, then off. I also have a motion light switch at the bottom with the zone configured right in front of the switch. Motion in front of the switch, occupied 100%, same delay for walking up.

   • I think this one will work as I have it now with how I weighted the sensors but still testing my thresholds and timing Detected/Clear. I am going to leave it and see how it learns too.)

4. In my bedroom I have a helper set with an automation to hold during sleep. I treat this sensor as occupied if on 100%.

   • I included this helper with all my other motion sensors and a heavy weight. I concerned of its behaviors with decay and if its proportionally weighed against the other motion sensors with how much I trust this in being 100% occupancy when on. )

Now I can understand if I just need more experience and time, but I also think there is a place for newer users to understand it more simply. I have little doubt that I wont get the prediction dialed in eventually, but with so many variables involved I don't know what I should do sometimes to get the behavior I want.

If it seems out of scope I can understand that and don't think it will turn me away because of my setup, but it still feels like my automations may be a little more involved than I hope. And if I am using the integration for a prediction with a little more logic that isn't so bad. Overall though, its a great idea and it will already help me from getting too many automations being too complicated!

---

To summarize my final thoughts and what I would be hoping for is all the existing sensors are still always there and prediction occupancy is always there to compare to. But it would be nice if there were a few more options to get a little more control of:

• "entering/rising edge" conditions
• "leaving/falling edge" conditions
• hold occupancy conditions
• hold clear conditions

Then I would envision a sensor for each of those override condition to determine what type is active. Finally there would be another occupancy sensor that follows the prediction sensor unless an override causes it to detect or clear differently than predicted. (Maybe even another sensor or two that counts overrides opposite from prediction vs. overrides consistent with prediction. It may be helpful for users review over ride counts and if there should be adjustments the prediction values/thresholds or adjust overrides conditions from doing something wrong from the prediction.)