bpwwer

Yes, that's very helpful. But it raises some questions on what's the best way forward. I see a couple of options. I can try and update the existing sonos plugin. It seems possible, at least the discovery of zones part looks pretty easy. But the existing sonos plugin also allows for manually specifying the zone in the config parameters. Converting that to work with Amp Multi looks to be more of a challenge. There are also other areas of this plugin that could/should be updated as well. Use the generated plugin from ha-to-eisy.zip to create a new Sonos plugin (possibly replacing both ST-Sonos and Sonos). I do see some issues in the plugin that would need to be corrected and it seems to be based on outdated PG3 plugin designs. I'm leaning toward option 2, simply because it seems like the work needed is less and it already has the missing features from the Sonos plugin. Where did ha-to-eisy come from? I can't find anything in the .zip file that lists the license, author, or url to find out more about this. I'd like to make sure that it's ok to modify and re-distribute the code.

The library being used for the sonos (udi-sonos-poly) plugin was updated a couple of weeks ago to add support for Amp Multi, but I don't really know what that means. I can attempt to update the plugin to use the latest version of the library.

That was weird, the store was throwing an error when I did the submit and never uploaded the package. I found a way around it so it's there now, but because I had to do this with PG3, I think it will take a few hours before the eisy integrated plugin store picks up the change.

Yes, thanks for the reminder. I just sent it to the production store. It has the same id so should work with existing licenses.

I was able to run the recreate/reload api requests from the web browser, curl never asked for authentication and I didn't provide any on the command line so that's why it was failing initially. None of those had any effect. Calling the rest api's to view the profile files, /rest/profiles/?family=10&instance=23 returns the correct data, both roku_44 and roku_45 are present in the nodedef and NLS. However, calling /api/profiles does not return the correct data. It has only the profile information for roku_45 (the working node) not roku_44. This seems significant. Here are the step-by-step process the plugin is following during startup discover roku_45 generate NLS and nodedef files -- write these to the profiles directory call updateProfile() which sends installprofile command call addNode() which sends addnode command gets addnode response back discover roku_44 generate NLS and nodedef files -- write these to the profiles directory call updateProfile() which sends installprofile command call addNode() which sends addnode command get profile installation finished get addnode response back get profile installation finished discovery finished Of note is that the first profile installation finished response comes after the second installprofile command is sent. But this is the same flow and timing when the plugin is started in PG3.

Both GET /api/profile/node ... and GET /api/groups/nodeRoles... fail with the internal server error message in the response object. However, the /api/get/profiles call prior to that does respond with a nodedef for the node that has both the roku_44 and roku_45 nodedefs. All of the /api/profile requests return a 401 error. Am I calling it correctly:curl http://192.168.92.14/rest/profiles/ns/23/move?recreate=true i upgraded to the latest packages in staging and rebooted. That didn't help, still save issue.

Actually it's /rest/profiles/?family=10&instance=xx And it seems like it would be coming from somewhere on disk in order to be persistent. In any case, it returns the same data that's in /var/isy/FILES/CONF/DEF/f10/i23/nodedef/nodedes.xml

@bmercier My Roku plugin is failing on the integrated plugins but works fine on PG3. The plugin discovers Roku devices on the network and creates the nodedef and NLS file based on what it finds. It then installs those files (using the installprofile() nodeserver api). When installed into the integrated plugins, it installs fine, it discovers both devices fine, it creates the profile files fine and it appears to install them fine. However when viewing the nodes, one of the nodes will report "internal server error" instead of displaying the node information. The eisy-ui log shows this: 2026-10-23 09:47:05 [debug] web: HTTP Request from ::ffff:192.168.92.100 - GET /api/groups/nodeRoles/n023_29806 2026-10-23 09:47:05 [error] web: Error processing /groups/nodeRoles/n023_29806: NodeDef roku_44 not found in family 10 instance 23 2026-10-23 09:47:05 [debug] web: HTTP Request from ::ffff:192.168.92.100 - GET /api/profile/node/n023_29806/cmds/accepts 2026-10-23 09:47:05 [http] web: GET /api/groups/nodeRoles/n023_29806 : 200 : 4ms 2026-10-23 09:47:05 [error] web: Error processing /profile/node/n023_29806/cmds/accepts: NodeDef roku_44 not found in family 10 instance 23 2026-10-23 09:47:05 [http] web: GET /api/profile/node/n023_29806/cmds/accepts : 200 : 2ms When I go and look at /var/isy/FILES/CONF/DEF/f10/i23/nodedef/nodedes.xml it shows both nodes; roku_45 and roku_44 in the file (same for the NSL file) The flow in the plugin is: discover devices for each device found get device info write profile install profile addNode() So it is doing the installProfile() twice. I think the node that's failing with the internal server error is the first node discovered. I'm not sure what's needed to debug this farther.

