I’m struggling with a little logic issue. I’d love to be able to just turn the heating off when everyone leaves the house or when the mode is set to AWAY. Then turn it on again when someone returns or when the mode changes to HOME. Ideally I’d like to achieve this without changing the setpoint. My Heatit thermostats for underfloor heating have a simple on/off capability, so I don’t have to manipulate setpoints to turn the heating on and off, but the SRT323 doesn’t seem to support this.
Is this something the “comfort mode” can be used for? Or does it always switch between 5 and 21 degrees?
BTW, the DH and thermostat have been rock-solid, so thank you!!
I can see in principle how to do this. The thermostat and zwave distinguish between ‘mode’ and ‘operating state’, a distinction I didn’t initially understand. It’s easier if you think about a more complicated system, such as air conditioning, which can be set for heating, cooling or automatic. That is the ‘mode’. The ‘operating state’ is what the system is actually doing, which could be heating, cooling, idle, etc. At the moment the ‘mode’ is fixed on ‘heat’ in the DH, but it would be possible to enable it to switch between ‘heat’ and ‘off’. However, do you really want to do this. I’m sure the reason the ‘comfort mode’ switches between 5 and 21 is that 5 is seen as the minimum temperature to guarantee frost protection. Maybe not necessary in summer, but important in winter.
At the moment I have my system set to change between 2 temperatures depending on whether the system state is ‘away’ or ‘home, night’ and the time of day. I also reduce the temperature to an even lower level when the house is empty for several days.
For me the main concern is switching from a preset lower setpoint back to the previously set high setpoint. In the recent changeable weather, the thermostat has been manually set to anything between 21 and 24 degrees. So if a routine uses a preset value, say 22 degrees, there’s a good chance it’ll be different to how it was left, meaning within half an hour of returning home I’d have to get manually change the setting.
Actually, thinking about it, the Heatit thermostats use two setpoints. One for heat and one they call “Eco Mode”. So from my routines, I switch to Eco Mode when away and back to normal when home. It’s kind of like comfort mode on the SRT323, but with setpoints I can define…
I’ll think about that, but at the moment it’s not obvious how to achieve this other than with webcore. I assume your fixed setpoints are set either in @meavydev’s scheduler or in the ‘Goodbye’ or ‘I’m Back’ routines. All of these expect explicit numbers.
In webcore it would be easy to define a piston which is triggered by a change between Home and Away, remembers the setpoint before the last change and resets it on the next change.
An alternative approach to get round the restrictions might be to tweak the DH to do something special if it’s given an absurd setpoint, such as T>100.
For the Heatit thermostats, the two setpoints are chosen in the tiles in the device screen in the app. Then I use CoRE to change the thermostat mode to eco and back again depending on HOME or AWAY. That way there is a single setting for the setpoints for each thermostat and CoRE just has to be a switch…
The hardware doesn’t recognise any mode other than ‘heat’. However, I have an idea how to achieve something similar. I’ll gat back to you when I’ve had time to try it out.
The latest version in GitHub has the following additions to the previous version:
If the DH receives a temperature setpoint greater than 99 it interprets it as a code rather than an explicit temperature.
The meanings of these codes are:
100) reset to the previous temperature. e.g. come back to a house at the same temperature as you left it.
101) set to the temperature defined in the DH preferences screen as “home temperature”.
102) ditto, but “away temperature”.
103) ditto, but frost protection temperature.
Typically a user finds that he has to set the same temperatures in multiple places, such as in @meavydev’s scheduler or in the “Goodbye” or “I’m Back” routines, etc. These codes can be used instead of the temperature in multiple places where integers are expected, but the actual temperature concerned need only be defined once in the DH preferences. This makes it easy to change such setpoints.
I finally got round to trying your new DH, but on updating from the repo, I get the following error. Is this something you can fix at your end or am I doing something wrong?
Error: 500: Internal Server Error URI: /ide/device/doRepoUpdates Reference Id: f514dc4b-8d4e-452e-99c9-209be546051b Date: Thu May 02 08:11:59 UTC 2019
I did a test by making a change to my local version and then overwriting it from the repository. That worked fine, so I can’t reproduce your error. Unfortunately, the error messages on the smartthings system are not very informative.
Incidentally there is a minor issue with the logic of the changes I made, partly on your suggestion, namely, if a routine which changes the setpoint back to its previous setting is, for whatever reason, run twice, you can end up with the wrong temperature setting.
Right, managed to update the DH. No idea what was happening there.
I’ve set it up with my routines and the new “code” temperatures. I’ll report back, but it seems promising so far. I’m not using the ‘revert back to previous temperature’ code anywhere, so hopefully won’t come across the small issue you mentioned.
Hi, I know this is an old thread but I was wondering if anyone has disconnect issues with the SRT323? I can include it with Smartthings but after a while it drops out of the zwave network and I need to exclude and include it again.
I doubt this is software related but I wanted to check with the community if it is a common issue or not.
mine has been pretty solid since using the DTH by @aonghusmor I’ve had one disconnection since then. Using the SRT321 handler by @meavydev previously, it was very unstable and disconnected after a couple of days, sometimes within hours.
My own experience is that I haven’t had issues for some time and then they appeared to be generic, several things dropping off at once, rather than specific to his device.
Several people have reported recently that devices appear to drop off, but don’t. Does anything appear in the “recently” list?. I removed the ‘wakeup’ from that list as it had become diffcult to see the wood for the trees, but I could put it back, or make it optional, if it would help users to see whether a device has really dropped off.
It is known that smartthings tends to mark a device as dropped off if it doesn’t see it for more than an hour. In this case a ‘wakeup’ interval of 600 or 900 (10 or 15 minutes) should guarantee that this doesn’t happen.
Remember that it is a feature of these devices that they wakeup every so often to check whether there are any instructions waiting. This can mean that here is a delay of up to the “wakeup interval” between the software issuing an instructon and the device implementing it.
I have three SRT323 thermostats and they generally work OK. I have set the wakeup interval to 300 seconds and using @meavydev DTH I can monitor their wakeup events.
Lately one of the thermostats has been dropping off quite often (every week or two). When it does there are no events registered and the antenna icon on the thermostat display is off. The only way to recover from this is to exclude it and include it again.
I am now using your DTH on all three devices and I will see if that makes any difference to the disconnect issue I have with one of them. I am not very optimistic though as I think it is a firmware issue that has to do with z-wave rather than Smartthings.
If the thermostat keeps disconnecting I will look for replacements - probably with mains power so that they are on-line all the time.
hi can this be updated for the new smart things app since the classic is going away.
I mean it works you can see the temp on the thermostat you just cant adjust the temp up or down like on the old app kind of useless like this.
I just upgraded to the new SmartThings app and it doesn’t work at all anymore “Server Timeout” when I try to change the temperature whilst the old app still works and does it’s thing.
Agree with the controls: Far too many for a simple (but great!) thermostat and would be wonderful if someone could have a look at fixing these issues. Thanks in advance.
UPDATE:
Having looked at the IDE logs I spot the error: “groovy.lang.MissingMethodException: No signature of method: static java.lang.Math.max() is applicable for argument types: (java.lang.Integer, null) values: [18, null]
Possible solutions: max(int, int), max(double, double), max(float, float), max(long, long), min(int, int), wait() @line 510 (setHeatingSetpoint)”
The way I seem to be able to fix it is to, in the new App, select the device, , settings, and set all the variables (Wakeup Interval, Reporting Step, Home Temp, Away Temp, Frost Temp). Make sure you change the defaults as not doing so leaves them empty which seems to cause that error.
I’ll try to look at this. For some reason these messages weren’t getting to me.
I’m also puzzled by the fact that I appear not to be seeing what others are seeing in the new App. I get a Battery tile, followed by a Temperature tile, a Set temperature tile, a State tile and a Mode tile. With these I have no problem using the thermostat. I have noticed different users getting a different combination of tiles on other DHs too, but have no idea what is the cause.
