[RELEASE] 5-2 Day Programmable Thermostat Scheduler (Weekday, Weekend) with Remote Temperature Sensor for each Schedule

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:

  1. 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?
  2. 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)
  3. 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.

Any ideas?

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.

Thanks!

Maddie:

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.

Mike

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.

  1. 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.
  2. 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.
  3. See point 2, the custom DTH needs to be updated
  4. 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.

Hi,

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 ?

thanks.

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…

The 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.

1 Like

You’re welcome and a couple of things to note.
While I submitted a patch to fix the fan mode issue for the DTH, it still isn’t completely compliant with the ST standard (e.g. it reports a dry mode or fan mode which doesn’t exist in ST).
The above screenshot doesn’t appear to this 5-2 day thermostat app but the Ultimate Modes Based Thermostat app. That works differently from this app and it appears to be doing what it should, sending the heat and cool setpoints when the DTH is reporting the mode as Auto. (8C the minimum heating setpoint which is set under various conditions like if a door/window sensor is detected as open, there’s a remote sensor etc).

@MRobi,

I made the conscious decision to not follow the thermostat standard for Auto mode as it would have required emulating a lot of the automatic function of the A/C and is not how split systems really work.

The “Air-Conditioner” ST device type is a much better fit as it supports Dry and Fan modes but I’m not sure if it is available yet and will also break any compatibility with thermostat-based automations anyway.

In Smartthings, Auto mode will essentially set lower and upper temperature limits, and attempt to either cool or heat to remain within that zone.

For Auto mode, the Daikin A/C expects input of just a single temperature and it will will cool or heat to keep it exactly at the degrees (-/+ ~1c). So unfortunately having auto mode as per the ST specifications doesn’t work very well as the Daikin A/C will only accept a “target” temperature and does not know the concept of cool/heat set-points.

As your outside temperature is so low, could you try just using heat mode and setting it to your desired temperature? As it is unlikely cool would ever come in to play :grin:

I am interested in implementing 3 separate CT100 (the 40 dollars version IRIS variety from Amazon without the IRIS controller) thermostats and utilize the scheduler app. All 3 will have their own unique schedules so I am not looking to maintain all three to be in sync at all times. Does the free or the premium app support multiple thermostats, namely CT100 units connected to the same ST hub and allow them to maintain their 3 separate schedules?
Thanks.

It can work both ways.
If you select multiple thermostats in a single instance of the app, then it applies the configured schedule to all the selected thermostats.
On the other hand, you can install the app separately for each thermostat and have independent schedules for each thermostat.

In exploring its full potential, taking it one step ahead, if configured correctly using Modes, you can even run it along side other thermostat apps like the Ultimate Modes Based Thermostat and Motion Sensor Based Thermostat on the same thermostat.

Thanks for your reply but can you clarify if the multi thermo. support exist both free and premium versions. And can you provide some idea what the advantage of using the premium edition over the free app.