ISY4Me

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.