Presence Governor

doug · June 7, 2019, 7:58pm

This application is no longer maintained or supported, use at you're own risk

Presence Governor v1.2

Have you found GPS on your phone to be flaky? Have more than one type of presence sensor per individual? Presence Governor was created to combine several types of presence detection methods into a single proxy presence device. Fobs, WiFi, Geofencing and Lock Codes each with a unique logic in how the presence of the detection process triggers the proxy presence.

https://github.com/omayhemo/PresenceGovernor

Install the parent and child app code.
Install the app and configure individual Presence Governors for each person.

Prerequisites
If you want to use the WiFi presence sensor, you'll need a driver.

I hope you find it useful.

Inspired and Adapted from Joel Wetzel's excellent offering. GitHub - joelwetzel/Hubitat-Combined-Presence: A Hubitat app for intelligently combining multiple presence sensors, to make a better overall sensor.

endorphin_junkie · June 8, 2019, 6:31am

Can you outline the new benefits above Joel's work?

doug · June 8, 2019, 2:11pm

There are considerably more options in Presence Governor and a different sort of algorithm if you will. I spent a good bit of time tweaking and finding the right combination of tracking to get the most reliability.

Presence Governor separates the logical routines for different types of presence detection or you can lump them all together with the threshold settings.

Allowing a configurable threshold for arrival and departure on any Presence Sensor, Presence Governor overcomes the unreliability of a single presence source. I generally use it for the Geofencing apps, because sometimes they don't work. I will install several tracking apps on a single device, because sometimes one or more will miss an event. (Amazon's app is notorious for that).

If you wanted you could lump all presence detection types into this setting and simply use the threshold to govern them all. However, breaking them up by type allows for more reliability and institutes different methods by which arrival or departure is triggered.

The WiFi presence driver has unique logic, if present the person is definitely present, but due to the iPhone sleeping, WiFi not present events on the WiFi presence driver are ignored.

A Fob disregards the thresholds and apps, if the Fob leaves or arrives, the corresponding presence action is triggered with no further checks.

Also included, Lock Codes. If you have a smart lock on your door and you're using LCM, you can configure a lock code to activate present. That's useful for guests, for example, or just as another way to not miss an arrival event.

And one last doohickey, a departure delay for those times your phone's GPS is freaking out and popping away and back quickly.

Here's an extreme example of every single option being used.

Or a far simpler configuration, where just the lock code is used.

mluck · June 9, 2019, 4:59am

Doug, love your concept here, but struggling to get it to execute proxy departure.

To confirm my understand of your "threshold" concept: I have two geolocation presence sensors, the Hubitat app and Life 360. If my departure threshold is set to "2", it means both have to be "not present" for the proxy sensor to be "not present". And if my arrival threshold is set to "1", it means my proxy presence sensor will change to "arrived" the moment either one of the presence sensors shows as present.

All the above is further conditioned on the Wifi Sensor, whereby if it's present, then the proxy sensor is set to present, regardless of any other inputs. But if the wifi sensor is not present, it could be just asleep and is therefore ignored for the purpose of setting the proxy/output sensor.

I'm not currently using fobs or locks. Am I interpreting your logic correctly?

I ask because I can't get my proxy sensor to "leave", even when I set my arrival threshold to "1". The departure thresholds never even show up in the event log for the app. Arrivals appear to work fine. Any ideas?

doug · June 9, 2019, 12:59pm

You're describing it exactly as I intend it to work.
Please go to apps and click the gear next to the Governor you are having trouble with.

On the Status page, scroll down to event subscriptions and shoot a screen shot for me.
Like this...

Now, go to the events for the app and scroll through looking for any Presence Changed events with not present values. Immediately following that kind of event you should see a Threshold event as well.

Like so...

Royski · June 9, 2019, 6:08pm

I'm having the same trouble.

Subscriptions.

App

**Devices. **
- Life 360

- webCoRE Presence

Proxy

Events

Logs

app:65132019-06-09 19:06:57.660 errorjava.lang.NullPointerException: Cannot invoke method currentValue() on null object on line 260 (presenceChangedHandler)
app:65132019-06-09 19:06:57.649 debugPresence Governor for Roy: Departure Check
app:65132019-06-09 19:06:46.287 debugPresence Governor for Roy: Arriving

Any help appreciated

