Generic Presence Detection

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:

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.

Okay. Thanks. I will try to do so.

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.

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.

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.
Dexcom API | Home

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.

Hi Rich

Sorry, I have been completely offline during the last two weeks.

It might be right that there is a delay of 3h or more via the api.

But nevertheless I can tell you that the Pebbles in use got their information in (near) real time. They are using the/an api which is supported by dexcom. They are using the so called “share account”. Although Dexcom once announced they finished the “share service” they decided in continuing it.

They are using the way watchface -> cell phone -> pebble app -> internet / share account -> pebble app -> watchface.

To give an example of a working watchface: https://apps.getpebble.com/en_US/application/56534d58d2d67de36d00005f

Well and of course those result of hacking hobbyists might result in accountability risks…that’s why they let you know “not for treatment decisions”. Nevertheless it is always a question where you are going to use it for. I thought it to be a good idea having flickering lights within your home if there seems to be something extraordinary.

Those guys doing diy closed loop systems are using the same way afaik…

So there might be a second api.

Dexcom supports apple as well as android watches. The usage of pebble is indeed a thing developed by ambitious hobbyists. From everyday usage I cant tell you that the pebble solution is as reliable as the apple or android one. The big advantage in reliability is that you do not have to recharge it once or twice a day. Makes you much more independent. The only little drawback is that you need internet connection cause of the way via dexcom share -> cell phone and not app -> pebble app directly. But that’s in most of the cases neglectable, especially while the watchfaces tell you the age of the last measurement in min.

As did my wife’s but that wasn’t through the official API. It was through the rube-goldberg system set up to make systems like night watch work.

As far as I can tell there is no officially sanctioned way for us to get the numbers in real time. Doesn’t mean there is no way, we just can’t do it through the official API.

I’m pretty sure those faces do not work through the official Dexcom apis. I could be wrong but at the time (this was year ago) it seemed to work using screen scraping.

That wasn’t our experience which is why we switched to Apple watch. And when Pebble stopped being supported we had no hope that it would ever get better. YMMV.

Which was also a problem when we are out hiking in the mountains and such where cell signal is along way away. The newer unit take straight to the phone and if one has a general Apple watch the watch take directly to the sensor and you don’t even need the phone.

Thanks Rich. I was just dreaming of a simple solution which was that obvious and close that we just did not recognize it :wink:

Perhaps they might offer their api being in real time in the future…

One can hope. But from what I can tell on their site and the various forums it wasn’t their decision. It was the only way that the FDA would allow them to offer their API at all. Perhaps users in other countries will have better luck.

It would have been nice to get the real time information to drive devices though. Create an announcement, light up a colored bulb, etc.

I’m sure it could be done with NightScout et al given their open source nature so if someone were motivated that could be an option to look into.

I can at least give Dexcom this much credit. They at least have an API. I could find nothing about a Medtronic API.

…well, there seems to be a way. If you follow one of the dexcom-pebble-watch-faces…you will find the way…

Just try a little simple reverse engineering. You will get to the share server… I do not know wether you are using the dexcom companion app. this is an official app for supporting family members or medical staff… and this is using the share server / share service.

Just a snippet of the pebble watch face code:

//use D's share API------------------------------------------//
function share(options) {

    if (options.unit == "mgdl" || options.unit == "mg/dL")
    {
        fix = 0;
        options.conversion = 1;
        options.unit = "mg/dL";
        
    } else {
        fix = 1;
        options.conversion = 0.0555;       
        options.unit = "mmol/L";
    }
    
    var host = "share1";
    if (options.region != 'outside') {
        host = "share1";
    } else {
        host = "shareous1";
    }
    options.vibe = parseInt(options.vibe, 10);
    var defaults = {
        "applicationId": "d89443d2-327c-4a6f-89e5-496bbb0317db"
        , "agent": "Dexcom Share/3.0.2.11 CFNetwork/711.2.23 Darwin/14.0.0"
        , login: 'https://' + host + '.dexcom.com/ShareWebServices/Services/General/LoginPublisherAccountByName'
        , accept: 'application/json'
        , 'content-type': 'application/json'
        , LatestGlucose: "https://"+ host + ".dexcom.com/ShareWebServices/Services/Publisher/ReadPublisherLatestGlucoseValues"
    };

    authenticateShare(options, defaults);
}

