my problem is directly related to wrong DST and Timezone setting for my region and it started after DST change at US. So I believe your problem is different.
[RELEASE] 5-2 Day Programmable Thermostat Scheduler (Weekday, Weekend) with Remote Temperature Sensor for each Schedule
Thanks @mrmrmrmr and @RBoy, I have 7 Zigbee thermostats and 2 smart plugs scattered around the house so coverage should be very good but I will check out the mesh issue details if this persists. I updated to Rboy’s latest app and at the moment the thermostats are behaving according to their schedules.
New rboy subscriber here.
I just installed the Programmable Thermostat Scheduler smart app. I’m using the rboy Device Handler (“Enhanced Z-Wave Plus Thermostat”) to control the thermostat.
I just purchased a Smartthings Multipurpose Sensor, which I’m using as the remote temperature sensor for all schedules.
I went through and set all the schedules for 70 degrees heat, 75 degrees cool.
It seemed to work at first, setting the heat temp to 85 degrees when the remote sensor registered under 70, and then down to 45 when the sensor registered 70.
But last night, the heat ran continuously, even as the remote sensor registered all the way up to 80 degrees.
Is there something I’m missing?
Add some repeaters if you’re using a remote temperature sensors. You mesh is weak and the events/commands aren’t reaching the devices/thermostats consistently. If you have a CT-xxx thermostat model running (and pairing) it with a C-Wire helps improve the mesh/device reliability greatly. Also helps to reboot the hub and do a Z-Wave repair.
Discussed a few posts above:
Thanks for the advice, but the mesh doesn’t seem to be the problem. We have a pretty small apartment, and looking at the logs in the Smartthings app shows plenty of communications sent by the sensor and received by the thermostat while it was failing to turn off. (attached some screenshots)
The images are a good start point, you may need to dig deeper into your device events logs as the Recently tab is only showing that the SmartApp has sent the command to the DTH. I’m not seeing too many acknowledgements (it just means that you can’t tell if the command reached the device or not from the Recently tab). For example at 9:02am I see the acknowledgement from the thermostat that the setpoint was set to 68F. I don’t see any during the night (just commands being sent to the DTH).
In general there could be three reasons for what you’re seeing:
- There is a communication issue (quite common with beaming devices), I’m sure you would read from my previous post why beaming devices (thermostats, locks etc) can suffer from mesh issues even if they’re sitting in front the hub. FAQ: why would I need another beaming repeater if my zwave lock is already close to my hub?
- You can wait for a few days and see how it behaves. If it happens again but at a different time of the day/night then it’s likely the first point. However if it happens at the same time/schedule everyday it’s likely a setting in the app (e.g. folks forget to select a remote sensor / incorrect settings etc)
- There’s another app which is overriding the settings of the thermostat/causing a conflict. This one is easy to figure out, if you click on the SmartApps tab under your thermostat device page it’ll show all the SmartApps that are controlling/using the thermostat
These are starting points but likely you’ll have observe it over a period of time to narrow it down
@RBoy @maddie I’ve been having an odd issue with the app. On a couple of occasions, like at least 2-3 I can recall, the times in the schedules have flip-flopped their AM/PM settings. For instance, here is the schedule I have for one Thermostat that is correct:
But. just earlier, I was looking in the app and the 12-hour times were all correct, but the schedule was off by 12 hours (so 5:00pm Wake, etc.). I have no idea what could be causing this to seemingly revert. The first time I assumed I had just goofed the settings, the second time I thought well, maybe I didn’t fix it the first time, but the third time I’m sure. When I saw the AM/PM shift I looked in the IDE and the settings seemed to match what was incorrectly shown in the app - off by 12 hours (sorry, no screenshot of that FWIW).
But, having said that I’m not sure if the AM/PM thing is the real oddity. The other thing I can’t seem to explain is that the historical IDE logs don’t seem to be matching the schedule either. For example:
Seems like the app is issuing the command an hour off from when it should if I compare the schedule to a few of the times in the log. Even if the AM and PM are swapped the actuals still didn’t seem to quite align.
I am running v03.09.02.
Sounds like the recent platform outages may have played havoc with your account schedulers or corrupted some settings. A few posts above you’ll see Ilker has similar issues and it turned out that the platform had messed up the hub timezone interpretation and was firing this schedules one hour ahead of the time that the app was asking it to fire them.
Ok, I thought about that after reading those posts but somehow didn’t connect it. I reset the settings again and I’ll keep a closer eye on it. As of today, the settings are still what I expect them to be and the logs indicate that the changes are occurring at the desired times.
Thank you again, for your excellent customer service. The Centralite Pearl thermostat is now responding quite well to commands from your Ultimate Mode Based Thermostat Temperature Management smartapp .(http://smartthings.rboyapps.com/Smart%20Apps/Mode%20Change%20Thermostat%20Individual%20Temperature.groovy.txt)
I am now able to run the upstairs thermostat on a different circadian cycle depending on whether I am home or only my son is home. I have two sets of modes that cycle through 24 hours and different settings for each in the smartapp.
The smartapp is also able to heat the upstairs based on temperature in the bathroom that each of us uses, respectively, to accommodate different use patterns.
Really nice service changing the “forced setpoints” to accommodate limitations of those thermostats. If I ever use this smartapp at my cabin, with Sensibo units, I may ask for another update, since the low temp on those units is 50 degrees F.
Thank you for producing really useful smartapps. These have saved me from learning groovy, which I may do in retirement.
Having a few compatibility issues here. Using in conjunction with the Ultimate Mode Based Thermostat app to have a schedule and then have different set points for away/vacation mode.
The DH I’m using is this one for my Daikin mini split system.
The issues I’m running into:
1: App will not switch between heat/cool modes. If I manually select heat through the device, every command sent from the app is setHeatingSetpoint. If I manually select cool, then it switches to setCoolingSetpoint.
2: This DH doesn’t support fan adjustment with my model. If I select any of the fan options in the settings, it will set the device into full fan mode (blows air in from outside)
3: My solution to #2 was to simply leave the fan options blank however the app appears to be still sending multiple ThermostatFanMode commands which keeps switching my unit to full fan mode.
4: At some point this morning it sent a command to set the heating setpoint to 8 degrees followed by a command to set it to 20. ??
At the outset it appears to be working as designed and some issues you’ve pointed out all appear to be related to your custom thermostat DTH/configuration.
- The app does not change the thermostat mode set by the user. It reads the mode set on the thermostat and then sends commands accordingly, if it’s set to Auto mode, the app will send heat and cool setpoints, if it’s set to Heat mode the app will only send heat setpoints etc. The only time it switches the mode is if you’ve configured the outside temperature sensor section and defined a temperature threshold to switch between heat/cool. If you’re looking for automatic switching of the mode the DTH will need to support Auto mode. The point of using a Thermostat DTH is that it needs to be compliant with requirements of a thermostat capability. The app can take over the thermostat responsibilities when a user is trying to create a heating/cooling setup using switches to controls fans, coolers/heaters etc but then you need to select the appropriate switches/sensors in the app so it will emulate the heat/cool/auto modes when a thermostat is not being used.
- The app will change the fan mode only if it’s defined in the app (check your settings again) or unless an outside temperature section is configured to use sensor to switch between heat/cool modes (in which case it sets the fan to Auto mode). If the HVAC doesn’t support fanAuto mode then the DTH should handle it accordingly. From what I see in the DTH code it turns the fan On when it receives a fanAuto command, and from what you’re explaining, it should be turning the fan Off or ignoring the command. I also see that the DTH doesn’t implement the setThermostatFanMode command.
- See point 2, the custom DTH needs to be updated
- Check your app settings
I did set exterior threshold temps to switch between heat and cool mode (the wife hates auto because it sometimes blows “cold air”). I’ve also double checked and there is no fan set on any of the schedule settings.
If I manually set it to cool mode and set the heat threshold to 10 degrees (currently - 9) should it not switch to heat mode? Because what is happening here is that it’s sending the setCoolingSetpoint command.
If I set to auto mode it seems to be sending both the heat and cooling set points.
It sounds like my only solution at the moment would be to use auto mode and disable the exterior temp thresholds and wait for future development on the dth?
I had the idea that maybe it was because I was using the same device to read the outside temperature and there may not be any distinguishing between temperature and outsideTemperature. So I created a virtual temp sensor and a webCoRe piston to set the virtual temp sensor to the outsideTemperature value of this DTH.
Even using a separate temp sensor for the outside thresholds, that I can confirm is reading -9 degrees, it still won’t switch between heat and cool mode and in auto it is still sending both setHeatingSetpoint and setCoolingSetpoint commands back to back.
Note: This is on a clean install of the app as well. I deleted and re-installed to do this test.
If you can replicate the issue with the stock ST/compliant thermostat DTH we can look into it. We don’t see any issues with the standard/compliant DTH’s. As I mentioned above, when the DTH reports Auto mode the app will send both heat and cool setpoints (if defined in the app). Your issue appear to be arising from the custom DTH.
To my knowledge this custom DTH is the only way to integrate the Daikin WiFi module into smartthings.
If the app is designed to send both heat and cool setpoints, then it is functioning as designed. My issue is definitely in the DTH which seems to be listening to both when in auto mode. So it sets to 20 degrees and then 23 degrees.
my CT200 thermostat is making a long beep sound when the program changes the setpoint.
This started recently.
I don’t think it is related to tha device handler or the smartapp, but since there are other users of the thermostat on this thread, I would like to ask:
is there a configuration that would make this sound ? and how to disable it ?
If I have missed this somewhere I apologize, but I can’t really seem to find what the “circulate” setting does on the fan setting. Is there a FAQ I missed somewhere that explains the basic settings? I get most things here are self explanatory…
Circulate fan mode is a special fan mode that is used by some HVAC systems which when enabled circulates the air. The fan turns on and then off after a set period of time and the cycle repeats itself so that the air is circulated periodically, but the fan isn’t running 24x7. Some systems also require this for internal operations to keep the coolant moving.
You should use this fan setting only if your thermostat supports/requires that feature. If not you can take a look at this app to replicate the feature.
Ilker, If the beeping started recently it could mean that the battery is low
Thank you for submitting the updates for the Daikin DTH. I’ve manually applied the update to the code and it’s no longer putting the device into full fan mode.
I’ve switched to using the ultimate modes app only and have a piston automatically setting the location modes based on time of day. Instead of starting over in the other thread, I figured I’d post again here.
I’m still getting random heatsetpoints to 8 degrees followed by setting it to the proper temp that I have stored in the app settings.
In all the modes I have programmed, I don’t use 8 degrees anywhere for anything.