I installed the plug both on both internal and PG3 with eisy-ui. On PG3, it is working correctly On internal, one of the nodes is giving the internal server error and it coming from eisy-ui: 2026-10-23 09:47:05 [debug] web: HTTP Request from ::ffff:192.168.92.100 - GET /api/groups/nodeRoles/n023_29806 2026-10-23 09:47:05 [error] web: Error processing /groups/nodeRoles/n023_29806: NodeDef roku_44 not found in family 10 instance 23 2026-10-23 09:47:05 [debug] web: HTTP Request from ::ffff:192.168.92.100 - GET /api/profile/node/n023_29806/cmds/accepts 2026-10-23 09:47:05 [http] web: GET /api/groups/nodeRoles/n023_29806 : 200 : 4ms 2026-10-23 09:47:05 [error] web: Error processing /profile/node/n023_29806/cmds/accepts: NodeDef roku_44 not found in family 10 instance 23 2026-10-23 09:47:05 [http] web: GET /api/profile/node/n023_29806/cmds/accepts : 200 : 2ms However, looking at the nodedef files, roku_44 and roku_45 are both there. So some type of bug in eisy-ui.

From the log, there seems to be a couple of different things going on. But it doesn't seem like those would be unique to running in the new internal plugins on eisy-ui. Have you migrated back to PG3 and is everything working fine there? That's usually the first test, if it works fine in PG3 but not after migration, it's something UDI will need to look into. The two things I see in the log are: it looks like the discovery process is returning a list with the first item being an invalid/null device which may just mean something else on your network is responding to the discovery broadcast. It throws an error for that, but that's what it should do when a non-Roku device responds. the errors around 'native-ui' appear to be related to some recent firmware change on the Roku. Maybe they renamed something or added something. I'll need to look into this more. Neither of these look like they are breaking anything. From your log, both Rokus are being discovered and the nodes created for them. The "internal server error" sounds like it may be coming from eisy-ui and possibly could be related to the native-ui errors or may just be a bug in eisy-ui.

Not at this time. I attempt to maintain both the Sonos and ST-Sonos plugins but I don't have any Sonos equipment. That makes attempting to support new features difficult. Both plugins are based on external libraries so if those libraries add support for the this, it may be possible to update the plugins to take advantage of it. I'd really need to know what support for this means. Is this something that would only change the way the plugin internally address zones or is there some external/visible change to the configuration and/or nodes themselves?

May be an installation problem. Can you download the log package for the one that's not working and PM it to me?

It's working fine on my eisy, but I'm on the staging branch so have more updates on mine than on the production or beta branches. I do see in release notes that UDI has been adding python packages so it may be that the current production branch doesn't have that package yet.

I'm glad it started working. I may have to try and set up some test cases and try to reproduce it on my end. I don't think there's anything to change in the plugin, but it would be nice to know if there's a process when migrating that would work without the delay.

Since you see all the node's values, it appears the migration was successful. The "${sys.node.n001_forecast_0.GV1}" is the way to identify that node value in messages/notifications. What it's basically saying is that you want to substitute the value of node n_001_forecast_0 GV1 value into the message. From your screen shots, everything looks correct. When you say the notification is not working, do you mean that you get a notification email, but all the ${sys.node.n001...} values are blank? Or do you not get the notification email at all? If you're getting the email but it's all blank, it may be that IoX is somehow out of sync with the migration and is still trying to get those from the PG3x version. Rebooting the eisy may resolve this. @bmercier is this possibly the case?