bpwwer

What do you mean everything seems to still be working? Do you mean that node servers are running and updating values in the AC? If that's the case, then have you tried logging out of the UI and logging back in? It's possible that the browser has cached credentials for PG3 and that those don't work for PG3x. PG3x no longer has it's own username/password database and instead authenticates against the IoX username and password as set for the local IoX.

When the UI is disconnected from the server you can't really do anything at all in the UI. Typically, this means that the server (or MQTT broker) isn't running. I would suggest running the upgrade packages from the admin console (even if you already did this) and then rebooting the Polisy.

With changes to allow for different types of purchase options, checking for updates got a lot more complicated as not all node servers have updated to the latest purchase option format in the store. Yes, I'm aware of the issues and how badly it is currently working. Unfortunately , fixing it is not at the top of Michel's priority list for PG3 updates right now.

Ahh, it looks like that data may be available via the Version 2 API, but not the Version 1. The node server current uses the Version 1 API. I have it on my list to convert the node server to use Version 2 of the API, but that's basically a full re-write of the node server and I don't have a time frame yet as to when I'll be able to do that.

The is what the server is sending in response: The plan is restricted and cannot perform this action. Adjust action and try again: endTime cannot be more than 5 days ahead.' It sounds like you're requesting more days of forecast than your plan allows. Reduce the number of forecast days to 5 or less.

Does the node server detect the sensors? If so, do you see anything in the log (probably need debug enabled) showing the data from them? I don't have any Davis equipment so I can only add support for something if I have enough info.

If you set the log level to 'debug' you'll get more information. It will display the actuall http request that it is making for the forecast data and it will display what the server returns. The error message is because the server did not return any forecast data.

From the admin console go to the configuration tab and then the portals tab. It should be obvious if it's registered or not.

I don't believe it is possible to get it working with the node server. The node server will need to be re-designed to work with the j7+.

The license is bound to the Polisy (or eisy) UUID. This is a hardware ID and will be valid as long as you're using that specific Polisy/eisy. If you had 5 i994's, you could install the node server on any/all of them. Once you have the license it's good for installing on the i994 and the later you can install it on the IoX running on the Polisy using the same license. The target ISY/IoX info displayed before you purchase the license isn't really meaningful. PG3 is using the same dialog box for the purchase and for the install, so it's only when installing that the target ISY/IoX means anything. I can see how that might be confusing so I'll see if I can make it less so.

Is you eisy registered to your UDI Portal account? It needs to be or PG3 won't be able to install node servers.

It's certainly possible that they've changed something in newer Roomba's that breaks the way the node server attempts to access it. Everything related to connecting to Roomba's is based on reverse-engineering how they work as there isn't a public API to do this. Given that it's unable to connect to the Roomba because it is denying the connection attempt, you may need to do something to the Roomba to enable that. Ah, yes, the issue has been reported and it looks like the way to get the password is different for the j7+ and that method is not easily integrated into the node server.

No, the current design is based on the fact that the Roomba broadcast the information needed to connect to it. So the node server has to be able to receive that info to function. This is mostly a function of how the Roomba works, not the node server.

There was more than one. Release notes for 3.1.26 - Fix permissions on node server files after migration from PG3 to PG3x - Add an enhancement to cloudlink support, primarily for the Google Calendar node server - Compress old log files and limit the size of a log file from 100Mb to 30Mb - Fix a submission issue for node server developers.

Just to follow up, I spent some time with @pkauf and this is what we found. Node servers that install from a .zip package are getting installed with some of the files (seems like mostly the Python files) corrupted. The files contents are all there, but the order in the file is wrong. Usually a chunk of the code from the middle of the file ends up at the beginning. This causes the Python interpreter to fail, no surprise. Node servers that install from a git repository are fine. No idea why this is happening. I replaced all the PG3 files on the system and replaced the node.js module that does the unzipping in PG3 with no change. The FreeBSD unzip program works fine unzipping the same files. If anyone has any ideas, let us know.

PG3x 3.1.26 had a couple of very minor updates and one update to fix issues when a Polisy user migrated from PG3 to PG3x. I forgot to make a forum post about it.

How easy it is to add depends on what data is available from the source. If you set the log level of the node server(s) to debug and let them run for an hour or so, then download the logs and post them or PM them, I can take a look and see if there are fields available that I didn't use. If any of those are available directly, it's pretty easy to add. If they aren't, then they would have to be calculated from existing data which is more effort.

