I’m frustrated

API Limitations

I have to say, I'm a little disappointed with the API implementation, it's really not geared towards Home Automation use.
- The API should have allowed direct connection to the thermostat, not to the dot-com
- The API should have been a simple socket connection without http overhead
- The API should have allowed pushing of data changes to allow for real-time information. Your current polling strategy has a 85000 poll/month max, that's ~ every 30 minutes. Not very useful for home automation furnace status updates.

Hopefully I've misunderstood the documentation (which should have been a single PDF).
6 people have
this problem
+1
Reply
  • MarkK (API Architect) June 21, 2013 15:42
    Hi,

    Rather than argue the merits and faults of a specific implementation, I will explain why we made the choices we have made in the implementation of the API:

    1) Everything, absolutely everything speaks HTTP today. From embedded devices to PCs. HTTP has become the de-facto protocol in the interconnected world.

    2) We implemented a REST-like interface which has become the most common method of delivering API connectivity. JSON is a lightweight serialization protocol supported by all commonly used languages out there. It is also extremely common today, almost every API on the web uses it today.

    3) Industry standards were chosen because it is a common language everyone today speaks. It is easy to integrate with 3rd party services when they all speak the same language and operate in the similar ways.

    4) Polling is a scalability strategy which allows us to scale to millions+ requests. Push technology is expensive and would require on our part to ensure delivery, track state, etc. We choose to be light weight on our end so that we can continue to support millions of devices and 3rd party applications out there.

    5) The thermostat is already connected to our servers. This is how we provide data services (Home IQ). Our servers ensure that your thermostat is protected from attacks against it. It also does not require you to open any ports on your home firewall/router to communicate with your thermostat. This is a simpler and safer solution. It also makes our thermostat safer and stable by not including server code into it. It also makes us more agile by being able to update our servers much more quickly than we can with the thermostat device firmware. You get more quicker this way.

    6) PDF documentation gets out of date quickly. On the web you get the latest and greatest documentation every time you read it. If PDF is your forte, there are plugins and tools which can generate a PDF from a web site.

    I do not know where the 85000 requests per month comes from. We ask you do not poll for changes faster than every 30 seconds. I do not think that is unreasonable.

    Thanks,
    Mark
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited kidding, amused, unsure, silly sad, anxious, confused, frustrated indifferent, undecided, unconcerned

  • 85000 Points is here:
    https://www.ecobee.com/home/developer...
    Sorry that's 30s not 30min, which is adequate.

    For polling remote servers, absolutely REST/JSON is the way to go. But we shouldn't be polling. Push is only expensive remotely.

    A local socket push API is free to you and the user. It also provides a cleaner, faster, and more reliable home automation solution for power users and integrators.

    I love the Ecobee, I'm just disappointed that the API went the route it did.
    Browse the HA forums, I'm not alone.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I’m frustrated
    In my opinion, rpc/polling for getting real-time data is not a scalable strategy at all. From my experience, it is a much more resource-intensive architecture than a push/pub-sub architecture. Creating/tearing down connections is expensive. Database/cache hits required to service polls generate orders of magnitude larger loads and latencies than when a system can just distribute data in real-time as it receives/pulls it from the thermostats using a publish-subscribe messaging architecture.

    I see messaging as being much "lighter" than a polling architecture in every way. The persistence layer can just be another client to this architecture, historizing data as it is received.

    It seems to me that separating historical/persisted data and queries from real-time pub-sub would allow your system to grow much larger with less resources than a polling-only architecture used to simulate a true real-time api. In my opinion, this is a more modern architecture. And, of course there are a lot of proven, high-performance messaging platforms, both commercial and open source, that can handle all of the state/subscriptions/distribution as well as providing a variety of endpoints/protocols out of the box. The commercial messaging products are very expensive, but the open source alternatives are many and most are of high quality with long successful track records.

    Count me among the frustrated/disappointed about this strategy for the realtime/eventing part of the API. Of course, the choice for REST/Json for queries/commands is a very good one.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • > I do not know where the 85000 requests per month comes from. We
    > ask you do not poll for changes faster than every 30 seconds. I do not
    > think that is unreasonable.

    The 85,000/month comes from the API Agreement. 85,000 free quota per month, then $500/yr for an additional 170,000 queries per month: See Appendix B at https://www.ecobee.com/home/developer...

    I think that 30 second polling is more than reasonable for devices like this. Real-time updates are not that important for energy control devices where to-the-second state change notifications are not critical. I believe that a minute or two is more than good enough for most applications (at least it is in the application I am considering).

    However, lets assume for a moment that 30 second polling (120 queries per hour), is indeed necessary, the costs would the through the roof. For 1 user to poll at that rate, the API costs for 1 user would be over $230/year.

    See this cost spreadsheet: https://docs.google.com/spreadsheet/c...

    So, as I see it, by far the biggest problem with the Ecobee API is usage costs.

    Even for a very modest API query rate of 4 per hour, the cost per user is nearly $8 per user every year. The actual costs to Ecobee are a very very small fraction of this.

    I'd really like to get some feedback from Ecobee. The API pricing is geared towards hobbyists and utility companies that pay either nothing or a dramatically reduced rate for API access. It is simply not viable for real developers to build products around the Ecobee API.

    Also, see my previous unanswered question: http://developer.ecobee.com/api/topic...
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I’m sad
    FlyTheSky:

    I think you are hitting on the underlying reason for the decision - "Marketing". Some companies (like ecobee) are forcing users to be captive to their hosted solutions (and fees). This has a number of drawbacks including cost, security, reliability, etc.
    There are also benefits as MarkK as identified above. Each potential user must decide for themselves if the benefits of the hosted solution outweigh the drawbacks.

    I was interested in ecobee until I learned that we are forced to their web solution. Given that, it's definitely a non-starter for me. The search for a non-hosted, internet enabled TS will continue.....
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • 2
    I just recently bought the ecobee3, but then I realized to my disappointment that it doesn't currently support a local access API, but it doesn't have to be this way! Reading around in these forums, the biggest argument the ecobee staff is making for not including a local access API is for security reasons - most people not familiar with network security and having an open port on the ecobee3 isn't a good combination. And I realize that ecobee doesn't want to be liable for for any kind of hacks directly on the thermostats through such an open port.

    In my case (and for many others), as an IT professional, I want to have access to a local API in order to make my system *more* secure as I don't trust the cloud based API can be kept safe. If hackers can get into Sony's network and destroy their network, then they can theoretically also get into ecobee's network too. I'd like an opt in feature that enables local API mode (after accepting liability clause), and optionally disables all cloud based access.

    A local API can be implemented securely via https with authentication. As long as the hardware is capable, there is no excuse for not supporting a local API. It's no different than having a password protected router.

    So in summary, add a local API that's disabled by default (but can be enabled via opt in for advanced users), and password protect the API. Your users will love you, promote your product like crazy, your sales will soar, and your boss will notice and give you a good bonus.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited kidding, amused, unsure, silly sad, anxious, confused, frustrated indifferent, undecided, unconcerned

  • I tried to argue this a number of times with no luck (you'll notice this thread is marked as solved).
    Claiming a cloud API is more secure is ridiculous, ask Apple or Sony.

    Ecobee could have easily wrote a simple local socket interface for the stat in the amount of time we've spent arguing in this topic.
    They just don't want to.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • 1
    To say that opening up the thermostat to local access will at least maintain the same level of security, is a ludicrous thing to say. That is obvious.

    Besides, you will gain ZERO additional functionality and the device is designed to be permanently connected to the internet.

    You gain absolutely nothing from local access unless your thermostat isn't connected to the internet. And if it isn't connected to the internet, what is the point of having an Ecobee anyway?

    Sorry, folks. There isn't a solid case for local access except that you might feel more comfortable with direct local control.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • 1
    Reasons:
    - I don't want to trust ecobee's cloud or anyone else's. I have an automation controller that I connect to (directly, no cloud) which if we had a decent local API, could control the thermostat. Many home automation users connect directly to home automation controllers (no cloud).
    - Polling, ecobee's polling limitations
    - Zone control - getting real-time feedback to my automation controller so that I can adjust zone dampers based on temperature/humidity sensors and runtime. Also, if the cloud or my internet goes down, I can't get this functionality anymore (not the case with a local API)

    This is my last forum post/visit. This has become ridiculous.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • > Reasons:
    > - I don't want to trust ecobee's cloud or anyone else's. I have an
    > automation controller that I connect to (directly, no cloud) which
    > if we had a decent local API, could control the thermostat. Many
    > home automation users connect directly to home automation
    > controllers (no cloud).

    It sounds like you want an RS-232 thermostat, not an internet connected thermostat. Those are more suited to your application.

    > - Polling, ecobee's polling limitations

    Agreed, but for cost reasons only: this is a costly artificial limitation imposed by Ecobee, and is not dependant on local control.

    > - Zone control - getting real-time feedback to my automation
    > controller so that I can adjust zone dampers based on
    > temperature/humidity sensors and runtime. Also, if the cloud or
    > my internet goes down, I can't get this functionality anymore
    > (not the case with a local API)

    Really? A few seconds or even a minute lag is going to make a difference? I don't think so. Thermal inertia isn't that sensitive and your software should be predictive anyway.

    How often does the internet go down for you? It never does for me, and if it did, the internal thermostat program would handle temperature transitions just fine. If you are letting your controller make those decisions, you better have a super reliable home automation controller... and I have yet to see a home auto controller that is super reliable.

    Again. I don't feel you've made a case for local control.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited kidding, amused, unsure, silly sad, anxious, confused, frustrated indifferent, undecided, unconcerned

  • There are valid use cases for local control: home automation without internet access (for a cottage for example), better privacy (no data sent to the cloud, no chance for abuse of personal info), faster response times (no need to wait for polling cycle), better reliablity (still works when ecobee cloud services go down in a DOS attack), zero internet bandwidth usage (for people on low bandwidth internet connection, say 3G in remote areas).

    I don't deny that having a cloud based thermostat is the wrong approach. It's probably best for the majority of ecobee's customers and it should remain that way. However, for the minority technical users, we love control, we love privacy, we love speed, and for these we need local access. Having an option to turn this on would be awesome.

    The fact is I like the ecobee3 hardware features and design. There are other products on the market that offer direct local control, and yes I can use them instead.

    In my opinion, I think some of the reasons why ecobee wouldn't want to enable local access are:
    - not worth the effort to support a feature only a minority of users will use (unlikely as it's probably already implemented for development purposes),
    - lose the ability to track users
    - lose the possibility of future monetization through web based enhanced services

    I'd rather accept one of the above as an official reason why local access isn't supported. I don't buy into the security/safe/easy argument as those are things I can manage on my end.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • 2
    So glad I found this before buying an Ecobee thermostat. I love the internet, but requiring an internet connection for something that could be handled locally is a deal breaker.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • 1
    Thank god read this BEFORE buying. Been wanting to start to play with programming IOT stuff and read earlier notes on ecobee being really great on an API (pre ecobee3). This move to a cloud based (only) api while might be a great business plan that investors will love to hear, IS NOT what I want as my only choice for IOT. First, I need to be able to be disconnected and my house should still work, if my !@#$ charter box goes down, I'd like my windows to still be able to open up. Let alone, I don't want to get stuck with some company that 1) might go out of business, or worse 2) turn into another Charter who I have no choice but to pay.

    Let's move to MQTT type messaging where we all can tie into this stuff and do what we want. Sure if Ecobee wants to store stuff in the cloud great, nice business plan, BUT DON'T make it the ONLY choice. Don't try to tell us customers how it must be!
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I’m frustrated
    1
    @MarkK, cloud-only control is a poor design decision that will ultimately lead folks away from your product.

    @Tom Kamanski (above) has a great summary of reasons for allowing local control without requiring a cloud network.

    And, honestly, this draconian, cloud-only mindset really seems contrary to much of your companies espoused philosophy of openness and wide relevance for this device. Why are you maintaining this position?

    You must realize that your product is not that complicated. You are only in the first wave of IoT devices; it will be duplicated by others. If you remain locked into a cloud-only mindset, early adopters and key decision makers WILL help move away customers from your product.

    Add local network control ASAP. Fix this!
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • 1
    Well, let's see -- currently the ecobee servers are down for maintenance and have been ever since I wanted to change the temp. So, clearly a local API is not a waste at all -- so much for the guy with bulletproof internet and unshakable cloud-faith!



  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • Well I'm real happy to be reading this now, NOT.

    I definitely disagree with cloud only control as well for every reason stated above and more. Unfortunately unlike others I didn't read this until after I had purchased the ecobee Smart. Its been a while (pre Smart3) since I installed so there is no return route for me. I guess I'll end up yanking it out and replacing with another T-stat. really disappointed with this stat. Can't remember why I got it to begin with. I didn't want to go Nest and someone said this was a better stat.

    Oh well, live and learn. Maybe I'll see if I can work around it somehow. All I want to do is toggle in and out of QuickSave mode from my home automation controller. This should be 1-3 lines of code max. I don't plan on writing my own "app" for this simple task.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I’m frustrated
    Ya, still stuck with the thing here. It does alright, however it's not doing anything a cheap 7-day programmable couldn't do. I still can't control the dumb thing.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I'm also one of the ones who initially picked up on the API because I need zone control, but I don't think going up to the cloud and back every time is reliable enough to feed into my zone board to control dampers and booster fans.

    It's sad because after a lot of research, it seems that there are zero smart thermostat products out there with real support for multiple zone systems (I don't count when they all say to just put up 3,4 or 5 totally independent units in the house). The ecobee is so close though it kills me, it already has the nifty wireless room sensors and the software seems like it already organizes into 'zones' by default -- all it needs is some way to actually communicate that data to a zone board and it's a killer solution to a super annoying problem.

    Has anyone looked into hacking the ecobee hardware itself to get data/signals out? It's so frustrating to be so close to a perfect solution, but have no way for the ecobee to communicate its "virtual zones" out to my actual zones.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I’m frustrated
    I would also like a local API, which would be a lot safer since it can be completely contained within the LAN. No ports need to be opened. Then hacking, pooling vs push, servers up time, server hit limits, and many other issues would be gone. HTTP REST with JSON is fine. No one is arguing against it. Just also make a local API available for developers they we wouldn't need to hit your servers at all. Win win.

    The problem is that there is no competition in this space. I know of no other thermostat that has remote sensors with this much control. So we'll have to suffer with this poor remote API until someone builds something better.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I’m frustrated
    2
    Looks like Home Depot will be getting four ecobee3's back for a refund. What a shame. Such a good product being dumped for such a technologically lame reason. Shame on you ecobee!!
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I fully understand the reasoning why the Ecobee team has chosen for a centralized control & operation of their device(s).

    Nonetheless, I agree that a local API is very desirable for those with the right 'expertise'. My point is, it does not need to be one or the other. An (advanced) option to enable a local API would be sufficient. This allows the majority of users (and by default) to use the centralized portal. For those use-cases that prefer not to be dependent on a 3rd party website the local API can be enabled and they're on their own for providing (or not) remote access.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I’m sad
    Not having a local API is a big turn off. Non of the reasons presented by ecobee have an real merit.

    My greatest concern is having a half functional device if/when/after ecobee either A). goes out of business or B). gets sold. One of those two is going to happen eventually. B) is almost ALWAYS the goal of tech startups like this.

    A great example is Harmony remotes. They went from a very flexible full featured interface for programming the remotes to a brain dead poorly features web interface several years later.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I have to jump in and agree. I have an entire suite of home automation integrations including Philips Hue, Belkin, Amazon Echo and others. I call and access every single one of them through a local API integrated with my Amazon Echo application to allow for complete home control via voice both in and out of the home. I'm not a developer but well documented and local APIs are easy to use, easy to integrate and reliable. Every one of them works reliably except the Ecobee. It's 50% if lucky. Either a loss of connectivity, some kind of problem with either the refresh or access token requiring me to redo the application PIN or some other issue associated with not being able to access a local API. Unfortunately I'm beyond my return period with Best Buy but consider my investment here a total waste. Granted it's my fault for not doing the research, minus the unreliable connectivity, prior to purchasing but I took for granted a local API would exist. Totally disappointed...
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I’m frustrated
    I agree that Ecobee's servers are very unreliable and who knows how long they'll be around. They drop all the time for me or can't log in periodically. Why not add a simple low level local API on top of the current system. The simple user that don't know better can use the current system while us power users can use the local API which can be a very simple REST Web API.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I’m disappointed.
    I would think the company would be in a fabulous position to align with all platforms including Alexa (Amazon) and soon to be, Google Home.

    To allow localhost queries would make this the best thermostat out there. Managing queries allows the company to sell this aggregate data to big companies and systems but in the long run, a nightmare to manage hosting. Maybe they're looking to be bought or have a large partnership? I dunno. But more and more people are looking to be secure. And people are starting to notice that it is idiotic to go out to the Internet to turn off a lightbulb in your house, three feet away.

    So yes, again, please offer a localhost API to query and change data on the Ecobee3. Or, if you must keep your secret sauce secret, then offer a blob plug-in to OpenHAB, FreeNAS, etc. Or make us pay for it. (registration to use, license, etc.) I don't mind putting beer money in your pockets after paying for the hardware and system; it comes with the territory. But when you open the Ecobee3 to local control, you will have positioned your system to being the best. And with very little loss of dollars to you.

    Because you know, you could give small controls while keeping some for your cloud API. Or better yet, leverage your cloud API to connect users to HVAC manufacturers (runtime data of their systems) and connect users to their local HVAC repair company. I'd bet some local repair guys would love to see diagnostics before they even ventured out to the site.

    It all fits, local and cloud, if you would just extend an API to localhosts.

    PLEASE!
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited kidding, amused, unsure, silly sad, anxious, confused, frustrated indifferent, undecided, unconcerned

  • No local API, if only I knew before I bought this device. The quality of the advice I received during installation (of which if I followed would have costed me big $s) was enough for me to not recommend this product. Now no local API, why is ecobee silent on this issue? Obviously their user base is still concerned.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I’m frustrated
    What's worse is that their cloud service lately has had constant up time problems and login issues. Every week and sometimes more, I can't connect to it and control my thermostat because of their undependable cloud service.

    Most of my day is spent in my studio on the second floor of my house with the thermostat on the first floor. I always keep a browser open on one of my monitors so I can control or monitor as needed. But since the service is so spoty due to the LACK OF LOCAL API, I constantly have to go downstairs to control through thermostat itself. Total pain in the ass.

    All could be solved with a local API.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I’m confused
    Yep. Shopping for a replacement for my cloud-based thermostat due to outages lately, and was hopeful that this was the one that let me hit it with LAN requests. Welp, continuing on...
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I’m frustrated
    1
    Let us know if you find another thermostat with remote sensors and local API. I think I'm going to have to ditch Ecobee since they are not listening to their customers.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • While I've not confirmed it, I just thought I read about the latest release of code for the wink hub... looks like they now have local control as part of the SDK. And the thing is still rootable.... I believe there is some activity in openhab towards utilizing such items with (all the radios) and scripting to control those annoying zigbee/zwave thingys.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I’m frustrated
    Was about to buy one of this in Amazon until i read there is no way for local control, no through the wifi connection or even a z-wave add-on. I want to be able to tie the device to my home automation controller and not be limited by polling rates and be on the mercy of outside servers.

    This issue is not solved!
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I need four thermostats for different zones in my home, and I was going to purchase until I realized there is no local control. I need a local, reliable system. Cloud connections are great for convenience, but they are notoriously unreliable and commands are slow for home control compared to local access.

    The only reason I'm writing this is that I like the device enough that I'd like it to work. At this point, it just needs this one small feature.

    I'd be willing to write the feature and contribute it!
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I have three zones and would have bought several units - They are well designed little systems. With the dependence on a third party cloud service and no local API - that is a deal-breaker. I'm sure your cloud service is more secure (at the moment) than most of your customers households. I'm guessing that they have mechanisms in place to push out firmware updates - solving an obsolete-on-arrival issue with IoT devices, but failure to integrate locally with other systems is a mistake.

    Ecobee's faith in it's cloud security is misunderstood. If a household is compromised, one device is vulnerable - not good. If your cloud systems are compromised - that opens up hundreds of thousands of devices - which represents WAY more risk.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited

  • My extended family, on my recommendation, owns 16 of these thermostats. I am now writing integrated home control software and have been very disappointed with ecobee's integration behavior. My app polls the API, and I guess too frequently because it seems that ecobee has blocked my IP address from their server.

    There should be a local push API like most of the best home automation products have, and in the absence of that, comparably responsive cloud polling workarounds are not allowed.

    Very disappointed customer, I'll be taking my business elsewhere unless ecobee can offer me a viable solution. I'm personally responsible for $4k in ecobee sales and would have been more in the future.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated happy, confident, thankful, excited