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.