bpwwer

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.

The fbinfo from your dmesg shows the resolution as 1680x1050. That's a strange resolution even for a TV (or at least a north american TV). Although it is a valid mode. It's not a standard HD resolution. What model of TV are trying to use?

If you ssh in to the eisy using the same account that you used from the console. After running start.win, go to the ssh session and try the following: sysctl compat.linuxkpi That will list the i915 and drm tunable parameters and their current value. The i915 driver is pretty good about detecting monitors, but some monitors do have bugs that can cause problems. Possibly the driver is unable to get the supported mode list from the monitor and is defaulting to it's built-in list. And maybe the highest resolution on the built-in list isn't supported by the monitor. What's the output of xrandr -d :0