Presence Sensors

🛎️ Get Help Devices
3

Same here dpdurst. Yesterday’s SmartThings Cloud failure was the last straw in a line of failures I’ve had with that product in the past 2yrs. I don’t need (or want) the Cloud governing the functionality of my devices and the Hubitat is going to free me from it. :sunglasses: ST Could failures are an opportunity for Hubitat sales…at least for some of us. :wink:

1 Like
4

It was almost like the Hubitat crew knew ST would be in a mess this year and timed their release perfectly. As soon as January hit and there was failure after failure…and ST started talking about a new API…I was ready to jump. After I saw there was Lutron Integration and the Other Hub allowed for a phased transition…it was a no brainer. And that’s the story of how this tinkerer got his “groovy” back :nerd_face:

4 Likes
5

Frustration over the latest ST outage last night forced me into looking for an alternate. The “straw that broke the camel’s back”.

I just heard about Hubitat this morning and saw it is available for $99. After work, I went to order and see they raised the price today to $129.95. Oh, well, I ordered it anyway.

2 Likes
6

Yes Life 360 is what we use so anxious to see the difference if there is much between ST and Hubitat. The one thing that might slow this down for me a bit is I need alerts when doors open and close to make sure folks are doing what they do. I’m pretty sure from what I read that is possible so as long as those are workable this might be doable for our upcoming cruise, otherwise it will have to wait till I get back to get that portion setup.

7

I just talked to my brother who is an ST user as well, he is going to check this out when he gets home tonight as well. His big thing is Alexa integration for the device.

I told the wife about it a few minutes ago and she said have fun playing… love it when she just goes with the flow… lol

4 Likes
8

I use life360 for presence for both myself and wife. I have to refreshed the app almost every 2 days with ST and it was pretty frustrating. It was working fine for a couple of years with just a couple of refreshing before November of last year.
Only been playing for 2 weeks with Life360 on Hubitat and so far so good but it's still early to know.
I still have half my devices on ST and it was not fun yesterday with outage. Don't think I will abandon ST anytime soon because of the mobile app. I don't use it often but it's a must for my wife and kids.

1 Like
9

I have a virtual presense sensor in ST that is based on wi-fi presence. I have a script running on an ASUS router that checks for a MAC address on my wifi and then sends an away or present command to the virtual presence sensor. Is that something that could probably easily be done with Hubitat?

Here is an example of what gets sent now to ST.

curl -H "Authorization: Bearer " -X POST “ST GRAPH URL/api/smartapps/installations//away”

curl -H "Authorization: Bearer " -X POST “ST Graph URL/api/smartapps/installations//home”

10

this works without an actual Bearer token value?, or was this just omitted for privacy...
Anything is possible here, its just a matter of priority!

11

I would love to have this functionality as well. App presence sensors are fine, but this way I could add all my family’s devices for presence without adding apps they don’t need otherwise.

12

Interesting. I’m looking at possibly using this Homebridge plug-in to trigger a virtual switch once @pdlovelace has ported his Homebridge plugin for Hubitat. I thought I might be able to use it as part of a rule in combination with other means of detection to determine actual presence vs devices dropping off the network alone.

13

Yeah the access bearer token APPID got stripped. when I posted. But it seems like this might be easy to do. probably with the same overall process?

14

I cannot edit my post for some reason, but to be clear. I have a smart app for the presence sensor. The DTH is/was just a Simulated Presence sensor, the CURL command set the Home or Away to the APPID from ST

15

This is fixed in an upcoming release, currently app generated tokens do not work in the header as Authorization: Bearer (token)

to work around this, it needs to be a URL parameter access_token=(token)

16

We don’t currently have a cloud endpoint that would accept this type of request at this time.

You should be able to do this with a hubitat driver and avoid the cloud altogether.
Folks that have written some lan device drivers can chime in, i currently don’t have any code tidbits to offer…

17

Thanks. That's kind of what I was imagining. Seem like if its all local the router should be able to send something to the IP of hubitat to accomplish pretty much the same thing.

1 Like
18

This is definitely possible and would be more reliable on Hubitat since it’ll be a local endpoint. Do you a SmartApp on ST that creates this endpoint and controls the virtual presence sensor? Should be fairly easy to port over. If you have the SmartApp code, you can start a new thread here and we can help getting the code ported over.

19

I used this one (I’m unable to post URLs, but I think you can figure it out. :slight_smile:

github/chadly/smartthings/blob/master/smartapps/chadly/asuswrt-wifi-presence.src/asuswrt-wifi-presence.groovy

20

The smartthings forum post is here for the asus router presence sensor script.

1 Like
21

@mike.maxwell, @mattw, @dalenberg

My HubDuino (ST_Anything) supports Child Presence Devices. This was a recent addition for a ST user (long story...:wink: )

I am guessing that the Asus router code could be modified to send the properly formatted LAN packet (no OUATH required) to my HubDuino Bridge Driver / Service Manager App / Child Presence Sensor Driver. It just needs a LAN packet that contains the string "presence1 present" or "presence1 not_present" for the driver to parse() and create events for the service manager to use to automagically create child devices and keep them up to date.

2 Likes
22

I gave that code a shot, it works great. I added this to the update method so I could get the right urls:

def updated() {
    log.debug "away url: ${fullLocalApiServerUrl('away')}?access_token=${state.accessToken}"
    log.debug "home url: ${fullLocalApiServerUrl('home')}?access_token=${state.accessToken}"
}

Here is what I get in the logs:

2018-03-15 16:12:33.795:debughome url: http://192.168.1.15/apps/api/776/home?access_token=2a16f329-7e13-4d62-b925-7682abdc7985
2018-03-15 16:12:33.790:debugaway url: http://192.168.1.15/apps/api/776/away?access_token=2a16f329-7e13-4d62-b925-7682abdc7985

here are the commands I used to invoke:

curl -X POST "http://192.168.1.15/apps/api/776/home?access_token=2a16f329-7e13-4d62-b925-7682abdc7985"
curl -X POST "http://192.168.1.15/apps/api/776/away?access_token=2a16f329-7e13-4d62-b925-7682abdc7985"

With the new version of the hub 1.0.3 (available today) you can also call it like this:

curl -H "Authorization: Bearer 2a16f329-7e13-4d62-b925-7682abdc7985" -X POST "http://192.168.1.15/apps/api/776/home"
curl -H "Authorization: Bearer 2a16f329-7e13-4d62-b925-7682abdc7985" -X POST "http://192.168.1.15/apps/api/776/away"
3 Likes