SmartThings Community

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

askalexa
thermostat
smartapp_hvac
dth_hvac
project_hvac

(Leviathan) #354

I am having the same set of issues. Got the green bar (ios) that said authorized, then clicked save and was told that operation was not authorized.


(Leviathan) #355

Okay. I manually deleted the two test devices that were automatically created, then the smartapp allowed me to complete the process.


(Barry) #356

What version of Ecobee Suite Manager are you running? The latest version should have deleted them for you, without making you start all over from the Marketplace…


(Leviathan) #357

I got it through github yesterday, so I assume the latest version?


(Barry) #358

Dang it! I thought I had solved the problem of abandoned children causing install problems.

Oh well, back to the drawing board. Glad that you were able to work around the issue.


(Phil) #359

I am finally trying to move from Ecobee (connect) after having issues with my thermostat not getting commands from WebCORE like it used to. Anyways when I go to OAuth I get an error that the page can not be displayed. Any suggestions?


(Jason) #360

Open the IDE in an incognito/private browser window. That should do it.


#361

Hi, I’m trying to install this SmartApp for the first time. I have installed using the GitHub integration, followup the OAuth instructions and Authorized the App to access my ecobee Account.

In Suite Manager, I can open and save various changes. However, as soon as I add my thermostat and click save, I get an error message “An unexpected error has occurred”. Here is what shows in Live Logging:


(Barry) #362

@dwaram -

Is N0B1S0 your proper zip code?

  • If not, set the correct one for your SmartThings hub and try again.
  • If so, I suspect somethings’ awry with SmartTHings’ getSunriseAndSunset function (rumor is they recently changed the data provider for that).

You could try setting your SmartThings location’s zipcode to blank, but be sure that you have also set the geolocation of your hub so that the code can use that to find your sunrise/sunset time…

Let me know…


(Barry) #363

Also, make sure that you have set the proper Zip Code in your thermostat itself (I think it has to be done via the Ecobee WebApp or the Mobile app…)


#364

Thanks Barry,

Yes. N0B1S0 is my postal code here in Canada. I don’t see a way to set my ZIP Code to blank in the App, so I edited the code and it works! Thank you so much for your help. Is there a way to request a change to the GitHub repository to prevent this issues from happening again?

Thank you!


(Barry) #365

This is the first time this problem was reported, and I know that I have several Canadian users who didn’t experience the issue that you did.

After some more testing, it appears that SmartThings is not handling your Zip code properly - I tried using your Zip code in the Example they provide below and it fails in the same manner. So they’ve broken something - you should definitely report this to support, since it seems to handle other zip codes properly.

I don’t want to code around their bug…check that, I’ve decided to code around the possible error…see below


(Barry) #366

Ecobee Suite Manager updated to version 1.6.22 on 6 January 2019 at 9:55am EDT

Fixes include:

  • Eliminated unintended recursion
  • Cleaned up some error messages
  • Now properly handles the case where SmartThings getSunriseAndSunset throws an error when using certain Canadian postal codes.

NOTE: Sunrise/Sunset data is only used to control which weather icons are displayed…if no valid data can be obtained, the code will use a ‘generic’ day of 0500–>1800.

This update is recommended for everyone


(Barry) #367

Ecobee Suite Smart Mode updated to version 1.6.18 on 10 January 2019 at 12:15pm EST

  • Now uses the new getTwcConditions() (The Weather Company) instead of the deprecated getWeatherFeature() (Weather Underground) for external temp/dewpoint/humidity.

Important Notices:

  1. The current Weather Underground interface in SmartThings will stop working on or before Feb 15, 2019
  2. The new API (currently) does not provide a means to access a specific Personal Weather Station directly. If that is required, you should find a SmartThings Weather Station DTH that supports your weather station and use its sensors instead. There are numerous options:
  3. The new API appears to not support non-US postal codes. Users are advised to allow the API to use the geographic coordinates for your location get get the most precise/relevant data for your location.
    • Your geographic location must be defined in your Mobile App in order for this to work properly

This update is recommended for ALL Ecobee Suite Smart Mode users


(Tobin Smail) #368

I worked with " * The Ambient Weather DTH by Kurt Sanders" He got my ambient weather station data reporting to smartthings with exact data from my station outside sensor…way better than WU. Great guy and very helpful! Now that I have this DTH setup I am trying to work with the smart mode for my aux heat. We got this working before with WU but since it is going away I went with the “Ambient Weather DTH” which works much better.

The problem I am running into is that when I select “The SmartThings-based Weather Stations DTH” I do not get a list of available and supported Weather Station devices below…
image

Is The Ambient Weather DTH by Kurt Sanders not a supported device?

This is the weather source I want to select
image
This is the North Outside Sensor from my ambient WS


(Barry) #369

I should be able to add the necessary support over the weekend.

In the meantime, simply select the “SmartThings Sensors” option, and select the temperature and humidity from your Ambient Weather Station device. The only difference from using the weather station DTH directly is that my code has to calculate the dewpoint - not a big deal.

