We will be working on making changes to the plugin to reduce polling to Ecobee servers in hopes that @Michel Kohanim can negotiate a deal with them. We can temporarily switch to another API key if anyone wants to give it out once we reduce polling.

On 4/26/2026 at 7:43 PM, Jimbo.Automates said:

We will be working on making changes to the plugin to reduce polling to Ecobee servers in hopes that @Michel Kohanim can negotiate a deal with them. We can temporarily switch to another API key if anyone wants to give it out once we reduce polling.

After all the algorithms I have use to control temperature ramping down during heating, and temperature ramping up during A/C (no brand does this), I ended up only using my third ecobee for Home/Vacation status.
It was a much more reliable status than any other method I had fund in years of experimenting. Hopefully this status will survive as it demands only one status point, unlike weather with it's dozens of analogue points.

ecobee has been the best stat I have used for HVAC from almost a dozen brands, so far. No the brand has had the accuracy of control, yet.

Best of luck with this. Your PG2/3 bridge plug-in has been the best.

On 4/26/2026 at 7:43 PM, Jimbo.Automates said:

We will be working on making changes to the plugin to reduce polling to Ecobee servers in hopes that @Michel Kohanim can negotiate a deal with them. We can temporarily switch to another API key if anyone wants to give it out once we reduce polling.

@Jimbo.Automates I don’t know if this is a valid concern or not, but I wanted to put it out there. With the old plugin there are changes to the thermostat settings made in IoX that take minutes for them to traverse from the plugin-> Ecobee via API -> back to my thermostat. With what you are working on… will reducing polling result in increasing the delays that I already see?

48 minutes ago, ISY4Me said:

@Jimbo.Automates I don’t know if this is a valid concern or not, but I wanted to put it out there. With the old plugin there are changes to the thermostat settings made in IoX that take minutes for them to traverse from the plugin-> Ecobee via API -> back to my thermostat. With what you are working on… will reducing polling result in increasing the delays that I already see?

That's an Ecobee limitation. We are only allowed to poll their servers every three minutes. The reduced polling will not change this, it only changed some other cases were that polling could be done more often. But, after making major code changes and sending a proposal to Ecobee asking them to give us back access, they haven't even respond to emails.

There are unconfirmed rumors that they would implement Matter support, but they won't answer questions about that either.

So, I'm actually working on a better solution. Developing a HomeKit plugin, which is done but undergoing testing and hardening for a beta release hopefully this weekend. This will allow you to connect the Ecobee to the HomeKit plugin. But if you rely on using HomeKit currently for Ecobee control, you can't have both...

Then major changes to the Ecobee plugin to talk to the HomeKit plugin to get Ecobee data.

The nice part is changes are reflected back to IoX very quickly.

But this has been a huge development effort so far and I haven't even started on the Ecobee side yet, so will have to really think about the price, it won't be a free upgrade.

@Jimbo.Automates Thank you for the update.

I am temporarily using IoX married with an Ecobee HA Integration w/API (no version of HomeKit ever installed). The HA Ecobee Integration is doing all the hardware control and all the logic is being done in IoX… so those delays are still being experienced, as would be expected. Hopefully just a temporary fix, but it allowed everything to continue to function.

Bringing HomeKit into PG3 while still using a version of the Ecobee PlugIn sounds like a cool solution. I look forward to the updates.

Thank you for all the work and support.

I went with the eisy hub specifically because Elk M1 lost the ability to integrate with other thermostats. UD was able to provide the thermostat/alarm integration I previously had so I can change my setpoints based on my alarm arm status and also by time of day. I hope there is a solution soon to get Ecobee working again.

The Homekit and Ecobee plugins have been released to beta, but require an update of IoX that is not available yet. But for the adventurous I can provide instructions on how to get it working if you PM me. In the meantime check out the release information

GitHub

udi-poly-homekit/README.md at 5c1294fcc22b8aab06ae32c8251...

Polyglot PG3x Node Server: HomeKit Accessory Protocol (HAP) controller hub with a local WebSocket API for other Node Servers (e.g. `udi-poly-ecobee` in Local mode). - jimboca/udi-poly-homekit

GitHub

udi-poly-homekit/CONFIG.md at 5c1294fcc22b8aab06ae32c8251...

Polyglot PG3x Node Server: HomeKit Accessory Protocol (HAP) controller hub with a local WebSocket API for other Node Servers (e.g. `udi-poly-ecobee` in Local mode). - jimboca/udi-poly-homekit

https://github.com/UniversalDevicesInc-PG3/udi-poly-ecobee/blob/e3bb3624872b167209d912efba1e003c82c22099/README.md

GitHub

udi-poly-ecobee/CONFIG.md at e3bb3624872b167209d912efba1e...

Contribute to UniversalDevicesInc-PG3/udi-poly-ecobee development by creating an account on GitHub.

From the ecobee status webpage.

"Scheduled - On May 6, 2026 from 9:00am-10:00 EDT, we’ll be performing some scheduled improvements. The important thing to know is that ecobee thermostats will continue to operate as usual on the set schedule and by manual adjustment, including all in-progress energy-savings events. There’s a chance that the ecobee app, web portal and third-party apps might be temporarily unavailable. Thanks for your patience and sorry for any inconvenience!

May 5, 09:13 EDT"

