ISY4Me

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.

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

I have read (somewhere) that the EISY does not have a speaker, so no sounds. 
if you have a hdmi monitor and keyboard on the EISY you can monitor the update by viewing the log after you login  
sudo tail -f /var/udx/logs/log If you don’t have a monitor and you are comfortable with it, you can ssh into the EISY and then view the log. 
When updating is complete the last line in the log will actual state that the update is complete. 
Another option is… if the update is still in progress, you will see a warning when you start the AC for the EISY, but I have never confirmed that the update is complete if the message is not visible. 

I received a reply from @Michel Kohanim this afternoon regarding my ticket on this issue.  Here is a cut/paste of his response... shared with his permission.
There were no suggestions as to how to snap the excess off the board, but at least we are aware of the guideline.
Michel Kohanim wrote:
2023/01/01 17:28
Hi Jim,
Yes, so very sorry. You need to snap it in the middle.
JWeaver01 wrote
2022/12/31 08:05:27
With no guidelines or instructions included with the Enclusure I was trying to mount the “as shipped” ZMatter board into the Enclusure intact getting interference with the posts of the antenna connector.  Yes, there was extra depth to the cable that I originally pointed out, which made that interaction worst, but that may be a non-issue. 
But after looking closer at things this morning and seeing that one image of a mounted board (see attached) I am beginning to think that the full ZMatter board was never designed to mount in the Enclosure.  
Is snapping (or cutting) off the top half of the ZMatter board the sanctioned method approved by UD?  Recommendations on how to do that without damaging the board? 

I ran multiple tests this morning and finally was able to get a persistent change.  I think @Jimbo.Automatesis correct, in that something was not under control.  So, this is the criteria that finally appears to work.
I set the Ecobee app "Device Settings" for "Hold Duration" to the "Until I change it" selection In IoP, I programmatically set the Climate Type to my "Away" test comfort setting, but I had to set the "Hold Type" to "Indefinite Hold" to keep the changed value for climate. In IoP,  programmatically issue a "Wait" command for two minutes to give time for the last command to propagate to the thermostat settings.  Changing the Climate Type will change the Schedule Mode to "Hold Next", so that setting needs to be stable before forcing it in the next step.  Perhaps it can be shorter that a 2 minute delay... needs further testing. In IoP, programmatically issue a "Schedule Mode" change to "Indefinite Hold" In the testing so far, the Temperature, Climate and Schedule Mode are all staying as set in the experiment.  They did not change when the Ecobee when through a Scheduled Comfort Setting change.  I then manually changed the schedule on the Ecobee App to go back to my standard daytime schedule and again, the Temperature, Climate and Schedule Mode remained the same as they were for the Away Test experiment.
Reverting back to standard operation is as simple as issuing an IoP command to change "Schedule Mode" back to "Running" and everything goes back to the standard schedule.
The standard Ecobee Vacation Mode is a very good tool, but I am optimistic that being able to programmatically control things will give me other options where they are needed.