just wondering if anyone is successfully using the Secure SRT323 Thermostat with SmartThings? It seems to be the simplest solution to automating my central heating, since it’s a straight replacement for my current (dumb) Honeywell T6360B.
Since it only does heating, a lot of the tiles in the DH will be useless. This could be an easy project to learn coming up with your own DH if it works with the default (keep reading, someone’s already there perhaps). Note though that battery level reporting isn’t in that DH.
Also, since it’s battery operated, I would highly recommend performing the include process right next to the hub. Don’t be surprised if you have to try a few times, and that it’s found as a Thing at first.
Here’s someone (@meavydev) in your region that looks to have made an SRT321 work with ST, including the device handler you’ll need perhaps. I recommend getting included in this discussion:
Also, here’s documentation you need for your thermostat that may be handy to keep around:
Yes I would try the handler I wrote for the SRT321, as it’s working fine for me in the system I have with four SRT321s each associated with a TKB power monitoring switch controlling electric radiators.
I might not have copied the latest code across to the US servers as it’s a pain to keep doing it…
@brumster Sorry, I never got round to buying or installing the SRT323. Other things overtook me. I’m still planning on fitting one at some point though.
Sort to resurrect this.
I have got the code above and my HRT4-ZW is picked up ok, and reporting temperature changes, and also any local changes made to the thermostat, even the association is working great. It’s not picking up any changes made from ST app however.
I’ve changed the wake up to 256s but left it a few hours. nothing.
I seem to remember there might be a minimum wake up period.
My devices are set to 600s and I see a thermostatWakeUp event in the event list from the device every 10 mins.
Mind you I can’t remember if that’s something I added more recently in the code in my device handlers…
I’m afraid the most likely scenario is that SmartThings have partially broken ZWave support again.
I’ve noticed that one of my ZWave switches has stopped reporting its state.
I can’t check at the moment, but as everything was working and no changes to the driver, then SmartThings backend or firmware are the likely culprits.
@meavydev - I’m playing around with that great handler which you wrote for the SRT321 to get my SRT323 to work. I think it will work but playing round with it I notice that the Config is only sent to the thermostat when it wakes up. At the moment it wakes up every 60 min so making changes is very slow.
Would it be reasonable / possible to send the config back when the Thermostat dail is changed (which it sends to SmartThings) or can you see a problem with that? It would allow me to make far more frequent config changes obviously. I welcome your thoughts.
You can change the wake-up period, as I run some at 10 min without impacting the batteries too much.
I can’t remember if the device sends a wake-up event if you move the dial but the reason that config changes are only sent on wake-up is that the ZWave commands are ignored when it’s sleeping, so sending after a dial change should work.
I finally got my SRT323 and the DH and it kind of works, but after a few days the little icon to show it’s connected switches off and I have to pair it again.
It also doesn’t seem to receive commands when it is connected. Even if I leave it for hours or after manually waking it by turning the dial. So changing the configuration to shorten the wake up period doesn’t seem to work.
Anyone got any ideas? Especially the disconnection issue? It’s only a couple of meters away from the hub, so that shouldn’t be problem…
I’ve just installed an SRT323 on my system, but I spent a few days testing @meavydev’s DH before I connected to my heating. I found I had to tweak several things to get it working properly:
the “battery” capability was missing. Some parts of smartthings didn’t recognise that it had a battery.
I added an extra fingerprint in which 0x25 was replaced by 0x42. The external switch functionality is replaced by “operating state”. See (4) below. I found I had to do this for the DH to be found, instead of the generic zwave thermostat DH.
I added 0x42:2 to the list of codes in ‘parse’.
I added a new zwaveEvent function - ThermostatOperatingStateReport. This is almost identical to @meavydev’s ThermostatMode Report, but I found that the new function was needed to allow the DH to properly reflect changes made to the SRT323 by hand, in particular whether the device was in ‘heat’ or ‘off’ mode (called ‘heating’ and ‘idle’ in the operating state code).
I added a new zwaveEvent function - ThermostatModeSupportedReport. This wasn’t really needed, but I found that when “configure” was pressed the DH asked the device for a list of supported modes, but failed to catch the reply.
I have no way of checking, which of these changes would also be required by SRT321 or whether there are differences between UK/European versions and those sold elsewhere. It may well be that my version will work for both SRT321 and SRT323.
I don’t suppose I could have a copy of your amended DH? I can reproduce some of the changes you made, but I’m not sure how to add the zwaveEvent functions you mention…
I may well tidy this up a bit and then put it on GitHub, but perhaps I should wait to see whether I get any comments from the original author @meavydev first.