[RELEASE] Universal Ecobee Suite, version 1.7.**

I’m not at home anymore, it hasn’t worked in a long time, I upgraded my networking equipment this weekend but it’s not connection, it has to be the SmartApp, I’ll try removing and remaking it but can’t see my fan on any cameras so won’t know for sure for 11 more days. Was hoping I just missed something within the updated app.

Thought making the app again would work but it didn’t, still just sends off commands, no ons, I’ll have to try to open the log on my phone during a call for heat and see what pops up. Strange that it just stopped sending on commands but still sends the off command

That’s usually a transient error, but I would suggest reporting to SmartThings support to see what they say about it. I’ve seen it once or twice - the code should recover, once SmartThings is able to allocate a connection…

[PRE-RELEASE] New Open Contacts & Switches Helper

A user recently asked if I could make the Notifications sent by the Open Contacts & Switches Helper customizable, so that they sounded better as Echo Speaks announcements. I have completed a major update to this Helper that enables you to customize:

  • The notification prefix - default: "(Helper Name) at (Location Name)"
  • The way Contact Sensors are referenced - default "contact sensors"
    • Option to use the specific device’s display name that is open/closed (e.g., "Front Door Sensor")
    • Includes the ability to remove specific words from the devices’ display name (e.g., "Sensor" --> "Front Door")
    • Optionally add “the “ as prefix to devices’ display name (e.g., "the Front Door")
  • The way Switches are referenced,
    • Option to use the specific device’s display name that is on/off (e.g., "Attic Fan Switch")
    • Includes the ability to remove specific words from the devices’ display name (e.g., "Switch" --> "Attic Fan")
    • Optionally add “the “ as prefix to devices’ display name (e.g., "the Attic Fan")
  • The way Thermostats are referenced (e.g., "Thermostat", "HVAC system", "(thermostat display name")
    • Includes the ability to remove specific words from the devices’ display name (e.g. "EcobeeTherm: Downstairs" --> "Downstairs")
    • Optionally add one of a selection of prefixes to devices’ display name (e.g., the , Thermostat , … --> "Thermostat Downstairs")
    • Optionally add one of a selection of suffixes to devices’ display name (e.g., "The Downstairs HVAC system"
  • Whether or not the delay minutes is included in the notification (e.g., "... has been open for 5 minutes, ..." or "... has been open too long, ...")

The Customize Notifications page dynamically shows you how various messages will appear based on the Helper’s device/setup options and the selected customizations, helping you select the options that work best for your home.

Some examples:

  • "The Front Door has been open for 5 minutes, the Downstairs HVAC system is now off"
  • "One or more doors and/or windows have been open open too long, you should turn off the HVAC system"
  • "All windows are closed, the Upstairs Thermostat is now on"
  • "Upstairs HVAC Monitor at Daytona Beach House: the Attic Fan was turned on, the A/C is now off"
  • "ATTENTION RENTERS! the Porch Slider has been open too long, the HVAC System is now off"

I’m looking for users to try out this new version and provide feedback on the options and resulting notifications. Just please be aware that there may be bugs in the code…

You can find this development version here

I would like to assign a non Ecobee sensor as a temp sensor. Does your smart app allow this or is it limited to Ecobee branded sensors?

Thanks

As noted in the documentation, my Ecobee Suite does not support using non-Ecobee sensors for the purposes of current temperature averaging. This because it is not possible to control what the thermostat displays for the current temperature - it will only display the temperatures it has averaged from Ecobee sensors, and it will only use this averaged temperature to determine if heat/cool is required to reach the desired setpoint(s).

That said, it is possible to utilize sensors to cause a room with an Ecobee sensor to be added to a program. To do this, you will need to utilize WebCoRE (or native IDE Groovy programming) to call (sensor).addSensorToProgram() or (sensor).deleteSensorFromProgram().

Further, the Smart Circulation, Smart Mode, Smart Vents and Smart Room Helper applications do allow you to choose a non-Ecobee thermometer (and/or humidity) devices as their target sensors - e.g., the Smart Vents Helper will control a smart vent damper as it seeks to get the temperature of a specific sensor to the target setpoint.

1 Like

Is it possible to get the comfort settings’ configuration information? In other words, given the current program name, is it possible to get what the heating/cooling setpoints are configured to be in the comfort setting itself?

My use case is that I want to write a weather-based automation that adjusts the setpoints based on the outdoor temperature, but in order to do that, I need to be able to know what the current setpoints are supposed to be based on the schedule.

There’s no easy way to get at that information, but you could just call setThermostatProgram("Away") and then thermostat.currentValue("heatingSetpoint") and thermostat.currentValue("coolingSetpoint").

Have a look at the included Ecobee Suite Smart Mode, Programs & Setpoints Helper - it might already do what you want .

Note that if you change the setpoints using setHeatingSetpoint() and setCoolingSetpoint() you will create a hold for the new setpoints, but the Comfort Setting itself won’t be modified, but if you use setProgramSetpoints() you will actually change the setpoints of the Comfort Setting.

What are the parameters to setProgramSetpoints(), and is it possible to only adjust one setpoint and not the other? I might be able to do what I want using that method.

(The included helper doesn’t do what I need.)

     void setProgramSetpoints(programName, heatingSetpoint, coolingSetpoint) 

There is a bug in this: it enforces the minimum delta between the heating and cooling setpoints regardless of what mode the thermostat is in. However, the minimum delta is only supposed to apply if the thermostat is in auto mode, not in heat or cool mode.

There’s also a typo at line 3231 of the device handler:

if (heatinfSetpoint) updates << [heatingSetpoint: heatingSetpoint]

Should be heatingSetpoint, not heatinfSetpoint

Thanks for the typo - I’ll get that released momentarily. Fortunately, it isn’t fatal - the heatingSetpoint display should get corrected the next polling cycle.

I am pretty sure that the minDelta / setpoints don’t work the way you describe.

I just tried this on one of my Ecobee 3s:

  • Set heat-only mode on the thermostat
  • check the current setpoints by looking at the ES Thermostat device in the SmartThings IDE (heat: 70.0, cool: 75.0, heat/cool min delta: 4.0)
    • You can also find these values in the dump of ES Manager’s state, but they’re named “heatTemp” and “coolTemp”
  • raise the heatingSetpoint to 73.0 using the Ecobee browser interface or direclty on the thermostat (I tried it both ways).
  • force a refresh in the ES Thermostat device (or just wait for the next polling cycle to complete)
  • Check the setpoints again (heat: 73.0, cool: 73.0, heat/cool min delta: 4.0)

Yep, apparently if you are in either heat or cool when you change the associated setpoint, BOTH setpoints get changed to the new value!!!

Further, if you change the thermostat Mode back to Auto, the heat/cool min delta is applied - with the above case, the coolingSetpoint is recalculated to be 75, and the heatingSetpoint is reduced to 71 (that’s a +2/-2 adjustment to meet the heatCoolMinDelta of 4.0).

So, if I DON’T force the heatCoolMinDelta when you change only 1 setpoint, the thermostat will set heatingSetpoint (heatTemp) and coolingSetpoint (coolTemp) to be the same value, and it will enforce (calculate) the delta when the thermostat is set to Auto mode. The resulting calculation will adjust BOTH setpoints to meet the delta (instead of maintaining the heatingSetpoint in my example above and just adding 4.0 degrees to get the new coolingSetpoint). In the above case, my code will maintain the heat/cool setpoint if in heat/cool mode (respectively), and adjust both only if the current mode is Auto.

Note that when the hold override expires, then both setpoints are reset to the values in the currently scheduled Climate.

Given all this, I chose to enforce the minDelta any time you change the current setpoint, as it made no sense to me that the two setpoints should match when you manually override one of them. IMHO this shouldn’t break anything, but I’m open to changing it if you can explain why it should be changed.

FWIW, you can also override the heatCoolMinDelta value if you would like, although I’m not sure that you can set it to 0.0°

I have an ecobee4. Maybe they did something different there. I’ve been running ever since I installed it with climate settings with a 0 degree differential. It gives me no trouble at all.

This is actually the reason I don’t use auto mode: as soon as I put the thermostat into auto mode, it would adjust all my climate settings to respect the min differential. As long as I never switch it into auto mode, it has no problem with climate settings that even have negative differentials (I’ve tested that too).

Yep, apparently if you are in either heat or cool when you change the associated setpoint, BOTH setpoints get changed to the new value!!!

I’ve never seen this happen, either.

Since I noticed this last night, I’ve been running with a local modification to force the min delta to be 0 in the Ecobee Suite Manager code. It seems to work up to a point: Changing a program’s heating setpoint to be within 1 degree of its cooling setpoint works, but making them the same does not.

When I go to the thermostat and edit the programs manually, I can set the setpoints the same – I can even set the heating setpoint to be higher than the cooling setpoint, and that works. So either there’s a difference in what they allow in the API, or I’ve missed a spot in the code that also needed to be changed.

OK - if you comment out line 2132 (see below) of the thermostat DTH, you won’t have a “forced” delta:

     if (!delta) delta = isMetric ? 0.5 : 1.0

I’ll do some testing to verify that this doesn’t negatively impact anything else, then release that fix later this morning…

Also, FWIW, once you set the heatCoolMinDelta to 0.0, you shouldn’t have to set it again.

How did you test this? I just tried another test on my e3 and I still get both heat and cool setpoints changed:

  • Same setup as before
  • In Heating mode
  • Change (heating) setpoint from 70 to 73°
  • Change Mode from Heating to Cooling
  • Cooling setpoint displays as 73°
  • Verified that this is what my code sees and displays as well

So, the above edit, and your heatCoolMinDelta set to 0.0°, you shouldn’t get your setpoints adjusted by my code when you change them using my Ecobee Suite.

I would be interested to know what your ecobee4 does with the above test. Also, do you have the Auto Heat/Cool Feature Enabled?

My change last night was changing line 5138 of the suite SmartApp to:

def delta = 0

Changing line 2132 of the DTH doesn’t work because I’m not changing the thermostat setpoints, I’m changing the program setpoints. That function doesn’t get called as far as I can tell.

Also, FWIW, once you set the heatCoolMinDelta to 0.0, you shouldn’t have to set it again.

I can’t do that; the minimum at the thermostat is 2 degrees. But as I said earlier, it doesn’t actually enforce the min delta until I switch it into Auto mode. That’s why I’m looking for a code change to ignore the delta.

How did you test this?

  • In heating mode
  • The active program’s setpoints are currently 71 heat, 73 cool
  • Change the active program’s heating setpoint to 74
  • Cooling setpoint remains at 73

All done manually at the thermostat.

Also, do you have the Auto Heat/Cool Feature Enabled ?

No. That was one of the first things I turned off because I didn’t want it messing with my setpoints.

How did you verify the cooling setpoint?

I configured my e3 to disable the autoHeat/Cool, and then set the (heat only) heating setpoint to 78° (higher than the cooling setpoint), but it still changes the cooling setpoint to 78°. I verified this by looking at the data sent back to ES Manager after the setpoint change. If I switch from heat to cool, the cooling setpoint is 78° also, even though I did nothing to change the cooling setpoint (except change from heat mode to cool).

So, how about this compromise:

  • I’ll change all the setpoint-related stuff to check if autoHeatCoolFeatureEnabled and also that auto mode is a currently supported mode (these are actually linked to each other).
  • If both are false, I will ignore the heatCoolMinDelta and whether the requested heatingSetpoint is higher than the coolingSetpoint.
  • Thus, the code will pass the requested value(s) through without modification, and you will (eventually) get whatever the thermostat thinks you should get, without any muddling with the values.

Will that work for you?

How did you verify the cooling setpoint?

I checked it in the comfort setting. I did everything manually by the thermostat. I don’t know what the API sees.

Will that work for you?

It should. Hopefully the thermostat itself won’t try to be too smart.

Thanks.

© 2019 SmartThings, Inc. All Rights Reserved. Terms of Use | Privacy Policy

SmartThings; SmartApps®; Physical Graph; Hello, Home; and Hello, Smart Home are all trademarks of the SmartThings, Inc.