1 hour ago, bpwwer said:

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

eisy-ui relies on the profile shown in /rest/profiles?family=10&instance=XX. (XX=slot)

# Move/re-parse a single node server profile
curl http://{host}/rest/profiles/ns/XX/move?recreate=true
# And/Or just re-import profile files from disk for a single node server slot
curl http://{host}/rest/profiles/ns/XX/files/reload
#And/Or
rest/profiles/move/all?recreate=true

Edit: fix query string

1 hour ago, Javi said:

eisy-ui relies on the profile shown in /rest/profiles?family=10,instance=XX. (XX=slot)

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

35 minutes ago, bpwwer said:

Actually it's /rest/profiles/?family=10&instance=xx

Thanks, yes.

25 minutes ago, bpwwer said:

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

It is, directly from SQLite database. However the 2 apis that are failing have a server side cache for lookups that have frequent use of profiles, that could bring the system to a crawl if not cached. My guess is for some reason the cache was not invalidated, If this is the case we will need to investigate.

Do both of these still fail? If not does dev tools show what api is failing?
GET /api/profile/node/n023_29806/cmds/accepts
GET /api/groups/nodeRoles/n023_29806

Did any of the recreate APIs fix?
Does a restart of eisyui service fix?

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.

Very strange, the endpoint looks correct, I copied into chrome exactly. Even without an NS in 23 it succeeds, also returned when changed to an NS that does exist. 401 is usually invalid creds so maybe try in a browser? Legacy "/rest/" can work on Port :8080 with local creds, eisy-ui APIs "/api/" require portal creds, and do not work on port :8080 (80 or 443 only)



However, If issue persists after reboot, I'm not sure that is the cause. eisy-ui's server should not have a cache and all request again. To be safe it would be ideal to resolve the 401 first. If this does not resolve it may point us to the issue.

If it does resolve and does not fix the issue, we will need to check for race or missing invalidation by forcing the server profiles to reload. Currently the only way to do this is by event _3 control NI or ND, translates to Node Added or NodeDefUpdated. So, try installing another node server into another slot, which will add a node an force invalidation. We know the Node Added works 100% of the time, but very possible race in Node Def Updated, this is not something easy to see in the UI, like a node appearing.

13 hours ago, bpwwer said:

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.

In the browser, the 401 will come with the WWW-Authenticate header, which tells the browser to prompt for a username/password.

Do you get the promt?

Since this is the hot topic for eisy-ui plugins and it is probably already on UDI's road map I just wanted to mention the lack of identifying if a plugin needs an update along with the update button to go with it.

@Javi, @bpwwer I think it's indeed a cache problem.

Based on the description of the problem, the profile is updated based on the discovery of Roku nodes. When eisy-ui receives the command to install the profile, it uploads the profile files to IoX then calls /rest/ns/${profileNum}/profile/reload. In the eisy-ui log, you will see "Tell IoX to reload the profile in slot ${ profileNum }".

So if the query is done prior to that, I'm not sure there is anything happening to invalidate the cache.

To confirm this:

1. Reproduce the error

2. Look at /rest/profiles/?family=10&instance=xx

   • If it is properly updated, this means the profile was processed successfully on IoX.

3. Lool at /api/profiles (This returns all families and instances known to eisy-ui)

   • Look at the data, under family 10 and the correct instance.

   • If it is NOT updated (or nothing under the instance), this means the cache was not invalidated.

If I recall there may be a gap in coverage for the node def updated event in IoX, e.g not triggering when profile/reload is executed. So could be that nodes created was slower than profiles reload from pg3, so it was rarely seen as nodes created was always after profiles reload

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

1. discover roku_45

2. generate NLS and nodedef files -- write these to the profiles directory

3. call updateProfile() which sends installprofile command

4. call addNode() which sends addnode command

5. gets addnode response back

6. discover roku_44

7. generate NLS and nodedef files -- write these to the profiles directory

8. call updateProfile() which sends installprofile command

9. call addNode() which sends addnode command

