8 hours ago, bpwwer said:

1. 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

2. 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.

For #2:
(A) The fixing itself over time could be triggered my any nodeDef update or node created event. e.g. nodeDef changed or node added from any Family/NodeServer including the NodeServer with the error. Depending on (B).
(B) It is unclear from your reply if, when the issue returned, the profiles existed in /rest/profiles, and the api continued to fail. Without knowing this it is hard to debug any further. If they do NOT exist in /rest/profiles there is either a parsing error or the profile is not received. If they do exist in /rest/profiles we need to know if they are still missing in api/profiles, if they are there is gap in coverage somewhere.

4 hours ago, Javi said:

For #2:
(A) The fixing itself over time could be triggered my any nodeDef update or node created event. e.g. nodeDef changed or node added from any Family/NodeServer including the NodeServer with the error. Depending on (B).
(B) It is unclear from your reply if, when the issue returned, the profiles existed in /rest/profiles, and the api continued to fail. Without knowing this it is hard to debug any further. If they do NOT exist in /rest/profiles there is either a parsing error or the profile is not received. If they do exist in /rest/profiles we need to know if they are still missing in api/profiles, if they are there is gap in coverage somewhere.

/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.

3 hours ago, bpwwer said:

/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.

Perfect, so restart replicates every time? This may be the key, the profiles are not deleted on restart or stop. The Node server is recreating profiles and overwriting the existing? I think timing needs to be checked.

Open the event viewer in another tab and look for the instance (slot)

2026-10-28T15:01:11.153807-06:00

_3

NI

<family instance="20">10</family>

Does the event correlate to when the the app gets profiles? If it does it is simply that the files did not exist during that time.

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.

18 minutes ago, bpwwer said:

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.

Understood. The issue appears to be the time to discovery can have a huge lag?

This sounds like the expected behavior in a dynamic update.

While I dont have these devices, my suggestion would be something similar to:
(1) Have the NS hold a profiles cache until the device is found, then update as needed.
(2) (optional) Instead of removing a profile the node can have a property showing the discovery state.
then
(A) Clear the devices profiles after some time. This keeps existing form.
or
(B) Give the user an option/cmd to purge non existing devices. Possible breaking change.

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.