bpwwer

Currently the only "feature" difference between PG3 and PG3x is that PG3x is getting remote access support. We can't do remote access for PG3 which is one of the main reasons PG3x was developed. There are internal changes in PG3x that make the node servers more secure but that's not something that is user visible. There are no other plans for PG3x specific features other than those that are enabled because of the remote access framework. An example is that there is a Ring node server that will piggyback on the remote access framework and thus, will only run on PG3x. As mentioned above, Polisy is capable of running PG3x and there is a migration path available to switch. We can migrate from PG3 -> PG3x but we don't have an easy way to migrate back so make sure you make backups of everything before attempting to migrate PG3 -> PG3x.

Thanks! That's not how I thought they'd map.

I'm still curious if I'm missing something with the 1,2,3,4,all buttons. I'll have to add some additional logging to the node server to check that. Also, if you can check each of the other buttons and let me know which button mapped to which letter, I can update the node server to name them better.

You'll only be able to trigger on control, not status. You don't see something like this: The Test_Pico is a 3 button Pico remote. It might say "on" instead of "Button Pressed". I believe the Lutron app creates that representation internally based on how you've linked the devices in the app. The node server doesn't have that same ability. The app isn't really communicating with the remote commanding the remote to send a specific button press event to the bridge, it just knows that the button is linked to the shade so it it sends out the command to the shade directly when you press the virtual button. I don't know how Lutron tracks what is linked to a button press event. The unofficial information I have on the Lutron API doesn't document any way to get that information from the bridge (assuming it is actually stored in the bridge and not in the app or in the cloud).

@hart2hart I had no idea that's what the remote looked like. Support for it is in the node server but it's completely wrong based on what the remote actually looks like. Since it thinks it's supported, it won't dump any of the information it normally does for unsupported devices. Some general information about Lutron remotes (mostly Pico's). As I said, they are control devices. When you press a button on the remote, it sends a button press event with info about what button was pressed and then it sends a button release event when you release the button. The node server can detect the button press events and use that to trigger programs (and via a bit of a hack, scenes). The node created for the button isn't a simulated button. The node server cannot generate button press or button release events and send those to other devices. The Caseta API doesn't have any way to do that. That's why there's no "action" available in the node. I had assumed that the remote you have is similar to the other Pico remotes but it isn't. I suspect that when you press one of the number button (or all), it doesn't actually send out any events, just sets internal remote state. Then when you press the open/close/raise/lower or favorite button, it does send out an event. So that may be what the 5 nodes represent. There must be something different in the button pressed events depending on which number button was last pressed, but I don't know what that is. With Lutron (at with the Caseta smartbridge) you can only control devices directly. So if you want to control the shades from the node server, you'd use the shade nodes to do that. You can't have the node server tell the remote to control the shades. I think the only thing you might be able to do with the remote is something like this: If the remote open button is pressed, run a program to do something if the remote close button is pressed, run a different program You can experiment and see if you can create a program that triggers on one of the buttons. The way the node server configures the remote button nodes you should only have the option to trigger on button pressed. I'd like to know if this works. It probably maps A = Open, B = Close, C = favorite, D = Up/raise, E = Down/lower

I don't think I've seen any info on a 10 button remote. Which means it's not really supported in the node server. The log should detect the remote and dump some information about it. I'll need to see that info before I can add support for the remote. I'm curious as to what it was detected as. There's nothing in the node server that should create a node with a 'F' suffix. Yes, you can put the shades in a scene to control them all. I believe you can group the shades in the Caseta app to allow them all to respond to a single button. At least I somehow set my 2 up so that they only only remote that controls both. The node server doesn't do any polling so it doesn't matter what you set the poll values to.

Yes. The trial and the licensed node server are the same, except the trial expires after 30 days. I believe once you purchase the license, it replaces the trial license and the expiration is no longer checked. Worse case, you'd need to re-install but that won't delete any configuration you've done or any nodes already created.

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.