bpwwer

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

Hello all, We are very happy to introduce PG3x v3.1.23 for eisy. The eisy is using a new version of Polyglot version three called PG3x. PG3x has infrastructure changes to make node servers (and PG3x) more secure. This release includes features already available in PG3 3.1.18 for Polisy. For now, Polisy users should remain on PG3 and eisy users will use PG3x. To upgrade PG3x: In the Admin Console, click on Configuration, Upgrade Packages (note, this can take many minutes, depending on how long it's been since you last updated.). After the upgrade is complete you should restart/reboot the eisy. Do this from the Admin Console, Configuration, Reboot. Once PG3x has restarted, reload /refresh the browser page. Changelog for 3.1.24 - Fix bug that would sometimes cause node server delete to fail. Changelog for 3.1.23 - Add setClientState API framework to support remote access to PG3x - Add device config remove for node servers that make use of hardware device configuration - Handle cases where the purchase entry from my.isy.io is unable - Rework handling of incoming requests with requestId from IoX - Filter package upgrade messages to only show PG3x upgrades - pg3_helper: Use onerestart instead of onestart to start node server. - Don't display new version available in footer (use upgrade available messages from UDX instead) - Return discovered IoX when ISY discovery is called - Enhance error message when uuid is invalid (uuid must be available and valid for PG3x to run) - Be better about trapping errors in UDXstart - Add some additional log messages around node server start - Implement node server rating support - Remove the "Log Out Of Portal" button from pages. Being logged into Portal is required. - Add a button to display the Node Server EULA license - Change startup message to PG3x from PG3 - Missing uuid from IoX is fatal - Add support for Node Servers that need device hardware support - Check for existence of UDX socket, this is required for PG3x to run - Node Server info can now list which controllers the node server will work with (eisy and/or Polisy) - Add local store backup/restore feature - Add button to download system log messages (to help with debugging issues) - Check for existence of log file before streaming it Migrating from Polisy/PG3 Make a PG3 backup on the Polisy. From the PG3 UI select System -> Backup/Restore -> Backup. This will download a backup file Restore the PG3 backup on eisy. From the PG3x UI select System -> Backup/Restore -> Migrate from PG3 backup. Select the Polisy PG3 backup file and when the button changes to "Restore" click it. Depending on how many node servers need to be migrated it can take a while. The UI should pop up messages showing the status as it migrates node servers. There are some limitations to the migration process. Only one IoX device can be migrated. If your Polisy was connected to more than one IoX device (say the local IoP and an i994), the migration process will only migrate one of these and it will use whichever one shows up first when it does it's database query. This will remove any previously installed node servers in PG3x and possibly overwrite them with a node server from the backup. You should start this process with no node servers installed. Any node servers on the Polisy that were installed from the "Local" store will fail to properly migrate (applies mostly to developers). All node servers will be left in the "Stopped" state. You will need to manually start each node server after the migration.

It looks like there's now a alternate way to get the password which gets it from the cloud vs. from the machine itself. The claim is that it works for any machine. Switching to that would be a pretty major change for the node server so I'll add it to the list for the node server but no ETA at this time.

Can you try re-installing it now. Do a refresh store first (from the Node Server store page). The problem with the unhandled exception should be fixed so it should install properly.

unmanaged, means that they are not being managed by PG3 but by something else. That's why you can't delete them. In your case, I suspect they are being managed by a previous installation of PG3? or PG2? You can delete them from the Admin Console. Go to Node Servers -> Configure -> slot number for the node server slot you want to delete and click on the "Delete" button. After a few minutes they should disappear from the PG3 dashboard.

You're close. Yes, you need to add a custom parameter with the "Port" "key" field and then the value will be the port that you configure in Meteobridge API URL. If you configure the API URL as "http://10.0.0.56:8045", then you'd set "Port" to 8045 Note, that the IP address in the API URL is the Polisy's IP address. Note2, notice I didn't use port 8080, port 8080 is already in use by the IoX running on the Polisy so you can't use that. When you configured the API URL with that, Meteobridge was trying to send the data to the IoX which rejected it. Note3, I believe the key name is case sensitive so "Port", not "port".

Either I wasn't thinking when I typed the sql command or this auto-corrected it for me. It should have been: select name,nsid from Node Server where name="DysonPureCool"; You can also leave off the where name= part and just do select name,nsid from Node Server; which will display all installed node servers. I looked at the store entry and I don't see anything wrong, but something is happening during the install because it shouldn't be throwing the unhandled rejection error. a 404 is a not found error so maybe the .zip package hasn't been uploaded to the server so it can't be found, downloaded, and installed.

Now that you've re-installed, it's overwritten the nsid that I wanted to see so never mind. Do you remember what you originally installed? I'm not entirely sure how the license is linked but since there can be more than one license type associated with a given node server, it needs to have some way to know which purchase option entry was used to purchase the the license. If the purchase option entries change, as they seem to have in this case, then the license may be linked to a non-existent purchase option. This makes it difficult to properly validate a license. I'm not real sure what to do about this since I can't look at license records nor do I know if it's possible to manually update the records to link with the new purchase option. This may be something that @glarsen, UDI will have to work with you to resolve.