Ecobee WiFi Thermostat

Posted on
Sat Nov 01, 2008 9:42 am
saklad offline
Posts: 12
Joined: Jan 16, 2004
Location: San Antonio

Ecobee WiFi Thermostat

Does anyone know if Indigo could be used to interface with the new Ecobee WiFi thermostat that will be available early next year?

Steve

Posted on
Sun Nov 09, 2008 11:30 am
Jann offline
Posts: 120
Joined: Mar 12, 2006
Location: Auburndale, FL

(No subject)

Currently it cannot as Indigo only supports Insteon and/or X10.

Whether their product can or will present an obvious interface that Matt can use to read/write to and from the device has yet to be seen.

I would prefer that Indigo *not* talk to something like this -- instead I would prefer that Matt keep to the Insteon/X10 line and--if adding protocols--would add UPB and/or Wireless Protocols like ZWave. But that is only if he branches out the code to include other methods. There is NOTHING wrong with you, as a programmer (if you are) using Applescript to get/set variables for this 'stat from within Indigo, though. We have to see what kind of interfacing with outside programs that this unit defines.

Jann

Posted on
Sun Nov 09, 2008 3:54 pm
anode offline
Posts: 697
Joined: May 27, 2007
Location: NC

(No subject)

Using applescript is fine and dandy, *if* the 'other' app/device supports it also. (and the user is OK with programing)

Adding in more protocols isn't a bad thing. Limiting them, limits the audience.
Got a hydrogen car? Can't get fuel for them everywhere, hence they aren't sold in any numbers.

Matt is running a biz. Times are tough. To exclude or limit an audience isn't the best idea if done intentionally. (technological limits and NDAs can play a part)

Indigo is *awesome* and he does add stuff. Look at the w800rf32. Where does that fit in?


Jann wrote:
Currently it cannot as Indigo only supports Insteon and/or X10.

Whether their product can or will present an obvious interface that Matt can use to read/write to and from the device has yet to be seen.

I would prefer that Indigo *not* talk to something like this -- instead I would prefer that Matt keep to the Insteon/X10 line and--if adding protocols--would add UPB and/or Wireless Protocols like ZWave. But that is only if he branches out the code to include other methods. There is NOTHING wrong with you, as a programmer (if you are) using Applescript to get/set variables for this 'stat from within Indigo, though. We have to see what kind of interfacing with outside programs that this unit defines.

Jann

Posted on
Sun Nov 09, 2008 7:00 pm
bjojade offline
Posts: 285
Joined: Aug 03, 2005
Location: Wausau, WI

(No subject)

I'd love to see the program expanded to talk to other devices without having to always resort to AppleScript. However, it's important to keep focus and when a device is implemented, it's done in a complete and quality fashion. I think that's been the case so far. Keep up the great work!

Brian Jojade
HappyMac Digital Electronics
http://www.happymacshop.com

Posted on
Sun Nov 09, 2008 7:09 pm
anode offline
Posts: 697
Joined: May 27, 2007
Location: NC

(No subject)

Matt has done an wonderful job on Indigo. Its *fully* aplescriptable, such is a Godsend. I liked the xtend product, but that was only applecript. (and device dated) Indigo gave me the transition aspect (and with that in ind, at a better price)

Its a clean IF for all the power. Hard to balance the IF with features (I have done programing, and can understand that aspect) Very little on my wish list.

Posted on
Sun Nov 09, 2008 8:49 pm
Jann offline
Posts: 120
Joined: Mar 12, 2006
Location: Auburndale, FL

(No subject)

Please don't get me wrong. I think Indigo *can* be extended...just extend it intelligently.

We are *still* seeing further Insteon integration in Indigo (as well as X10 updates to new X10 modules -- still waiting for FULL EZX10RF Link Management support, Matt). I just would like to see it done smartly in a method that stays true to what Indigo was meant to be. (If I am speaking out of turn, Matt, please clobber me) but it would seem that versus coding for 1 item in it's own format of speaking is not the smartest way to go. As a programmer myself I look for the greatest return on investment. That return (to me) would be to extend this to other full product lines such as UPB, ZWave, ZigBee, etc. That way, once you code for one switch, most switches of that type "just work". Think programming for a plug in light controller...all outlet type devices are now much easier to add since you have a 'base' to work from. This is why, for instance, that it does not matter whether you use a Levitan or X10 switch, since Matt coded for one already, the other was much easier to add to Indigo. You get a larger return on investment with your user base.

For instance, supporting this thermostat would do several things right-off, not all of them good.

You would have to include either a Kludge or an "Ecobee" engine in and of itself to "speak" the device's language.

