bpwwer

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.

Since you see all the node's values, it appears the migration was successful. The "${sys.node.n001_forecast_0.GV1}" is the way to identify that node value in messages/notifications. What it's basically saying is that you want to substitute the value of node n_001_forecast_0 GV1 value into the message. From your screen shots, everything looks correct. When you say the notification is not working, do you mean that you get a notification email, but all the ${sys.node.n001...} values are blank? Or do you not get the notification email at all? If you're getting the email but it's all blank, it may be that IoX is somehow out of sync with the migration and is still trying to get those from the PG3x version. Rebooting the eisy may resolve this. @bmercier is this possibly the case?

I believe that notifications using those node variables should work the same after migration as they did before. Can you still see the Climacell nodes with those values listed under the Nodes menu in eisy-ui? If you don't or you get an error when selecting the node, the plugin didn't migrate correctly. If the node looks correct this is probably a question for @bmercier

No, don't try to create the nodes manually. The plugin won't know they exist so it will never try to update them. One of the main reasons nodes don't get created is because there's something wrong in the info being used to create the node. There are restrictions on what can be used for address and names and the plugin may fail to catch everything before trying to create the node. In the plugin log there should be lines like: "Adding Roomba 980: name (address)" so if you see those, then the plugin is attempting to create the node. At the same time (using the log timestamps), the PG3 log should be making http requests to IoX to add the nodes. If you send me the full log package which includes both the plugin log and the PG3 log, I can take a look. Keep in mind that both logs will reset at midnight so you need to start (restart) the plugin and then download the log package if you haven't done so today. You can PM the package or email it to bpaauwe at yahoo.com

I've noticed it too, but just in the past couple of days. Seemed like it stayed logged in longer a week or two back.

Probably something with the data feed, either missing or the format changed. It's not like the plug-in would suddenly decide to stop reporting the UV index. I don't know if I can still get a feed from them so if it continues to show zero, get a debug log when you can and I'll take a look.

@stillwater I understand what your doing as I also created a couple of node server like that back then. I don't think the API is going to to change in a way that will break your node server, but it may get harder for you to manage it. The API calls your node server is using are the same ones that PG2 and PG3 use, but they handle all the management so that everything on the admin console's plugins menu is not needed. In fact, it tended to confuse people as they would sometimes try to use that to configure PG3 plugins and overwrite the configuration that PG3 had done. That's likely why you don't see that menu/capability in eisy-ui. @bmercier will have to comment on the long-term viability/support for your type of node server. If you do want help converting it to a PG3 plugin, I can do that. In that case, you would have to put it in the local store.

I just pushed version 2.0.18 of the plug-in to the store. So give that one a try.

@jwagner010 Are you running PG3 or PG3x on the Polisy? I know that none of the changes being made for eisy-ui are being tested on PG3. I'm also pretty sure that nothing is being tested with an ISY994i and it's firmware version. They aren't intentionally trying to break that setup but it could happen. My current plug-in development environment is still PG3 based so I can test on that if needed.

He has 3 different Nuheat plugin repositories. The python one is at least 2 years older than the two javascript based versions. The version I've been maintaining is based on the private version and I've made updates to it since then. Oh, looking at the python version more closely, that looks like a PG2 node server, not PG3. Yes, I can update the store entry/db or if you want to take it over, UDI can switch the developer field in the database to you.

if you go to the polyinterface github, there are instructions in the Oauth2.md file on how to add oauth2 support into a plugin. https://github.com/UniversalDevicesInc/udi_python_interface.git except that the Nuheat plugin is written in javascript and I don't think the javascript interface got any of the updates for oauth2. It does have some basic support, but it's not documented. I think @simplextech was really the only developer that created plugins using javascript so that interface isn't nearly as well supported as the python interface. If the plugin needs a re-write anyway, maybe it makes sense to switch to python. Do you have a Nuheat thermostat? Or were you able to get credentials without one?

Umm, I seem to have lost the memory of sending you an email. I'm a bit confused.

@Panda88 If you figure anything out, let me know. The plugin interface does have the ability to do oauth authentication which is what the new API needs, I believe.

I personally would do a package upgrade from the admin console first. That way the Polisy is running the very latest supported versions of everything for the Polisy. Then do the manual ssh package upgrade to get the new eisy-ui and it's dependencies. And, yeah, back up first. I sometimes forget to do that and it's not always ended well.

@bmercier Is this the right place to report issues with the integrated plugins feature?