When you exceed the number of queries allowed per whatever plan you're using, the queries will fail until that limit is reset (I think daily). So depending on the time when it exceeds the limit, it could be a while before it is reset. I should add some checking for the limit being exceeded and display a notice when that happens. I'll put that on the list, but don't know when I'll have time to work on it.

As far as I know, the original author is not maintaining it any longer. I did the conversion from a PG2 node server to a PG3 node server, but I don't really have time to figure out how to add new features to it.

Version 1.0.7 of the Caseta node server should now recognize the Serena roller shades.

Not really. UDI creates the certificates that are used by all the components to enable encrypted and signed communication. There's nothing "insecure" about that. The problem is that browsers have no way to trust non-public servers at least not in a way that's easy for user's to configure. Servers like PG3, don't typically have a public IP/DNS address. PG3(x) has no way to get a certificate from a signing authority. The only option is to use a self signed certificate**. If you don't trust the certificate signed by UDI, you probably shouldn't be using UDI controllers. Currently, the browser based UI is only designed to support local connections to PG3(x). You can use SSL encryption for this (but you have to tell the browser to accept the self signed certificate) or you can use unencrypted connections. It's your choice. I would not recommend trying to use the browser UI remotely unless you're connecting over a secure VPN. We are working on providing UI remote access to PG3x. The connection will be routed from a secure internet visible server to PG3x over a private secure connection (similar to VPN). ** Yes, it is possible to configure a Polisy/eisy to have a public DNS address and get valid certificates generated for it. However, doing so is probably outside the scope of what most users can do. With PG3, you can do that because the only thing that makes use of the certificate is the browser UI or UD Mobile. And in theory, you could do the same for PG3x, except that all the internal communication is now SSL encrypted based on the certificates that UDI creates. So you'd have to replace all them, including generating new certificates for each node server. So while it may be possible, it's not really practical. ** And also, it is possible to set up a system where PG3(x) gets a public DNS and certificates from an authority, but doing that is non-trivial and also not free. (Plex for example, does this). But UDI would probably need to require a more expensive portal license to cover the costs.

Leaving the IoP unconfigured won't hurt anything, you'll just keep getting a bunch of warnings/errors in the log. From the log 4/28/2023, 19:58:05 [pg3] info: [00:21:b9:02:43:ab_9] :: Cloning repository... /home/admin/dev/udi-solaredge-poly into /var/polyglot/pg3/ns/0021b90243ab_9 4/28/2023, 19:58:05 [pg3] error: gitClone: failed to clone solaredge_poly from /home/admin/dev/udi-solaredge-poly :: Error: fatal: '/home/admin/dev/udi-solaredge-poly' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Looks like @photogeek54didn't change the installation URL when moving the node server store entry to non-production. So it's trying to install from a local (to the Polisy) git repository that only exists on @photogeek54's machine. The installation URL needs to be a publicly accessible git repository.

Some node servers don't currently work if the eisy is on wireless. To implement the wireless driver on the eisy, it runs a Linux VM with the wireless driver in the VM and sets up the firewall rules to forward TCP traffic between the VM and the eisy's internal network. Thus, any node server that relies on broadcasts tend to not work as broadcast type packet don't typically get routed. For example, the WeatherFlow node server won't work in local mode as it will never see the UDP packets being broadcast by the WF hub.

For PG3, I believe it is still possible to use your own certificate. The certificates would go in /var/polyglot/pg3/ssl/custom and you'd have to change the /usr/local/etc/rc.d/pg3 startup to tell PG3 to use the custom certificates. For PG3x, it is not possible as changing the certificates will break all communication between PG3x and node servers (and other components on the system).

@Ross Do you have two ISY/IoX devices configured? From the log it kind of looks like it and that one of them is failing warn: ISY Response: [Try: 3] [00:0d:b9:53:36:80] :: [401 - OK] :: 6.87654ms - http://192.168.1.6:8080/rest/profiles/ns/0/connection That error means it is unable to connect to the ISY/Iox at 192.168.1.6. Likely because the either IP address or username or password is wrong. When it tries to start the solaredge node server it errors with error: [solaredge_poly(12)] :: STDERR: python3: can't open file '/var/polyglot/pg3/ns/0021b90243ab_12/./solaredge-poly.py': [Errno 2] No such file or directory Try re-installing the node server again. Something may have gone wrong with the initial installation.