Ecobee API - Usage Limits & Costs

I really like this API and I would like to develop some mobile software around it. As we all know, it's hard to make money in the mobile space when users are used to paying one time fees of $0.99 for an app. Price is a major consideration.

The API works very well -- it's fast, the functionality is great, and the implementation is really good (status reporting, tracking of updated data etc), but I'm also hoping for realtime-ish updates at some point.

My questions are related to API usage costs:

1. Are token refresh requests counted towards API usage?
2. Are thermostat polling requests counted towards API usage?

These are extremely important numbers because the annual cost per user is approx $1.50 - $2.00/year for just 1 query per hour (assumes 85,000 free queries per month).

If token requests and polling are counted towards usage, then the cost at least triples to $4.50 - $6.00 per user (3 queries per hour = token + polling + just 1 actual query).

And if, say 6 queries are made per hour then the cost jumps up to around $11.67/user/yr (with $2000 API fees to support just 171 users) and it's a nearly impossible to win customers at that price point.

Bottom line: I would love to see a price point that encourages API development -- this would enrich the Ecobee ecosystem, encourage more consumers to purchase Ecobee thermostats, and we could all make a little money.

Thanks!
Rori
1 person has
this question
+1
Reply
  • Should I assume that no response from Ecobee means that token requests are counted as API query usage. And the same thing for thermostat summary (revision) requests?
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

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

  • If I have a multi-tenant building with 200 ecobee thermostats and they are communicating with WIFI that uses a private IP space, how can I communicate with the devices directly using an API or command port associated with a given thermostat's private IP address. I cannot see value in having to communicate with a device through a third-party site, i.e. ecobee's, but in my readying of the API leads me to believe that to be the case. What am I missing here? What is the value of having an API that does not communicate directly with the devices?
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

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

  • Is ecobee ever going to definitely answer this question?
    I continually get people wanting to but a stat and use my program and right now I tell them not to.

    - What's the max number of polls per client per timeframe?
    - What's the max frequency of polls per client?
    - What polls are and are not included in the quota?
    - Does the stat summary with equipment status cost against the quota?
    - What's you're suggestion for getting "realtime-ish" system status to an app?
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

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

  • All requests, other than token refresh requests, will count towards your quota. This includes thermostat polls (thermosatSummary/) calls.

    We do not currently rate limit API calls, but reserve the right to do so in the future to protect our other API users. Our recommendation is to not poll any more frequent than once per 10 secs. On average, a round trip of a thermostat change (from an API client, to our servers, to the thermostat, and back from the thermostat) can take 6-10 seconds so polling at a faster frequency than that yields no real benefit.

    For "realtime-ish" status our own ecobee apps poll at a frequency of once every 20 seconds and ramp up to once every 6 seconds when we are waiting for confirmation of a change just submitted. Once the change has been confirmed we back off to the 20 sec poll rate. We also do not poll like this 24/7. You only need to provide this realtime response if a user is physically interacting with your application. Hence we only poll in bursts when users are utilizing our apps, and then either halt polling entirely, or poll at a much much lower rate. Typical bursts are for 10-15 minute durations once or twice a day per user, correlating to each time they interact with our app.

    If your app is truly providing 24/7 monitoring of thermostats then it is not unreasonable to incur some costs associated with the volume of calls, and for users to bear this cost for the 24/7 service they are being offered.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

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

  • First,
    Thank you for your reply, some great info in there.

    My app would be polling 24/7 and I don't believe it should be considered unreasonable.
    My app is strictly for home automation integration. I've asked many times for a local API to be available but it doesn't look like that's in the cards.
    How can a user make his HVAC dampers react to a cooling cycle if he can't see device status in "real-time-ish"?
    I'm struggling to see a use for this API otherwise.
    • I'm sorry that you feel our solution doesn't meet your needs. Unfortunately it is hard to make a product that will work for everyone. For ecobee, one of our number 1 priorities is to ensure that security is never compromised. It is for this reason we have not designed our product with a local API.

      There are likely a ton of arguments that can be made either way, but our philosophy is that having the thermostat run open ports that can accept inbound requests just creates a huge attack vector that can (and ultimately will) be exploited.

      While tech savvy users, like yourself, will know very well how to secure their home networks to prevent such attacks, the bulk of our user base is not as tech savvy. The risk is too high to have even just one ecobee thermostat compromised, and it is a risk ecobee is choosing not to take.

      Regarding your use case of controlling HVAC dampers, one thing to consider is that HVAC cooling equipment has minimum on and off running times. So there is no need to poll constantly as it will provide little value. If the cooling just came on, then your next poll only needs to occur after the min on time has expired (usually 5 mins) as well as any additional fan dissipation time. Likewise, if a cooling cycle has just stopped, there is no need to poll until the minimum off time has expired.

      There are probably a bunch of other optimizations you can make, such as comparing the current indoor temp with the set dead band to determine if a cooling cycle is likely to kick in or not. We can definitely discuss such ideas on a separate thread if you are interested.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

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

  • I appreciate the response from Ecobee, but the fact remains that there is virtually no opportunity to build a viable software product around Ecobee due to API usage costs.

    I thought the numbers I laid out clearly illustrate that.

    I've long since abandoned any hope of developing software around Ecobee thermostats - it's simply not commercially viable. I don't see this as being anything more than a hobbyists API and looking at the lack of software available, I think that has already been proven.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

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

  • It is clear that Ecobee has no interest at this time in having their products integrate with software that manages homes or facilities. I believe it is a very short-sighted strategy that will ultimately fail. Once the market pressures are more apparent to Ecobee and it reverses its strategy, Ecobee will be late to the game. Companies like Network Thermostats and VenStar will likely give Ecobee a run for itsmoney as these two competitors get more sophisticated with their marketing abilities.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

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

  • While everyone is entitled to their opinions, it is not appropriate or fair for people to spread misinformation via this forum.

    To state that there are no credible home automation platforms using the API is plain false. I would suggest that readers take a look at the SmartThings (https://www.youtube.com/watch?v=e1hOR...), MiCasaVerde(http://watou.github.io/vera-ecobee/) and Control4 (https://www.thedriverslab.com/product...) integrations that are readily available, and built 100% upon the ecobee API. These are all very popular home automation systems.

    There are also developers who created a windows phone app for ecobee (http://www.windowsphone.com/en-us/sto...), again using the public ecobee API.

    As an additional data point, Channel Parity developed a hotel/rental property management system that ties into the ecobee thermostat to control room comfort and maximize energy savings, and is utilizing this across many properties in the US.

    There are several other examples to provide, and we would be happy to share these with the community here.

    ecobee is fully committed to supporting the API, however the economics have to also make sense as well. It is not unreasonable to require usage fees to compensate the overhead of having particular apps make a high level of API calls. Most reputable API providers do this as well, such as the Google Maps API. This allows us to maintain the high availability of our API's and offset the costs of this, with honestly almost zero profit.

    While I agree that the economics may not suit a $0.99 app, they do work for many more substantial applications, and frankly that is the market we would like to foster to create a real ecosystem of credible platforms ecobee users can connect their thermostats too.

    Finally, I'd also like to say that no one at ecobee has ever closed the door to a discussion about supporting a particular app. If any of you have a true business case for a great app, but the economics don't work, you can always reach out to us to discuss alternative ways we can make your app succeed.

    Let's continue to make this community about fostering success rather than misinforming others.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

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

  • It is not misinformation - I am trying to explain something to you, and your impulse is to call me a liar.

    You need to go take a look at your internal data - how many PAYING API customers do you have, and are those PAYING API customers helping to sell Ecobee thermostats because of the value they add? I already know what you will find.

    Why not say you're not really interested in making the API easily accessible? It isn't that hard to do. For example, the MicCasaVerde example you gave above requires that the user sign up for a DEVELOPER account - a DEVELOPER account!! Furthermore, that plugin doesn't even work with the latest family of Vera controllers...

    As I have said, I like Ecobee and I think the API is great. But it's useless for commercial development as far as I am concerned, and once again... I believe that market penetration of your API proves me right.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

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

  • I was in the same boat. In order to get a "realtime" program for home automation I need to poll an amount that ecobee doesn't like. My app is free so I'm not about to pay API fees.
    I was close to making users create developer keys to run my program.

    I've since given up.
    If ecobee would allow say a 60s poll rate then I'll jump back in, I'm not about to make a dynamic poll rate to tweak based on various times of day and furnace settings.
    My app is used to turn on dampers and alert users of status - it needs to be quick.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

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