10. get profile installation finished

11. get addnode response back

12. get profile installation finished

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

12 hours ago, bpwwer said:

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

1. discover roku_45

2. generate NLS and nodedef files -- write these to the profiles directory

3. call updateProfile() which sends installprofile command

4. call addNode() which sends addnode command

5. gets addnode response back

6. discover roku_44

7. generate NLS and nodedef files -- write these to the profiles directory

8. call updateProfile() which sends installprofile command

9. call addNode() which sends addnode command

10. get profile installation finished

11. get addnode response back

12. get profile installation finished

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

Thanks for confirming, verified gap in coverage, replicated gap, working on fix. Will need to test firmware build due to possible issues . ID: universaldevices/udi/issues/10

Same problem with the Kasa Plugin. Migrated, and now all devices are gone and I get this message when trying to discover. Settings are correct.

Restarting does nothing. Eventually that message with show up again in restart as it's trying to find nodes.

Edited Sunday at 09:45 PM2 days by TRI0N-1
More to add...

Little more info on my setup and versions.


Critical Log:


Error Log:


Sample Debug Log for Kasa: ( Just keeps repeating itself for Long Poll / Short Poll )

Edited Monday at 04:31 AM1 day by TRI0N-1
More to add...

22 hours ago, Javi said:

Thanks for confirming, verified gap in coverage, replicated gap, working on fix. Will need to test firmware build due to possible issues . ID: universaldevices/udi/issues/10

Firmware test completed Pull ID: /universaldevices/udi/pull/24

On 10/24/2026 at 6:23 PM, bpwwer said:

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

1. discover roku_45

2. generate NLS and nodedef files -- write these to the profiles directory

3. call updateProfile() which sends installprofile command

4. call addNode() which sends addnode command

5. gets addnode response back

6. discover roku_44

7. generate NLS and nodedef files -- write these to the profiles directory

8. call updateProfile() which sends installprofile command

9. call addNode() which sends addnode command

10. get profile installation finished

11. get addnode response back

12. get profile installation finished

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

Fix is live in staging

@Javi

The expand all / collapse all works for programs but not for nodes

Is it possible for eisy-ui to remember the last sort order when opening

41 minutes ago, Techman said:

@Javi

The expand all / collapse all works for programs but not for nodes

Is it possible for eisy-ui to remember the last sort order when opening

Where are you finding the collapse / expand all for programs? I am running 1.4.6 of UI and dont see it anywhere?

@Javi Also, when you right click on a node and select GET INFO... there is no BACK arrow.. so you have to start all over by selecting nodes and starting all over at the top of nodes.. Similar to @Techman "remember request" above, it would be nice to take you exactly back to where you were.

4 minutes ago, dbwarner5 said:

@Javi Also, when you right click on a node and select GET INFO... there is no BACK arrow.. so you have to start all over by selecting nodes and starting all over at the top of nodes.. Similar to @Techman "remember request" above, it would be nice to take you exactly back to where you were.

Yes, that's annoying.

@dbwarner5

It's in the latest staging update

Edited 11 hours ago11 hr by Techman

53 minutes ago, Techman said:

@dbwarner5

It's in the latsest staging update.

Strange. I am on the latest there as well, with one exception of IoX, which I wouldnt think would have that fix in it.

Will update soon and see if it fixes it.

@Techman just did the IoX update and the expand / collapse arrows are there...

However, not only are they not working with nodes, but in programs, it isnt expanding all of them... seems to miss about 20%

It would be nice if each click on the arrows, expands one layer at a time and vice / versa.

Edited yesterday at 12:31 AM1 day by dbwarner5

@dbwarner5

All of my programs expanded correctly

On 10/26/2026 at 11:59 AM, Javi said:

Fix is live in staging

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.

2 hours ago, bpwwer said:

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.

Might be different issues, the fix specifically addressed the gaps in coverage notifying clients that a profile changed.

(1) Does eisyui lof show any APIs with errors. (2) Does rest/profiles show the profiles for the other node?