bpwwer

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?

Mosquitto does have the ability to log to a file, I think with different levels of verbosity but you'd have look at the documentation on how to configure that.

Unfortunately not. Did you attempt to log in after opening the javascript console? If not try logging in with the console open. You may have to scroll up to see all of it outputs. I'm looking for an error message related to "/auth". The errors in the screen shot are "normal", in that it is trying to use information it gets from PG3 to format the menus, but because it isn't logged in, it doesn't have that info from PG3 yet.

The first step is to get things working with MQTT Explorer as that will mean everything is configured properly. You need to have a MQTT broker running somewhere. Either on the RPi that is running the solar-assistant software of on the Polisy/eisy. Running a MQTT broker on the Polisy/eisy can get confusing because each is already running a broker but the default running brokers are configured to only work with PG3(x). On the Polisy, PG3 has a built-in MQTT broker, but you can't use it. However, you can install the Mosquitto broker and run that along side the PG3 built-in broker. On the eisy, Mosquitto is already installed and running for PG3x, but it is also configured so that only PG3x can use it. I'm not sure if you can install another copy of Mosquitto for your own use or not. What hardware are you using and what have you tried so far?

I wasn't sure if logging out/back in would solve this. Guess not. That's strange that it works from one computer but not another. If you open the javascript console (developer tools) on the one that's not working is there any more details on the error?

The PG3 UI authenticates directly with the PG3 server which is a separate account/password from anything else. The PG3x UI authenticates using the IoX account/password and also has to authenticate with the MQTT broker to establish a connection with the PG3x server. So while the UI looks the same, how it works is very different. The changes are an attempt to both improve security of PG3/node servers and consolidate the IoX/PG3 accounts to simplify it a bit.

The portal authentication has a fairly short time period before it expires. Once it expires, the UI will pop up a warning saying it has expired and in most cases it should auto refresh the authentication with the portal. Portal authentication and authentication with the PG3x server are different and shouldn't be effecting each other.

Log out and then log back in. The problem is that the browser has cached information that is preventing it from connecting to PG3(x). The UI running on the browser thinks that you are logged in but it keeps sending old authentication information to the server and server rejects it. Without a connection to the server you don't get any information from the server (IoX configuration, node servers installed, etc. and the UI can't send anything to server (edited IoX configuration info, etc). When you switch to another computer or browser, the UI has no cached authentication info.

Do you have the option to log out on the menu? If so, try that and then try to log in again.

Do you have other node servers working correctly?

What version of PG3 are you running?

As soon as I get a chance, I'm going to look into this. Given the reports, it may be some incompatibility between the node server and PG3x.

Just for reference. The error means that the configuration of the node server on the IoX (when you go to Node Servers -> Configure -> slot # -> <node server>) has an incorrect password. When PG3 installs the node server on the IoX, it sets the password to an encrypted token, when the IoX sends a command to PG3/node server, PG3 checks that password to see if matches and if it doesn't, it throws that error. Normally, this would mean that the node servers was installed on the IoX by a different PG3**. ** PG3 creates a unique identifier when it creates it's database for the first time. Removing the database and restarting PG3 will create a new unique identifier and this will also cause the authentication to fail.

I have no idea. The MQTT stuff is all handled by standard Python modules.

Portal access is unlikely to be the cause of your issues. You'll need Portal access to purchase node servers or verify node server licenses, but you're not to that point yet. PG3x has two components, the UI running on the browser and the server running on eisy. The can't connect to server is the UI saying it can't connect to the PG3x server. You can't do anything if it's not connected. So yes, that needs to be resolved before you can restore. In general, with PG3x, you don't need to configure the IoX/ISY unless you want to manage node servers on something other than the local eisy. Once the PG3x server side starts, it will pre-populate the IoX config with the local IoX. It appears the PG3x server side is not running, the question is why? PG3x has a dependency on UDX and the local IoX, if one of those aren't running, then PG3x won't be able to start. At this point, it is probably best to reboot the eisy and see if that clears it all up. If it doesn't, then we need to use OS level tools to look at what is happening when PG3x tries to start. If you are comfortable with ssh'ing into the eisy you cat do something like sudo tail -f /var/log/messages which will show the system log messages. PG3x startup messages will be there and it should be repeating the same set of messages every minute or so. If PG3x is crashing, it will show the crash, if the local IoX isn't started, it will show that in the log before aborting. CTRL-C will stop the log display. If you're not comfortable with that, submit a ticket and support will probably have to remote into the eisy to determine what's going on.