ISY4Me

@DennisC Thank you... that was the solution.

I just want to be clear... all of the comments below ONLY apply to users who are using the Ecobee Plugin in the cloud/API mode. Users who are using the default HomeKit mode should not have issues migrating the Ecobee plugin to eisyui and do not need to read this. The main problem seen with v4.1.11 of the ecobee plugin after migration to eisyui was failure to be able to read current values/parameters from the ecobee API server due to authentication issues. With work by @Jimbo.Automates and ecobee plugin update to v4.1.13, issues are resolved, but users with their ecobee configuration in cloud/API mode will still have some extra steps that have to be preformed to have everything working on eisyui after migration. Ecobee plugin has been updated to v4.1.13 and addresses issues related to authentication with Ecobee. Here are the recommended steps... and again, this is ONLY for users that work in the cloud/API configuration mode. 1) Update the Ecobee Plugin to v 4.1.13. It was recommended to update this on PG3 before migration and confirm all is OK 2) Migrate the Ecobee plugin to eisyui. Due to the way that Ecobee handles the authorization of the API using the xxxx-xxxx PIN handshaking, this new instance of the plugin running on eisyui will be seen as a new instance of the plugin by the API Serves too and it will not be able to use the old auth codes. To resolve this, the xxxx-xxxx PIN or User ID has to be communicated to ecobee. This does not happen automatically during the migration and the user has to manually trigger the xxxx-xxxx PIN handshaking process. 3) To manually trigger the handshaking process, you have to know what the new xxxx-xxxx PIN is. The method I used is as follows... and this is done after migration... 1) On the eisyui plugin view in the Configuration Tab, remove your API String from the API Key field in the configuration. 2) Save the change you just made. 3) This will trigger a pop-up blue notification in the Overview tab, but it will not have a xxxx-xxxx PIN in it because the API was removed. 4) Now, go back to the configuration tab in the eisyui plugin view and re-enter the same API String into the API Key field (this is your own personal developer API String), 5) Now, save the configuration changes again. 6) You will see an updated blue notification in the Overview tab and within the lower blue notification box you will see your new xxxx-xxxx PIN. 7) Now, log in at the Ecobee web site → Profile → My Apps → Add Application → enter the PIN and click Validate. The website will popup a verification of what you just submitted... verify and then click validate in that popup. Ecobee will then tell you the process worked and will probably send you an email saying essentially the same thing. 8) Back in the eisyui plugins view in the Overview tab... the blue notification boxes will disappear within 2 minutes. AFTER those blue notification boxes have disappeared, re-submission of the xxxx-xxxx PIN handshaking process is finished. 4) With the xxxx-xxxx PIN process completed, the plugin is still looking at the old validation that it did on startup. To refresh everything with the new authentication code, go to the eisyui plugin view and in the Overview Tab and STOP the plugin and then START the plugin ( I suspect a RESTART will to the same, but I did not test that). At this point everything should be running as it should.

That was the first thing I tried. When you click on … vertical, you get an option to edit the tile, but there is no option to edit the title. No matter what choice I make the Tile Title Box is never presented as an editable feature. I expect the UDI team will need to put this on a feature update list.

When adding some parameters to display values on the EISY Home Page, I cannot see a way to edit the title box in a specific widget. In this example, the title "Temp Sensor 1" is not descriptive and it would be good to be able to edit.

I am running the Ecobee plugin in API mode and it has been running rock solid in PG3 since @Jimbo.Automates released the current version with API, or Homekit backends. I have been working on migrating this plugin (using API configuration) from PG3 into EISY-ui and having issues. A fair amount of my programs appear to run, but there are issues where programs evaluate thermostat temperatures and errors in the log files are present. On this first post I don’t want to distract you with the specifics of the issues I am seeing, but whether the UDI community users have migrated their Ecobee API configured plugin into EISY-ui and everything is working as you expect and your log files show no concerns.

