[OBSOLETE] Integration with HoneyWell TotalConnect Alarm & Monitoring System

I’m having the same issue. While watching the Total Connect live status on the TC website when I manually press the routines like good morning or I’m back on my phone, I have found that it logs into the TC website and starts to act like it’s arming for a small time(says arming with the moving dots). However, something seems to cancel it and it doesn’t actually arm. After the live status on the website stops acting like it’s arming the TC website status goes back to disarmed status. Really weird. Hope that makes sense. :slight_smile:
I do know that I used to get 5 notifications on my phone when it arms/disarmed from a routine( 2 login,1arm/disarm, 2 logout) with the old smartapp/DH, and now I am only getting 1 logged in notification. Not sure if that tells anybody anything.

Hmm, assuming you’re using the one I have there were a couple of departures when it was redone. The first is that instead of logging in, performing an action, then logging out it attempts to maintain a connection and re-login if it fails or times out. I’d tested those areas on mine, but I don’t use auto routines (only voice-activated manual routines). I’m unsure how they would behave differently in those cases, but the first thing I’d suggest is trying to find the commented out lines in the code that look like this

//runIn(15,refresh)

and remove the two slashes at the start. It’s possible that a previous arm action never updated the panel state, and thus when it tried to do another action it thought there was nothing to do. Are either of you using pollster to periodically refresh the state of the panel? Otherwise, there are some log.debug statements that could also be uncommented to show in live logging what is happening.

first, special thanks to Oendaril and jhstroebel for making this think work, then work again…thanks to henryh74 for clear, directions to get device id. Its working perfect again.

Is there a way on Oendaril code to disable the disarm portion? on jhstroebel’s code, i just replaced arm with disarm, publish it, then tile still says “disable” but it won’t do anything, even google home and alexa sends the “disarm” but it won’t do anything. I want it this way for security purpose, don’t want anybody going in inside the house then commanding home and alexa to disable the alarm. I’m not a coder by any means but sometimes can see simple logic in shorter codes, so i’m reluctant to touch Oendaril’s code coz its working so good.

Thanks again for your help.
b

Thank you for the explanation on how to uncomment lines. I did that this morning and will see if helps when I get home tonight. I’ve tried it a few time manually and it now logs in twice, but not sure it actually arms/disarms correctly yet. Seems to work when I press the good bye routine on my phone twice within a few seconds of each press. Seems like when it logs in for the first time after awhile it doesn’t send the arm commands. However, at the second press of the good bye routine button it appears to be logged in to TC already and sends the arm command and arms the system. Seems maybe I need to add repetitive routines so that the first routine logs in and the second routine arms the system. I haven’t tried that yet, so can’t say it will work, but in theory it should. Thanks again for all of your help

I was dealing with that same issue when I was setting up Alexa. I really didn’t want people to be able to disarm by talking to Alexa. What I came up with is just naming the Alarm Device something other than just Alarm. I know that is not as intuitive as the fix you are looking for, but a burgler would have to know that Alexa is connected to ST and would have to know your exact device name and then say it perfectly within the 30 until the alarm goes off. I’ve also found that when telling Alexa to “Turn on/off Alarm”, Alexa thinks I’m talking about an alarm clock or timer.

RhinoC…you’re braver than I was, I was at work and reluctant to mod the code and test, wife’s at home and I don’t want her to freak out with the alarm chirping to arm and disarm. If code breaks, i could delete and re-apply. If wife breaks, theres no dinner tonight…So…I’ll wait. :slight_smile:

Lol. Luckily my wife is working today and I’m in charge of dinner tonight:)

Decided to get rid of the “//” but not at home to test it out.
Basically copied the original code from BD Wilson

Copied and pasted Line 217 to the bottom with the Oendaril code at line 509 beginning with “handle commands”

Probably will break things…

My only coding experience was getting a C in a fortran class that I took as an undergrad. Promptly changed my bioengineering degree to regular bio after that experience.

Let us know how it works.

I’ve had a chance to test removing the // in the runIn15 lines, and adding repetitive automatic routines with arm/disarm alarm comands. Arming seems to work flawlessly with all routines but disarming never seems to work automatically with routines. Looking through the DH code I can’t tell why arm and disarm is being treated differently . You’d think if one works they’d both work, but I am for sure not a coder.

