bpwwer

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.

Try re-installing it. the module should get installed as part of the node server install process.

Should be there now, might have to refresh store for it to show up. @photogeek54 you have to change the status to 'active' for it to show up in the store. When status is 'new' it is added to the store, but won't show up in the list.

Go to the "Log" menu item and download the log, then PM it to me. I'll take a look. It should show up just like the OpenWeatherMap node server did.

Yes, you both seem to have the same issue. I just did a migration again on my Polisy and the node servers started without any issues. So I haven't been able to reproduce it. It looks like the node servers are simply crashing when they try to start but nothing in the log files provide any information on why they are crashing.

You may have exceeded the number of API calls your plan allows for in a day. The free plan is quite limited. Or you may have asked for more forecast data than what your plane allows. It looks like they may have reduced the number of days of forecast data you can get with the free plan from 7 to 6. The node server gets stuck if it's looking for 7 days but only sees 6.

When a node server is installed, it places node server configuration information in both PG3 and the IoX (in your case the i994 ISY). To "move" a node server would mean changing PG3's configuration and installing the node server on the new IoX. So that's basically what you have to do to migrate. Once you restore the i994's backup to the IoP, the IoP will have the node server configuration from the i994, but it will be wrong. When you switch PG3 to the IoP ISY, it should detect those node servers, but they'll be unmanaged. I believe you can then select the node server in the node server store and use the "re-install" to same slot option. That will correct the installation without requiring you to re-enter the node server custom parameters so everything should continue to work. It's been a long time since I've done any migrations from i994 to IoP and PG3 has changed a lot since the migration was first documented. Just follow the steps and it should be fine. If you encounter a problem. Stop and post here or open a ticket.

Yeah, that wasn't me that said to restore the PG3 backup, I would have liked to see a PG3x log after you tried starting a node server. I've done the PG3 -> PG3x migration on a Polisy a couple of times to test it, but that's the not same as having it run in the real world.

The status not showing up in programs is a bug. I can fix that. @Jimbo.Automates has nothing to do with this node server. It was written by @simplextech but he's no longer maintaining it, I am. Same for ST-Inventory. As I mentioned, the ST is set to true when the node server starts but there's nothing to ever set it false. Fixing this is a fair amount of work and right now it's not really a priority for me.

@JTsao based on your ticket, I don't think this is useful to you now, but might help someone else later. When PG3x migrates node servers from PG3, it leaves them in the disconnected state. You need to manually start the node servers after migration. You're post says you tried "rebooting, power cycling and restarting PG3x" and none of those steps will attempt to start the node servers when they've been previously stopped. PG3 and PG3x remember the last state of node servers. If you stop a node server, it won't be automatically restarted, you have to start it. In this case it's the migration process that stops all the node servers so they can be migrated, but it still relies on the user to start them back up.

Restart the admin console. You need to do that after installing any node server.

The status not showing up in programs is a bug. I can fix that. However, I don't think it ever changes as it looks to be hard coded to "True" in the node server. You can't use commands in the "if" part of a condition as these are things the IoX sends to the node server. They should be usable in the else/then portion to send the command on some trigger.

Great! Thanks for letting me know. It wasn't hard to add them, but you never know when you can't test.

I'm trying an experiment with this. I added support for both in version 1.0.9. I have no idea if this will work or not since I don't have any Sonos devices. So instead of replacing the existing 1.0.8 version, I added 1.0.9 as a second install option. I think you can simply re-install 1.0.9 over your existing 1.0.8 without having to get a new license, but I'm not sure. If it wants you to purchase it again, DON'T. I'll move it to the beta store. Since this does add new controls, you'll have to restart the admin console after re-installing and starting it to see those new controls.

Yes, you can run multiple copies of any node server. So in theory, you can run two copies each linked to a different smart bridge.

I have no idea what that means. The existing node server doesn't use either of those endpoints.

The node server can only link to one smart bridge.

Thanks @DennisC I meant to imply that I'd look into more, but I probably should have been more clear on that.

It won't automatically try update anymore. Each installed node server checks for updates when it is started and if it sees one available, it will display a notice and add an update button to the node server details page. Clicking the update button is a basically a shortcut to the purchases -> re-install page. It still should be doing global checks for updates every 8 hours same as it was before. It seemed to be working as intended when I tested it, but I only test with a small number of node servers (mostly my own since I can't make updates to other developer's node servers).