Generic Presence Detection

presence
Tags: #<Tag:0x00007fd31db6e908>

(trumee) #30

I have a weird problem that the timer never expires. I have two sensors, an owntracks sensor and a phone IP

Group:Switch:AND(OFF,ON) gPresent <present> // all presence sensors belong to this group
Switch Present "Someone is Present" <present> // turns off 5 minutes after everyone leaves
Switch Present_Timer { expire="5m,command=OFF" }
Switch  PhoneBT  "Me @ Home" <bluetooth>    (gPresent)   { mqttitude="mosquitto:owntracks/me/phone/event:Home" }
Switch  PhoneIP <network>  (gPresent) {channel="network:device:d12435eb:online"}

The rules file looks like this

rule "System startup"
        when
                System started
        then
                Present.sendCommand(OFF) // assume no one is home on startup
                PhoneBT.sendCommand(OFF) // assume phone BT is not reachable 
end


rule "gPresent updated, at least one sensor changed state"
when
    Item gPresent received update
then
    logInfo("Debug", "------gPresent updated------")
    gPresent.members.forEach [s | logInfo("Debug", s.name + " equals " + s.state.toString)]
    logInfo("Debug", gPresent.name + " equals " + gPresent.state.toString)
    logInfo("Debug", Present.name + " equals " + Present.state.toString)
    // someone came home
    if(gPresent.state == ON && Present.state != ON) {
        Present_Timer.postUpdate(OFF) // cancel the timer if necessary
        Present.sendCommand(ON)
        logInfo("Debug", "Someone came home")
    }

    // no one is home
    else if(gPresent.state == OFF && Present.state != OFF){
        Present_Timer.sendCommand(ON) // start the timer
        logInfo("Debug", "No one is home after five minutes")
    }
end

rule "Present_Timer expired"
when
    Item Present_Timer received command OFF
then
    Present.sendCommand(OFF)
end

When both the sensors go off the logs show that the timer is switched on. However, the timer continues inifinitely. I dont understand why the group rule is getting update every few seconds, since the events dont show the update. The log file looks like so

2017-08-23 19:40:18.657 [INFO ] [eclipse.smarthome.model.script.Debug] - PhoneBT equals OFF
2017-08-23 19:40:18.657 [INFO ] [eclipse.smarthome.model.script.Debug] - PhoneIP equals OFF
2017-08-23 19:40:18.657 [INFO ] [eclipse.smarthome.model.script.Debug] - gPresent equals OFF
2017-08-23 19:40:18.658 [INFO ] [eclipse.smarthome.model.script.Debug] - Present equals ON
2017-08-23 19:40:18.659 [INFO ] [eclipse.smarthome.model.script.Debug] - No one is home after five minutes
2017-08-23 19:40:23.600 [INFO ] [eclipse.smarthome.model.script.Debug] - ------gPresent updated------
2017-08-23 19:40:23.600 [INFO ] [eclipse.smarthome.model.script.Debug] - PhoneBT equals OFF
2017-08-23 19:40:23.601 [INFO ] [eclipse.smarthome.model.script.Debug] - PhoneIP equals OFF
2017-08-23 19:40:23.601 [INFO ] [eclipse.smarthome.model.script.Debug] - gPresent equals OFF
2017-08-23 19:40:23.601 [INFO ] [eclipse.smarthome.model.script.Debug] - Present equals ON
2017-08-23 19:40:23.602 [INFO ] [eclipse.smarthome.model.script.Debug] - No one is home after five minutes
2017-08-23 19:40:38.694 [INFO ] [eclipse.smarthome.model.script.Debug] - ------gPresent updated------
2017-08-23 19:40:38.694 [INFO ] [eclipse.smarthome.model.script.Debug] - PhoneBT equals OFF
2017-08-23 19:40:38.695 [INFO ] [eclipse.smarthome.model.script.Debug] - PhoneIP equals OFF
2017-08-23 19:40:38.695 [INFO ] [eclipse.smarthome.model.script.Debug] - gPresent equals OFF
2017-08-23 19:40:38.695 [INFO ] [eclipse.smarthome.model.script.Debug] - Present equals ON
2017-08-23 19:40:38.696 [INFO ] [eclipse.smarthome.model.script.Debug] - No one is home after five minutes
.......
2017-08-23 19:49:59.298 [INFO ] [eclipse.smarthome.model.script.Debug] - ------gPresent updated------
2017-08-23 19:49:59.298 [INFO ] [eclipse.smarthome.model.script.Debug] - PhoneBT equals OFF
2017-08-23 19:49:59.299 [INFO ] [eclipse.smarthome.model.script.Debug] - PhoneIP equals OFF
2017-08-23 19:49:59.299 [INFO ] [eclipse.smarthome.model.script.Debug] - gPresent equals OFF
2017-08-23 19:49:59.299 [INFO ] [eclipse.smarthome.model.script.Debug] - Present equals ON
2017-08-23 19:49:59.300 [INFO ] [eclipse.smarthome.model.script.Debug] - No one is home after five minutes

