bpwwer

Welcome back! Let me know what happens.

The upgrade available notice is kinda broken. It really needs to have an easy way to see what the upgrade is going to do and a way to skip it (i.e. stop telling you everyday that it's available if you indicate you don't want it). And no, having to go to the forums and search for a post about it is not what I consider easy. When my system is stable, I'm very hesitant to install any upgrades. I'd like to know, before doing an upgrade, that there is something in the upgrade that will solve an issue I am having, if not, I want to skip it. This is for my "production" system. My development systems tend to be kept up-to-date.

That's kind of the opposite of what I would expect. Setting debug just makes the plug-in add more messages to it's log. Possibly it's a timing issue, but the error you're seeing indicates that when IoX sends the command to the plug-in, the plug-in never acknowledges it. If the plug-in is crashing, even the log when it's set to 'Info' should provide some information.

Looks like the requests being submitted to the Jishi server are failing. The error is the same as what I get when I send a request for a speaker that doesn't exist. I believe that changing the names is what's causing the issue. When the plug-in creates a node for a speaker, the key identifier for the node is the node address. The node address is derived from I believe the speakers uid. When the plug-in start or you initiate discovery, the plug-in compares the address to determine the node was previously found and created. It doesn't really care of the name changed. This is by design as in most cases, the address and name remain linked and a constant. The Jishi server, on the other hand, uses the speaker name to identify the speaker. So when the plug-in sends to the commands to the Jishi server, it's sending them using the old name, which no longer exists, thus causing the error. This has been addressed in the plug-in interface where the plug-in author can force the node name change on discovery. I can look into doing this as I believe it would be the right way to handle it for Sonos speakers. However, ST-Sonos uses a different language than most plug-ins and I'm not sure the force rename feature is available to that language. Deleting the nodes and letting the plug-in re-create them should also solve this issue. You'll probably have to delete them both with PG3 and with the Admin Console. If you look at the node listing in PG3, each node has a "Delete" column with an "X" button in that column. Clicking that will delete the node from the PG3 database. In the Admin Console you can right click on the node and one of the options is to delete it. Once it's deleted from both places, restart ST-Sonos and it should re-create the nodes with the correct names.

I believe I ported that from PG2 to PG3. To debug, set the logging level to debug, restart the plug-in and the next time you notice it has hung, download the log and either attach it here are send it to me in a PM. The log does clear and start over at midnight so if it hangs on a Tuesday and you don't notice till Wednesday, the Wednesday log won't show what caused it to hang.

I just published a new version of the plug-in to the store. It adds a debug message that shows what request the plug-in is making to JishiAPI server and provides an improved error message should that request fail. The new version is 1.0.12

@simplextech handed the plug-in off to me, he is no longer working on or supporting the plug-ins he wrote. I attempt to maintain them now. Like I said, from the log, it looks like the plug-in is working correctly so the problem likely lies outside the plug-in's control. It could be that the JishiAPI server is not running. That seems unlikely if you're getting updates from the speakers. You can check that it's running using a browser and going to http://<polisy/eisy IP address>:5005 This will bring up a Sonos API page with information about the JishiAPI. Including information on how you can send commands from the browser. If this doesn't come up in the browser then the server isn't running and we can try and debug the reason for that. It could be that the JishiAPI server isn't able to communicate with the speakers. You can test this by using the instructions above and attempt to send commands via the browser to the speaker. If that's failing, the error may give us some information as to why. The process of sending commands via the plug-in is pretty simple IoX sends a command to the plug-in. This typically has the node(address), command, and possibly a value. The interface layer looks at the node address in the command and forwards it to the that node. The plug-in parses the command and value out of the message sent and executes the command For the PLAY command, it uses the JishiAPI to send the proper http request to the Jishi server Sends a status update back to IoX In your log, I see all of those steps happening and no errors being reported for any of them.

@pjjameso When the custom parameters are correct, it should skip the auto detect of speakers an it should display a notice in PG3 that it did skip auto detect. Here's my configuration. With this configuration I get two speaker nodes; Office Speaker and Basement Speaker. No Living Room Speaker node is created since using the "sonos_" prefix in the key is handled as part of the auto-detect code in the plug-in. So I'm pretty sure it is bypassing the auto-detect code. But since I have no real speakers, I can't be 100% sure.

The problem is that the Sonos topology is dynamic and IoX programs are not. ST-Sonos maintains a list of "coordinators" which are speakers that manage a grouping. You can only join a speaker to a coordinator. IoX programs that use the join command also use that list, but since IoX doesn't ever use strings, it uses the index to the coordinator name on the current list. If the coordinator list changes (which it may as speakers join/unjoin or go on/off line, or the plug-in is restarted) and the program executes, it will execute using the original index into the list as it was at the time of program creation. When that index no longer represents the same speaker/coordinator, you have problems. The ST-Sonos plug-in is correctly representing the Sonos topology. But IoX provides no way to update a program's parameter list dynamically. What I'm attempting to do with the Sonos plug-in is to create a fixed, never changing list for the programs. When the plug-in starts, it creates a list of speakers (not coordinators). It then uses this list as the parameter to IoX programs. Since the list is always fixed (well as long as you don't allow the plug-in to restart and dynamically build the list) the program's parameter index should always point to the same speaker. The main problem with this is that since it is a list of speakers and not coordinators, if the program executes and tries to join with a speaker that is not currently a coordinator, it's going to fail. However the program is trying to do what you asked it to do. I don't think you'd have the same issue with network resources as I think you'd be specifying the coordinator name embedded into the network resource and not an index into a changing list of coordinators. The only way this could be "fixed" is if IoX programs would save the name instead of the index in the program. But given the IoX design, I'm not sure it's even possible without completely re-designing IoX's program infrastructure. I'll continue to try and get my changes to the Sonos plug-in to work, but I'll need debug logs since I can't test much beyond creating some fake nodes. An including the time frame you ran the test helps because debug logs can be 20,000 lines or more and searching them for when you were testing can be difficult.

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.