My new Ecobee Device (disconnection issues are resolved)

Hello Yves,
Before I donate the $15, I just wanted to make sure this is stable and there are no more issues with the authorization dropping.

1 Like

For those that are wanting to know if this is more stable, I can report that it IS more stable than the previous version. Is it fixed? I would say no. I am still having to reauthorize every 24 hours or so. I am doing nothing fancy, just trying to change fan run times based on profile. I have pollster installed and only have it polling once per hour.

So is it better? Yes…
Is it usable? for me, I would say no. Unless there is some way to know when it loses its token.

So I would suggest adding a notice for when the token is lost.

Hi, I’m actually testing some minor tweaks to some parameters to make it even more stable but as I posted earlier the real connection issues are between ST and ecobee.

The device sends some some warnings about connection issues in verbose_trace. You may want to listen (subscribe) to this attribute for any connection issues…

Regards.

EDIT: I will send an update to all contributors as soon as my testing proves that the ā€œtweaksā€ I’ve made are reducing the number of ST exceptions…

Performance and reliability may vary from one user to another: a user with 6 ecobee3 told me today that they have been working for more than 1 week w/o any issues. But with the Chrismas season, there has been a peak of activity on the ST side, so it may explain some connection issues.

Yvesracine,

I really thought that the new method of using code on the Ecobee side would have eliminated the token issues. In reading the documentation you had pointed to earlier, the tokens are not supposed to expire for an hour after issue. When we lose a token, does that mean that the Smartthings platform was unable to talk to the Ecobee platform for more than an hour?

I really think it would be worthwhile to throw a notice on the phone when the token has expired. You mention subscribing to the log feed, I do not know how to do that. I mean, I can read it fine, but as far as subscribing to it and getting a notice when the token has expired is currently outside my skill set. Is there a tutorial or thread I can look for that shows examples of doing that? I tried searching for it based on what you posted, but all I get are your threads about the ecobee device and where it logs to.

Hi,

Just to recap:

  • As I said earlier, since December, ecobee has implemented new changes on its authorization servers as per:

