bpwwer

I've uploaded a version of the Sonos plug-in to the non-production store. This version supports adding specific speakers and doing so, disables the auto detection of speakers. I've added the join/unjoin commands. I've tested it as much as I can by creating a speaker simulator, but that really just allows me to create the nodes, it doesn't allow me to test the join/unjoin commands as I can't figure out the communication needed to do that. To add specific speakers, you use a similar method to adding speakers manually, by adding custom parameters: key = only_<unique> where <unique> will be the unique speaker address. For example: only_living value = {"name": "<speaker name>", "host": "192.168.1.43"} where <speaker name> is the name of the speaker (and will be the node name) You can add as many as you want, but I think only the first 5 will currently work. There are a number of cases that I don't account for and have no idea what will happen if you attempt them. You are supposed to only join a speaker to a coordinator, but that's what causes all the trouble with ST-Sonos, which speakers are coordinators changes dynamically. My implementation in the Sonos plug-in ignores that. It will allow you to attempt to join a speaker with any other configured speaker. If that speaker is not a coordinator, it should ignore the request, but may crash. I believe unjoin will fail silently if the speaker is not currently joined, but again, it could crash. The list of speakers generated for programs should be always be the same (for the same configuration). I think this handles your use case so try it out and let me know.

The answer is probably a qualified yes. Both plug-ins are designed to do auto discovery of the speakers on your network. The Sonos (not ST-Sonos) plug-in does give the option to manually add speakers, but it does this after doing the auto discovery, not in place of. It would be possible to add custom parameter support to the ST-Sonos plug-in where you specify which speakers you want. Then during auto discovery it would only add nodes for speakers that it found that matched what you configured. I don't really want to try this, I'd be modifying code I don't fully understand without being able to really test. It would be a lot easier to modify the Sonos plug-in to only do auto discovery if no speakers were manually specified. This could be a breaking change that effects other users of this plug-in. Also we're back to me trying to add the join command too. Of the two options, I'd rather attempt this as I feel more comfortable modifying the Sonos plug-in vs. the ST-Sonos plug-in.

I'm not sure. I don't have any Sonos devices so I can't do any debug/testing other than analyzing your log files. Doing that I don't see anything that looks wrong. At 12:20:45, it looks like you tried to send the PLAY command for the speaker identified by 7ad3b3a. This is from the PG3 log. After the command is sent to the plug-in, there's a message to IoX requesting that it set 7ad3b3a's status for the ST value to 1. In the plug-in log, there's an error "NS: undefined". This error is coming from the interface between plugins and PG3. I've seen this a lot from ST-Sonos and it seems harmless. But since I can't run the plug-in, I can't debug where in the interface layer it's happening. The plug-in code for the PLAY command is pretty simple: call the API's play command for the device set the ST value to 1The plug-in uses a third party library, JishiAPI, to communicate with the Sonos devices. From the logs: IoX sends the command to the plug-in The plug-in sends the command to the JishiAPI The plug-in updates the status Which is indicates that the plug-in is doing what it is supposed to do. Now the JishiAPI communicates with the Sonos devices by sending http requests to a server component called node-sonos-http-api/server.js. This component is supposed to be installed when you install the plug-in and started when you start the plug-in. If it is not running, the plug-in would not be able to do any communication with the Sonos devices. You indicate IoX is getting updates from the device which implies this component is started and working.

I've played around with ST-Sonos and modified it to create fake zones and speaker nodes. I'm not sure I can explain this well with just text but I'll try. The Sonos zone topology is dynamic. As you do joins/unjoins and if speakers go on/off line Sonos changes the topology. IoX/PG3 can adapt to those changes somewhat but the problem becomes very apparent if you try to use programs to change that topology. Say you have 4 speakers and none have been joined. This will give you a topology that looks like: zone 1 / speaker 1 zone 2 / speaker 2 zone 3 / speaker 3 zone 4 / speaker 4You create a program that says join speaker 4 to speaker 2. Now your topology looks like: zone 1 / speaker 1 zone 2 / speaker 2 & speaker 4 zone 3 / speaker 3Now you go back to the program interface and you only have 3 options to join with instead of 4. Any program that made use of zone 4 will fail because zone 4 no longer exists in your topology. IoX programs created with one topology will possibly make no sense if that topology no longer exists. There's no way from PG3 to fix programs created in IoX, it doesn't have any way to do that. So I can't really see anyway to resolve the issue your having. The ST-Sonos plug-in mostly adapts to the change in topology but there isn't any way to communicate this to IoX and IoX has no way to adapt.

The Sonos plug-in and the ST-Sonos plug-in were completely separate efforts. I ported the Sonos plug-in from PG2 to PG3 for UDI since the original author seemed to have abandoned it. The original author of ST-Sonos handed it over to me after he decided to stop writing plug-in and I think moved on to other HA technologies. I'm generally OK with trying to fix issues, but adding features is quite a bit more work for code I didn't originally write. I also don't have any Sonos devices so not only do I have to rely on others, like you, to test any changes I make. I also need some direction on how this should work within the plug-in. I understand the general concept of a join(), but how that should be implemented on a speaker node and what it should look like are where I'd need help. I can't run the plug-ins beyond making sure they load, without any Sonos devices, I can't create nodes. Another thing, looking at the library that the plug-in is using, it's using a version of the library from 2019. I don't know if it's possible to update to the latest version without re-writing the plug-in. I'm willing to try, but I'm not sure it's possible without me having the actual devices.

