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.
Okay. I manually deleted the two test devices that were automatically created, then the smartapp allowed me to complete the process.
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âŠ
I got it through github yesterday, so I assume the latest version?
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.
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?
Open the IDE in an incognito/private browser window. That should do it.
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:
@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âŠ
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âŠ)
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!
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
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
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 deprecatedgetWeatherFeature()
(Weather Underground) for external temp/dewpoint/humidity.
Important Notices:
- The current Weather Underground interface in SmartThings will stop working on or before Feb 15, 2019
- 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:
- The Weather Tile station DTH provided by SmartThings
- Weather Station Tile 2 by Takis, which provides more data
- My own Free MeteoBridge Weather Station which uses direct access to your local weather station via MeteoBridge/WeatherBridge
- The Ambient Weather DTH by Kurt Sanders
- 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
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âŠ
Is The Ambient Weather DTH by Kurt Sanders not a supported device?
This is the weather source I want to select
This is the North Outside Sensor from my ambient WS
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).
No worries. Thank you
@storageanarchy, thanks for the heads up on this! Here is my take on this!
- 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)
- 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.
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:
- 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).
- 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.