Honeywell Total Connect (Windows Phone) Information / Source Code

Been a while since I posted here. Have had a crazy past year so I have not had time to do much on this blog. But I am back for a topic that I have been getting emailed about a lot since my previous post about the Total Connect tool I made for Windows Phone.

Be aware: The information in this post is for educational purposes only. While the app is free, I do still respect Honeywell and their services. Please do not abuse this information. Use at your own risk. I am not liable for what happens when you use anything posted here or referenced by me.

Obtaining The APK Locally
The link to the APK on the play store can be found here: https://play.google.com/store/apps/details?id=com.alarmnet.tc2
We can see that the file name is ‘com.alarmnet.tc2’, Just add .apk to the name and Google. You will find a dozen sites with the APK. You can also root your phone to gain access etc. but I will not cover that here.

Decompilg The APK
Now that we have the APK we need to decompile it. You can use the following tools to accomplish this:
– dex2jar: https://code.google.com/p/dex2jar/

With this tool, you can easily convert the .dex file inside the .apk file (it is just a .zip file!) back to a usable jar file.
Simply drag and drop the .dex file onto ‘d2j-dex2jar.bat’ and you’re done.

Next to decompile the Jar to readable source code I used:
– Jd-Gui: http://jd-gui.softpedia.com/

Again simply open the .jar now with this tool and you will see the decompiled source.

Understanding The Source
While I do recommend looking through the entire thing to get accustom to their setup, I will point out what is important.
– com\alarmnet\tc2\rcmobile\rcConn.java
– com\alarmnet\tc2\rcmobile\rcSecure.java

Both of these files contain the service call data and connection flow that we will need to follow in our application. I really recommend studying these because their method of handling the connection is fairly convoluted in my opinion.

Making The Connection (Service Call Flow)
Now that we have the source, we can analyze the setup of the service calls and how they are handled. For one, we see the main service object can be found here:
https://rs.alarmnet.com/tc21api/tc2.asmx

They were nice enough to use a Windows service so this makes things a bit easier while working with it at least. 🙂

To make a login request, we have a two step process:
– AuthenticateUserLogin : Which does what it sounds like, it auths our login information.
– GetSessionDetails : Obtains information about our session. (ie. Session Id, Module Flags, Security Locations, User Info)

To even login, we are required to give the service some information:
– Our Application Id
– Our Application Version

Given that the Windows phone does not have an appId/version for this, we use the Android one to fake the call. In the case of the code I wrote, the version info was:
– Application Id: 34857971
– Application Version: 2.2.0

The next step is to keep the session activated and alive. After we login, the app creates a thread to keep pinging the service. Inside that thread, the app was calling KeepAlive and GetPanelMetaDataAndFullStatusByDeviceID.

Thankfully, we are given the nice usage of async callbacks for everything when we reference their service. So we can make a fairly decent setup that can be UI friendly.

Arming Our Security System (And Disarming..)
Next was seeing how we arm and disarm the system. Here I found that the call was made to ArmSecuritySystem. This handled both arming for away and stay modes. This takes a number of params which I am not 100% sure if the user id param was required or not. I would recommend not sending it at all if you do not have to. My examples sent it just to be safe when I was testing this setup.

Following suit, to disarm the system we have a similar call: DisarmSecuritySystem

Status Information And The Like
Finally, with the information obtained status codes and bitmasks were all that was left to obtain the information data. When querying for the panel status in the keep alive, we can get a number of results that mean different things (based on different security systems):

  • 10200 – Disarmed
  • 10211 – Disarmed (bypass)
  • 10201 – Armed Away
  • 10202 – Armed Away (bypass)
  • 10205 – Armed Away (instant)
  • 10206 – Armed Away (instant-bypass)
  • 10203 – Armed Stay
  • 10204 – Armed Stay (bypass)
  • 10209 – Armed Stay (instant)
  • 10210 – Armed Stay (instant-bypass)
  • 10307 – Arming
  • 10308 – Disarming

When we arm or disarm the system, we can get a specific result return of: 4500
When this occurs the system wants us to force-request the current panels last command state. When we do this, that service call can have the following returns:

  • 0 – Success
  • -4502 – Invalid pin. (Yes, that is a negative result.)
  • 4501 – Repoll Required (Command is currently scheduled.)

Also when we call the GetPanelMetaDataAndFullStatusByDeviceID method, we are given the current panels zone data. These zones can have a series of flags in their status mask. The status codes are as follow for the zones:

  • 0 – Normal
  • 1 – Bypassed
  • 2 – Faulted
  • 8 – Trouble
  • 16 – Tampered
  • 32 – Supervision Failed

Putting It All Together

When I first started working on this I made a simple test application which can be seen here:

After getting the test app to work fairly well, I moved to working on the demo phone app I created. Which can be seen here:

Getting it to work simply for myself was great. I was happy to get it in a somewhat working manner. However, I am by no means a Windows Phone developer. This was my first solo app project for the WP7 platform and I can honestly say my last. I am not a fan of Windows Phones at all and I have since gotten rid of mine and moved to Android.

About The Source Code
The source code is in a beta “working” state. Meaning, things are thrown together just to get it to work and test things out kind of state. I did not take the time to fully cleanup the code, it may [read: does] still have errors and problems. I cannot guarantee it will work for everyone and such. The following sources will be of my original test application (proof of concept) and the phone app.

I do wish that people at least honor me by giving me credits if you use this source code. I also do request that you do not sell your app, if you make one, for money. Honeywell offers this service free of charge on all other platforms, there is no reason to nickle and dime people for a simple feature-set like this.

Windows Proof of Concept Client: https://github.com/atom0s/HoneywellWindowsPoC
Windows Phone 7 Proof of Concept App: https://github.com/atom0s/HoneywellWP7PoC

Leave a comment