You would need a way to let people know that when they are dealing with this device it may have different results and therefore the troubleshooting would be harder for the user. (wifi connectivity vs simple power line interface issues for example).

You are also then placing this "new device" in front of the other "formats" for support. This is purely political. Do you wish to tick off all those waiting for UPB and instead do this add-on? We all waited nice and long for Matt to finish his Linking protocols for Insteon. Many many of us upgraded simply for Insteon Link Management. Does the EcoBee have that kind of following?

If Indigo actually supported other formats such as UPB, it could be used to "bridge" the format languages such that we all could have access to the devices on the "other side". For instance for the UPB people that want to use the less-expensive Insteon for a few purposes when there is no UPB alternative I can see that Indigo *could* be made to be the interpreter. Since UPB still has no RF, this opens up a whole new world for the UPB owners. Conversely Insteon/X10 owners could use long-distance UPB adapters for controlling lawn lighting, garage items, etc (those items that are longer distance than the RF/PowerLine Mesh technology of Insteon would normally allow)


To "anode's" "Times are Tough" statement I would only add that opening up a program such as Indigo to an entirely new audience of "UPB","Zwave", or "ZigBee" owners is, in the long run, a much better investment in programming time cos you then have opened up your audience to a purchaser of an entire product line versus an audience simply buying a thermostat.

Plus, it would give Norm an entire new product line to sell that is Indigo compatible! The elephant in the room that no one really speaks of (that we understand and appreciate though) is that Norm at MacHomeStore.com makes a living off of product lines -- not necessarily products in and of themselves. It may be good for us to be able to buy the EcoBee at MacHomeStore.com and use it in Indigo, but if it is only one item that Matt adds, the audience for Norm is *much* smaller. Think for a second: Would the Venstar T1700 or T1900 Thermostat & Insteon Adapter sell better than a EcoBee Thermostat? Well, if the buyer has a bunch of Insteon or X10 devices, they are more likely to purchase the Venstar devices because they ARE Insteon compatible (as I did this week -- I love it!). Thus, the investment that Matt made in adding this device (thanks Matt!) to Indigo *and* the investment that Norm made in stocking the Venstar devices is truly working for both of them. Their businesses feed off each other -- even if they were not designed to. (Sounds like a really good affiliate relationship Matt!)

In short, don't be offended that I took the tack that I did. I was just trying to say that it is better to support a format than a product.

Jann

Again, I am not trying to speak for Matt. He probably has opinions that are directly opposite from mine. I am just stating a few things that I think go toward supporting "Formats" and not "Products"

Posted on
Tue Nov 11, 2008 12:04 pm
matt (support) offline
Site Admin
User avatar
Posts: 21411
Joined: Jan 27, 2003
Location: Texas

(No subject)

I think all of these points are valid. Adding additional hardware support and protocol support obviously increases the value of Indigo.

That said, supporting new hardware (and especially protocols) thoroughly and with a user-friendly UI is much more time consuming than one might think. For example, adding support for the Ecobee is probably not worth the development cost. That is, the additional revenue it would bring to us (new Indigo sales) is much less than the cost of the development hours to support it. Hacking something in that communicates or sends commands to particular hardware is quick and easy, but extending that to be fully integrated into Indigo is not. There are several different aspects of supporting new hardware, such as:
  • Communicating with the hardware (protocol layer)
  • Handling all the failure cases appropriately
  • Mirroring state information from the hardware in Indigo (ex: polling)
  • Trigger Actions based on state changes
  • Actions to control the hardware
  • State inspection on Control Pages
  • AppleScript support for the hardware
  • ...

Now some of that is already done since Indigo supports the Venstar Thermostat already. But there will definitely be several differences in what the Ecobee supports compared to the Venstar. As always, the devil is in the details.

Anyhow, one huge goal for us is to improve Indigo's plug-in architecture. Currently we have fairly thorough AppleScript support for commanding devices and inspecting states, AND we have the IndigoWebServer plug-in model. But we need a hardware plug-in architecture to make it easier to extend Indigo to support new hardware and even protocols. Having such an architecture will make it easier for me and others to add new support to Indigo, so it is a very high priority for us. But right now I need to get back to that iPhone programming. :-)

Image

Posted on
Wed Nov 12, 2008 8:14 pm
anode offline
Posts: 697
Joined: May 27, 2007
Location: NC

(No subject)

Oh I can agree with much of it too.

Adding support for a single item is kinda pointless, unless its *really* cool. Now for a family of devices, its more enticing.