@bmercier I have just seen the same issue, but I am not sure I understand your recommendation. Are we changing the time zone in AC or EISY-ui? And where exactly is this done. I looked in EISY-ui and didn’t see anything. I do graphs and trends in HA and data is not plotting correctly on the time axis and I am assuming that this time issue for when the data was last updated is part of the problem.

See the link in the post above. Issue was resolved by running "Discover" on the Bond plugin after it was migrated.

I approached the Bond Bridge migration again this evening. Tried to do this as cleanly as possible, purged the cache on Safari and started eisy-ui in a web window. the migration showed no issues and produced the following view in the nodes list... The nodes and sub-nodes all showed as before and the sub-node buttons appear in the right panel. However, when clicking on the buttons to turn the test light on/off they did not work... nor did any of the others for the Bond Bridge. The other strange thing I noticed in rebooting after installing the Bond Bridge plugin in EISY-ui, it apparently caused the OpenWeatherMap and SUN plug-in to go into a Disconnected state when viewed in the Node List. However, when you examined the plug-ins in the EISY PLUGINs list in EISY-ui they all showed connected. When the plug-ins were restarted in the EISY Plugins view all the plugins in the Nodes view changed to connected. I am not sure what caused this, but I will watch out for this pattern on future reboots and if it occurs again I will submit a Ticket. So, after getting all the plugins to show a "connected" status in the EISY-ui Nodes view, I still did not see any change the Bond Bridge sub-nodes (buttons and stuff in the right panel not working) and I was still seeing the comment "node address xxxxxx does not exist" in the log file. I then wondered if I had to re-discover these sub-nodes even thought they had migrated over OK. After I did a "Discover" from the EISY-ui "eisy Plugins" Bond Bridge view, this is what I saw in the Nodes View... Now the "Status" column was showing the current state of the Bond Bridge sub-nodes. After I saw that change, I tried the buttons for a single sub-node (as shown in the above view) and they worked. This is progress and I will now leave the system in this state and see if everything continues behaves normally. But it does leave a few questions for the experts. 1) Should running Discover become the default recommendation after a migration from PG3 to EISY-ui? 2) Why am I seeing some of the Plug-Ins (In the Nodes View) drop to a disconnected state after a reboot? Then I have to restart them.

A new day, so I thought I would try again. I migrated the Bond Bridge from PG3x to EISY-ui and that seemed to go OK. When I look at the Bond Bridge in EISY-ui, I see everything and all the sub-nodes, but now today when I click on any of the sub-nodes in the EISY-ui Nodes list, I do not see the buttons in the right panel and instead I see a red "internal server error". I tried rebooting and that did not change and I then power cycled the box and again this performance did not change. @Goose66 Are you aware of any issues with the Bond Bridge after migrating to the EISY-ui? When I reversed the process and put the Bond Bridge back in PG3, everything returned to normal and I can go to the EISY-ui Nodes list (as shown above) and the buttons and lists for all the submodes appear in the right panel and I can change them as desired and all is good. I suspect some help is needed from the EISY-ui team since everything is OK when the plugin is left in PG3.

I could not find any reason for all Bond Bridge subnodes not working, I assume there is some tweaks necessary. When the Bond Bridge node was pushed back from eisyui to PG3x, everything responded as I would expect. This post should have been posted into the eisyui sub-forum... sorry about that.

Please see the posting I put in the EISY forum regarding the Bond Bridge nodes all being unresponsive after migrating to eisyui... the error is indicating the submode address does not exist, when everything worked perfectly when the plug-in was in PG3x. Please see this new listing at this link, my apologies it was intended to be posted in the esiyui subform.

