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.

12 hours ago, bpwwer said:

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 noticed the possibility of a race which could explain the issue. Before I submit can you verify there are multiple _3/Ni events at about the same time? e.g. milliseconds apart.

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.

55 minutes ago, bpwwer said:

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.

Perfect, I think it is an issue with eisy-ui plugins. Fix submitted, did not make it into todays release.

43 minutes ago, Javi said:

Perfect, I think it is an issue with eisy-ui plugins. Fix submitted, did not make it into todays release.

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

@Javi yet another issue that seems to be related to profile file. This is on a plugin that I'm currently enhancing. There are two issues.

1. eisy-ui's display of the node is not displaying the text associated with a GVx value. See the difference in the title, artist, album fields between eisy-ui and the admin console.

2. The GV1 field is showing incorrectly (in both). GV1 (Bass) is a numeric value, using the editor:

   <editor id="sinc">

   <range uom="56" min="-10" max="10" step="1" />

   </editor>

   It's current value is 1. Why is it getting displayed as if it's Boolean (uom=2)?

   When I run this plugin on an older IoX 5.9.1 / PG3 it displays correctly as '1'

16 hours ago, bpwwer said:

@Javi yet another issue that seems to be related to profile file. This is on a plugin that I'm currently enhancing. There are two issues.

1. eisy-ui's display of the node is not displaying the text associated with a GVx value. See the difference in the title, artist, album fields between eisy-ui and the admin console.

2. The GV1 field is showing incorrectly (in both). GV1 (Bass) is a numeric value, using the editor:

   <editor id="sinc">

   <range uom="56" min="-10" max="10" step="1" />

   </editor>

   It's current value is 1. Why is it getting displayed as if it's Boolean (uom=2)?

   When I run this plugin on an older IoX 5.9.1 / PG3 it displays correctly as '1'

Need to see the editor to diagnose.

The formatted value does not come from eisy-ui it is formatted in eisy, and has always been. The event Viewer (search for the node id) will have the whole property update event with the formatted value, just refresh the page before viewing. This will also show the UOM provided in the property update.

My best guess is either the editor (NLS) has incorrect values or the property is being submitted with the boolean UOM.

2 hours ago, Javi said:

Need to see the editor to diagnose.

The formatted value does not come from eisy-ui it is formatted in eisy, and has always been. The event Viewer (search for the node id) will have the whole property update event with the formatted value, just refresh the page before viewing. This will also show the UOM provided in the property update.

My best guess is either the editor (NLS) has incorrect values or the property is being submitted with the boolean UOM.

Looks like the udi_interface/pg3x has a caching issue with driver uom's. I've been re-installing the plugin and when I send updates for those I just use setDriver(GV1, 1) and either udi_interface or PG3x is pulling the wrong uom before it sends it to IoX. Deleting and doing a new install of the plugin fixes that issue.

However, eisy-ui not displaying the text associated with the value is still an issue. These are being sent from the plugin with:

setDriver(GV10, 0, text="some text")

The admin console handles this right but eisy-ui is just displaying the value, not the associated text.

1 hour ago, bpwwer said:

Looks like the udi_interface/pg3x has a caching issue with driver uom's. I've been re-installing the plugin and when I send updates for those I just use setDriver(GV1, 1) and either udi_interface or PG3x is pulling the wrong uom before it sends it to IoX. Deleting and doing a new install of the plugin fixes that issue.

However, eisy-ui not displaying the text associated with the value is still an issue. These are being sent from the plugin with:

setDriver(GV10, 0, text="some text")

The admin console handles this right but eisy-ui is just displaying the value, not the associated text.

The UOM value comes from one of two places, in priority order:

The database — on node init, updateDrivers() loads previously saved driver values (including uom) from the PG3 database via poly.dbgetNodeDrivers(address). If a saved value exists, it overwrites the class default.

The class-level drivers list — the uom you defined statically on your node class, e.g.:

drivers = [

{'driver': 'ST', 'value': 0, 'uom': 51}

]

This is the fallback if no database record exists yet.

So in practice, the uom reported to ISY will be whatever was last saved for that driver (or your class default on first run). Unless included in setDriver
self.setDriver(driver, value, report=true, forceReport=false, uom=None, text=None).

The text, I'm not sure, I'll need to investigate. Do you happen to have a screenshot of the event showing the update? If not I'll need to create an example to test so it may be a few days.

test as it won't let me post what I want

3 hours ago, Javi said:

So in practice, the uom reported to ISY will be whatever was last saved for that driver (or your class default on first run). Unless included in setDriver
self.setDriver(driver, value, report=true, forceReport=false, uom=None, text=None).

The text, I'm not sure, I'll need to investigate. Do you happen to have a screenshot of the event showing the update? If not I'll need to create an example to test so it may be a few days.

And that's the way I wrote PG3 to handle it, so sorry for the churn. Changing driver definitions from one version of the plugin to the next requires removing the plugin to clear the database entries so it picks up the new definitions. I'm old, that's my excuse.

You mean in the event viewer? It just shows: n031_xx5682aiel48u {"name":"Title","value":1,"formattedValue":"True","uom":"2","prec":0} without any of the text. What's there is correct.

In the PG3 log it shows PG3 sending the update to IoX with the text info:

/rest/ns/31/nodes/n031_xx5682aiel48u/report/status/GV11/1/2/text/Elle%20King

I don't see anything relevant in any other log. Is there a way to see what is being sent to eisy-ui?

16 hours ago, bpwwer said:

You mean in the event viewer? It just shows: n031_xx5682aiel48u {"name":"Title","value":1,"formattedValue":"True","uom":"2","prec":0} without any of the text. What's there is correct.

In the PG3 log it shows PG3 sending the update to IoX with the text info:

/rest/ns/31/nodes/n031_xx5682aiel48u/report/status/GV11/1/2/text/Elle%20King

Yes, Thanks this confirms what i expected, the text is not being sent to eisy-ui. I will need to investigate. So for now formatted text relies on the use of NLS (XML) or editor.names (JSON) from profiles

Property XML (node status query response):

<property id="ST" value="42" formatted="42 %" uom="51"> <text>Eco Mode</text> </property>

Subscription event stream:

<Event ...> <control>ST</control><action uom='51' prec='0'>42</action><node>addr</node> <eventInfo>...</eventInfo> <fmtAct>42 %</fmtAct> <text>Eco Mode</text> </Event>

Created issue: '''eisy-ui missing "text" param/key in node update events.'''  Id: /eisy-ui/issues/152.
Currently at least 1-2 weeks out.

P.S.

This is not intended to replace formatted value, it was implemented for strings to enhance the trigger that are single use. For example the last image from a doorbell camera, a detailed error message with a error property, a url for stream or images.

12 minutes ago, Javi said:

P.S.

This is not intended to replace formatted value, it was implemented for strings to enhance the trigger that are single use. For example the last image from a doorbell camera, a detailed error message with a error property, a url for stream or images.

Understood. This is for media meta data (title, artist, etc.) Not stuff that would be used for triggers.

Thanks for the update and debugging work!

upgraded my Polisy and will this new plugins system work with it now? I see it as option to migrate.