bpwwer

Hello all, We are very happy to introduce PG3x v3.1.29 for eisy and Polisy. With these releases, there are changes to how Portal access tokens are managed. Prior releases attempted to manage the Portal access token in the web UI code. This tied the access toke to the PG3x login/logout functions requiring a new access token every time you logged into PG3x via the web. With version 3.1.27, the management of the Portal access token has moved into the PG3x server code. PG3x will request the WebUI to obtain a Portal access token only when it needs a new token. The server side will maintain the token indefinitely so you will no longer need to provide PG3x with a new access token when logging in to PG3x via the WebUI. The eisy is using a new version of Polyglot version three called PG3x. PG3x has infrastructure changes to make node servers (and PG3x) more secure and enable features based on remote access. Polisy users may update their systems to use PG3x if they want access to the new features. PG3 will continue to get updates for the foreseeable future. To upgrade PG3x: In the Admin Console, click on Configuration, Upgrade Packages (note, this can take many minutes, depending on how long it's been since you last updated.). After the upgrade is complete you should restart/reboot the eisy. Do this from the Admin Console, Configuration, Reboot. Once PG3x has restarted, reload /refresh the browser page. Changelog for 3.1.29 - If refresh token expires, request UI get a new token. - Add menu item to UI system menu to reset portal credentials. Changelog for 3.1.28 - Remove unnecessary log messages. - Update local globalsettings when db is updated. - Add log message to warn of missing key if a key that doesn't exist is queried. - Handle 'seq' field in incoming messages from frontend clients - Synchronize settings with frontend. - Clean up error and log message for portal based queries. - Force devMode to be 0 or 1

Thanks, that's currently the expected behavior. There's a timing bug that causes it to prompt a second time but it doesn't cause any problems. With this version, you shouldn't get prompted again for portal logins. PG3(x) should now manage the portal access token for an indefinite amount of time.

What have you set the IP address/port too? What shows up in the log when you start the plug-in?

Are you sure the plug-in is configured properly? From the log, the plug-in is not able to connect to the eisy at all.

As far as I know, it should work with the eisy, but it's possible that a recent firmware update breaks the plug-in. Does the plug-in log anything that might indicate what the problem is?

I like the Rainforest device a bit better than the Vue. I think it's more expensive, but they are bit more open with their API. Have you tried the Eagle 200 node server with it? The Eagle 200 is a Rainforest Automation device.

Thanks @Jimbo.Automates You're setting a good example for how node servers should behave.

PG3x uses another UDI component called UDX to authenticate. UDX does a bunch of system level tasks for the eisy (and Polisy) including the package upgrade process. Depending on what state the system is in, when UDX starts it may have a lot of work to do, my guess is that sometimes it is so busy doing other stuff (maybe trying to bring the system up-to-date) that it can't properly service PG3x's request for authentication. The result could be that the process seems to hang so that nothing happens when you click login or you get authentication failed as above. Once UDX is finished and is able to service the request, things start working. This is just my guess. UDX is mostly a black box to me, I don't know anything about it's internal workings. PG3x also had dependencies on a MQTT service and the IoX firmware so it could be something related to one of those as well.

Purchase the product and install it per the instructions that come with it. In my case, I had to contact the power company to get it setup with my meter. Install the Vue node server and configure it to communicate with the Vue device.

I just tried one of your queries and this is the response from WeatherBit

Just to explain a bit. The WeatherFlow hub sends the data via a UDP network broadcast. Without special router configurations, UDP broadcasts are limited to a single network subnet. Meaning the hub and the eisy/Polisy need to be on the same subnet for this to work. If it's not possible to have them on the same subnet, you can configure the node server to use remote data vs. local data. It will then query the WeatherFlow servers for the data instead. The trade off being that you're now dependent on the your external Internet connection for the weather data.

Thanks! I reviewed the log and see the problem, there's a bug in PG3. I've provided Michel with the steps needed to work around it so you should be good after the remote session.

Yes, there have been a lot of accuracy issues with the haptic rain sensor. To resolve that, WeatherFlow does a lot of server side processing/modeling to try and correct for that. That's the corrected rain value that they report in their app. I've not had a need for accurate rain info myself, so it hasn't been an issue for me, but I'd say that's one of the main weaknesses of the Tempest (the other, as @MrBill points out, is a high hardware failures). However, they are pretty good about replacing failed hardware.

This thread is probably not the right place to continue working your login issue. But if a reboot doesn't help, then you'll probably have to submit a ticket. It may be that something failed during an update and is now not working properly.

In general, once PG3(x) gets the access token, it will manage that and you won't ever be prompted to enter those credentials again. So the fact that you're not getting prompted probably means that it is working as intended. Lack of an access token is one reason why for it to not display purchased node servers so the steps above have been to try and make sure that's not the problem. Can you attempt to view your purchases (Refresh the listing or refresh the browser page) and then download the PG3 log? either PM me the log or attach it to the ticket. The log should have the reason why it's not able to get the purchase list.

PG3 has dependencies on other components on the system and if those aren't yet fully operational when PG3 tries to start, it can cause login failures. There are a few different reasons why logging in can fail. 1) Clicking the login button and nothing happens. This usually means that the component that does actual authentication check is not working right. This could be because it isn't fully started yet or it could mean it has hung. If it isn't fully started, it should eventually and then things will work. If it's hung, the only solution is to reboot the system 2) Clicking the login button and an error 401/unauthorized message pops up. This happens when the component that does the authentication returns something other than success. Most likely because the username or password is incorrect. 3) Clicking the log in button and an unknown error message pops up. This happens if PG3 is unable to connect to the component to do the authentication. It may not be running or it failed while starting up. The only solution is to reboot the system.

