Basically what you're doing is adding a timeout, like "Don't depart immediately from a gps sensor. Wait a bit and see if it sticks." (Because the wifi sensor has a little time delay)
There are other ways I could implement that in the standard combiner. It would increase the time to detect a departure, while helping avoid false departures.
I've actually been thinking of doing that, because I've seen the same thing as you. Every once in a while, one of our HomeKit gps sensors will flake. I'll get a "Wife has departed", followed by a "Wife has arrived" about 1 second later.
An explicit (and configurable) delay on gps departures would probably be a better implementation than also requiring wifi departure. I'll keep this in mind as other feedback comes in.
I have a multiple presence sensors (wifi, GPS, presence fob, etc) setup that includes a BLE USB dongle in my car. The issue I run into is that it detects my arrival really well but then after the car has shut off for a while it cuts power to the USB and then the app briefly becomes not present and then switches back to present. Is there a way to make it so that it will not change if a certain number of presence sensors are still present? Would this be a use for the advanced combiner?
That is likely why HE includes that in the configuration of the geolocation for the built in GPS presence in the app. If I recall, even ST did this. The only device I have found that does not have the capability for a delay built in is with Google Home for their home away routines. I think if you are using Home Assistant, you may also have to write your own rule.
If you add the feature, please make it user configurable on time and allow it to be turned on/off. I currently use an external trigger from Tasker, and built in my own delays externally. Not looking to change everything with the new version that is working flawlessly for me.
Joe, I currently use them. I have 6 geofence detection systems that are fed in pairs into a ‘best of 3’ majority gate giving a final geofence Present / Not Present per family member. The logic is represented in my dashboard view below (where CP-AC1 = Combined Presence-Advanced Combiner 1) for Advanced Combiners 1, 2 & 3. It may be overkill but provides multiple levels of redundancy and I have never had a presence failure in over 3 years. I did have Life360 in the mix until they pulled the plug, so replaced it with Google Home.
The geofence presence then is combined with WiFi presence via another Advanced Combiner to give a final aggregated Present / Not Present per individual (as shown in the second dashboard screenshot) and then a Boolean OR combiner to get the final Resident Home status.
That sounds little like wifi sensor behavior, where arrivals are 100% accurate, but departures are not. You could put the BLE sensor into the wifi category in the standard combiner.
Ok, I think I've seen enough votes. I'll keep the advanced combiner around. (Though I probably won't put the effort into new features on it that I'm putting into the other ones.)
I started having issues with the standard combiner showing departure when wifi was still connected, so I switched my family of 6 over to advanced combiner and it has been working great. It seems like sometimes an iOS update fubars the iPhone gps so that the location wanders in and out of the geofence constantly until another update fixes it.
I'm also using Advanced Combiner because I'm not using the same presence indicators for arrived and departed. At first I was having some unreliable presence and since I've been using the Advanced Combiner, it has been spot on every time. Maybe I had just not configured it correctly and I also since added Locative and Homekit to the table and these were both game changers, so maybe I don't need it anymore but since it works great as is, I have not touched it nor tried to use the regular combiner.
It would be if we had the ability to say I need at least x number of devices to be present before considering arrived and same for departed. I would be happy and believe I could have a perfect balance by not having the advanced part. I believe I had asked for this in the past, but since you are rewriting it, it might be something you would consider adding?
New user here. Just this morning life 360 stopped working for me in both built in and + versions of the handler. I created a combined presence sensor based on my HomeKit location and wifi status for both my wife and I. My question is about the standard setup and arrivals. Will this trigger a present state of the output device for the first status change it sees whether it by GPS or Wifi, or do both input sates have to be present before the output state will be present? I assume for departures, both have to be not present to create a change in the output state.
I have been using the OwnTracks with the wifi in OwnTrack and UNIFI. I has been sold so far. For my Presence I Hubitat, OwnTracks, HD+ (V-Switch) and WIFI this as worked best for me. I'm assuming this all compatible with Combined Presence app.
I rely heavily on advanced combiners for presence tracking. I can't imagine how they could be harmful (you'd certainly know better than me @jwetzel1492 ) I've used them for so long I'd have to completely rethink how my presence detection was setup. My argument for keeping them is that it provides redundancy for when other options fail (which happens frequently with the hubitat app) or aren't reliable (as with wi-fi presence detection, especially considering that iPhones set off their wifi radios t save power).
For a little background on my use, I'm using Node-Red to process all of my presence flows. The flows are very complex (see attached pic for an example of just my first tab of flows). Within the Hubitat app I'm using four different advanced combiners. Two of them track home/away presence for me and my wife using wifi presence, a virtual switch based on location reporting from the apple home app, and the hubitat mobile app. The other two track sleep/awake presence using Withings sleep sensors and the Sleep Number presence sensors (both of which have their issues, but work very reliably with advanced combiner).
Of course, the four advanced combiners report to one virtual output "sensor" each. Those four virtual sensors and their individual states are the very first nodes in my presence flows and are the bedrock of everything else that happens within my home automation. As far as I know, there is nothing else like it in the thousands of nodes available in the Node-Red library.
For me the advanced combiner has been bulletproof. I would be quite sad if it didn't exist. I could probably find a work around eventually, but it would be rather complex and probably require some coding. I'd rather not have to reinvent the wheel if I can avoid it.
I have been using Standard Combiner for a while now and a persistent issue has been that GPS absence overrides Wifi presence. So when I arrive at home, Wifi (iphone Wifi presence sensors) immediately connects and becomes present, however the combiner waits until GPS has arrived before combining -> Present.
I can understand this type of logic applied to departure, but not arrival. Can Wifi be made to have priority over GPS for arrival only?
Not sure if this is a fluke on my end or an inherent/systemic problem - all I know is when I come home and my arrival automations haven't ran, I load up my dashboard and see my wifi present, lack of GPS presence, and combiner output sensor isn't Present. A few minutes later my automations trigger and I look and see GPS has arrived and Combiner output is Arrived.
This issue is still plaguing me. My standard combiner has been stuck on present since 12/2 ~5PM.
The Wifi presence input has toggled plenty since then (including around the time of the above combined present event), but the GPS input has been stuck on departed/not home since ~9AM that morning. So the Wi-Fi arrival triggered the combiner arrival on 9/2 5pm, but I guess because the GPS never updated the combiner somehow failed to "reset" ..... Ohhhhh, because loss of wifi is not a trigger for departure... Right, okay I guess that's "expected" (but undesired) behavior. Any suggestions? Maybe I can set a rule so wifi arrival overrides/sets GPS presence status to present?
Sorry I thought that was the whole idea behind these apps, to work around/with unreliable presence sources. If we were all able to "fix" them there'd be no point in this app existing...
Not necessarily. A typical use of combined presence would be to establish presence based in input from presence sensors for different individuals who are all residents of the same space.