FWIW, Kurt uses a non-standard name for the dewpoint - ALL of the other devices (mine included) name the attribute “dewpoint”, he uses “dewPoint”. Not a big deal for me (my code pre-supposed this would happen), but it would be better if he followed the de-facto standard.

Also, I noticed that he has the version number in the name (“V3”) - whatever I do will break if he ever changes the version number, because the selection logic that SmartThings provides is based upon his device name (
“Ambient Weather Station V3” becomes “ambientWeatherStationV3” in the ST logic). Again, it would be better that his device name stayed the same as he released updates…

I’ll let you know as soon as I have the code updated (I’ll need you to be my tester/validator).


(Tobin Smail) #370

No worries. Thank you


(Kurt Sanders) #371

@storageanarchy, thanks for the heads up on this! Here is my take on this!

  1. The camelCase naming of ‘dewPoint’ actually comes from Ambient’s published Device Data Specs API.. I followed their exact naming convention for server calculated fields and it allows my code to easily loop through the returned variables of the various weather stations I encounter with this app. I can recode to send a separate event to the DTH’s as a hidden lowercase dewpoint attribute in the SmartApp in the next minor release, which can be immediate if you let me know if this is something you would desire rather than change your side. BTW, I was unaware of any de-facto published “non standard attribute naming conventions”, like dewPoint, feelsLike, lastRain, etc, but if it makes it easier for everyone, just let me see the list so I make available camelCase shared attributes in lowercase.

Ambient Weather API Server calculated fields:

  • lastRain - Last time hourlyrainin > 0, date (calculated on server)
  • dewPoint - Dew Point, ºF (calculated on server)
  • feelsLike - if < 50ºF => Wind Chill, if > 68ºF => Heat Index (calculated on server)
  1. As far as the naming of the Ambient Weather SmartApp with major release Number ‘V3’ added to the end of the name, I support this naming convention in many of my other APPS so as when I need to release a MAJOR UPGRADE (V4), it usually requires that the previous users delete their old versions and start new because of the marked changes. Or they can choose to keep the older major version and the new MAJOR RELEASE can be installed without impacting the previous MAJOR RELEASE. They can delete the old version when they have determined that it produces the results they expect.

I do not see a MAJOR RELEASE happening for years from now, just minor features and patches which do not change the suffix of the title. We all know that it would be perfect if iOT things that depended on other iOT things never unexpectedly changed, but we have all seen that happen time and time again with depreciated API’s which cause us to re-code.

Again, let me know. Happy to help, and BTW you have an excellent Ecobee Suite that I installed along with another that I have been using for years. Heads and shoulders great app with many educational parts that I am reviewing! I plan to send some beer money your way for all your hard work after testing with all my dependent pistons.


(Barry) #372

Glad to hear you like my Ecobee Suite - it all started when I decided that I wanted things in my “suite” in a manner much cleaner/simpler/easier than that other guy was willing to do (his DTHs are among the ugliest I have ever seen on SmartThings, IMHO). It’s also what led me to build my own Meteobridge Weather Station - a desire to get MY PWS data without having to depend upon a third party (once I saw what WunderGround was doing).

As for your comments:

  1. When you are defining attributes in SmartThings DTHs, it is more important to use the same naming as existing DTHs instead of trying to maintain consistency with the source devices. Otherwise SmartApps and WebCoRE pistons won’t “just work” with any similar device without customization. Imagine if every contact sensor, humidity sensor or switch used attributes with vendor-specific names. No, you really should change your DTH to use “dewpoint” like all the existing weather station DTHs do, and if you insist on using the “proprietary” version, go ahead and make it a “hidden” attribute.
  • FWIW, I have had to do the same thing with my Ecobee Suite, on many occasions as standards have emerged (especially as SmartThings railed between using maxHeatingSetpoint/MinHeatingSetpoint to heatingSetpointRange to finally heatSetpointMax/heatSetpointMin - I currently support FOUR different versions of those, despite the fact pretty much nobody uses them).
  1. As for the naming, the problem is that your name structure prohibits me from using it in my SmartApps to select devices of yours. The code I need to use is this:

input(name: "ambientWeather", type: "device.ambientWeatherStationV3", title: 'Which Ambient Weather Station V3?', description: "Tap to choose...", required: false, multiple: false, hideWhenEmpty: true)

The problem is that this won’t work - the naming structure that SmartThings defines to select devices of a specific type translates the name above into Ambient Weather Station V 3, which won’t match (because of the space between V and 3 that ST inserts). Thus, there is no way for my code to specify devices of your custom type, and thus no way for me to compensate for the fact that you use different attribute names than every other weather station that I support in my code.

You can see for yourself the restrictions and naming conventions required to select devices by their device name: https://docs.smartthings.com/en/latest/smartapp-developers-guide/preferences-and-settings.html?highlight=using%20device-specific%20inputs#using-device-specific-inputs

It’s up to you if/when you change these things. Let me know what you decide.


(Kurt Sanders) #373

@storageanarchy I started a PM