function authenticateShare(options, defaults) {   
 
    var body = {
        "password": options.password
        , "applicationId": options.applicationId || defaults.applicationId
        , "accountName": options.accountName
    };

    var http = new XMLHttpRequest();
    var url = defaults.login;
    http.open("POST", url, true);
    http.setRequestHeader("User-Agent", defaults.agent);
    http.setRequestHeader("Content-type", defaults['content-type']);
    http.setRequestHeader('Accept', defaults.accept);
    
    var data;
    http.onload = function (e) {
        if (http.status == 200) {
            data = getShareGlucoseData(http.responseText.replace(/['"]+/g, ''), defaults, options);
        } else {
                sendAuthError();           
        }
    };
    
       http.ontimeout = function () {
        sendTimeOutError(options);
    };
    
    http.onerror = function () {
        sendServerError(options);
    };

    http.send(JSON.stringify(body));

}

This is be the result of reverse engineering of the official app…and this is in fact real time.

You can find the entire code within https://github.com/tynbendad/simplecgmanalog if you are downloading the zip-file within the pebble-js-app.js file. And this is in fact no rube-goldberg-machine or algorithm.

What do you think about it? I am quite happy seing it.

If you have the time I say give it a try. I just remember for the G4 with my wife’s pebble the path was the Sensor->CGM->iPhone->Dexcom Cloud->iPhone Pebble App->Pebble

If any link in that chain broke then no readings. NightScout is even a longer chain (or it was last time I saw it IIRC):

Sensor->CGM->Android (iOS wasn’t supported at the time I think)->Dexcom Cloud->Android->NightScout Server->Android->Watch Face

For some reason, the BT connection to the Pebble was flaky and the we are out of cell network far to frequently for it to be a viable option much of the time. When FitBit bought and discontinued support for Pebble we realized the BT problems would never get better.

Anyway, long story apropos to nothing.

This posting on the NightScout github might be a tad more complete:

It’s three years old so it might not be kept up to date. But there are curl examples and everything. The hard part will be constructing the HTTP requests which is already done in the OAuth2 tutorial I posted.

If you’ve the time I say go for it. I won’t have the time to look back into this at least until September.

Ok thanks. Perhaps I will have some time (and spirit) trying a little on our summer holidays. Thanks so far.

Please do report your progress if you do tackle it.

Thank you for this code, I added a manual over ride switch for the babysitter or guests. This is assuming I don’t use zwave 3in1 sensors as presence sensors…not sure yet but it was fun to play with the code anyway as I am new to openHAB.

I added the manual switch item (probably doesn’t really need to be in the group switch but it didn’t work by just setting that switch to ON when in the group switch):

Group:Switch:AND(OFF,ON) gManualPresent <present>
Switch Manual_Present <present> // master manual present switch

then added the below in to the “gpresent updated” rule

 // no one is home
    else if(gPresent.state == OFF && Present.state != OFF && Manual_Present.state == OFF)

then another rule

rule "Manual Present Switch Turned Off"
when
    Item Manual_Present received command OFF
then
    Present_Timer.sendCommand(ON)
end

The idea being that present switch won’t turn OFF if manual over ride is on. Then when I turn it off it just sets the presence timer on to resume normal operation.

Thanks again!

Thanks @Nick_Moad
Good idea
Could you edit your post and add the code fences, please?
Thanks

1 Like

After thinking about this, it is probably not required to integrate it with the timers above as you could just set any rules that use the presence to check “manual presence != ON”

I’m trying to use DSC Alarm sensor with this fantastic rule. But presence never goes off. What’s wrong?

items

Switch Present
Group:Switch:AND(OFF,ON) gPresent
Switch Present_Timer { expire="15s,command=OFF" }
Switch PresentDSC (gPresent)

rule

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

rule "gPresent updated, at least one sensor changed state"
when
    Item gPresent received update
then
    logInfo("presence.rules","gPresent aggiornato")
    // 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
    else if(gPresent.state == OFF && Present.state != OFF){
        Present_Timer.sendCommand(ON) // start the timer
    }
end

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

rule "DSC"
when
    Item DSCAlarmMotion changed from OPEN to CLOSED
then
    PresentDSC.sendCommand(ON)
end

debug

rule "debug"
when
    Item Present received update
then
    sendTelegram("home", "Presence - " + Present.state.toString)
end

Does PresentDSC change state?

Yes

2018-10-25 23:02:17.523 [ome.event.ItemCommandEvent] - Item 'Present' received command OFF
2018-10-25 23:02:17.525 [vent.ItemStateChangedEvent] - Present changed from ON to OFF
2018-10-25 23:02:28.625 [ome.event.ItemCommandEvent] - Item 'PresentDSC' received command ON
2018-10-25 23:02:28.632 [ome.event.ItemCommandEvent] - Item 'Present' received command ON
2018-10-25 23:02:28.638 [vent.ItemStateChangedEvent] - Present changed from OFF to ON
2018-10-25 23:03:24.084 [ome.event.ItemCommandEvent] - Item 'PresentDSC' received command ON

(See time)