Secure SRT323 Thermostat

I don’t have any comments, as these changes don’t seem to be needed for the 321.
I’m using a V2 hub with the classic app and see Heat updates and temperature changes fine from the 321.

I’ve put an updated and tidied version on GitHub SRT323 Device Handler

One minor detail: I am using the popular “Device Monitor” app, which, among other things, lets me quickly check the state of the batteries in all my devices with batteries. I noticed that the SRT323 wan’t on the list, even though I had added it to the list of devices to be monitored. That’s when I noticed that the battery capability was missing. I could see the battery state within the DH and even in WebCore. The other issues may well reflect the difference between the 2 devices, but I suspect the battery capability is more generic.

Hello,

thank you so much for working on this. I can confirm that your tidied up DH from your github is working more or less correctly. The thermostat receives setpoint changes from the app and reports manual changes back to the app.

Unfortunately, I now get an ‘unexpected error’ when trying to save any of the setup changes, like the Wakeup interval from the gear icon in the app.

That didn’t happen with the previous ‘untidy’ version.

Also, when I try to update the DH from github, I get the following error in the IDE: “Updated 0 devices and created 0 new devices (1 skipped due to errors)”

I’m happy to be the unofficial guinea pig tester, BTW :slight_smile: Just super happy this is working much better than before…

Thanks,
Chris.

I can reproduce these. I obviously didn’t check carefully enough before posting the new version on GitHub. I also suspect the real temperature is not being reflected in the DH properly. This is my first attempt to post code on GitHub. I’ve probably messed up somewhere. I’ll look into it.

I’ve fixed the “unexpected error” message, although I don’t know what I did to fix it. Googling suggests it may have been an issue with Samsung’s server rather than anything in my code.

I’ve made a couple of amendments:

  1. The main tile now has the measured temperature in the middle. The set temperature was previously appearing in 3 different places, which seemed like overkill.
  2. The DH now asks the device for the measured temperature at every wakeup, which keeps the DH better in sync with the device.

I’ve uploaded this latest version to GitHub, but I haven’t managed to fix the GitHub integration issue … yet.

I’ll look at what page 15 of the instructions booklet calls “comfort mode”, although I wouldn’t call 5 degrees comfortable. This looks like an easy way to set the device to a minimum when the house is empty for a period. It may turn out to be easier to ignore this and achive the same thing with software.

I think I’ve fixed the GitHub issue … unless you know differently :blush:

Can confirm pulling code from github works without errors, as does saving settings.

Not entirely sure I have the correct DH now though. Mine looks like this in the iPhone app:

Try again. I think the GitHub version reverted at one point in my experiments. It should be OK now.

Yep, that’s got it. This is fantastic!! Thank you again for working on this. Lifesaver :slight_smile:

I’ve posted an updated version, with the SRT321 specific code removed (commented out).

I’ve also checked the effect of setting and resetting “comfort mode”. All this does is flip the set point between 5 and 21 degrees and nothing else. I don’t see that this serves any useful purpose in the context of Smartthings.

The DH still works with @meavydev’s scheduler.

One suggestion for @meavydev. It would be nice to be able to choose more than one mode in the scheduler, for example Home and Night mode, but not Away. I’m not 100% sure, but this may only require changing “multiple: false” to “multiple: true” in line 125 of the child App.

I can confirm that a couple of simple changes to @meavydev’s scheduler Child App will enable chosing more than one mode.

Line 125: input “smartThingsMode”, “mode”, title: “Only run when in this Mode(s)”, multiple: true, required: false, submitOnChange: true
Line 224: boolean modeOK = settings.smartThingsMode ? settings.smartThingsMode.contains(location.currentMode.name) : true

This gives an extra bit of flexibility.

I’ve posted an amended version, which implements the capability in the device to change the frequency with which it reports temperature changes back to the DH. This can vary between 0,1 C and 10 C. A higher value saves battery life.

To summarise the behaviour:

  1. the device will wake up every few minutes, as set in the DH, to check whether any requests are pending.
  2. Any change in the heating setpoint on the device itself is immediately reported back to the DH.
  3. Any change in the operating state, heating or idle, is immediately reported back.
  4. Any change in the measured temperature of more than the threshold set in the DH, is immediately reported back.

Changes set by software, e.g. in the DH itself, by @meavydev’s scheduler, or by WebCore. Are sent to the device at the next WakeUp.

hi can you explain how i can get this dh to work as i have set this up as i do other dh but i cant even turn on or off the switch or change anything in the thermostat
i am only showing 1 item in smartthings should i see switch and thermostat?

You should only see the thermostat. You should see something similar to what @cpetzny posted a couple of weeks ago. The arrows on the right should raise or lower the setpoint, i.e. the temperature you want. The device saves battery by only contacting the DH every so often as set on the setup page you get to by clicking the wheel on the top right. So there will be a delay of up to that time. I have it set to 600, i.e. 10 minutes.
You should see the setpoint between the arrows and in the message at the bottom, whereas actual measured temperature is in the middle.
If you look at the log files in the IDE what do you get?

Thanks for the reply. I can see something like the above pic and in the logs in the ide it all records whatever i do in the app. but nothing happens in the thermostat. the thermostat works in manual mode but is not changed by the app .even if i change the the delay to 600 the log says it has updated it but 3600 is still showing in the ide any ideas

sorry its checkInterval 3600 other is changed in ide also

Assuming the delay is 600, I’d expect the logs to say
WakeUp[8408]
updateIfNeeded
every 600 seconds, with additional messages every time the thermostat itself is changed and every time it changes from Heating to Idle. There are corresponding messages in the “Recently” page in the smartthings app, with green dots next to the Heating/Idle messages.

Also, what happens if you press the configure and/or refresh buttons in the App? I’d expect a simple instant response in the logs followed by something more complicated at the next WakeUp.

Similarly if you press the up and down arrows in the DH. You will see messages in the IDE. I’m aware of a bug which means that the setpoint displayed in the DH sometimes doesn’t change, but, if you go out of the DH and back in, it will have changed. I need to investigate this. In any case, the change should be transferred to the thermostat at the next WakeUp.

The delay until the next WakeUp can make it appear as through the changes are not being transferred, whereas, in fact, they are only delayed.

got it working thanks for info
this tutorial link below was a great help as its not the same as instructions that come with it.


i know it says vera lite but it worked for smartthings

Good! I agree that the instructions leave a lot to be desired, especially on pairing the device with a hub.
A couple of things which are still puzzling me and which I haven’t seen mentioned here, or elsewhere:

  1. The SRT323 is advertised as a straight replacement for an old fashioned dumb thermostat, but I found I had to change the wiring of the backplate. I couldn’t just plug the SRT323 into the old backplate. This appears to be related to the fact that it is a battery powerred device rather than drawing power from the backplate.
  2. The SRT323 has a third pin, which doesn’t appear to serve any purpose. There is a dotted line between 1 and 3 on page 14 of the instructions, but nothing else.