I migrated my Bond Bridge plugin today into eisyui and at first test nothing appears to be responsive when I go to the node panel and manually toggle lights or turn on the fan. When I look at the log file it appears to be using the correct device IDs... example here for a few different trys for different devices... 2026-10-23 16:12:31.202 Command udi_interface.interface ERROR interface:_handleInput: _parseInput: node address 2ffd4fe1 does not exist. {'address': '2ffd4fe1', 'cmd': 'DOF', 'query': {}} 2026-10-23 16:12:31.242 Command udi_interface.interface ERROR interface:_handleInput: _parseInput: node address 355343b0 does not exist. {'address': '355343b0', 'cmd': 'DOF', 'query': {}} 2026-10-23 16:16:45.517 Command udi_interface.interface ERROR interface:_handleInput: _parseInput: node address 2278430c does not exist. {'address': '2278430c', 'cmd': 'DON', 'query': {}} 2026-10-23 16:16:45.559 Command udi_interface.interface ERROR interface:_handleInput: parseInput: node address 2278430c does not exist. {'address': '2278430c', 'cmd': 'SETSPEED', 'query': {'FAN_SPEED.uom56': '1'}} The node addresses shown in this log grab are correct for the device I was trying to enable or toggle and the Token for the Bridge itself is verified as correct in the configuration tab. The Bond Bridge does show as connecting in eisyui and I have tried to restart the plugin with still always getting the same error on the node addresses not existing. Has anyone migrated the Bond Bridge from PG3x to eisyui and had verified that things are working?

Can you provide some information on which method you are trying to get to work. Just to review, the old plug-in (I think it was prior to 4.1.x) will not work due to Ecobee changes. The fix is out there… @Jimbo.Automates released a HomeKit Plug-in and when used with the New Ecobee Plugin (version 4.1.10 or greater) configured for integration with HomeKit, will populate the AC. HomeKit offers less data than the old Ecobee plugin… not an UDI issue, limits are in the HomeKit design… I assume on the Apple side In the second method, you can use the New Ecobee Plugin without HomeKit, but you must have your own Ecobee Developer API, issued before Ecobee stopped handing them out. Acquiring your own API is not possible today as Ecobee stopped handing them out. In this mode the Ecobee plugin would have to be configured with “cloud” for the “backend” setting and you would have add your personal API to that configuration field. These two methods are the main UDI EISY options. Which one are you working with?

When using the new integration of Ecobee with PG3 HomeKit, the extra precision is lost... it appears to be a HomeKit thing. If you were to use a pure (non-PG3) Ecobee pairing with a real Apple Hub or Apple Home, you would see the same thing. I have experimented on Home Assistant where I have done an Ecobee integration with the HA version of HomeKit. Out of the box, I see the same whole degree reporting only. The odd exception I found is that there is a way with the HA Ecobee integration to HA HomeKit to extract (using templates) a temperature with more significant digits. In doing so, I did not go the extra mile to determine if I was seeing the Average Temp (Thermostat average with remotes) or the actual temperature of the thermostat sensor, but at the time I believed it was returning the sensor value in the thermostat. To the best of my knowledge, the API connection to Ecobee method seemed to be the only way to get that extra precision. I too had the same issue as I used the ecobee thermostat temperature sensor to control all the programs I have for controlling my fans. That extra degree of control down to xx.x makes a big difference on controlling the fan speed and direction.

