bpwwer

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.

From the log it looked like it was recognizing the license, but it should have an "Install" button instead of a purchase button so maybe not. I would think it would show up under the Purchases screen as well. So before you do anything else, can you do something from a ssh command line? If you can run the following: sqlite3 /var/polyglot/pg3/pg3.db Then, from the sqlite prompt type: select name,nsid from Node Server where name="DysonPureCool"; This should show one line that looks something like: DysonPureCool|c8cca282-ba32-47a7-b56a-abbc8e25904c But the ID string will be different. I need to see that ID string. To exit sqlite, type ".ex" and it will return the normal ssh command prompt

It found your license so that's a good thing. But since it's a new entry in the store and has new purchase options, your PG3 can't figure out which purchase option was used to purchase it initially so can't auto-update it. You should be able to go to the node server server store, select the "Install" for the DysonPureCool node server and you'll have an option to re-install it to the existing slot. That should get you the latest version and then PG3 should now which install option was used for future updates.

Looks like @glarsendeleted it from the store. He also seems to have removed the node server from github.

The log shows authentication failures every time it tries to connect to the ISY. So most likely you need to reset the username and/or password in the ISY menu.

@oneklakes, not PG3 but the UDI portal (https://my.isy.io). Thanks for the log, I'll take a look and let you know what find there.

For some node servers, auto-update and re-install fail on PG3x. The effected node servers are those that use the 'git' method of distribution. With the current version of PG3x, the only way to get them to update is to remove and then install.

The license information comes from the portal so first step would be to check that. Log into the portal and select Connectivity -> node servers from the "More Tools" option. It should list all the node servers you have licenses for. That's information PG3 should be using to determine if the license has expired or not. If that looks correct. Switch the PG3 log to debug level, let it run for 2 or 3 minutes, switch it back to info, download the log and PM it to me.

No, there shouldn't be. It should allow you to rate anything that shows up on your Purchases page. I do see that a number of folks have rated multiple node servers.

Logging for node servers is done using a Python logging library. I don't believe it had support for compressing the old logs back when first used. I've changed it now to only keep 14 days, but this type of change will only really effect new node server installations, not existing one. I'm looking into compression to see if that's been added to the library.

I wrong about the logging. The node server logging for PG3 node servers was copied from PG2 and has been configured to rotate daily and, I believe, keep 30 days of old logs. It's been like this for about 3 years (I.E. before PG3 existed). It doesn't compress the logs. As @Geddysays, there's no good reason to leave the level set to debug as some node servers can be very chatty when set to that. Having a 10G quota on the PG3 directory seems like a new(ish) thing too.