bpwwer

Disconnected means it was unable to connect to the local (or configured) IoX. There are only a few different reasons it wouldn't be able to connect and viewing the log should reveal which. 1) the ISY software isn't running. In this case you also would not be able to start the admin console. The log would show a connection refused error. 2) The IP address is configured wrong. By default it's using the local address 127.0.0.1:8080 which is the local IoX. If you didn't change the configuration, then this should be correct. Again, you'll get a connection refused if it trying to connect at the wrong address. 3) The credentials are wrong. It starts with the default of admin/admin, but is supposed to update them if you log into PG3x with something different. The log will show 401 (authentication) errors in this case. You can update the credentials manually in PG3x via the ISYs -> Edit current ISY menu.

PM me the PG3x log file

An update on the bug. " a player drops and a topology change event occurs. If a topology change occurred which changes system.zones, but the group this thing was in did not get updated in a timely manner for some reason, then that is exactly the behavior you would expect." So there are two possible ways this bug could be triggered. A fix has been proposed. I'll keep monitoring it and update the node server as soon as a fix is available.

I don't recall any discussion about merging them, but then I didn't really follow discussions about them since I don't have any Sonos devices. So it's somewhat strange that I've ended up maintaining both. Both use different programming languages with different libraries so they can't really be merged. If there's a difference in feature sets, one could be updated to include all the feature of the other making one more desirable than the other, but I don't have information on the feature sets. At this point, ST-Sonos is likely to be better maintained simply because it's not free.

The author of the library responded and said this is likely caused by the group coordinator player dropping or being demoted. He think it might be a bug so there's hope. From your log @Ross, it happened at about 3:32 in the morning. @carealtor, yours happened at about 8:46 at night. Maybe once you stop the speaker, it takes a while to timeout and then the speaker is demoted from the coordinator and the next volume notification for the group then fails.

Yes, year to date, and month to date.

The good news is that both of you are seeing exactly the same issue. The bad news is I have no idea how to fix it. It appears to be that something Sonos is sending out a notification related to group volume or group mute, but the group has no members. This triggers an exception in the library which then gets trapped by the node server. So I'm guessing the real problem is somewhere in the library which isn't something I can change. I don't know if this is enough information for the library owner to debug/fix, but I'll create an issue for it.

First off, I want to thank everyone for responding. There are a lot of good suggestions and comments. I do want state that this poll was something I put up without any prompting from UDI. We've all experienced issues with the updates lately and I just wanted to get some idea if pushed updates might be helpful. And personally, I've been thinking about the all the problems with the PG3(x) node server auto-update feature. Based on this, I've decided to remove the auto-update from PG3(x). Instead, it will still pop up notices when updates are available and it will add an "Update" button to the node server details page that you can use to update when it is convenient for you. I've also been thinking about the ability to roll-back to the previous version of a node server. I think the ability to do this exists today, but it needs the node server developer to configure the store entry to support it. So I'll experiment with this and if it works, I'll provide the node server developers with instructions on how to set it up. And while I don't work any of the other update process, there is on-going work to make the process more robust and provide better communication about what is happening during the update. The poll remains open, probably for another week so please continue to provide comments.

Good idea @gzahar This is probably doable. I've had the same thought myself. I'd have to look into the security aspects of doing this and I'd rather the IoX had this built in.

@Ross The original developer of the ST-Sonos node server has stopped supporting it. He provided me access to the code so I am trying to support it, but I don't have any Sonos devices. If you send me a log package next time it crashes, I'll take a look.

Unfortunately, I am not the developer of that code. I can only make changes to the PG3(x) code base, not the IoX firmware or other UDI components on the Polisy/eisy. The IoX firmware needs changes for it to be able to send commands to PG3(x). If that was done, I'd be more than willing to update PG3(x) to accept those command for node server control. And I agree, we should be able to control node servers from IoX, but not my call.

Thanks @Ross I appreciate the comments and thoughts. I understand the desire to see every possible piece of data, but there has to be limits. If we're going to add rain accumulation since the station came on-line shouldn't we then do that for everything? Why not accumulated UV ratings since the station came on line. Or accumulated temperatures, dewpoint, humidity, wind, etc. All of these are meaningless numbers. I could just have the node server generate an ever increasing random number and it would have just as much meaning. I also understand the point that you may not have a use for data until you see it. And if we were talking about a specific sensor reading, I'd agree. Real-time sensor data has meaning. The example of soil temp has meaning, summing up all the soil temp readings since your station came on line does not. I've also been trying to get across the point that making changes/additions to node servers is not "free". Even what can seem like a simple change can have unintended side effects. Adding additional code means more testing and more effort over the life of the product. So if you're going to ask for a change, you should be able to articulate why that change is important.

