bpwwer

The only change I made was to the command sent for turning the chamber light on/off. Since none of my printers have a chamber, I can't test it. The run/pause/stop commands are all working for my printer. The docs I have indicate that the same commands should work for all models. But as I said, I'm running older an firmware version and given some of Bambu's recent changes, I can't guarantee that they work with the latest firmware. For the gcode state, it does not appear to be a problem in the plug-in. I see the plug-in get the proper state from the printer, I see it send the proper state to the IoX and I see the IoX respond by changing that state. Why programs aren't detecting the change in state is not something I can answer. It seems like an IoX bug to me, but it could be just the way IoX was designed to work with that type of value.

Sorry, I saw your post show up initially but the title didn't register that this was for the Bambu plug-in. I just did some testing with my A1 Mini and the plug-in is working correctly. However, the programs on the isy don't seem to register that change. You can check that the plug-in is changing the state by going into the nodes tab for plug-in in PG3x and watch the gcode state/GV10 value. The number should change as the state changes. I simply started printing a file and it switched to state 2 (RUNNING) almost immediately. I then stopped the print and it switched to state 5 (FAILED). I also checked the program status on the admin console and it is running the program on a state change (I see the last run time changing), but as you observed, the status never changes to TRUE. This may be a bug in the isy software or it may be the way it is designed to work with this type of value. Since PG3x is sending the updated values to the isy, it seems like a program should be able to detect those changes. Stop, Pause, Resume all are working with my A1 mini. After researching it, the chamber light command I send may be wrong. I can change that, but I don't think I can test it as it doesn't seem to apply to the A1 series. I haven't been able to find a command that turns on the camera light for my mini. There also could be some issues depending on the firmware version. I stopped updating the firmware on my A1's after they announced some changes that I wan't happy with.

@photogeek54 Great job! Those of us using the plug-in really appreciate you finding and fixing the issue.

The plug-in does not need the station to be shared publicly. When configured to get local data, it is getting the data the hub is broadcasting over your local network. There are only three things that can interfere with that. 1) the broadcast won't typically cross subnet boundaries (and based on your initial post, that is not a problem). 2) A firewall setting is blocking the UDP port internally (not something you'd typically set up). 3) Another program running on a machine on your network opens the address/port in exclusive mode (meaning nothing else can then open that address port). When configured for remote, you're requesting your data from the servers (and authenticating with the API key). So again, public sharing not needed. The "Station ID" and device address are two different things. With a Tempest, it's most likely a one-to-one relationship. However, with the early weather stations, a Station ID" would usually have two device addresses associated with it -- an Air device and a Sky device. The plug-in uses the Station ID to query the WeatherFlow server to get the device addresses, your preferred units, and historical rain data when it starts. If you configure a wrong/invalid station id, I don't think you'll get any nodes created, for sure you won't get any device nodes created as it won't be able to find any. When you get a replacement Tempest, it will have a different device address so you'll want to delete the node for the currently one from the eisy using the admin console. It's been too many years since I got a replacement Tempest to remember the exact steps. It may be easiest to simply copy the token, delete the plug-in, and then re-install it.

Somewhat off topic ... While I respect the right for areas to choose to either stay on DST or eliminate DST, I think it's a bad idea to stay on DST. The ISY software is actually a good example of why. To set the time, you configure the time zone and check if you switch between DST and standard time. So you (British Columbia) can't just click DST off because your time is no longer the same as what it should be for your timezone. You'll have to switch it off and then set the timezone to some other timezone that has the right standard time to match your non-standard time. It also seems like this could effect anything that's getting it's time from GPS or maybe even cell towers. Thinks like the navigation in my car seem to know what timezone I'm in and when to switch the time as it did that correctly yesterday and it's only connection is via GPS (no wireless connection and now cell connection). Changing timezone boundaries to compensate for places that stay on permanent DST seems like it would be a very difficult problem to solve since that's a global, not local change. But then, maybe all this has already been worked out and won't be a problem.

Don't think it's related to sunrise/sunset calculations. I have a lights out program that runs at 11:18pm, it didn't run last night because of the time change (as usual), but if it follows the same pattern it will run tonight fine. Maybe it is ignoring time-of-day and pre-calculating all program start times at midnight so possibly my 11:18pm program would have ran at 12:18, but probably not since that's after midnight. My lights on program did run, but I don't know when since we weren't home, but the lights were on when we got home. The best solution would be to just get rid of daylight saving time.

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.