(I'm fiddling with trying to get MODus/TCP working under the Mac)

Posted on
Fri Jan 30, 2009 1:21 pm
jguinn offline
Posts: 27
Joined: Dec 21, 2005

(No subject)

So now that the Ecobee thermostat is available for purchase, I am really curious to see if it can do anything that Indigo + the Venstar package can't do. If anyone has a few hundred dollars that you want to use up, I'm sure there are some other forum members that would love to see a head-to-head comparison! :D

Posted on
Fri Jan 30, 2009 2:56 pm
anode offline
Posts: 697
Joined: May 27, 2007
Location: NC

(No subject)

jguinn wrote:
So now that the Ecobee thermostat is available for purchase, I am really curious to see if it can do anything that Indigo + the Venstar package can't do. If anyone has a few hundred dollars that you want to use up, I'm sure there are some other forum members that would love to see a head-to-head comparison! :D


Actually, I'm rather happy with a EZIOS8A and multiple DS18B20 scattered around. Gives me more zone control (will add dampers soon) and I do get hours on the filter. Only thing I'm missing (currently) is RH in the zones.

Posted on
Fri May 15, 2009 11:55 am
alangraham999 offline
Posts: 43
Joined: Apr 25, 2008

(No subject)

I'm probably the only person in here who has an Ecobee...so I'll address it a bit...

The trick here isn't programming support for Ecobee...but Ecobee creating it for Insteon.

Ecobee supporting Insteon opens up more users than the other way around. I actually love the thermostat...it's actually very impressive and the value of having it work with Indigo is something I'd like to see as having a device like Ecobee (which can learn from your behavior and help you curb energy usage) can be crucial from both a cost and environmental standpoint.

While Indigo is awesome, it isn't a tool for analyzing energy usage...and the Ecobee is already built to talk with smart meters...what would be ideal is having Ecobee be able to adjust energy usage working with Insteon and Indigo...but I see Indigo as a controller...not a tool for analysis.

---------

One feature in Ecobee is the quick save rollback button which you hit on the way out the door to rollback the temperature...I'd love to hit that button and it also turn off the lights/appliances, and sets the security system.

Posted on
Thu Apr 07, 2016 7:13 pm
General Custer offline
Posts: 18
Joined: May 08, 2009

Re: Ecobee WiFi Thermostat

Where do i go in the ecobee site to enter the PIN number?

Posted on
Fri Apr 08, 2016 4:40 pm
decahill offline
Posts: 7
Joined: Nov 16, 2009
Location: Arizona

Re: Ecobee WiFi Thermostat

See attached for screen shots.

Steps to enter the PIN:
Login at ecobee.com
Click on the "lines" at the top right of your screen (this should bring up the menu where you can view Your Account, etc.)
Click on "My Apps"
Click on "Add Application" (this will open up the field "Enter code" where you enter the PIN you received from the ecobee plugin configuration screen.)
Click on "Validate"

You should then see "Indigo plugin by jdhorne" show up on the left side of your screen.
Go back to Indigo and refresh your credentials. This will fill in your Access Token, Authorization Code, and Refresh Token.
That should do it.
Attachments
Screen Shot 2016-04-08 at 3.24.44 PM.png
Click on the "Menu" in the upper right....
Screen Shot 2016-04-08 at 3.24.44 PM.png (21.9 KiB) Viewed 14728 times
Screen Shot 2016-04-08 at 3.26.01 PM.png
Click on "My Apps"...
Screen Shot 2016-04-08 at 3.26.01 PM.png (26.19 KiB) Viewed 14728 times
Screen Shot 2016-04-08 at 3.26.59 PM.png
Add Application, enter the PIN, and Validate....
Screen Shot 2016-04-08 at 3.26.59 PM.png (51.43 KiB) Viewed 14728 times

Posted on
Mon Nov 06, 2017 11:36 pm
koensayr offline
Posts: 90
Joined: Jul 10, 2013

Re: Ecobee WiFi Thermostat

Is this plugin still being updated? After I've merged PR 10 manually in my branch it seems to work quite well.

Posted on
Tue Nov 28, 2017 5:03 pm
allengray offline
Posts: 13
Joined: Jan 24, 2014

Re: Ecobee WiFi Thermostat

Code: Select all
Traceback (most recent call last):
File "plugin.py", line 286, in actionControlThermostat
File "plugin.py", line 340, in _handleChangeSetpointAction
ValueError: zero length field name in format

Is this plugin under active maintenance and/or development? I can submit a patch that fixes the "zero length field name in format" python error shown below.

While upgrading to Indigo 7 is a possible workaround, but the patch would make it work for earlier Indigo users and python2.6, etc.

Let me know!

--
Allen Gray

Who is online

Users browsing this forum: No registered users and 15 guests