Generic Presence Detection

Tags: #<Tag:0x00007f1877e75ae0>


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"
    Item gPresent received update
    // someone came home
    if(gPresent.state == ON && Present.state != ON) {
        Present_Timer.postUpdate(OFF) // cancel the timer if necessary

    // 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

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!

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.

Little Typo … and -> &&

1 Like

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.

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.

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!

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.


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:

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/ CFNetwork/711.2.23 Darwin/14.0.0"
        , login: 'https://' + host + ''
        , accept: 'application/json'
        , 'content-type': 'application/json'
        , LatestGlucose: "https://"+ host + ""

    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;"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 {
       http.ontimeout = function () {
    http.onerror = function () {



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 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.