I'm sorry that offering to provide a cost estimate rubbed you the wrong way. But I create and sell node servers and part of my business and I have to make decisions based on how that will effect my business. If you were asking for something that I though would enhance the product I'd likely just do it, but despite me asking with every reply, you still have not shown how this would enhance my node server. It's not a question of how hard or easy it is to do or even a question of interest. I certainly don't think I know best how data can be used or not. I can be convinced. Provide me with a real-world example of how reporting rain since system installation can be used to do something you can't do without it. That's all I've been asking for and I don't think that's unreasonable. There's no question that the NC data is valuable. I thought that's what was being returned in the server queries and didn't realize that they had added new fields for that until I looked it up after you asked about it. WeatherFlow doesn't notify me of changes to the their API. Updating that is on my list and is fairly high on the list.

You still have not described how you will use the data. The data is only valuable if it can be used in some way. Displaying it so you can look at it and say "Wow, my system has recorded 4956 inches of rain since I started collecting data" isn't making use of the data. The reason we collect data is to drive decisions with that data. In general, for home automation, that means looking at real-time data and making decisions in real-time. But that doesn't exclude making use of historic data. And I'll say it again, adding features is not free. Since I can't see any way adding this would increase sales, I can work up an invoice on how much it will cost to add this for you if you'd like.

This is the problem. IoX doesn't have any way to issue a command to PG3. There's no API in IoX that lets it send commands to PG3. You can send commands to node servers, but that won't work because you're trying to restart the node server, it probably isn't alive to get the command. There's also security issues to think about. You can issue a restart manually because you're logged in and authorized to do that.

I understand the desire to have a method to recover with things go bad in node servers. I made some proposals for this before PG3 was developed, but other things took priority. Because of the way things are designed, the only practical way to do this is to have node server status built into the IoX firmware so that that IoX can detect when a node server needs to be restarted and code added to IoX to send commands to PG3 to restart node servers. We've tried to work-around this on the node server/PG3 side by allowing node servers to have a "status" value to indicate it's health, but that is really only able to detect if PG3 loses connection to the node server, not really if the node server is operating correctly. But this is only half the solution. We still have no way for IoX to signal PG3 that a node server should be restarted, there's just no way to do that with the current IoX or PG3.

PG3x version 3.1.23 was extra chatty as we used that to do some initial testing for PG3x remote access. That has been removed in the latest version 3.1.24 of PG3x.

I still don't understand why displaying this data is important other than because you want to see it. The node server (well all node servers) are used to get data into the ISY/IoX home automation controller. Historical data, while interesting to view, isn't typically useful to enhance the control functions. rainfall year to date could be of some use in controlling irrigation, but a three year total, not so much. Because it's not free. It takes time to add features and more features means more complexity in the software and more complexity means more effort to maintain the software. I've been providing a WeatherFlow module for a couple of different Home Automation systems for over 5 years and no one has asked for this before. So I'm pretty confident that adding this will not increase sales at all. So it really comes down to a business decision. Is it worth my time to add this feature? Or do I use that time for something else that will generate more income? While it may seem simple, it's not. WeatherFlow doesn't make the data available via a database interface. If we could just do something like "select * sum(rain);" it would be simple. But the API can only query over specific time frames, "for all time isn't specific" That means making queries using earlier and earlier time frames until it returns an error and accumulating all the records returned with each query. Because the ISY/IoX isn't designed to maintain historical data, this process would happen every time the node server starts. How much additional time it adds to the startup will depend on how long the station has been in operation, increasing over time. Over time, because you're asking for all of station records, WeatherFlow may have to put limits on the queries. So no, it's not simple, and there's a possibility of negatively impacting the node server performance.

The node server is using the official local API from WeatherFlow https://weatherflow.github.io/Tempest/api/udp/v171/ According to that, there isn't a field 19. Looks like they changed the remote API at some point to split the NC rain out and added new fields. The node server is using the same code to process both local and remote as they're identical up through field 17. So it's not as simple as just switching to field 19 as that will break the local handling. I'll add support of the NC fields with remote to the todo list. I didn't say it would be hard to add rain for all time, I just do see how that could be at all useful in a home automation setting. Adding features that have no real value comes at a cost. It makes the code more complex and has to be maintained. I'm not charging enough for the node server for me to want to do that. The ROI for me, just isn't there.

Upgrade PG3x to 3.1.24 and you will be able to delete node servers again. It was a bug in version 3.1.23. There isn't any way to delete node servers via ssh.

When/if it happens again, capture the node server log and send it to the Tesla node server author.

PG3x uses the UDX component to authenticate. A 401 means that UDX specifically returned that error to PG3x to indicate that the username/password is not correct. I don't really know how UDX does that check, it may actually use IoX since it is supposed to be the same username/password used to log into IoX via the admin console. So one possibility is that IoX isn't running or is in a state where it doesn't respond properly. Can you use the admin console to log into IoX at this point?

If it's reproducible, it would be good to submit a support ticket and let support take a look at your system to try and understand why that is happening. There should be no difference between rebooting and power cycling the eisy. However, I've experienced cases where reboot from the AC simply doesn't work. I.E. it doesn't actually cause the system to reboot.

Not the node server, pg3x needs to updated and you do that via the AC. The current version of pg3x is 3.1.24.

Great comments @MrBill I agree that options are always good, but options aren't free. It takes resources to implement them in the code and more resources to maintain multiple options. I didn't want to make the poll to complicated and appreciate the comments like yours to provide context to the results.