I didn’t answer this earlier but I am not using polster for anything. You think that would help with disarming the system?

I am also getting the 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 373

I have set everything up from scratch. I do get a login notification from TC2.0 app that my ST user has logged in:

with this error before the above one:

Command Type: [body:SessionID=XXXXXX2&LocationID=XXX&DeviceID=XXXXX&ArmType=0&UserCode=-1, callback:armAway, path:ArmSecuritySystem, retry:0, handler:refresh] failed with ResultCode: -4002 and ResultData: The specified location is not valid

1 Like

Tested the changes on the smart things app and both arm and disarm work!
Think this did the trick for me!

Also, I am slightly more interested in getting my zone to work with SmartThings than arm/disarm. I saw some other code for that… what’s the current status? This is a VERY long thread to keep track of what’s going in. It would be nice to have a subforum for each App/device.

I wish there was a way to let the ST Hub push simulated switches to the Lyric, so that the Lyric could use it’s own automation and I could let the simulated switches to background work to automate things.

I believe I know what’s happening with disarm. I missed a callback mapping for the disarmAuthenticated call when disarm is called but the token is presumed invalid. I’ve gone ahead and pushed these changes into my github along with some code cleanup and re-adding runIn as a call for any arm/disarm calls, if you’d be willing to be a guinea pig and see if it helps you out :slight_smile:

Edit: @CGDaveMac the full v2 DH with full zone/sensor polling isn’t completely ported to async yet due to its larger size, but jhstroebel may be poking at it already. If I get some more free time I may be able to take a look at it, but i wanted to get the basic DH working well.

@dek4800 the disarm/arm functionality is intrinsically tied to this DH being exposed as a lock and switch. The only way to remove that ability to disarm from within the device itself would be to remove the ability to make it disarm at all inside SmartThings.

A preferable alternative is to instead of exposing the full device in Alexa/Google Home is to create an IFTTT phrase specifically for both arm stay and arm away but not disarm. I forget if this can be done with the Echo but that’s what I did with the GH integration.

I have done some fairly extensive testing with the new Async Device Handler. My conclusion, which is somewhat odd, is this:

  1. . If you are arming/disarming directly from the SmartThings app using the DH buttons - everything works very well and functions as desired.
  2. . If you set up SmartThings “Routines” under Automations - again everything works well and functions correctly.
  3. . If you are a WebCore user, and you attempt to interact with the DH by sending WebCore “Actions” such as Lock, Unlock, Switch On, etc - the results are very unstable, especially the “Unlock” or “Turn Off” (Disarm) command. Oddly enough the status reported back to the IDE confirms “Disarmed”, when in reality the system is still armed.
    4). In WebCore, you have the ability to “Execute Routines” under Actions, and if you execute the same routines that you would set up in #2 above, they seem to be stable. The odd part is even the Unlock or Turn Off (Disarm) routines work with no issues as well.
  4. . Based on all of the posts I have read here, I would recommend either using the built in SmartThings Routines or call the same routines from WebCore and that seems to be a fairly stable solution for arming/disarming.
  5. . I would also recommend NOT using Pollster or any automations that refresh status excessively, like every minute or even five minutes. That could be the root cause of why Honeywell potentially did some IP Blocking of the SmartThings web server initially - just a guess on this though.

Hope this helps get this integration stabilized for the end user and it helps the people that developed the integration code some clue as to what changes potentially need to be made to the code.

1 Like

@Oendaril I’ll try it. I am not relying on this at all yet, and nothing has worked for me. Not just disarm.

@Oendaril. So far with your current changes my routines have armed/disarmed every time! Thank you very much for all of your help and time you have put into this! It’s much appreciated!

Update from my side… I’m in a holding pattern waiting for a response from Honeywell, but the guy I need to talk to is on vacation. He’ll be back Monday I believe. I hate to rewrite everything just to have the synchronous calls be fixed. I’m still not 100% sure SmartThings didn’t break something with HTTPS synchronous calls.

Thanks, everyone who worked on updating this to make it work again. I am good to go now.

Like before, I made a small change to suit my needs (arm instant, instead of arm stay using status 10209 and armtype 2). The device and smartapp work great so far.

I’m in the same boat as you

I tried the updated DH by Oendaril and I get this same error.