The events logs shows that the timer is being called continuously,

2017-08-23 19:40:18.654 [ItemStateChangedEvent     ] - PhoneBT changed from ON to OFF
2017-08-23 19:40:18.654 [GroupItemStateChangedEvent] - gPresent changed from ON to OFF through PhoneBT
2017-08-23 19:40:18.659 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
2017-08-23 19:40:23.603 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
2017-08-23 19:40:38.697 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
2017-08-23 19:40:53.971 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
2017-08-23 19:41:09.411 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
2017-08-23 19:41:24.915 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
2017-08-23 19:41:40.071 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
2017-08-23 19:41:55.125 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
2017-08-23 19:42:10.231 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
2017-08-23 19:42:25.477 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
2017-08-23 19:42:40.577 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
2017-08-23 19:42:55.769 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
2017-08-23 19:43:10.923 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
..........
2017-08-23 19:49:13.757 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
2017-08-23 19:49:28.993 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
2017-08-23 19:49:44.084 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON
2017-08-23 19:49:59.301 [ItemCommandEvent          ] - Item 'Present_Timer' received command ON

Why is the Present_Timer being called every few seconds and why it doesnt stop after 5 minutes?


(Rich Koshak) #31

Have you installed the expire binding?

Since the time keeps getting command ON faster than every five minutes the timer will never go off.

Try adding a check to see if the Timeer is already ON in your else if and only send the command if it is OFF.

It looks like your rule keeps getting repeated away updates so the timer never gets a chance to expire.


(trumee) #32

Ah, I dont have that installed!


(trumee) #33