I think it doesn't like the fact I don't have a Fob Sensor?

rvrolyk · June 9, 2019, 6:15pm

I think line 260 should be something more like:
if (fobSensor && fobSensor.currentValue("presence") == "not present"){

so it makes sure there's actually a fobSensor configured before checking state.

Royski · June 9, 2019, 6:18pm

Quite possibly, but it doesn't like the fact I haven't configured one, as I don't have one
Which is producing the "Cannot invoke method currentValue() on null object on line 260" I think?

updated
If I set the Fob to be the same as a Presence sensor (As in add Roy ST as a fob too). Then its working

mluck · June 9, 2019, 6:49pm

Doug, per your request, here are the Event Subscriptions:

And on the event log, I get arrival thresholds (and the corresponding proxy events),but not the same for departure.

Any ideas?

EDIT: also, the logs show this:
2019-06-09 01:48:36.289 pm errorjava.lang.IllegalArgumentException: Command 'arrived' is not supported by device. on line 194 (wifiPresenceChangedHandler)

doug · June 9, 2019, 7:11pm

I pushed a change to correct the Fob Null Reference mistake and the inputsensor.arrived() problem.
Please let me know how you fare.

mluck · June 9, 2019, 7:31pm

For me, it's better, but not fixed. I do get my proxy sensor to update on threshold geoloc events for both departure and arrival now (thanks). However, the wifi sensor, when present, doesn't appear to override departures of the geolocation presence sensors, as I would expect. Ideas?

doug · June 9, 2019, 8:06pm

I'm thinking on that one a minute. I removed the fail safe on the geolocations and WiFi because of the error reported above. I need to understand exactly what was going on there.

mluck · June 9, 2019, 8:40pm

Understand, take your time. Appreciate you looking at it, cuz I think your concept is dead on.

Royski · June 9, 2019, 9:26pm

Thank you, working here very nicely now

doug · June 9, 2019, 9:32pm

I understand what's happening now. The HE mobile app doesn't implement arrived or departed, I should've noticed that. The error itself should not disrupt functionality, but I'm probably going to have to break up the Mobile App Device type from the Virtual Presence drivers, unless I figure out a way to get capabilities or device type. Still thinking...

Cobra · June 9, 2019, 9:56pm

@doug
This might help...

This is the code that I use to get the capabilities on a virtual device I use in ‘average all’
I use this to determine if the correct device (vDevice) is being used..

 state.devCapability = vDevice.capabilities.inspect()
	//	log.warn "$state.devCapability"
    if(state.devCapability == "[IlluminanceMeasurement, TemperatureMeasurement, RelativeHumidityMeasurement, MotionSensor, EnergyMeter, PowerMeter, Sensor]") {  
	LOGDEBUG( "You are using the correct Average All Virtual Device")
	state.correctDevice = true

You might be able to do something similar to check on which device is being used.

Andy

doug · June 10, 2019, 1:07pm

Unfortunately, the mobile app capabilities are listed as a PresenceSensor (which is expected in retrospect given they show up in the PresenceSensor input selector). So, from a capability standpoint, it looks almost identical to the virtual presence device.

Anyway that you know of, to sniff the publicly implemented capabilities?

Cobra · June 10, 2019, 2:07pm

The HE phone app also has device notification...
I don't think any virtuals have..

if you try this in one of your methods()

state.devCapability = deviceInputName.capabilities.inspect()
log.warn "$state.devCapability"

It should actually query the device give you the capabilities that the device has as a warn message in the logs..

doug · June 10, 2019, 2:23pm

Ya, I did exactly that for testing it. I did see the notificationdevice capability on the mobile app device, which is why I said almost identical. I'm dubious in using that to sniff it out, because technically it could be implemented on a custom driver in the same way somewhere else.

I really wish I could get the device Type. But failing that I will probably exclude all presence sensors with notification capabilities from being forced to arrive. I hate implementing hacks though.

stephack · June 10, 2019, 4:24pm

I quickly skimmed this thread so forgive me if I misunderstand what you need. If you would like to add a separate input for the mobile device, you should be able to use this format to list only a specific device type:

input ("devName", "device.[DeviceType]", title: "myTitle")

so for the Mobile app device it should be something like
input ("whichPhone", "device.MobileAppDevice", title: "myTitle")

Edit: forgot the quotations....Updated