ZXT-120 in 'newer' (non-classic) app

So!.. My ZXT-120 arrived, i’ve got it programmed (for my unlisted A/C brand, which was fun) and it now works using a mixture of code i found online from various other people. All is good using the ‘Classic’ SmartThings app.

However - i can’t get my head around how you write it so it works within the new SmartThings app? It’s like a different framework or something? My perfectly working device in Classic just looks like a random heating thermostat in the new app (and crashes when i try to change anything). I can’t even turn it on or off without a lockup/error.

What’s the deal with making apps (or should i say, Device Handlers) for the new application? I’m clearly missing something? All my other (Samsung) devices are perfect in the new app and i kinda wanted my ZXT-120 unit in the same place really?

Any pointers please? Cheers! :slight_smile:

1 Like

Read the following post. It is possible you may be able to add some code to the header of the device handler to get it to work in the new app

1 Like

Hi - thanks for that!


I had two issues, but i only have one now i’ve worked out how to force the updates in the App:

  1. My device (the ZXT-120) is an IR blaster, which pretends to be a thermostat, but in reality it controls an A/C unit. So i’m really not clear what new ‘type’ of device i need it to be (in the context of these vid: and ocfDeviceType: elements).

So, any idea on that? Thanks! :slight_smile:

I am not sure. You may want to post in the thread I posted above and see if someone else might be able to offer some assistance.

1 Like

Any luck getting ZXT-120 to work in the new app?

Hi - i found a ‘reasonable’ setup for it yes, you can use the code from Ronald Gouldner from here

And modify the definition line as follows:

definition (name: "ZXT-120 IR", namespace: "your-namespace", author: "your-name", vid: "SmartThings-smartthings-Z-Wave_Thermostat", mnmn: "SmartThings", ocfDeviceType: "oic.d.thermostat")

It’s not perfect (there is a thing where it always shows ‘heating’ even when mode = off further down the page) but for my purposes it was OK. Personally, i ended up writing an app to drive it from other inputs (combined from the central heating supply water temperature and the status of other A/C units) so it it’s pretty autonomous now, but i did get the app working reasonably well with those settings.

Hope that helps!

1 Like

Very cool. I will give it a try. I will try to disable anything related to Heating since my 4 mini-splits don’t have a heating mode. There is no feedback so ZXT doesn’t know if the unit is on or off. I’m thinking about just sticking a small door sensor to tell of the door that opens when it’s on is open. I just don’t know how to get the DH to know that the device is actually on and not do anything if it is and adjust its state to match reality. I’m an idiot when creating stuff, but I can try reverse-engineering stuff. Anything you can share is great. Thanks!

Hi - the ZXT seems to send everything every time you make a ‘change’ so if it is on already, and you change purely the setpoint, then it will send ‘on’ followed by ‘cooling mode’ followed by ‘target setpoint’ in one sequence. So it doesn’t actually care if you have turned the unit off or put it into a different mode manually in the meantime. The only thing is if you query the device on ST, it will tell you the last thing ‘it’ sent - as it has no knowledge of the events which may have locally occurred.

That said, it’s entirely possible this is something that is vendor-specific with the control codes, so your unit may differ i guess.

To keep mine in sync, i’ve just hidden the original remote and installed ST on everyone’s phones :wink:

© 2019 SmartThings, Inc. All Rights Reserved. Terms of Use | Privacy Policy

SmartThings; SmartApps®; Physical Graph; Hello, Home; and Hello, Smart Home are all trademarks of the SmartThings, Inc.