bpwwer

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

When the eisy starts up it's using VGA emulation for the text console. When you run start.win, it switches to using the i915 drm driver's framebuffer graphics and I believe X windows is configured to use the framebuffer driver and not the i915's native X windows driver. Can you ssh into the box? If so, after running start.win, run dmesg from the ssh console. That should show the drm driver starting. Unfortunately, I don't know anything about the freebsd port of the i915 driver. I used to work on the Linux i915 driver full time before I retired.

When you get the blank screen try CTRL-ALT-F1 That should take you back to the text console. That might show something to indicate what's wrong. CTRL-ALT-F9 will switch back to the X-Windows screen You can also check the /var/log/messages file for drm messages. Mine looks like Mar 10 11:04:33 eisy kernel: vgapci0: child drmn0 requested pci_enable_io Mar 10 11:04:33 eisy syslogd: last message repeated 1 times Mar 10 11:04:33 eisy kernel: [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19). Mar 10 11:04:33 eisy kernel: [drm] Got stolen memory base 0x0, size 0x0 Mar 10 11:04:33 eisy kernel: drmn0: successfully loaded firmware image 'i915/icl_dmc_ver1_09.bin' Mar 10 11:04:33 eisy kernel: drmn0: [drm] Finished loading DMC firmware i915/icl_dmc_ver1_09.bin (v1.9) Mar 10 11:04:33 eisy kernel: sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)! Mar 10 11:04:33 eisy kernel: [drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0 Mar 10 11:04:34 eisy kernel: drmn0: [drm] HDMI-A-3: EDID is invalid: Mar 10 11:04:34 eisy kernel: [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Mar 10 11:04:34 eisy syslogd: last message repeated 7 times Mar 10 11:04:34 eisy kernel: VT: Replacing driver "efifb" with new "fb". Mar 10 11:04:34 eisy kernel: start FB_INFO: Mar 10 11:04:34 eisy kernel: type=11 height=1200 width=1920 depth=32 Mar 10 11:04:34 eisy kernel: pbase=0x4000040000 vbase=0xfffffe0115a40000 Mar 10 11:04:34 eisy kernel: name=drmn0 flags=0x0 stride=7680 bpp=32 Mar 10 11:04:34 eisy kernel: end FB_INFO

The error is coming from the Honeywell Home server. A 500 error code means that the something went wrong on the server side. The response was: Oops! Sorry! Something went wrong.Please contact chil@honeywell.com so we can try to fix it. There's nothing wrong with the node server. However, it is possible that Honeywell changed the API and that the node server will no longer work with it. I didn't write the node server and don't have any idea how it works with the Honeywell servers.

Hello Everyone, This is the support thread for PG3x v3.1.23