Something like this?

    // no one is home
    else if(gPresent.state == OFF && Present.state != OFF){
        if (Present_Timer.state == OFF) {
        Present_Timer.sendCommand(ON) // start the timer
        logInfo("Debug", "No one is home after five minutes")
        }

(Rich Koshak) #34

That would work.


(Kim Skatun) #35

Never thought about using that one for presence detection!!


(Kim Skatun) #36

Is it possible to map 5m to an number item somehow?


(Rich Koshak) #37

It actually works exceptionally well with reelyActive. Unlike phones, Fitbits don’t change their boradcasted ID frequently (something I learned after the post above). So reelyActive isn’t all that great a detecting whether a specific phone is present but works great to identify specific Fitbits.

Unfortunately no. You can’t change the timeout for an Expire timer at runtime. It is hardcoded into the binding config. If you want that you will need to code traditional Timers in Rules.


(catss) #38

Hi,

thanks for this great pattern, I implemented this yesterday with the FritzBox TR64 binding (including an admin switch to force presence). Works like charm, but with the ruleset as described above the Present switch would never be triggered as the Presence_Timer would not expire.

After a bit of digging I found the problem in the gPresent updated rule. As the TR64 works with regular polling (which will update the state of all items, regardless if the are changed or not) the timer would be reset over and over again (assuming the update cycle is shorter than the expiration time). Fix was simply to add a check for Present_Timer.state != ON see below for the patched code.

rule "gPresent updated, at least one sensor changed state"
when
    Item gPresent received update
then
    // someone came home
    if(gPresent.state == ON && Present.state != ON) {
        Present_Timer.postUpdate(OFF) // cancel the timer if necessary
        Present.sendCommand(ON)
    }

    // no one is home and timer is not yet ticking (otherwise endless loop)
    else if(gPresent.state == OFF && Present.state != OFF && Present_Timer.state != ON) {
        Present_Timer.sendCommand(ON) // start the timer
    }
end

(David Arango) #39

Hello Rich! I wanted to ask you about your reelyActive + Pebble implementation. Is you pi-suite detecting the pebble without it being in pairing mode? mi reelyActive pi-suite only detects the pebble in pairing mode.

Thank you!


(Rich Koshak) #40

It has been more than a year since I’ve done anything with the Pebble. When Fitbit bought and discontinued it my wife moved to an Apple Watch. Plus, the Apple Watch had native support for her Dexcom rather than the hacked together reversed engineered support on the Pebble.

So I honestly have no memory of how it worked with reelyActive.


(Kevin) #41

Little Typo … and -> &&


(Justus) #42

Sorry, I might be totally wrong over here but I am highly interested into integrating a Dexcom G5 into openhab. There might be a chance via the share-account…cause the pebble gets the information that way as well.

Unfortunately I do not have a clue on how to integrate it. But the idea is just to activate a light while glucose level becomes critical. That might help a lot!

I cannot find anything within the web but very complicated solutions via nightscout…and I think it would be pretty much easier to get the information directly from dexcom’s share server and integrate it.

Thanks in advance.


(Rich Koshak) #43

This is an intriguing idea. My wife (the one with the Dexcom) had her’s integrated with the Pebble for awhile but now has an Apple Watch with the direct integration with her iPhone (no more little blue and black receiver :slight_smile: ).

As far as I can tell, Dexcom discontinued their support for Share:

and I’m pretty sure the G5 doesn’t use any Dexcom cloud servers at all. Though that doesn’t make much sense as there is still the Follow app.

[google google google]

Aha! I found a REST API.

https://developer.dexcom.com/overview

Looking around, this should be very doable. It probably warrants its own binding but it should be feasible to make something work with the HTTP binding and/or sendHttp actions. It would look a whole lot like the iCloud integration prototype

It might even be possible to make just one binding that doesn’t require every user to create a developer account with Dexcom. That would be really cool.

This is really exciting. I wish I had more time to work on this. I’ll have to talk to my wife to see if she is willing to be a guinea pig (she is pretty well controlled and has good hypo and hyper awareness so will not be gung-ho to have her CGM linked to the home automation).

Of course, if you or anyone else wants to run with this that would be awesome. I’ve not much time to work on something like this. If not I’ll start to chip away at it as my time allows.

Thanks for posting!


(Justus) #44

Well as far as I am able interpreting it the share servers still do exist. The pebbles in my household are still working via their share accounts. So from that point of view I think that there must be a simple way integrating it.

I had a closer look to the site you mentioned. Well I am able to understand the logic but I am not able turning it into a code. My programming experiences are quite old…

The idea is just getting logging in via the http-binding, and getting the glucose level. As far as it igets underneath a certain value, let’s say 65mg% turn a light into red. As soon as it rises above, turn to the last state.

Hypo awareness is great. But one thing is certain: Uncertain things occur :wink:

If you could give me some clues, or a very basic solution I would be very happy.

Thank you :slight_smile:


(Rich Koshak) #45

Your best best will be too read up the docs at that link and look at the iCloud integration link for an example that will work very similarly.

The way these REST APIs work is to create an account to get a token you use in your http commands. Then it is a matter of making the right http commands with the right body and format to send and receive.


(Justus) #46

Okay. Thanks. I will try to do so.


(Rich Koshak) #47

Over the past few months I’ve spent a few minutes here and there working with the Dexcom API, trying to make it work with OH Rules.

I finally have it almost working with their sandbox and I’ve run into this nice little footnote:

Data from the Dexcom API is available with a three-hour delay.

So for all intents and purposes the available data through the Dexcom API is useless in a home automation context.

Oh well, it was a good thought.


(Justus) #48

Well…I can’t believe it cause there seem to be several real time apps available. Or are you trying the sandbox data only? That might use a delay for…whatever reason. Perhaps in generating artifical data. All the pebble watch faces for example are using the api…in real time. Try to shift your example app to your wife’s share account and see what happens.

Unfortunately I failed with the oauth… .otherwise I would really like to waste some time with it.

If you would disclose your code I could try it as well (well… I am a real dilettante). But I would be very interested in that.


(Rich Koshak) #49

It’s the result of a compromise with the FDA. The FDA insists that apps that use Dexcom’s API cannot be used to make treatment decisions.

Data Availability
Data from the Dexcom API is available with a three-hour delay. This delay is enforced on the data upload time, not on the timestamps of individual data points. The G5® and G6® Mobile applications upload once per hour, so the data will (on average) be 3.5 hours delayed. On the other hand, data uploaded directly from a receiver over USB (via the Dexcom CLARITY® uploader) is available immediately because it is viewed as an active, rather than passive, upload. For more information on this delay, please see the FAQ.
https://developer.dexcom.com/endpoint-overview

and

https://developer.dexcom.com/content/frequently-asked-questions

See “Can apps get real-time estimated glucose values (EGVs) with the Dexcom API?”

I believe Dexcom only supports Apple Watches officially for real time data using their app. Pebble support was done through a hack (NightWatch or NightScout) or if I remember correctly, required a “Dexcom -> phone -> cloud -> back to phone -> pebble” communication path and that path used Dexcom’s internal APIs not the public API.

I’m posting a tutorial on the OAuth part. Stay tuned.