bpwwer

The connection error indicates that it can't connect to the MQTT broker. Did you install/configure a MQTT broker for this? If so, what do the broker logs show?

Using 127.0.0.1 for the mqtt server means that nothing external to the eisy will be able to connect to it. You need the eisy's external IP address there. That's 10.10.2.20 right?

I've never used the node server, but looking at it, I believe it should create nodes for your sensors shortly after you enter the username and password. It looks like it should have created a control node on startup and that node should have a "Discover" button. Clicking that will cause it to query for devices and create the nodes also. You do have to restart the admin console after installing the node server for the admin console to correctly display the nodes new nodes.

Yes, eventually (no current timeframe has been decided), PG3 will be deprecated. But for reference, I'm still doing almost all PG3 development on a Polisy with PG3. Then once I have it working on PG3, I move it to PG3x on eisy. PG3 on Polisy isn't going to suddenly disappear. Right now, it's only remote access to PG3x that doesn't and won't exist on PG3. There may be some node servers that depend on either the remote access framework or eisy specific hardware that work on a Polisy. Oh and PG3x will display update related notices like the admin console does. That's also something PG3 can't do. For people that are still using a i994 and have a Polisy, there's no good reason to try and migrate from i994 directly to PG3x. I'd first move to Polisy/PG3 and once that is stable, then you can think about migrating to PG3x.

I'm not sure what that link does. My assumption is that it sets a variable telling the Polisy that it should install PG3x instead of PG3 when doing updates. It should also remove PG3 and install PG3x. and then restart everthing. When PG3x first starts, it will check to see if it needs to migrate the database/node servers from PG3 to PG3x and will then proceed to do that. Depending on how many node servers are installed, this can take some time. It should send notices to the PG3x UI for each node server it migrates. Expect at least 30 seconds to 1 minute for each node server. If you interrupt this process you'll probably end up with some node servers migrated and some not so don't be in a rush, take your time. It also logs the migration progress in the PG3x log file so if something does go wrong, downloading the PG3x log and attaching that to any support request (ticket or forum/PM). I believe it does not try to start the node servers after it migrates them so they should all be in the disconnected state and you have to manually start each one. The migration should not effect any configuration or existing nodes. My testing involved migrating 30+ node servers multiple times (so yes, it takes quite a while to run) and I didn't see any issues, but I can't account for all the different environments and combinations of node servers. There's no easy way to go back to PG3. In theory, the variable can be cleared, PG3 can be re-installed and restored from a PG3 backup and it should work. There's probably some other stuff that PG3x did that will need to be cleaned up, but it should work. This hasn't been tested so for now, best to consider it a one-way migration. If you try https://polisy.local:8443/rest/pg3x.enable and it doesn't work, please submit a support ticket.

I would assume the username/password is the same as what you use to log into the admin console. We've been working to consolidate logins to use that everywhere, but we're not there yet. That is one difference between PG3x and PG3. PG3x uses the same username/password as the admin console, PG3 has it's own username/password database that's independent from everything else.

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.