Well I haven't changed anything and there's been no movement on the issue reported to the Emporia library maintainers so it must be something Emporia did, maybe they were having other issues with the change and rolled it back.

The plug-in uses a third party library to interface with the Emporia servers. 4 days ago, this issue was raised for that library: Once that issue is resolved in the library, I can update the plug-in with the new version. But until then, I don't think there's anything I can do to fix it.

The primary purpose of the "remote" option was so you could get data from a station that was not physically present on your local network. For example at a vacation home/cabin. Originally, you could use to get data for a station near you like you're trying to do. If that's not working then WeatherFlow has decided to block that for privacy reasons. Although I can't think of why looking at the station data via the map vs. via the API would have different privacy restrictions.

From the log, these are the nodes that the plug-in is creating: 2025-12-11 10:41:30.915 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Bedroom Sound(zone_1_1) [None] 2025-12-11 10:41:31.915 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Laundry Room Sound(zone_1_2) [None] 2025-12-11 10:41:32.916 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Sunroom Sound(zone_1_3) [None] 2025-12-11 10:41:33.918 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Porch Sound(zone_1_4) [None] 2025-12-11 10:41:34.919 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Game Room Sound(zone_1_5) [None] 025-12-11 10:41:35.920 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Kitchen Sound(zone_1_6) [None] 2025-12-11 10:41:36.922 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Deck Sound(zone_1_7) [None] 025-12-11 10:41:37.923 Thread-6 (start) udi_interface.interface INFO interface:addNode: Adding node Garage Sound(zone_1_8) [None]So it doesn't look like the plug-in is creating those extra nodes. However, after it has set the initial values for those 8 nodes, it reports 5 errors: node address zone_1_10 does not exist ... node address zone_1_14 does not exist when it tries to query those nodes. The log doesn't show the plug-in creating them and it's not clear from the log where they are coming from, could be either the PG3x database or IoX. I'd suggest deleting them from both places and then restart to see if they come back. How they got there in the first place is something I have no way of knowing without seeing a debug log from the plug-in from when they first appeared.

I suspect that something (IoX or PG3x) is saving the UOM values and unless something actually changes them back, they'll stay that way. I faked the creation of a node (since I don't have an api key) and the plug-in created the node with the correct UOM's and the admin console shows the node correctly as well. You can try first just deleting the node from PG3x. When you display the nodes for the plug-in, you can click the [X] button under Delete on the right and it will delete the node from PG3x. Restart the plug-in and it will recreate the node. You may also have to delete the node from IoX but that may mess up any programs that are using that node.

I really can't explain, nor do I have any suggestions other than to re-install the plug-in. The plug-in node defaults GV2 to UOM 25 and no where in the code does it change that. So how or why it got changed to UOM 17, I have no idea. For the temperature values, they should be UOM 17, that's what the data from the device shows. It's reporting the following: targetTemperature': 62, 'temperatureUnit': 'F' and that's the data the plug-in uses to determine the temperature UOM.

It is supposed to look at the units that the sensibo is set to and dynamically determine which units to use (C or F) when sending updates to IoX. I don't believe that PG3x's node display is dynamic so it should just be showing the initial units that the plug-in defaults to before it gets any updates from the sensibo. But that's not something I've ever looked into. The plug-in's debug log level should include messages showing what data is coming from the sensibo. There's nothing in the plug-in that is modifying the UOM of the power state. Looking at the PG3x log should show what the plug-in is sending to IoX when GV2 is updated. I don't believe it should be sending any UOM, so it should be defaulting to default UOM which is 25. If the log shows the plug-in sending the wrong UOM, then it may be a bug in the plug-in -> IoX interface library. If it's not, then it may be bug in IoX.

This is one of the plug-ins that I ported over from PG2 to PG3 for UDI. I don't have a Sensibo so I'm not able to do any debug/testing on this plug-in but I do try to fix bugs when possible. Since the plug-in uses the Sensibo cloud API, it's very possible that if it fails to connect to the cloud service that it will stop working and need a restart. That should show up in the log. Note that PG3x won't display historical log entries, you'd have to download the log to get the entries prior to is hanging/stopping. The profile files have GV2 using UOM 25 and restricted to values 0 and 1 with those mapped to Off and On. This matches what's defined inside the node itself: {'driver': 'GV2', 'value': 0, 'uom': 25, 'name':'Power'}, which is what PG3x should be displaying. I have no explanation for you seeing GV2 with UOM 17.

Not really. I haven't been able to find anything incorrect in the plug-in. What seems to happen is that after sending a few commands to the device, the device just stops responding and doesn't send anything else to the plug-in after that. I see this after about 3 days and I send commands to my bulb device 2 time a day, so that seems to match what you're seeing. I wonder if it's a race condition between polling the device for updates and sending commands. It may be possible that a poll happens while the command is waiting for a response. I guess one way to test this would be to increase the polling interval from 60 seconds to something really big like 6000 seconds and see if that helps. So just ran an experiment. I changed short poll to 6000 and was able to do at least 30 on/off cycles without any issues. Then I changed the short poll to 20 seconds and it failed after 3 or 4 on/off cycles, well it set the on-level to 0 so on stopped working. So I'm not sure that's the same failure. I've set my short poll to 600 now and I'll let it run and see if it fails after a few days.

I've been busy with other stuff and haven't had time to work on it lately. I'll get back to it soon.