Alright, here’s the full code: https://github.com/Oendaril/TotalConnectAsync/blob/master/TCAsync.groovy
Let me know how that works for y’all.
EDIT/UPDATE: I just updated my device handler source code with the source Oendaril just posted and it works again! Thank you so much!
Been using this for over a year now, become very reliant on it. All of a sudden it quit working about 6 days ago. Keep getting “Connection Refused” errors all of a sudden and the device is stuck in “Arming” status. I assume this is a common problem and has not been fixed as of yet?
Me too! Thank you! Just swapped out my old device handler code (the bdwilson version) with this updated one and it works again. Thanks!
Just switched to this new DH and I’m back up and running again. Thanks dude!
@jhstroebel For sake of easy understanding and new comers, how about you start a new thread in this Forum and I close this down. Clearly, you have made vast improvements in this project and have better depth and understanding of this issue. I’ll Close this thread pointing to your new one as well as Update my Git Repo to point to yours.
The reason I say this is because, I can’t edit my initial post to point to your code or updates.
I will do that.
All, quick update before moving… I have reached out to the person at Honeywell. I will see what is said. This code gives me some ideas on how I might be able to get this all to work with Async methods if necessary… I just do alot in preferences that needs to happen in the right order… but I can probably figure it out if needed.
Wish we could poll sensors in real time over the LAN… I think that would solve the issue with too many commands getting the SmartThings IP blacklisted and make Honeywell much happier.
Please forgive me, i’ve been a long time user of this integration (thank you!!). I updated my device handler code (https://github.com/Oendaril/TotalConnectAsync/blob/master/TCAsync.groovy) and installed the new smart app (https://github.com/jhstroebel/SmartThings-TCv2/blob/master/smartapps/security/totalconnect-2-0.src/totalconnect-2-0.groovy )
I install the smart app but when i enter the credentials it loads to a blank page. Any ideas?
This is an awesome integration that i truly believe HoneyWell should have offered stock. FYI I am using presence sensors and modes to configure when the house should trigger “Armed Stay” vs. “Armed Away”. If people are hone & event/time Armed Stay. If no one is home & event/time, armed away.
The only smartapp you’d be using with the DH I posted is the location and device helper smartapp, mine is just the panel-only device. If you were using the full zone/sensor setup, that’s still not ported yet due to the complexity of async callback chaining it will need To use my version, just install the DH on a custom device and configure the settings on it.
@jhstroebel, your version definitely does look doable but like you said it will take a bit more separation of the method structure into separate callbacks for each phase of config. If I get some more free time i’d be happy to poke at it, but wanted to get a minimum viable DH (also selfishly the one I use 
) first.
I’m also not fully convinced they didn’t IP block where we were requesting from, it may just be the async handler uses a different request server that wasn’t used before. I wish there was an easier way to “push” from the TC server but that’s not how they modeled it in there, and to do the hubaction stuff i’d bet it’s possible but would require everyone to have the wifi module (which I don’t have in mine).
Yeah, I’ve got all the non-setting related stuff async… But i need to validate login to pull locations, validate locations to pull sensors, etc… Only other option is if the information isn’t there, to refresh in 5 seconds and hope its there rather than have synchronous calls that wait for the last one (a prerequisite in this case) to be done. I could take that approach.
My Honeywell update is I have reached out to the head of IoT at Honeywell, but he is currently on vacation this week. The LAN integration is a heavily guarded secret… Even their own code is very abstracted so it would likely take weeks to figure it just whats going on. There seems to be a desire to make these panels useless w/o the TotalConnect service (probably to make the dealers happy), so LAN control is probably not something they would want to open up. Logically if we could require TC2.0 and pull sensor updates only over the LAN that would cut down on 90% of the cloud calls and everyone could be happy. I’m not sure that sensor integration w/o a faster polling rate (likely will be a sticking point) is even useful. As I’ve said, motion sensors you have to get really lucky and door sensors you have to have the door open for up to 15 seconds for it to read and I have not found a way to get historical data so we could trigger if the door was opened in the last 15 seconds even tho we missed it.
In my other thread about the httpPost problems, someone else is having issues with a local sever using HTTPS, but not HTTP… so there is still a chance its a SmartThing issue, but support will only help with official integrations, not API/code on unsupported ones. 
Do you mind if I repost this thread and include your handler link (with credit) in the new post?
I attempted to switch to this new device handler and couldnt get it to work. I got the following error on the log:
7feea83c-ab02-4f00-9efe-2c36a8e26950 9:50:18 AM: error groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.lang.Long#minus.
Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
[class java.lang.Character]
[class java.lang.Number] @ line 377
1 Like
Sounds good to me 
My worry about the polling situation is that is much, much chattier than the panel integrations. I bet they don’t mind us doing a once per minute status poll, but once you get to sensor statuses every 5 seconds it probably looks like someone is squishing their servers. The only public system available is their notification rules, but that would require an email client or IFTTT to parse and push updates out to the ST API, and not be directly in the DH. I had tried IFTTT before with the notications actually (email client -> check for sender and hashtag title -> forward to ifttt), and it was a bit too flaky to be reliable.
I got really excited when I saw an API call to get events… thinking I could pull all events since the last one we saw however log ago that was (save the last event ID, call the API with that + 1 on what we want to get) and then parse through them to fire off sensor changes we missed. Sure your door opening trigger might lag up to the polling time parameter, but at least it would fire. Turns out it doesn’t report sensor events…
I’m optimistic that Honeywell will be receptive. None of us are trying to circumvent anything and I’m not trying to avoid traditional monitoring, but their Automation Platform is very limiting… I stuck with it as long as I could before I needed to expand outside of it. Just would like to leverage existing sensors/devices (I started this b/c of the Alarm integration and ended up writing my own code mostly for Garage Door integration, which is not a zwave device that came pre-installed with my system).
Thank you! I removed the other smart app and updated the device handler. Now when I try to arm/disarm/refresh through the device view, live logging gives me this error (the same as @Revs9k01 ) :
groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.lang.Long#minus.
Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
[class java.lang.Character]
[class java.lang.Number] @ line 373
Am i missing anything?
It seems like the async method of doing this isn’t as reliable with SmartThings as the synchronous method. Anyone else seeing this? I can arm/disarm through the SmartThings app, although sometimes there is a long delay. However, it doesn’t appear that the ‘routines’ to arm/disarm based on time or geo-fencing work like they used to. Most of the time, it never arms/disarms the alarm, but occasionally, it does.
I’m guessing eventually we’ll have to move this to a local Raspberry Pi or something to do the TotalConnect communication.
That’s strange, that’s just supposed to be the equality check for if the token is null, not any kind of invocation. Unsure what’s happening there.
@jasonkhonlaw , I disabled the runIn(15) call at the end of the disarm/arm calls, because I personally just use pollster to ping it every minute anyways. Try uncommenting out those lines if you wish for it to still try a forced refresh.
edit: realized you may be using the version from jhstroebel. disregard if so
Yes, I am experiencing the same. It did Arm thru automated routine but did not disarm even the routine ran.
I have my LocationID - Tried running the tester app to get the DeviceID, but that is not working. Where else can I get my DeviceID?
@Oendaril Can you link to the SmartApp code you are using (from bdwilson)? I swapped out the original DH with your DH code and created a new device based on your DH. I’m having issues with bdwilson’s SmartApp both in the simulator and on my phone.
Error: java.lang.reflect.UndeclaredThrowableException @ line 106
Line 106 is the httpPost with the login parameters (SEE BELOW). I’m a bit confused b/c you swapped out all the sync calls with async calls but bdwilson’s original code still uses sync calls.
Thanks.
def login(token) {
def applicationId="14588"
def applicationVersion="3.0.32"
log.debug "===== Executed login ====="
def paramsLogin = [
uri: "https://rs.alarmnet.com/TC21API/TC2.asmx/AuthenticateUserLogin",
body: [userName: settings.userName , password: settings.password, ApplicationID: applicationId, ApplicationVersion: applicationVersion]
]
httpPost(paramsLogin) { responseLogin ->
token = responseLogin.data.SessionID
}
log.debug "Smart Things has logged In. SessionID: ${token}"
return token
} // returns token