I read over the Github pages and the way I understand it the Homekit plugin is going to act as an Apple hub so it will be OK that I do not have any Apple devices and this will still work?

3 minutes ago, tazman said:

I read over the Github pages and the way I understand it the Homekit plugin is going to act as an Apple hub so it will be OK that I do not have any Apple devices and this will still work?

Correct

1 hour ago, tazman said:

I read over the Github pages and the way I understand it the Homekit plugin is going to act as an Apple hub so it will be OK that I do not have any Apple devices and this will still work?

I've updated the readme to give this info: https://github.com/jimboca/udi-poly-homekit/blob/beta/README.md

Hopefully more clear now.

2 hours ago, Jimbo.Automates said:

I've updated the readme to give this info: https://github.com/jimboca/udi-poly-homekit/blob/beta/README.md

Hopefully more clear now.

Thanks for the update I think that is spelled out very well now to make it more clear. I look forward to getting things back to normal when it is all straightened out.

On 4/22/2026 at 3:24 PM, paulbates said:

That's what HA HomeKit Integration uses and is very much limited by HomeKit Accessory Protocol (HAP), which is Apple's definition of a thermostat vs the depth of the Ecobee Developer API. It's a big gap and not apples-to-apples. Adopting that would mean losing capability we have today

FWIW -- My Ecobee HA HomeKit integration doesn't allow setting fan hold duration when overriding a preset, unless I'm seriously missing something. It always uses "Until the next scheduled activity". This doesn't work for my use case. I need to set fan hold with a duration of "Until I change it".

If the HA HomeKit integration actually let me set hold durations properly I'd be using it right now.

@Jimbo.Automates: do you still think you could resuscitate the existing plugin with reduced polling if you had access to a different Ecobee API key?

It's on my list to investigate a hold until I change it mode, but so far it doesn't seem possible with the Homekit method.

If we switch API keys it'll work for a while until Ecobee shuts us down again. You can use your own API key by adding it to the configuration. If people want to do that I'll get oauth working properly.

43 minutes ago, Jimbo.Automates said:

If we switch API keys it'll work for a while until Ecobee shuts us down again. You can use your own API key by adding it to the configuration. If people want to do that I'll get oauth working properly.

@Jimbo.Automates When I read this… are you referring to adding our own APi to the current Ecobee poly or the new Ecobee? I added my own APi to the current PG3 Ecobee and was able to get it to recover from “disconnected” to “connected”, but no node data populated into IoX.

Another confusion I would like to ask about. In some of the read.me and config.md files for the new HomeKit poly and the new Ecobee poly I get the impression that there is a path to still use the backend=cloud while data moves through HomeKit (if the user has their own API). Can you elaborate on if this will be possible with the new polys? Thank you in advance.

17 minutes ago, ISY4Me said:

@Jimbo.Automates When I read this… are you referring to adding our own APi to the current Ecobee poly or the new Ecobee? I added my own APi to the current PG3 Ecobee and was able to get it to recover from “disconnected” to “connected”, but no node data populated into IoX.

It should work, but I have no api_key so not possible for me to test.

18 minutes ago, ISY4Me said:

Another confusion I would like to ask about. In some of the read.me and config.md files for the new HomeKit poly and the new Ecobee poly I get the impression that there is a path to still use the backend=cloud while data moves through HomeKit (if the user has their own API). Can you elaborate on if this will be possible with the new polys? Thank you in advance.

Not currently, backend can only be cloud, websocket or mqtt modes. Not sure what gives that impression. I suppose that could be valid to access some of the settings that are not available in homekit, but I'd need an api_key and more free time to test.

4 hours ago, Jimbo.Automates said:

It should work, but I have no api_key so not possible for me to test.

Not currently, backend can only be cloud, websocket or mqtt modes. Not sure what gives that impression. I suppose that could be valid to access some of the settings that are not available in homekit, but I'd need an api_key and more free time to test.

The Production Store version (3.15) doesn't have a pre-defined configuration setting for API key. Is it a custom configuration parameter we can enter if we know the right text to use for the key? Or does the Non-production Store version (dated today) have API key as a new configuration parameter?

"The Homekit and Ecobee plugins have been released to beta, but require an update of IoX that is not available yet"

This is great! For those of us who are considering being less adventurous, any idea when the new IoX will be availbale?

1 hour ago, BJB2757 said:

"The Homekit and Ecobee plugins have been released to beta, but require an update of IoX that is not available yet"

This is great! For those of us who are considering being less adventurous, any idea when the new IoX will be availbale?

That's up to UDI, not me. They must run all their regressions and push a release, I have no idea.

16 hours ago, ndfan77 said:

The Production Store version (3.15) doesn't have a pre-defined configuration setting for API key. Is it a custom configuration parameter we can enter if we know the right text to use for the key? Or does the Non-production Store version (dated today) have API key as a new configuration parameter?

Yes, the latest beta allows setting your own api_key, but as of now it is not tested because I'd need an oauth api key registered with a redirect URI matching Polyglot’s callback https://polyglot.isy.io/api/oauth/callback

Ideally the plugin could use both backends, get some info from cloud that is not available for local and rely on local for most. But that is a big change because my assumption was one or the other when I started.

Edited Sunday at 06:22 PM2 days by Jimbo.Automates