[DEPRECATED] Free Ecobee Suite, version 1.6.**

Bah! That was it. Everything appears to be running Ok again.

1 Like

Hmmm … getting this in Live Logging with 1.6.11:

6:57:33 AM: error groovy.lang.MissingMethodException: No signature of method: script_dth_0a3464c7f72b4727fffe94f3152de1d565f4593d99237ffe3bf7e59818751ea0.isStateChange() is applicable for argument types: (physicalgraph.device.cache.DeviceDTO, java.lang.String, java.math.BigDecimal) values: [EcobeeTherm: Dining Room, thermostatSetpoint, …]
Possible solutions: isStateChange(java.lang.String, java.lang.String), isStateChange(java.lang.Object, java.lang.String, java.lang.String) @line 1180 (doCall)

That’s in the thermostat device, correct?

Correct …

Ecobee Suite Thermostat device updated to v1.6.12

  • fixes type conversion error when displaying Auto Mode setpoints

https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/devicetypes/sandood/ecobee-suite-thermostat.src/ecobee-suite-thermostat.groovy

1 Like

Mode-changing Helpers updated to v1.6.12

Open Contacts, Quiet Time, Smart Circulation & Smart Mode each now support the notion of a “manual override.”

Now that these 4 helpers coordinate their operations (using reservations), I have implemented the formal notion of a manual override. Basically, if any of these helpers have taken out an ‘xxxxOff’ reservation (mode, fan, circ, humid, etc.), and that mode gets turned on again, then the Helper will treat that action as a manual override, and end the current control session immediately.

So, when Smart Mode has turned Off the HVAC (because it was cool enough outside), and then someone/something turns the HVAC back on at the thermostat or using an app, Smart Mode will realize this and reset its states.

Quiet Time goes a step further - if anyone overrides the Thermostat Mode, the Fan Mode, or the Minimum Circulation Time (providing you have configured it to turn these off), the helper will end Quiet Time and reset everything (except the Quiet Time switch itself - this may change after I think about it a bit). This won’t ping-pong, because Quiet Time is turned on by the switch change. Also, turning back on the humidifier/dehumidifier (if they were off) won’t end Quiet Time, it will just clear the reservations…until the next time Quiet Time is invoked.

Quiet Time is also the only one of the 4 that will take an action when manually overridden - it will try to reset everything it changed back the way it was before the last Quiet Time started - with the singular exception of the thing that was manually changed. So, if the thermostat Mode was “heat” when the Quiet Time session started, and Quiet Time was configured to turn Mode to Off, then if someone manually changes to Auto Mode, Quiet Time will reset everything back except Thermostat Mode. Again, I hope this makes logical sense…

FWIW, I have little choice in adding this, because I need a way to release all the reservations should someone change things while a Helper holds a reservation. As coded, a manual override basically cancels all reservations; which sets things up to ensure that the next time a helper needs to make a change, it can.

Thoughts, feedback comments welcome - I know I could be getting into the weeds here…

1 Like

Updates to remove location.contactBook support (deprecated by SmartThings)

Released 7:30AM EDT, August 1, 2018

Ecobee Suite Manager v1.6.11, Open Contacts v1.6.13, Routines v1.6.11, Smart Mode v1.6.13 & Smart Room v1.6.11 updated to remove sending notifications via the now-deprecated location.contactBook.

1 Like

Well, so far, everything that I use (Open Contacts, Routines, Smart Mode, Smart Switches) is working great. I did have a brief hiccup with Open Contacts when I updated to 1.6.1* (from 1.5.x) — whichAction got set to “Notify Only (default)” when I had it set to “Notify and HVAC Actions” in the previous versions; also there was the error mentioned in the post, above.

Mmmm … weed is fine here in Cali :wink: … thanx for the great work, Barry :+1: :beer:

It’s fine here in Taxachussetts, too! :face_with_hand_over_mouth:

Any idea why I cannot use the up/down arrows to change temp set points when viewing the device in the Smartthings app?

Hmmm… I just double-checked, and they work for me (on iOS) (unfortunately my Android device is out of service at the moment).

My suggestions:

  1. double check that the version on both Ecobee Suite Manager and Ecobee Suite Thermostat are the latest (1.6.1*)
  1. remove the ST mobile app from your mobile device memory, and restart it
  2. If those don’t solve the problem, please capture Live Logging for both the Manager and the Thermostat device and PM them to me. Hopefully there’s an error in there I can track down…

Also, please include version numbers and your mobile device type in error reports

I’m on the latest versions of everything. I’m specifically talking about the arrows here:

I’ve also noticed that the device handler always show my AC set to 1 degree higher than it is. For example, if I set the ecobee to 65-75, the ecobee will report 65-75 on the LCD but the device handler shows 65-76.

Yes, I understood that it was those arrows you are speaking about. Like I said - they work for me on iOS.

You appear to be running Android, so I ask that you capture the Live Log when you try using those buttons and send them to me.

To understand if there is an issue with the displayed range, scroll down in the device handler where all the sliders are shown. There you will see the actual set temperatures, and an explanation of when the thermostat will call for heat/cool based on the internal settings of the thermostat. Generally, it helps to understand what is going on if you use decimal precision of 1 instead of 0…

For the range part, I see the setpoints correctly (they report 65 and 75), but right below the setpoints it says “Heat at 65, Cool at 76”. So maybe that is where the 76 value is coming from?

Yes, as explained in the README file, one of the features of my Ecobee Suite is that it tells you when it will actually call for cool when it isn’t cooling (Cooling AT 76), and then it tells you the temperature at which it will stop calling for cool (Cooling TO 75). The Android implementation of the Thermostat MultiAttributeTile is different in that it always says either Cooling AT or Cooling TO (I forget at the moment), leading to some of the confusion. I have repeatedly complained to SmartThings about this, but it is apparent that they aren’t going to fix this again (they actually did fix it once, for about 6 months).

Sorry for that confusion - it is why I added the detail on the dashboard in the first place, to make it clearer what was going on…

The main issue I have with the cooling setpoint not showing correctly is that when the device is added on actiontiles the cooling setpoint is displayed incorrectly, here is an example when it is set to 60-80
Capture:

Not much I can do about that - I am using setpoints as they are defined in the documentation and as implemented in the iOS MultiAttibuteTile - they actually mean something different when the thermostat is operating and when it is idle/fan only. Many of my users have noted that they like this added feature of my Ecobee Suite, so I have no plans to change it…

As a work-around, you could install the stock ST device handler and expose that to actionTiles instead of mine.

Or, you could modify my code to suit your preferred display values, if you like.

Or, you could ask the actionTiles folks to display “heatingSetpointDisplay” and “coolingSetpointDisplay” instead for the “Ecobee Suite Thermostat” device - they reflect the value you see on your thermostat.

I really like your device handler so I’m going to keep it. I was just wasn’t sure if this was a bug of some sort. If you’d like to send me some instructions on modifying the device handler I could do that.

Sitting here thinking about it, I can possibly fix this without breaking things for other users. Give me a couple of days to implement and test…

Awesome, I’ll take a look as soon as you have something. Thanks!