I will defer your core question to @Jimbo.Automates, but I think the answer is yes. If you installed the new HomeKit Plugin in EISY PG3, it will act has the HomeKit Hub without any Apple devices. I highly suggest you throughly read all the Configuration instructions that come with these plugins. With both Plugins, go to either the eisy-ui Production Store or the eisy-ui Non-Production Store, find the plugin of interest and click on the button for that plugin and within that buy/trial/install panel you will see a 'More Info" button and you can read about the plugins before installing. If you already installed the plugin, then once installed (Trial or Purchase) go to the eisy-ui Dashboard, click on the plugin of interest and then click on "Configuration" tab and again Jimbo.Automates has really good instructions on all the setup process/options... all worth reading (in my case I read it many times). HOMEKIT... The eisy-ui PG3 Plugin Production Store has the $30 purchase version for HomeKit. However, if you want to evaluate first, the Trial Version (one month trial) of the same HomeKit is still available in the PG3 Plugin Non-Production Store... always good to try before you buy. In my experiments with this plugin I did not have to modify any of the configuration settings and the HomeKit hub showed up in the EISY Admin Console and you will be able to see that it is connected if all is OK... still, READ the configuration instructions. ECOBEE... Install the HomeKit Plugin first, then install the Ecobee plugin Version 4.1.3. Again, If you need to test how things work first, the trial version is still available in the eisy-ui PG3 Plugin Non-Production Store. the Production Store has the $30 purchase for the same version. The trial versions are great to test everything out. Once the Version 4.1.3 Ecobee version is installed (Trial or Purchase) READ the default Configuration Settings in the configuration panel of the Ecobee Plugin in the PG3 Dashboard. During the configuration of the Ecobee Plugin... if the Ecobee is still PAIRED with any Apple Hub, you will have to unpair the thermostat before proceeding... see the Prerequisites Section In the Configuration Tab. I believe everything is covered well in the guidance instructions that are found in the Configuration panel for that Plugin in the Dashboard. the default settings should allow the Ecobee Plugin to function as intended, just check the Ecobee configuration quick-start instructions.

@Jimbo.Automates I have seen these two new plugins in action and I am still trying to decide if I will use HomeKit direct communications or the new Ecobee plugin in API mode or possibly some hybrid. In thinking about this I have noticed I need to clean things up and that generates a few questions. When the non-production beta-ecobee plugin is released to production, will it be possible to install/upgrade it over the existing (old) production ecobee plugin in the old same slot? I ask this as I have many programs that are triggered off of the old production release... granted they are currently non-functional, but I am trying to understand what can be cleaned up and what should just be deleted. If I elect to use the new ecobee plugin in API mode, being able to install/upgrade the existing (old) plugin with the new should allow all of my old programs to continue to work. The other option I am considering, is using the new ecobee plugin in both API mode and HomeKit mode at the same time. Is it proper to think that I can have two instances of the new ecobee plug running at the same time (in two different slots) so that some programs can control directly via HomeKit and others through the API communication? What is the best forecast as to when the beta-ecobee and beta-HomeKit will be released to production?

@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.

@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.

@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?

@Jimbo.Automates Is the removal of Ecobee from the Plug-In Store and the Plug-In Purchases a sign that Ecobee PG3 fix is not possible?

I was not sure the Ecobee forecasting is superior to others, so I use OpenWeather for forecasts... current and future. The user controls the polling by setting the number of times per day the polling occurs and then you have to multiply that by the number of days out you want to forecast. In their current setup you do have post a credit card, but if the polling is low there is no charge... I think it was free below 1000 per day. This is just an example of options, I am sure there are others that will work for forecasting. So if giving that up helps get re-enabled, it is workable.

I am evaluating using a TZ45 thermostat on my EISY setup, but I can’t find documentation listing the parameters that will be added when the z-wave device is added to my network. RCS is the original manufacturer of the thermostat, but they were also sold as Trane TZ45. If there is a member that uses one of these devices I would appreciate a photo/screenshot of the main device screen on the IoX Admin Console so I can see what parameters I will be able to work with. Of course, if anyone has a pdf reviewing all the parameters and their options, that would be even better. I appreciate the help.

@Jimbo.Automates Have you been able to see if there will be a path forward? Any encouraging signs would be a positive thing and I suspect all Ecobee PG3 user would be thankful.

As with others, this is broken for me as well. I had communicated with Ecobee today and they confirmed that new APIs are not being released, but that the old API that was issued should still work and that all I had to do was to re-link or re-authenticate the API. The agent that helped me, kept thinking I was on Home Assistant where apparently this re-authentication is documented, so I do not know if this is a real fix for a UDI PG3 node. However, I can't see how to do that and I am hoping someone knows if that is possible. Is there a configuration key that can be added for the Ecobee PG3 that will achieve this re-authentication?

Thank you @Javi... This problem was fixed with the Android UDM 1.5.4 update that was available today.