bpwwer

Yes, it does use modbusTCP, but it's in 'C' so I'll just post pseudo code here. This is a function that takes the IP address of the inverter and returns the watt-seconds generated over the past minute. /* set up the context and connect to the inverter with ipaddress 'ip' */ mb = modbus_new_tcp(ip, 502); modbus_connect(mb); /* configure the modbus connection */ modbus_set_response_timeout(mb, 2, 0); modbus_set_byte_timeout(mb, 0, 1000000); modbus_set_slave(mb, 1); /* Set modbus slave ID */ /* * According to the sunspec, register 40094 is the * AC energy production over all time in watt-hours. * This is a 32bit value. * * Does this represent the power going out to both * the general output and the backup output? */ wh = read_32(mb, 40094); sf = read_16(mb, 40096); /* scale factor: 1, .1, 10, 100 */ /* convert the register scale factor value to the actual scale */ /* sf == 0 then scalef = 1, sf == -2 then scalef = 100 */ modbus_close(mb); modbus_free(mb); ws = (long long)wh * (long long)factor * 3600LL; ecm_log(L_INFO, "Inverter : %lld (w-h = %u scalef = %u)\n", ws, wh, sf); return ws; This is a I also have a solaredge meter installed and the code is basically the same as above, but uses different registers to get the imported and exported AC energy values. The register reading functions look like: /* * modbus_read_registers start register seems to be one off. * I.E. if I specify 40090 as the start I really read 40091 * * So should I be subtracting one from the start register? */ static uint32_t read_32(modbus_t *mb, int reg) { int rc; uint16_t tab[2]; uint32_t ret; rc = modbus_read_registers(mb, (reg - 1), 2, tab); if (rc != 2) { ecm_log(L_ERROR, "%s\n", modbus_strerror(errno)); return 0; } ret = (tab[0] << 16) | tab[1]; return ret; }

Many years ago I had software to pull data from both my inverters via the local IP address (one wired, the other wireless). I combined this with data from a energy monitor that CT's on the incoming connection from the grid. All this data went into a database. I still have the code for that program but I don't use it anymore. I can dig back into it if you have any questions about using the local ip address to get data.

I'm glad it's working now, but you really should not have to go through all that, it's not right. Tagging @Javi and @bmercier in case this is something they'd like to take a look at. I do have a bridge and a single shade, but it worked as expected when I installed using the PG3 store and then migrated it to eisy plugins. The Ryse plugin is a pretty basic plugin; static profile files, connects to bridge, queries for shade devices and creates nodes for each device found. It should not require any reboots, eisy-ui reloads, logging out/in or plugin restarts when using eisy-u and the current packages.

The only other thing you could try is to delete the plugin and then install it. I've had to do that before but usually because I'm changing things that get cached while developing a plugin. I have no way to debug why eisy-ui doesn't have the NLS file info, which is what appears to be happening. The plugin sends the file to IoX and that's the last interaction the plugin has with it. This is something UDI will need to track down so if you haven't yet, you should open a ticket.

I think I found and fixed the node status. Do a re-install and it should pick up the fix. I didn't change the version number.

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!

test as it won't let me post what I want 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%20KingI don't see anything relevant in any other log. Is there a way to see what is being sent to eisy-ui?

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.

I went and switched back to the original code base and added new features from the hatopg3 one. There are still some issues (some that seem to be bugs in eisy-ui) and I can't really test much. I created a simulated speaker but it doesn't handle any commands, it just allows me to see that the node displays correct. You may have to delete existing nodes before running this version. The version number is 4.0.0 so it will be easy to see that you're on the new version.

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

The others; speed and status are generic names that IoX assigns internally for those driver types so they're really missing too.

So maybe it's a similar, but different issue. The only way I know of to check eisy-ui is to look at http://eisy.local/api/profiles Unfortunately this is a big XML file. The browser should allow the option to show it formatted and then you have to search for ryse in there. You should find something like this: "nodedefs": [ { "id": "shade", "nls": "shade", "icon": "Output", "name": "RYSE SmartShade", "properties": [ { "id": "ST", "editor": "bool", "name": "Online" }, { "id": "GV0", "editor": "shade_position", "name": "Position" }, { "id": "GV1", "editor": "shade_state", "name": "Position State" }, { "id": "GV2", "editor": "power_type", "name": "Power Type" }, { "id": "GV3", "editor": "power_level", "name": "Power Level" }, { "id": "SPEED", "editor": "shade_speed", "name": "Shade Speed" } ],The name field under GV1, GV2, etc. is the label. If it's there, eisy-ui should be showing it, if it's not, the eisy-ui isn't syncing properly (most likely). You can also check http://eisy.local/rest/profiles. This one should be the same, but comes directly from IoX instead of from eisy-ui. If IoX is correct and eisy-ui isn't, is definitely is a sync problem.

I've been making a few changes and I've pushed them up stream so they are available. You just need to re-install to pick up the change. But I'm still having some issues getting things to work properly. I'm starting to think it may be easier to go back to the original code and just incorporate some of the code from the backend.py file so that it's gets the Amp Multi support. I may attempt that over the next couple of days.

I understand and it's frustrating. I've been working with @Javi on another plugin that had issues migrating. It took a while to track that one down and as a result, there have been a couple of fixes. You don't mention any versions or even if your on the latest production/beta/staging release so the assumption is most people are on the production branch which is why he recommended that wait for the fixes in staging to make it into production and retest. I was confirming that the plugin seemed to migrate fine using the staging branch. The fact that the labels are missing after migrating back to PG3 is most likely another symptom of the same issue. When the plugin starts, it sends the profiles files (which is where the labels are defined) to IoX. There's some process to synchronize those with eisy-ui. That's were the problem is and that's also what the fixes @Javi mentioned address. With the admin console, the sync happened when the admin console was started. There's not really anything you can do other than wait for the fixes. It's possible that something will trigger the sync and the labels will just suddenly show up.

The plugin doesn't support populating that field so it should be blank. I just migrated the plugin and everything seems fine. But I am running on the latest releases from staging. I've restarted the plugin, reinstalled the plugin and it continues to show all the proper labels.

Looks like eisy plugins isn't seeing the NLS file. That's what defines all the strings for label names and maps the numeric values to strings. I take it a restart of the plugin doesn't fix it? If it doesn't then either the migration didn't fully migrate all files or eisy plugins thinks there's something wrong in the file and doesn't load it. @bmercier @Javi

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

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.

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.

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.

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

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

Ok, we'll go with that. It should be in the non-production store now (or refresh the store listing to see it). It's called SonosV2

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.

The issue reported was that the plugin wouldn't start after migration. Your log shows the plugin starting and running correctly. The error messages being shown are actually debug messages that accidentally got left in (and have been there for about 4 years). I removed them in version 1.0.28