bpwwer

That's strange. A node server shouldn't be able to effect that connection. Can you try installing it again? If it does the same thing, capture the node server and PG3 log and post or pm it to me.

Release nodes are published and the 3.1.20 package should be available now.

So it actually works! I wasn't sure if the notification of new versions was working. I added that recently as I thought it might help notify folks about new updates. I guess I need to be better about finishing the packaging process when I create a new release now. The code is available, but the eisy package hasn't been updated yet to install it.

The data reported by the node server is what the Ambient servers report. There's no conversion happening in the node server.

Double check that the ISY configuration is correct. To connect to the ISY running on the Polisy you should have the IP address set to 127.0.0.1:8080 and re-enter the username and password. The PG3 log should show why it is unable to connect to the ISY instance but it most likely either a wrong IP/port or wrong password.

Yes, both my eisy and Polisy leave the other network settings blank when using DHCP. Only the IP address is shown.

PG3x can only migrate the node servers, not the licenses. The licenses need to be migrated through the portal. If you log into your portal account and select migrate under the Select Tools -> Maintenance -> Migrate to there's an option to migrate the licenses from the Polisy to the eisy.

OK. You'll have to submit a support ticket so someone can remote in and figure out what's wrong. https://www.universal-devices.com/my-tickets reference: "PG3x login failure (UDX socket)" in the ticket

Thanks! That's what I needed to see. It looks like the service PG3x uses to authenticate is hung. Have you tried rebooting the eisy? If not, try that.

Thanks! That narrows it down a little but it didn't log enough to pin-point what went wrong. I see it making the request to authenticate, but then PG3x restarts. That does indicate that something crashed and it wasn't able to handle it. If you can try again but instead monitor this log file: sudo tail -f /var/log/messages You don't need to let it continue monitoring after you attempt to log in. It will log the crash info and then restart PG3x so the useful messages will be within 5-10 seconds of the login attempt. FYI, the errors in the log you captured are normal at this point, It is trying to communicate with the IoX but you haven't yet logged in so it fails to authenticate and throws the errors.

The response indicates that something went really wrong trying to authenticate. I've not been able to reproduce this specific case so I don't know what went wrong. The PG3x log may have more information as it should be logging an error message. However, the only way to check that is to ssh to the eisy and watch the log while attempting to log in. The command line to watch the log would be: tail -f /var/polyglot/pg3/logs/pg3-current.log (may or may not need to prefix that with sudo). To stop displaying the log, use CTRL-C.

Some node servers need to build the required modules and to do that they need development libraries installed. You can install the development libraryies with 'sudo /usr/local/etc/udx.d/static/udxops.sh install.dev.pkgs'

Version 1.0.11 fixes the z-wave discovery. And because I could, I made it do a discovery on startup so you don't have wait for the poll event for it to populate. Just a note, installation takes longer than I would expect and discovery takes 10 - 12 seconds so it can seem like a long wait on first installation before it sends everything to the IoX device.

I've updated the interface module and it now should work with both PG3x and PG3. New installs will pick up the latest, if you already have it installed and it's not work, a re-install should pick up the new interface module.

Nothing has actually changed in ST-Inventory. 1.0.8 and 1.0.9 are the same as far as the code goes. The difference is in the interface module used to interface to PG3(x) so 1.0.8 is using an older version of the interface module and 1.0.9 is forcing it to use the latest interface module. Showing the nodes as insteon vs. zwave is likely because how zwave node are represented with the zMatter board is different from how they are represented with the older boards. ST-Inventory is probably checking to see if they match the old representation and when they don't, assumes the nodes are Insteon. I have not looked at updating ST-Inventory to recognize the new z-wave representation, yet. I'm just trying to get the node server to work.

Thanks Jeff. Looks like I have more work to do to make it work with both.

Are you using wi-fi on the eisy?

I've released an update to ST-Inventory so that it should now work with PG3x on eisy. Note, I've only tested this update on PG3x 3.1.18 on eisy. I have not tested it on PG3/Polisy, it should work there as well but if not, let me know.

The path for the token.txt file is something you configure in the node server. There's a configuration parameter with the key "tokenFilePath" used to define that. "/var/polyglot/node_servers/AugustLock" looks like it might have worked for PG2 but it won't work for PG3 or PG3x. For PG3(x), the node server is installed in /var/polyglot/pg3/ns/<uuid>_<slot> so it depends on the IoX UUID and the slot number where the node server is installed. If you look at the ISY or IoX configuration, you can get the UUID. For example: 00:21:b9:02:61:ab and if you installed the node server in slot 3, the path would look like: /var/polyglot/pg3/ns/0021b90261ab_3

Try logging out and then see if you can log back in.

No, it can't. The admin console has full control over how the content is rendered. The node server (via PG3(x)) simply sends the value (numeric value). The only control the node server has is over values that are represented with text. The node server creates the numeric value to text mapping that the admin console uses.

It should switch seamlessly between wireless and wired. At least when everything else is configured correctly. With PG3x 3.1.18, I was able to connect the cable and WeatherFlow immediately started working. No restarts/reboots/re-installs/etc. needed.

The wi-fi setup on the eisy is a little different. I didn't realize this until I started talking with @Michel Kohanimabout why WeatherFlow wasn't working. The actual wi-fi connection is made through a VM and you don't get to see that configuration at all on the eisy. Instead, the eisy creates a virtual network and bridges that to the wi-fi in the VM. So while the wi-fi will get a IP address on your local network, the eisy only sees the IP address of it's virtual network. It was probably that virtual network IP you saw configured (173. something). Because of this PG3x (and node servers) can't actually get access to your local network directly, it all goes through the virtual network via the bridge. Initially, that bridge was pretty locked down and didn't allow much through it. I believe @Michel Kohanimhas figured out how to make it more transparent so things like WeatherFlow will work. However, using wi-fi on the eisy is going to impose some limitations. For example, you'll never be able to connect PG3x to an i994 over wireless.

WeatherFlow won't work if the eisy is using wi-fi. Currently the internal bridge that's created for the wi-fi network blocks most ports and broadcast messages, thus the UDP packets from WeatherFlow hub are never seen by the eisy. I believe this effects any node server that's using UDP broadcasts. So node servers that send out broadcasts to search for devices on the network will likely fail when using wi-fi. In my case, switching to an ethernet cable caused WeatherFlow to start receiving data almost immediately. I didn't have to restart it even.

It can and does. There was a bug initially where it would switch it back to the external IP address when doing verification of installed node servers but that's fixed in 3.1.18 But remember, PG3 was designed when most (all) were still using a i994.