And you've tried restarting PG3? From the PG3 menu: System -> Restart Polyglot 3x

Typically, not being able to get the list of purchased nodes means that PG3 does not currently have the access rights to do so. PG3 needs an access token for your portal account in order to query for the node server's you've purchased. Normally if it doesn't have the access token, it will send a command to the WebUI asking it to get the token for it, since that is an interactive process it needs to be done via the UI. @DennisC's suggestions are good. I'd also add that you may want refresh the browser page and then log out and log back in first and see if that prompts you for the portal authentication.

Probably because the WeatherFlow app is showing adjusted values vs raw sensor values. I'm working on adding the adjusted values to the node server but it's not done yet.

PG3/PG3x now does a pretty good job of recovering from network issues without it causing any visible issues. If node servers loose their connection to PG3(x), they'll keep trying to connect until they succeed. If PG3(x) looses network connectivity or crashes, in most cases it will recover transparently. But the way the notification feature in PG3(x) works is that it now detects these issues and reports them. Chances are very high that these disconnections/connection events where happening all along and you just didn't know until it started sending the notifications. In general, these types of events are being caused by external factors so the node servers and/or PG3(x) can't do anything to make them stop. But if PG3(x) is crashing periodically, causing all node servers to disconnect/reconnect it's good to check the log and report it as it probably is bug in PG3(x).

Ah, I understand. Don't change anything there. Polyglot based node servers configure everything on the IoX automatically. From the Polyglot website, you should now have a dashboard view that includes the Caseta node nodeserver, click the details there and you'll see something like this: Click the Configuration button and you'll see a field where you can enter the IP address of Caseta Bridge. Once you enter that and save it, you should get a notice prompting you to press the black button to pair. It should pair in a second or two. Once it pairs it will query the bridge and add nodes to the IoX for each device it finds. When it's done, you'll have to restart the Admin Console so it can read the new created nodes properly and display the correct fields and status.

I'm maintaining that node server, but mostly that means that I'll attempt to fix any bugs that show up. I didn't write it and I don't have any hardware to test with. I can attempt to add features but I'll need details on the what is being sent in the data for the different sensors.

@RichTJ99 My Caseta node server asks for the IP address of the bridge and then prompts you to press the button on the bridge to link just like HA does. It doesn't ask for a password. It also has the following instructions included. The Lutron Caseta node server has the following parameters: * lutron_bridge_ip: This is the IP of your Smart Bridge Device. If you have a Pro Bridge you can set a statis IP by opening the app and going to Settings->Advanced->Integration->Network Settings Once the ip address has been entered and saved, you will be prompted to press the button on the back of the Smart Bridge. Pressing the button will pair the Lutron Caseta node server and SmartBridge. Once paired, the Lutron Caseta node server will query the Smart Bridge for the connected devices and create ISY nodes to represent those devices. The Discover button may be used to force the node server to re-query the Smart Bridge. Use this if you add additional devices to the Bridge using the Luton App. I'm not sure what you are using the eisy to try and connect to the Caseta bridge.

In the node server config you can create a group of devices that can then be controlled as a single entity. But I don't think you can make use of groups created in the app.

I suspect that most node server consider a lose of connection to the device a fatal error. They make the connection on start and fail if the connection is lost. I agree that it would be better to attempt to re-connect and only fail if unable to reconnect for some period of time. But I doubt most node server developers take the time do that. I'm pretty confident that it would have nothing to do with the public IP address, it's just the way the node servers are defined to behave.