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…)
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?
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
- Eliminated unintended recursion
- Cleaned up some error messages
- Now properly handles the case where SmartThings
getSunriseAndSunsetthrows 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 deprecated
getWeatherFeature()(Weather Underground) for external temp/dewpoint/humidity.
- 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 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.
@storageanarchy I started a PM
For those Ecobee Suite users who may be interested in utilizing temperature and dewpoint data from Kurt’s Ambient Weather Station V3 with Ecobee Suite Smart Mode, it turns out that I won’t be able to integrate support for his DTH after all.
Therefore, you will need to select “SmartThings Sensors” in Smart Mode, then select the temperature and humidity sensors from Kurt’s DTH as your input sources for outdoor conditions. You don’t lose any functionality doing it this way, as Smart Mode will calculate the dewpoint automatically.
Hi Barry, my Ecobee thermostat has been unavailable on Smartthings since this morning at 5:24AM when it gave it’s last update, after that I keep getting “This device is unavailable” with a red dot on the icon. I tried running the Suite, logged in again using my ecobee credentials, and rebooted the ecobee itself?
Is there anything else I can try to resolve this? Will deleting the Suite delete all my helper settings?
My code doesn’t (can’t) put a red dot in the icon, so this is something on the SmartThings side, unrelated to your connection to the Ecobee service…
Are you running with Device Health on? If so, turn it off and see if things recover - that is sometimes the problem.
Also - is this with the new Samsung Connect mobile app, or with SmartThings Classic? I always suggest using Classic whenever working with the thermostat device…
Whatever you do, don’t delete the Suite - because yes, it will require you to delete all your helpers, and quite likely it won’t solve the problem. See my other message for some first-level debugging questions…
One other thing to try - reboot your SmartThings hub…actually, pull the power, remove the batteries, then power it back up…it may be the culprit, refusing to see that your thermostat DTH is in fact actually working…
I am having the same problem. Last update 4:22 AM Central time zone. Four sensors and two thermostats show unavailable and red dot on left.
Same suggestions. Reboot your hub. Turn off Device Health.
OK - weird…seems that several users experienced their Ecobee devices going off-line at the same time (around 5:22am EST this morning). Time to contact SmartThings support…
Looks like an issue with the SmartThings/Ecobee connections again, impacting (I think) only users on the original/primary useast shard.
Best bet is to report the issue to email@example.com - don’t uninstall, and probably best not to try to re-authenticate…if they fix the problem before 5:22AM Sunday (EST), the code should auto-recover…