Honeywell Tuxedo Touch Local API Integration

I came across a local API integration app on the SmartThings platform for the Honeywell Tuxedo Touch. Any chance someone could port this to Hubitat?https://github.com/jrizza911/tuxwifiAPI/blob/master/tuxedoapi

2 Likes

Could you provide a link to the SmartThings app?

I was able to control it with the momentary switch driver and these url's:

Note, replace usercode with your own pin

/M2MCommunications/Security/ArmAway?pID=1&uCode=usercode&operation=set

/M2MCommunications/Security/ArmNight?pID=1&uCode=usercode&operation=set

/M2MCommunications/Security/ArmStay?pID=1&uCode=usercode&operation=set

You enter the up address of the tuxedo touch and port 80 in the driver of the virtual device you create along with the url's above and it will arm and disarm the system.

1 Like

I'm very interested in this but a little confused about how you're going about it.

What device driver are you using for the virtual device? I don't immediately see one that takes address/port/url parameters.

Also, I don't see those endpoints in the API documentation from @jrizza911. I only see ArmWithCode for arming. Is there other API documentation that you got those from?

https://raw.githubusercontent.com/ogiewon/Hubitat/master/Drivers/http-momentary-switch.src/http-momentary-switch.groovy

1 Like

These url's are for version 4 Tuxedo Touch firmware. If you update to version 5.3.21.0 then you'll have to use the API links from jrizza911. I just upgraded to 5.3.21.0 today so I haven't got it set up with the new links yet but it seems pretty straight forward. I'll post more once I play with it a bit.

Writing a new virtual driver that interacts with the Tuxedo Touch local API, but there is some challenges code wise with subjects I'm not good with. It's coming along though.

1 Like

@tomw has been helping a lot with this but I think we got it about as far as we can for now. If someone wants to jump in and figure out how to get it past the last itty bit to clear the 302 redirect it should work. I'm not beyond bribing HE staff either if that's what it takes. This was written for use with version 5.3.6.0 firmware on the Tuxedo Touch.

https://raw.githubusercontent.com/heidrickla/Hubitat/main/Drivers/HoneywellTuxedoTouchAPI/HoneywellTuxedoTouchAPI.groovy

3 Likes

Hi,

Not sure if I've got the same situation that you do, but I think I so. My Honeywell Tuxedo panel has the same API_REV01 documentation as yours, although it reports itself to be version TUXEDOW_02.01.023.0003. So, what I'm about to say may not apply, but I think it does.

First, the 302 error I believe is because of an HTTP to HTTPS redirect, so if you change the URL to use HTTPS the 302 goes away.

Second, there appear to be two API calls for device registration. One is in the Administration section and is called AddDeviceMAC. The other is in the Registration section and is called Register.

It looks like you have to add the device MAC to the system using AddDeviceMAC first. In this call you also provide the device type. The list of device types is documented with the Register call even though the device type isn't used in the Register API call. I used device type 2 (for a PC) and the Hubitat Elevation's MAC address. This gave me back a private key and public key which I copied and used in the Hubitat driver configuration.

After you add the device MAC address, then you can register it using the Register API call. I did this, and it gave me back a MACID code which was different than the MAC address. It appears that the MACID code (not the MAC address) is what you're supposed to use in the authtoken parameter for subsequent API calls.

After doing this, I am now getting a different set of error messages that I don't have time at the moment to debug. But, I wanted to go ahead and pass along what I think I've figured out so far.

Hope this helps...

I'll take another look at this tonight and see if I can make any more progress.

Weโ€™ve got a Vista 15P, firmware TUXW_V5.3.21.0_VA.
The LAN interface sometimes goes deaf, but it always works from the touchscreen, and arm/disarm seems to wake it up enough to make it responsive. I havenโ€™t tried sending WOL to see if that revives it. If you need help testing, I could do that.

I modified the code to give you an option to select http or https but still no love. Also tried with the macid code and mac and neither progressed. I get 302 for http which is redirect, and 408 for https which is timeout. To use http instead of https you have to make sure Secure Web Server is unchecked on the Tuxedo Touch. I did enable it to test the HTTPS stuff.

The devices were already registered as part of the testing and have the macid, public, and private code you get from that process.

You might be able to just use the momentary switch driver up at the top of the post with that version of the firmware.

I'm interested in this driver and would like to help out to get it to work. If I understand the problem correctly we have a redirection issue. Can you help me understand the source of some of the input variables so I can start debugging. I'm unclear how you created the public/private key pairing and how that relates to the user/password combination we would set in the Tuxedo GUI or even if we can use that info for authentication.