Have been keeping an eye on your post, as I am in the same exact situation with Universal Devices (UD).
ISY stuff great, but ZWave and now Zigbee really disappointing implementations.
UD seems to be rushing keeping up with the latest home automation technologies, but producing junk code, and producing that new junk on top of an outdated code base lacking key features (with few/no improvements).
The interrupt-based control logic has lots of downsides, but I can live with that, as it is perfect for Mealy State logic implementation (only using if-thens, and never any elses, and never using waits (except in making state var timers).
The initial codebase does not have a variable abstraction between raw device interfaces, and all subsequent references to those devices in programs and scenes. You have no ability to re-map raw devices to the logic base. Yes, Insteon stuff has a “replace” function, but that does not exist for ZWave and Zigbee. (really amateur land).
The biggest deal for me is the inability to backup and restore this zwave and zigbee stuff, and lots of opportunities to lose it all and have to go back to redoing everything.
Great for a hobbyist, but not so good for larger projects.
Here is my situation (like you, with it since about 2005, ISY-99. then ISY-994, now Polisy):
(35) Hue bulbs, nearly all White Ambiance (that allows amber to bright white change).
(20) Insteon plug-in dimmers
(8) Insteon bulbs
Lots of spares for above as I have been transitioning to Hue
(5) Insteon Motion/Temp sensors
lots of Insteon human interfaces: wall dimmers, multi-button dimmers in walls, on tabletop, and quite a few multi-button mini-remotes. (Insteon still king in this area).
(8) Zwave motion, tilt sensors, and multi-digital outputs for sprinkler control
Here is why “losing” a Zwave or Zigbee (Hue) setup is such a big deal for me.
My basic system before additional scenes and lots of programs:
I have four scenes for a large main living area Morning, Evening, Dim, Sleep.
And I have four Controllers in each of those four Scenes (mini-remotes, in-wall, tabletop 6-button).
And…I have the same 27 bulbs that I am controlling in those four scenes.
And nearly all the bulbs are Hue Ambiance with Brightness and (color) Temperature setting.
Again, four controllers in each of four scenes, plus the top “named” scene is in itself a virtual “controller” that programs can command. Each of those five controllers needs to be individually configured for each bulb. And each bulb has two variables.
Here is the math:
4 scenes x 5 controllers/scene x 27 devices/controller x 2 entries/device = 1,080 changes.
If it takes me 30 seconds per change (on average including breaks), that is 9 hours of non-stop work. I am suicidal in those final hours it is so tedious.
I am currently using a Hue Hub and Nodeserver for the Hue bulbs. I wanted to get rid of that hub and use UD’s ZMatter ZWave/Zigbee USB module. Spent a lot of time on forum and even direct comms with Michel. It looked perfect.
Here is reality:
Polisy firmware update that goes bad? REDO (this has happened twice for me).
Accidentally delete a Hue bulb in Admin console before first removing it from the Zigbee network? 1) Throw bulb away, 2) Sell bulb on eBay, 3) reset the entire Zigbee system to be able to again discover that bulb and start from scratch. REDO. (ZMatter still thinks it is there and will not allow a re-add)
Accidentally unpair an installed bulb (at the actual bulb). Same as above. ZMatter still thinks it is there and will not allow a re-add. REDO
Four or more right-click options in Admin Console have no explanation in online documentation, and nothing in the Forums. At least three will, without warning, cause a complete reset of your Zigbee system and lose all handles to devices in Scenes and Programs. REDO.
Basic debugging of radio comms problems in ZWave Dongle or ZMatter often call for a reset of the module: REDO
The implementation of ZWave has the same interface and options and issues as the Zigbee. But there is one big difference. You can always recover a ZWAVE device, as when you do a factory un-pair AT THE DEVICE, the micro in the ZWave Dongle or ZMatter unit detects that device reset and removes it from its polling list. With Zigbee, the ZMatter micro does not detect an external reset of device and it remains in its polling list, and will not allow a re-add.
So yes, you can also screw up in ZWave by deleting a device before removing it from your ZWave network. But easy recovery.
But for both ZWave and Zigbee devices, why when you delete a device is there not a sequence that forces a network remove first??? I raise this with UD developers and get no response.
But the big killer for me is that the UD implementation of Zigbee does not fully support Hue bulbs.
Nearly all of my bulbs are the far more expensive White Ambiance with color temperature control.
The Hue Hub works great (of course).
The UD ZMatter Zigbee stack only recognizes the Candle E12 bulbs color temperature variable. None of the other Hue bulbs (BR30, E26, etc.) will have the color temperature variable recognized (just brightness).
A big show-stopper for me. UD support just shrugs their shoulders and says it is the Zigbee library 3rd party stack they use that they can do nothing about.
Really? The monster in the Zigbee HA world (Phillips Hue) is not properly supported by the library you use?
But even more shocking to me is that there is nothing in the UD Forums about this. That tells me that UD has a very niche, very small market of hobbyists.
And as far as maintaining their base code, even just for Insteon:
Here is a simple thing they could do that would benefit all users, and save me about 8 hours of effort to REDO the system:
Have the ability to right click a controller in a Scene and pick “Capture current bulb levels” (brightness, and color, temperature if avail)
My wife could manually set each bulb for desired effect for a scene, and in ten seconds, it is done.
At the least, why not have a right-click of a controller in a scene and have the ability to copy the settings from a previously set controller in that scene?
BUT UD HAS NO INTEREST IN IMPROVING THAT BASE CODE. For all I know, the original programmer of that code is long gone, it is a spaghetti mess, and they are adverse to even touching it for fear of breaking sh1t.
I am not convinced they are going to survive. It is time to future proof.
Considering my options and will look into H.A. But programming looks pretty weak on first glance