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.