SimpliSafe Alarm Integration (cloud to cloud)

dth_security
dth_alerts
project_security

#712

So with the two scenarios I’m running:

With the presence, using the SHM is pretty responsive because there’s no polling that needs to happen. As soon as we are in range, ST changes the SHM state and that drives the SS change. I’m not clear as to what changes the SS tile in that scenario. My belief it is SHM and the polling is not needed. This is great, but I’m hesitant to go 250m before my house arms so I use it when I come home and the door is unlocked and Bambi is eating grass in the yard etc.

Due to the above mentioned neurosis, I use the keypad when I leave, which of course relies on the poling. I suppose since the house is now “armed”, I don’t need to care about when the other things like AC set to away or lights change etc. It’s just the ADD in me that wants everything to work immediately.

I’m not sure the polling detection with SS is an issue. If you are using the API more now, then wouldn’t it be just an emulation of the iOS and Android apps? And, I would think by now they have full knowledge of others (not just us on this site) who are doing similar things. This is the wave of the future so I’m not sure the “detection avoidance” theory holds as much water now as it did a year ago.

I’m surprised you are getting upwards of 7 minutes on your updates when there is a 5 minute time set. That’s really odd.


#713

Any chance either your or Toby are looking into the Hubitat environment? I would love it if you could port SS over to that. It supports most of the DTH now except the Oath is only on the app side.


(Scott Silence) #714

No, I am not familiar with Hubitat and didn’t have any plans to look at it.


(Scott Silence) #715

Is anyone else experiencing connection issues today. I commented the try catch around the primary api login command and get the following error:

5:22:27 PM: error javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure @line 289 (apiLogin)


#716

I just checked I can’t change anything with the ST. Home and Away say pending and then change back. I am getting this error as well:

2:58:28 PM: error java.lang.NullPointerException: Cannot get property ‘respAuthHeader’ on null object @line 313 (getUserId)


(Ajay Prakash) #717

Yes, I can’t use the app today and the stage changes wouldn’t realy back from SS to SimpliSafe. Looks like they changed the website again today as when I login to SimpliSafe website I’m presented with a new look which may have broken the functionality.


(Toby Cth3) #718

Same here. Looks like they changed something and broke it again. :cry:


(Scott Silence) #719

I can access with a test app that runs in chrome fine. So, maybe something in SmartThings??


(Scott Silence) #720

What a pain!!! Might be about time to look at other diy alarm systems to see if any have published api’s or work well with SmartThings.


(Scott Silence) #721

Well, I am done messing with it for tonight. It looks like either SmartThings is having issues on the back end, there is some new SSL requirement that we are missing (not likely), or SimpliSafe is blocking request from the SmartThings API (this is my fear).


(Toby Cth3) #722

Not making much progress here either. I’m hoping it’s just something on the SmartThings side.


(Marc) #723

I switched from Simplisafe to Abode two months ago just in the nick of time. The integration with the IFTTT maker channel and WebCoRE/Smartthings has been flawless. Highly recommend Abode.


(Olivier Cuny) #724

At this point, I am thinking about doing the same and switch to Abode.

How is the response time with IFTTT in general?


(RCP) #725

it appears to be a TLS version issue. I have PowerShell code for connecting to the API and if I force it to use TLS version 1.2, I can connect to the API. However, I don’t know how this can be done in groovy. I hope one of you can figure that out. :slight_smile:


(Marc) #726

With the IFTTT maker channel, very fast.


(Scott Silence) #727

I am starting to agree this is some sort of certificate issue.

I found this post (the entire thread looks to have issues similiar to ours that resulted in delayed certificate updates on SmartThings, which eventually resolved themselves).

From that post I went off and setup an apigee.com account for free. I then changed all the urls and have them running through apigee.com, and it all is working now. I don’t think this is an ideal solution as apigee can see your username and password, but it does confirm the api still works correctly and it is either SmartThings having SSL issues with the simplisafe api or simplisafe blocking smartthings.


(Scott Silence) #728

Ok, so this does appear to be working (with some quirks). Every now and then a post or get won’t work (not sure why, guessing it might have to do with passing through a secondary server). But, it does make it work again. Again, not an idea solution, not sure what the path forward will be.


(RCP) #729

I guess SS updated their API to require TLSv1.2 and ST by default does not use TLSv1.2. See this thread about using TLS version in the request but I can’t get it to work.
https://community.smartthings.com/t/release-automatic-connected-car-integration-with-smartthings/19990/298?u=rcp


(RCP) #730

(Scott Silence) #731

I tried that one yesterday, and couldn’t get it to work either. Looks like SmartThings needs to update to use TLSv1.2.