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

So, I am not 100% sure how this is happening… but I wanted to log that it was setting it, and although the value is “true” it still goes to the else clause?

def hasSetLevel = (theVent.hasCapability('switchLevel') || theVent.hasCommand('setLevel'))
LOG("Set Level is ${hasSetLevel}",3,null,'debug')
if (hasSetlevel) {
    LOG("Set Level is ${hasSetLevel}",3,null,'debug')
	if (theVent.currentValue('level').toInteger() < 99) { theVent.setLevel(99) LOG("Setting to 99",3,null,'debug') } //some vents don't handle '100'
    //if (theVent.hasCommand('refresh')) theVent.refresh()
    //if (theVent.currentSwitch != 'on') theVent.on()						// setLevel will turn on() for some devices, but not all
    changed = true
} else {
    LOG("Somehow it skipped it",3,null,'debug')
	theVent.on()
    changed = true
}

[271f72bb-8b22-4952-b8ae-40e3d53362d3](https://graph-na02-useast1.api.smartthings.com/ide/logs#271f72bb-8b22-4952-b8ae-40e3d53362d3) 7:13:10 PM: info Opening Olivia's Room Vent

[271f72bb-8b22-4952-b8ae-40e3d53362d3](https://graph-na02-useast1.api.smartthings.com/ide/logs#271f72bb-8b22-4952-b8ae-40e3d53362d3) 7:13:10 PM: debug Somehow it skipped it

[271f72bb-8b22-4952-b8ae-40e3d53362d3](https://graph-na02-useast1.api.smartthings.com/ide/logs#271f72bb-8b22-4952-b8ae-40e3d53362d3) 7:13:10 PM: debug Set Level is true

[271f72bb-8b22-4952-b8ae-40e3d53362d3](https://graph-na02-useast1.api.smartthings.com/ide/logs#271f72bb-8b22-4952-b8ae-40e3d53362d3) 7:13:10 PM: info Vents should be open

This is my first time looking at this, so I could be misunderstanding something, but it appears to me that it somehow didn’t evaluate the true?

Typo - it should be “if (hasSetLevel)” instead of “if (hasSetlevel)”…please fix that and tell me if it works…

Ah will do, might be tomorrow before I can cycle then again but I’ll let you know.

No problem - I’ve already posted the fix to the GitHub…

Actually, I just pulled from git and all is working!

One more quick question. I couldn’t find a definition of what the Heating and Cooling differential are. I understand it is an offset but does it offset the set point, or the current temperature? Does this differ when heating (raising temperature) and cooling (lowering temperature)

For example:
Heating from 70 -> 72. If you want to close 1 degree early, would that be a +1 so that you consider the room 1 degree warmer than it reads
Cooling from 74 -> 72. If you want to close 1 degree early, would that be a -1 so you consider the room 1 degree cooler and will close earlier?

Since ecobee does an average, I am finding that my 2 rooms almost always are 2 degrees apart. I want to try and get them to close a little early so they might converge.

If you want it to close early on heat then put a - 1

ok, so it is an adjustment to the set point? So closing early on cooling would be a +1?

Ya as far as I know, that sounds right

Yes, the differential is added to the actual heat and cool setpoints, so to stop early on heat you would use a negative number, invert for cool.

Note that the logic is pretty clever, in that it will open vents when Smart Recovery starts (if you have that enabled) - otherwise the room wouldn’t get warm because the main thermostat won’t show the actual target set point until the actual time the change is scheduled, at which point the demand for heat will be canceled because the thermostat will be at the desired temp. I mention this because it can seem strange.

1 Like

Barry,
I tested the new switch/dimmer/vent helper (with action disabled time window) and it works well. Thanks!

Also wanted to flag an unexpected app behavior: if the trigger condition is true (in my case, ecobee AC running) and the disabled period comes to an end, the expected action (switch room fan on) doesn’t occur. Is as if events are “edge triggered”, so the assessment is done when the AC state changes, but not when the time window changes. Not a big issue for me, because the triggering will eventually sync on the next cycling, but this behavior was not expected, in case you want to review it further.

Alex

Thanks - I’ll look into what I can do about the time window…

Hi Barry, so #1 my use case is attempting to loosely do a better job than Smart Recovery at turning on the heat to reach my setpoint when my actual Ecobee Home time setting kicks in without it kicking in too early to wake up overheated. I turned off Smart Recovery long ago and have tried it a few times only to be continually disappointed. My basic thought is to set a time 15 minutes earlier which isn’t an option in regular Ecobee as it seems to be in 30 minute increments, so I was attempting to use Smart Modes/Routines/Switches/Programs Helper to do it, with a time based virtual switch. Seems to setup fine but was hoping you could add Thermostat mode to the helper to select whether it should apply to Cool or Heating settings. #2 With that said bigger picture, have you looked at just making a Smarter Recovery helper. I think you have most of what you need already in the various helpers to do this. I would think a lot of the users pay attention to the heat/cool times, so they know how long their furnace/ac really needs to get it to where it has to be depending on the temperature situations. My thought was you could shift (my 15 minute example ahead of actual Home time setting) setting and base it off Outside temps and Inside temps similar to the Smart Circulation Helper I helped you with. i.e. 50 degrees trigger Home 10 minutes early if inside temp is -3 degrees lower(from the desired Home Setting), 5 minutes early if inside temp is -2 degrees lower etc, 40 degrees outside 15 minutes, 30 degrees 20 minutes type thing. Something that user’s could define. If you have an alternative solution to this please share as I would definitely be interested. #3 is there a way in your suite to change the minimum run Heat time, looking to potentially use this to allow my humidifier more time when it gets really dry in the winter, but not something I really want to be manually adjusting.

OK, so here goes:

1. Better Smart Recovery

  • Hopefully you realize that SR needs to run for days, if not weeks, before it is really functional. It has to built a heat/cool loss curve for your house as observed in a variety of outside conditions (e.g., temp, humidity, wind, rain, etc.). This is complicated math, and while your desire for something simpler-is-better isn’t crazy, I would first recommend letting Smart Recovery run for a few weeks before you give up on it. Sure, it will start too early in the beginning, but it will gradually adjust that based on its recognition that the house warms/cools quicker than it has been allowing.

  • That said, you turning on a switch when you want the program to change should work fine with the Smart Modes/Routines/Switches/Programs helper. I would say that you should also employ an instance of Smart Mode that sets the thermostat to Heat/Cool/Auto based on the outside temperature; then whatever program you select should do the right thing, no matter when you turn the virtual switch on.

  • (edit) I also should note that Smart Recovery is able to take advantage of multi-stage heat - it will typically run the (most efficient) Stage 1 only during recovery, kicking in the gas-sucking Stage 2 only when it gets close to the target time and isn’t yet up to temp. I don’t think we can programmatically request only Stage 1 - the thermostat decides on its own when to engage Stage 2 heating.(/edit)

2. Better Smart Recovery

  • I really haven’t given this much thought, because Smart Recovery works for me quite well. There’s a lot of fluid and temperature dynamics logic required to predict recovery times across a variety of outside weather conditions - I’m not really into spending months figuring out what’s necessary and what really makes no difference.

#3 Minimum Heat Run Time

  • Unfortunately, Ecobee doesn’t expose any of the Equipment Settings and Thresholds to the API - these can ONLY be changed physically on the thermostat device itself.

  • Note that you can should be able to set your humidifier as a device that runs whenever the fan is on instead of only when heating. If you’re using an evaporative humidifier this might not work all that well, but the system will keep running the fan until it reaches the setpoint.

  • Raising the humidity inside your house is difficult, and the HVAC-based systems rarely work well, and often enable mold to grow in your duct work. For these reasons, I employ a large forced-air humidifier on the first floor of my house (humidity rises). It’s a pain filling the water bottles every day, but it makes the difference between my house being 30% RH and 45% RH in the winter.

The contacts and doors is broken, do you know about it or, do you want a log?

It’s got something to do with the push notification. “You can’t currently add this”

What version are you running:

  • ES Manager
  • ES THermostat
  • Contacts & Switches Helper

Are there any errors in the Live Logging for any of the above?

I just updated this week, so, the latest.

Yes, please - give me the version numbers so I can test with the version you are running…everything is working for me, but I run my own “development” version.

Info from the log file is also helpful - it’s hard to debug “is broken” with no other information…

1.7.34 is the version. I may have some time to get you some logs in a few minutes

986f941d-41a8-4568-8c89-9c1b9acae191 9:29:36 AM: error java.lang.NullPointerException: Cannot set property ‘mode’ on null object @line 352 (doCall)
986f941d-41a8-4568-8c89-9c1b9acae191 9:29:36 AM: warn Initialized while should be ‘Off’ - can’t update states
986f941d-41a8-4568-8c89-9c1b9acae191 9:29:36 AM: info switchOffState = false
986f941d-41a8-4568-8c89-9c1b9acae191 9:29:36 AM: info contactOffState = true
986f941d-41a8-4568-8c89-9c1b9acae191 9:29:36 AM: info Ecobee Suite Contacts & Switches Helper, version 1.7.33 on SmartThings - Initializing…
986f941d-41a8-4568-8c89-9c1b9acae191 9:29:36 AM: trace Installed with settings [offDelay:5, hvacOff:true, theThermostats:[Ecobee Thermostat], tempDisable:false, contactSensors:[Back Window Contact, Bedroom Window Contact, Front Door Contact, Sliding Glass Contact], speak:false, debugOff:false, quietTime:false, onDelay:0, contactOpen:true, pushNotify:true, whichAction:Notify Only]

Any reason you see here that it doesn’t send fan on commands anymore, only sends off?