https://www.ecobee.com/home/developer/api/documentation/v1/change-log.shtml

  • There seems to be new rate limiting policies on their authorization servers as well, but it’s not clear what they are. I’ve contacted ecobee about them, but with the Holidays, I haven’t gotten any responses from them yet.

  • If you lose the token, it probably means that ecobee has blocked your authorization token renewal due to their new rate limiting policies or your access token was not refreshed on time (as it lasts for one hour; not more).

  • I know for a fact that SmartThings is working with ecobee to solve the connection issues as Jody Albritton confirmed to me that they are experiencing the same connection issues with their stock ST device.

  • I opened a ticket (#171366) related to the connection issues and Jody has escalated it to the Engineering team.

  • In the meantime, I’m working on some tweaks to reduce the number of exceptions. This should not solve all the connection issues, but it will hopefully reduce their number even more.

  • Now, with the new code, there is no more Service Manager that can warn you of any connection issues (based on my testing, the Service Manager was interfering with the Http connections). By simplifying the architecture, the number of exceptions has been reduced significantly.

  • To detect if they are connection issues, you can simply list the events under https://graph.api.smartthings.com/device/list by clicking on the device, and you’ll see all the related verbose_trace events (the same events you can view by clicking on ā€˜recently’ in the ST app).

  • Otherwise, if you want to do it programatically, you may want to create a simple smartapp that subscribes to My Ecobee device’s verbose_trace attribute, parse the evt value and checks for exceptions, and notifies you if any.

Regards.

BTW, I can send you the new version I’m testing now so that you can beta test it at your site as well.

Just PM me your email address that you used for your paypal contribution (as I have several Stephens in my list)…

Regards.

OK, that was what I needed to know. Not sure if I am ready to tackle that one, I just got finished learning Java Script so I could make my own geofencing solution via a Google Apps script, which is working great!

Will do, more than happy to give it a go.

Thats the hurdle Im waiting at. Once the token exceptions are figured out/resolved, @yvesracine will receive my monies.

1 Like

If you want the connection issues to be solved, just contact ST support and report
this issue to them. It’s not my code that creates them.

Please stop adding the same comments to this thread.

Regards.

Well to be fair, people who ā€œpayā€ $15 probably want something that works consistently regardless of whether its issues are caused by your, SmartThings’ or Ecobee’s code.

As one who ā€œdonatedā€ previously and will probably do so again, I donated in appreciation of your efforts and contributions to the community. I encourage anyone else who appreciates custom development to donate as well. However I’m in the same boat as @CheezWiz. For me, the app isn’t really usable as much more than a novelty due to the reliability issues and my lack of desire to monitor/resolve them. While there might not be much you can do about it, its certainly a part of the $15 purchase price valuation discussion. While they may seem redundant, comments in the thread speaking to reliability likely provide value to those trying to decide if purchasing said app is right for them. I’d say they’re especially relevant since the name of the thread includes the phrase ā€œ(exceptions issues to be resolved)ā€ā€¦

Bottom line, If you’re only interested in paying $15 for something that reliably works you probably want to hold off. If you’re interested in supporting custom integration in the SmartThings/Ecobee space, purchasing this app for $15 is a great way to do so. Just my $.02

3 Likes

I agree. I donated to promote Yves work as well. I think that it is important that people understand where we’re at regardless of where the failure is occurring. People should be aware of these issues so that they can make an informed decision and to avoid harsh feelings post ā€œdonationā€.

I have no issue skipping a meal out at a restaurant to throw $15 in Yves direction, but some people might not be in the same frame of mind or situation.

Now, how do we report the platform issues in such a way as to provide a baseline for prioritization without spamming support? United we stand and all. But we don’t want to be an angry mob.

Edit: Happy new year everyone!

Hi,

I"ve been struggling for days to find the right balance between different parameters, but the fact of the matter is the following:

  • Reliability is not really attainable if the core ST platform itself is broken, and I believe that’s the main issue at hand here.

  • If you look at the standard quality metrics in a software, and you refer to some industry standards such as ISO 9126 (replaced by ISO 25010 since 2011):

http://www.cse.dcu.ie/essiscope/sm2/9126ref.html

I believe the main issue here is that DevConn (the core ST cloud platform) is so unstable that Maintainability is even more criticial than Reliability at this point.

ST should take a long hard look at their platform and should re-assess it in terms of Stability, Analyzability, Changeability, and Functional suitability first.

  • Reliability may come after ST has fixed their core development platform (DevConn). Reliability is usually just resolved with redundant hardware & software and techniques such as clustering & session replication.

  • I work in the Telecom industry, so 99.999% availability/reliability (around 5 minutes downtime per year) is not uncommon for the core Voice & Data Network elements. It costs a lot of money, but this can be achieved.

  • I doubt that ST is willing to invest that much money for the HA consumer market.

  • Based on my own experience, the current platform is deterministic at 60% at most (stability). Most of my routines (such as Good Night) work only 2 to 3 times a week, which qualifies (in my book) the platform to be quite unstable given the fact that we’re talking about processing which does not involve cloud-to-cloud integration, just internal stuff.

  • Under these conditions, any device or smartapp which involves cloud-to-cloud integration like My Ecobee device may be even more unstable as there are network latency, and some external servers involved. On top of it, timeouts and rate limiting constraints are applied by ST and there are currently no way for developers to control these timeouts and constraints (ex. http timeouts), which is critical especially for the cloud-to-cloud integration stuff.

  • I’ve been asking for more developer control for a while as per the following threads, but after some talks with the ST Head of Engineering, I don’t think that these capabilities will happen soon or will be even considered:

  • No practical developer’s guide is available, and the core development platform is not stable: the ST platform can react one way at one user location, but another way in a different user location. There are no beta servers we can test against, so everything has to be tested in a production environment which may cause more issues for other users…

  • Believe me, I’ve done some intensive testing, and the ST scheduling and queuing mechanisms are not predictable from one user to the next.

Here is my 2 cents:

  • ST should consider moving away from their own cloud container and use standard ones like Docker (Docker: Accelerated Container Application Development) or other similar solutions, so that they spend less time fixing things in their DevConn, and more time providing a decent UI app and more HA features for their users. I don’t know about you, but my ST app on Android crashes on a regular basis, and very often does not give me my list of smartapps under Home (this is the most current issue at the moment)…

  • In the meantime, I will try to ā€œtweakā€ some of my parameters to make My Ecobee device more stable, but it is quite hard to do so for a developer when there are no ā€˜Good ST Development Practices’ to be followed in order to achieve such stability.

Conclusion

  • I will continue to work to make MyEcobee device more stable in the coming weeks, but I’m also very dependent on some ST and ecobee backend issues over which I do not have any control.

EDIT: Happy New Year 2016, may this year be the right one for all ST users and thank you to all the contributors.

Regards.

2 Likes

While I appreciate your efforts here, the minute you turned your code into a commercial offering you also lost the ability to ask everyone to understand when things aren’t working. I get that ST, as a platform, can be a huge pain in the neck to work with. We’ve all had to deal with SmartApps and devices not working for hours/day/weeks/(months!) because of dumb backend ST issues. It’s something that comes with a platform that is largely supported by community efforts.

However, you’ve decided that you’d rather take your own code and turn it into a commercial endeavour. That is well and good and a perfectly reasonable approach. I’ll happily pay you the (very low) price you are asking, but only if I can know that it’s working. With your new model, I can’t access the code so I’m left to rely on people’s posts here.

You keep asking people to take their conversations elsewhere when it isn’t directly pertaining to how great your device and app are. If you want to run your own forum to support your own commercial efforts, then that too is totally within your rights. However, that’s not the case here. The ST forums are a community where people help each other. While you do own your code and can do with it as you please, you don’t own the community here.

For myself, I appreciate the comments from people who are having a hard time justifying the purchase, at any price, of a piece of software that’s known not to work. If it were an open, community-supported project that folks could install and test for their own use cases, you would get miles of slack from everyone involved. We all appreciate your efforts, but when you turned this into a commercial product you’ve lost a lot of that slack.

With payment comes expectations. Trying to shutdown people who don’t feel like you’ve met those expectations just feels like sour grapes.

2 Likes

@Luma,

Kavvy or Turbo02 is not on my list of contributors…So I do not think that your comments pertain to this specific case.

Regards.

EDIT: My app works, but due to ST-ecobee backend issues, it fails from time to time without any reason. Some users may run it for days without having any issues (which is better than before as it was only running for hours before).

This has been documented for quite a while here:

http://thingsthataresmart.wiki/index.php?title=My_Ecobee_Device#Known_issues

No, neither one is a paid licensee of your commercial software. I’m not either (yet, maybe when somebody reports that it works reliably). We are here discussing it in an open forum, and I find their input valuable. They aren’t just posting senseless crap, they are offering a different look at your commercial software solution. The open exchange of ideas is what makes this place useful to me. Your repeated attempts to persuade them to take it elsewhere isn’t valuable at all.

Again, you have the option of running your own forum to support your commercial endeavors. This isn’t that place, so I’d hope you’d understand that you’re left to take the positive responses with the negative.

1 Like

I have been following this and other threads closely. I just got an Ecobee a few weeks ago and was considering whether or not to purchase your code. I don’t mind contributing to your efforts but for the value I would just stick with the free solutions if your going to raise the price ā€œsignificantlyā€. You just lost me.

I wish you the best of luck and hope it works out for you.

That’s fine, I’m not trying to reach everybody…For some people, the free solutions may be enough.

Good luck to you.

You’re free to put a fair price on it, and I’ll still consider it once it’s in a working state. I fully acknowledge that it’s broken for reasons out of your control, but given that I have no way to test it myself, and it’s known to others not to work, I’m going to wait until a working version is available and reports from others confirm its long-term reliability.

I really do appreciate what you’re doing here, and I don’t think that charging for your work is bad. It simply changes our relationship in ways that I don’t think you’ve fully come to terms with. You’ve turned a community effort into a commercial product and that comes with expectations and commitments. Don’t be surprised when people treat your efforts differently now that you’ve put a price on them.

Hi Luma,

Just consider this: when you bought the ST hub kit, it costed you several hundred dollars, and then with all the other connected objects that you bought after, your initial investment is likely now several thousand dollars.

Given all the money you invested (BTW, I did the same), do you expect ST to guarantee you that it will work under any circumstances?

In fact, ST has several disclaimers in all its codebase, saying exactly this:

  • ā€œUnless required by applicable law or agreed to in writing, software distributed under the License is distributed on an ā€œAS ISā€ BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.ā€
  • ā€œWhile SmartThings supports multiple communications standards, including ZigBee and Z-Wave, we cannot guarantee the implementations of those standards by third party devices. Certain devices may not work, or may cease to work with SmartThings despite supporting the same standards. We provide no guarantee or warranty of compatibility for third party devices, even if we provide access to or resale of those devices through the SmartThings Mobile application or ThingStore.ā€

And again in their terms of use (see under What else do I need to know?, in all uppercase this time):

  • ā€œProducts and services purchased or offered through the Services are provided ā€œAS ISā€ and without any warranty of any kind from SmartThings or others, unless a separate written warranty is provided expressly and unambiguously for a specific product or service (and if such a warranty is provided, it will apply only to such specific product or service, and not to the Services generally). THE SERVICES (AND ALL PRODUCTS, SOFTWARE, SERVICES, INFORMATION AND CONTENT) ARE PROVIDED ON AN ā€œAS-ISā€ BASIS, WITHOUT WARRANTIES OR ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR THAT USE OF THE FOREGOING WILL BE UNINTERRUPTED OR ERROR-FREE.ā€

  • So, my business model is just following the ST business model, nothing less.

  • Actually, my contributors are likely to have more regular code improvements than regular ST users with the ST stock ecobee device. Nothing has changed for more than 18 months on that front, and it does not even support any ecobee3 features.

Again,just trying to defend my work here. For all contributors out there, stay tuned!

I paid you, just so I can continue to post in this thread (sarcasm).