bpwwer

Thanks! I'll keep an eye out for it.

Initially I thought it might be a race in the plugin so I compared the two plugin logs and the log messages have identical ordering. From the Roku plugin log on PG3x: 2026-10-29 09:32:02.876 Thread-39173 (poll) udi_interface.interface INFO interface:updateProfile: Sending Install Profile command to Polyglot. 2026-10-29 09:32:03.002 Thread-39173 (poll) udi_interface.interface INFO interface:updateProfile: Sending Install Profile command to Polyglot.Also, the event view log snippets I posted above show both within about 400ms. When the plugin is running under eisy plugins the plugin log looks the same, but the event viewer only shows one event instead of two.

Keep in mind that this plugin was originally for PG2 and ported to PG3 where it's been working fine for over 4 years. I agree that it could be re-written so that it works better with eisy plugins, but from a plugin developers point of view, if it works on PG3x but not eisy plugins, it's eisy plugins that is broken, not the plugin. The discovery process actually finds the devices and then loops over the found devices to create the profile and node. The time between profile updates is pretty short, probably a couple hundred milliseconds. I don't disagree that there are likely multiple ways the plugin could be enhanced to take advantage of new capabilities in the interface/IoX/eisy-ui. But there's no real ROI for me to invest the time to do so.

Yes, when the plugin starts it does a device discovery and re-creates the profile files. This was my way of handing cases where device are added or removed between restarts (really discover events) without having to maintain state. Roku devices can also have apps added and removed which means NLS entries need to change to reflect that. Back when this was written, there wasn't any other way to handle some of this. When I restart the plugin in eisy plugins I see this. Only this one instance and 1 of the 2 nodes shows internal server error 16368 2026-10-28T15:30:22.234357-07:00 _3 NI <family instance="23">10</family>As I've been typing this out, another entry showed up in the event viewer 10 minutes later. Now the node is correct with no errors. 16524 2026-10-28T15:40:21.434498-07:00 _3 NI <family instance="23">10</family> When I restart the plugin in PG3x I see this. 16380 2026-10-28T15:31:54.829922-07:00 ST 0 n026_83075 {"name":"Online","value":0,"formattedValue":"False","uom":"2","prec":0} 16381 2026-10-28T15:31:54.878589-07:00 ST 0 n026_29806 {"name":"Online","value":0,"formattedValue":"False","uom":"2","prec":0} 16382 2026-10-28T15:32:04.338506-07:00 _3 NI <family instance="26">10</family> 16383 2026-10-28T15:32:04.343330-07:00 ST 1 n026_83075 {"name":"Online","value":1,"formattedValue":"True","uom":"2","prec":0} 16384 2026-10-28T15:32:04.755582-07:00 _3 NI <family instance="26">10</family> 16385 2026-10-28T15:32:04.779537-07:00 ST 1 n026_29806 {"name":"Online","value":1,"formattedValue":"True","uom":"2","prec":0}And both nodes display correctly with no errors. Note that there are 2 of those lines (along with the other ST lines that don't exist when restarting the plugin in eisy plugins. And again, 10 minutes later there are 2 of those lines in the event viewer for the PG3x plugin. So every 10 minutes I see 1 line for the copy installed in eisy plugins and 2 lines for the copy installed in PG3x.

/rest/profiles is always correct When I restart the plugin or reboot the eisy, one of the two nodes will be missing the profile information in /api/profiles. In this state the node shows the internal server error instead of the node values/commands Over time, it get corrected so that /api/profiles is correct and the node displays correctly. There's a good chance this is related to the plugin's startup/discovery process. As it discovers Roku devices, it updates the nodedefs.xml and NLS files. After each update it pushes the updated files to IoX. It seems like the second profile update isn't making it to eisy-ui (/api/profiles) immediately.

Yes 2026-10-27 19:15:24 [debug] web: HTTP Request from ::ffff:192.168.92.100 - GET /api/groups/nodeRoles/n023_83075 2026-10-27 19:15:24 [error] web: Error processing /groups/nodeRoles/n023_83075: NodeDef roku_45 not found in family 10 instance 23 2026-10-27 19:15:24 [http] web: GET /api/groups/nodeRoles/n023_83075 : 200 : 4ms 2026-10-27 19:15:24 [debug] web: HTTP Request from ::ffff:192.168.92.100 - GET /api/profile/node/n023_83075/cmds/accepts 2026-10-27 19:15:24 [error] web: Error processing /profile/node/n023_83075/cmds/accepts: NodeDef roku_45 not found in family 10 instance 23 Yes However, it seems to correct its self over time. After eisy reboot and reload of eisy-ui, the node shows just internal server error. No values and no commands. Over time it seems to get corrected. Before I responded to this, I checked the nodes and both were displayed properly with no internal server error. It had been running for about 6 hours at this point. So I rebooted the eisy and reloaded eisy-ui and the error is back.

Ok, we'll go with that. It should be in the non-production store now (or refresh the store listing to see it). It's called SonosV2

Updated to all the latest versions in staging and I'm still seeing the same issue. One node is fine, the other shows internal server error and /api/profiles only has the info for the one working node.

The issue reported was that the plugin wouldn't start after migration. Your log shows the plugin starting and running correctly. The error messages being shown are actually debug messages that accidentally got left in (and have been there for about 4 years). I removed them in version 1.0.28

@Howard I've got something at appears to be working. I'll try and get it published to the beta PG3 store today so you can try it out. I'm still a bit concerned about the licensing and copyrights From what I can tell, no code from the HA integration was used so their license/copyrights aren't relevant. However, the plugin files: sonos.py, controller.py, and device.py are based on template/boiler plate code in the script. The copyright/license for the code the template/boiler plate was copied/derived from should be passed down to those files. If I understand correctly, it was an AI that created the script and we don't know what files it referenced to do so. Who created the backend.py file? Is that something you created or was it also created by AI. It's probably safe to license it under MIT as most other plugins are but it would be nice to have proper copyright info for the files.

No, I'm not really involved with migration issues unless it's something I encounter personally and work with UDI to resolve. I'm not sure of the state of migration for javascript based plugins. Since I have no Sonos devices, it's very hard for me to test/debug issues. Best to submit a ticket when you have migration issues.

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.