bpwwer

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.

I finally got around to trying it myself. The problem is the node server is requiring a very old version of the interface module and that old module doesn't support PG3x MQTT. @Javiin the requirements.txt you have udi_interface == 3.0.32. Version 3.0.32 is a very old version of the file. The latest is 3.0.51. You should probably use udi_interface => 3.0.51 and update the store entry version. @garybixlerOnce the node server is updated to use the latest udi_interface, you'll need to do a re-install (note, not delete and install) for it to pick up the change.

While I don't have a Mac, I did get access to one and had no issues connecting to PG3x with safari. However, I did notice something interesting when I did this. It appears that the new process only allows one browser connection at a time. When I logged in on the Mac, the UI I had connected on my Linux box disconnected. Now that I think about it though, that is how it is designed to work.

Maybe. I notice you're using https. With that the browser needs to be told to trust the certificate from PG3x. If it doesn't trust it, it will likely simply not actually make the request which may explain the "empty response" error. If PG3x responds, the response can't be empty. If it happens again, try changing to regular http to access PG3x and see if that works. Unless you have some reason to not trust communication on your local network, I don't believe using https is necessary. In the meantime I can try with https and see if I can reproduce the problem.

You have tried re-installing the iTach node server, right? I don't remember if you mentioned that or not earlier in the thread. The only reason I can think of for SSL errors would be if the certificate didn't get installed, re-installing should also re-install the certificate.

PG3(x) was never designed to support the ability to change it's IP address. This is mainly due to the fact that to support bi-directional communication between ISY and PG3 both need to know the IP address of the other so if the IP address changes, both need to be reconfigured and there isn't really an API to allow that re-configure to happen. Now that shouldn't effect node servers starting when switching from wi-fi to cable but without seeing the logs, I don't know why they didn't start, but this is something I can try to reproduce.

Are you using wi-fi on the eisy? If so, the eisy's wi-fi implementation is currently incompatible with some node servers, including WeatherFlow.

I was asking because all node servers use the same library code to make the MQTT connection. Since other node servers are installed and connecting, it's not something wrong at the library level and most likely something wrong related to that specific node server. I don't know anything about the iTach node server but making the initial mqtt connection shouldn't be something that's easy to break. Are you using Wi-FI to connect the eisy to your network? If so, the Lifx node server may be incompatible with the current wi-fi implementation.

I don't know. I don't have a Mac so I can't use Safari. Logging out clears the app local storage which is where the authentication credentials are saved. Maybe the call to clear local storage isn't working on Safari. Maybe there's a way with Safari to clear data associated with a browser app?