bpwwer

Auto updating has been problematic for a while now. It started having issues when I added a the ability for node server developers to release multiple versions of the same node server. Previous to that, PG3 didn't need to know what you had purchased, you had simply purchased node server X and if there was a new version of node server X, it could update to that. Now there could be node sever X standard edition and node server X professional edition so PG3 has to know which one you purchased to know if it can update what you have. In some cases it's easy for PG3 to determine what you have installed and update, but in many cases now, what was installed doesn't have the information PG3 needs to know what it should update. In this case you can manually update using the "re-install" option. The "re-install" option does the same thing as a update, but you have to tell PG3 what purchase option to use when updating. "re-install" doesn't delete existing nodes or delete existing configuration so you won't have redo configuration. About a month ago I made a change that broke version detection for some (many) node servers. This also impacts the auto update as it compares the running node server with no version to the version in the store and says you need to update. It can't tell that the version you're running is the latest because of the missing version info. Unfortunately, the fix can't be pushed out globally and may require the individual node server to be modified by the author to require the fix and then be re-installed.

Restarting node servers or restarting PG3 multiple times a day is not normal or even close to normal behavior. Trying to fix it by automating the restarts doesn't do anything to resolve the underlying problem. I understand that not all node server authors are responsive and there are currently quite a few that are basically unsupported at this time. But the first step should always be to try and contact the author for help. If the author is unresponsive or says they can no longer help, PM me and let me know. I'll do my best to help. Also, and this is more of a general comment, when looking for help on a node server, the log file is critical. When one isn't working as it should there's a good chance that the log file will include the reason and simply reviewing it lead to a resolution. Ideally, capturing the log file with the level set to debug is best.

You'll have to submit a support ticket. https://www.universal-devices.com/my-tickets

Are you on the latest IoX already? I believe this only works for version 5.5.9 so you should probably do an "Upgrade Packages" from the admin console, prior to trying to migrate.

Unless the node server is crashing, which it doesn't look like it is, the author may not have set default parameters so as @DennisC suggests, you may have to add them yourself.

If you set the node server log level to debug, it will output what it's getting from the SolarEdge server. Basically, from the above, what it gets from the server has no inverter data in it, but we don't know why. It's possible that you are exceeded some query limit. Seeing the actual return from the server may include details on why it has no data.

This should be fixed in the latest interface module for node servers. However, this isn't something that can be easily pushed out. Basically all node servers need to be modified to require the new module. For PG3 on Polisy's it only gets updated when a node server is installed that requires the new version of the interface module. For PG3x on eisy's, each node server install loads a separate copy of this module. So each would have to be modified and then re-installed. Over time, as node servers are modified, they'll get the updated version.

Pushed out yet another update. Hopefully I got it right this time. This is still version 3.1.24.

RYSE provides a retrofit automated shade solution for shades that are controlled by cords or beaded chains. A basic system consist of the shade controller itself (either corded or battery powered) and a bridge/hub to manage the shade controller. The RYSE-shades node server interfaces with the bridge/hub via your local network to receive status updates on the shade positions and allow the IoX to control the shade positions. To begin, install the RYSE-Shades node server from the Node Server store. Then go to the RYSE-Shades Node Server details page and select Configuration. To configure the RYSE-Shades node server, enter the IP address of the RYSE bridge/hub like so: Once you "Save Changes", the node server will connect to the bridge/hub and query it for all connected shades. It will then create a node in the IoX for each shade it finds. Restart the Admin Console (if running) and you will find nodes representing each shade. For example: You can then incorporate the shade into your automation programs.

Ok, a new version of 3.1.24 is back up and should have working dialog boxes again. "Upgrade Packages" should see it and update it.

All model dialog boxes are disabled. I don't know why this rebuild of the UI is like that. In the meantime, I've removed 3.1.24 and rolled it back to 3.1.23.

Version 3.1.24 of PG3x should be available now although it may take a few hours before your eisy checks for available upgrades.

Will be fixed in 3.1.24 that will be available as soon as I can get it out there.

Looks like there's a bug in the latest PG3x release that's preventing it from removing node servers.

Log files. I can't emphasize this enough. While I've tried to improve the error reporting to the UI, it's just not designed well enough to make make error reporting easy and intuitive. The log files should contain the details when things go wrong. Node server control (install/start/stop/remove) is very different for PG3x on eisy and PG3 on Polisy so knowing which is also important. In your initial message you say that you: 1. first delete the node server from the admin console. Don't do that. PG3(x) installs the node server and should also remove the node server from the IoX. By first deleting it using the AC, you've remove it from the IoX and now PG3(x) is somewhat confused as you did that "behind it's back". Using the AC to remove a node server should only be done for orphaned node servers (ones that are currently being managed by something (PG2/PG3(x)).

Some older node servers/older versions of node servers can't auto-update because PG3 doesn't have enough information to know what to update. In those cases, selecting the correct install option / re-install to same slot should update the node server.

No it doesn't. I don't think that creating a node just to report the node server's status is a good way to accomplish that.

What errors are you seeing? What version of PG3x are you using? The login process will report a couple of different errors depending on what is wrong. For example, if it reports authentication failed, that mean just what it says, the username or password didn't authenticate to the eisy username and password. If it says the error is unknown, then it was unable to connect to the authentication server. Also, if you're not on the latest version of PG3x, (3.1.23) there are bugs in earlier versions of the login process that can cause login failures.

Yes, after migration the node server has to re-create the certificates for the new machine it's running on and then sync those with the smart bridge. Having the IoX monitor node servers was something I asked for years ago, but it would be something that needs to be added to the IoX firmware. Currently, the IoX can monitor node server status for node servers that report that if they use the PG3 node server status reporting feature. You can have a program that sends notifications if the status is disconnected or failed.

There have been other reports of MQTT SSLEOF errors. That error is coming from the Python MQTT library so not something any of our code (node server, udi_interface, or PG3) can do anything to change that.

Try restarting and then run the sudo kldload i915kms from a ssh session. If you can do so while the display is attached to the eisy and on, that would be best. What's showing on the screen looks correct so the driver does seem to load properly. It's just when it tries to detect the display that something goes wrong.

Yes, that would do it. The start.win script is running sudo kldstat -m i915kms sudo kldload i915kms So the first time after a boot, it may display that error as the driver isn't loaded, but then it does try to load the driver. You can try running those from the command line. After the sudo kldload i915kms is loaded, the screen should switch from VGA emulation to a graphical console screen (most noticeable because the text gets smaller). In your case, I'm expecting this will probably give the same black screen results. You can also try running the 'sudo kldload i915kms' from a ssh session and see if it generates any error messages. The i915kms kernel module should be in /boot/modules and is installed as part of the package drm-510-kmod-5.10.163_1 so you can try re-installing that package sudo pkg install -f drm-510-kmod-5.10.163_1

From the looks of it, macID is something that is supposed to be returned from the server when it queries for devices.

Unfortunately, none of the tools that I've used in the past to debug issues with i915 seem to be available for FreeBSD. Two more things you can try 1. There are two HDMI ports on the eisy, have you tried both? 2. After running start.win, try unplugging and re-plugging in the hdmi cable. The driver is supposed to detect that and reset when it detects a cable being plugged in. Maybe even switch it back and forth between the two HDMI connectors on the back. And maybe try a different HDMI cable if you have one. It's possible that when it switches to a high resolution, the cable can't handle it if it's an old or very cheap HDMI cable. P.S. I thought I had left the days of debugging i915 issues behind

That's very strange. Have you powered down the eisy and restarted it? The only thing I can think of at this point is that the graphics hardware is in a hung state and needs to be power cycled to reset it.