@naugehyde bt-sensors-plugin-sk plugin is causing a bit of problem for this update. For some reason amd64 is working fine, but arm64 fails to load configurations settings for the plugin. Not really clear to me why this happens.

Plugin Bundle: [React, RJSF, Plugin Code]
Server Bundle: [React, RJSF, Server Code]
↓
TWO copies of RJSF
↓
React Context breaks!

With Module Federation it should go:
Plugin loads:
Server provides: React ✓
Server provides: RJSF ✓
Plugin only loads: Custom UI code
↓
No conflicts!

That would need some extra work here to expose component to plugin, but also changes to plugin.

And I am currently working on an update to the shelly2 plugins configuration, I based that on the bt-sensors-plugin code.

The bt-sensors custom config panel embeds @rjsf/bootstrap4 panels

package.json:

{
  "name": "bt-sensors-plugin-sk",
  "version": "1.3.4",
  "description": "Bluetooth Sensors for Signalk - see https://www.npmjs.com/package/bt-sensors-plugin-sk#supported-sensors for a list of supported sensors",
  "main": "index.js",
  "dependencies": {
    "@rjsf/bootstrap-4": "^5.24.12",
    "@rjsf/core": "^5.24.11",
    "@rjsf/utils": "^5.24.11",
    "@rjsf/validator-ajv8": "^5.24.11",
...
}

it looks like there's a minor version difference between the mainline package.json and my own.

perhaps the version difference is the source of the issue.

AI friend says: Even with identical versions, having two separate instances breaks React Context because they're different objects in memory.

Is the problem that a browser on an ARM64 based system is failing to load the plugin config?

If so, what errors are you seeing?

Cannot GET /bt-sensors-plugin-sk/remoteEntry.js
And this happens only with arm64, amd64 returns fine same as earlier.

Which browser are you using? Firefox?

Gemini reported the following:

The ns_error_corrupted_content error for remoteentry.js is typically a Firefox-specific issue, often indicating a problem with a cached file or an incorrect server configuration. [[1]
(https://www.reddit.com/r/firefox/comments/138q8ln/getting_message_ns_error_corrupted_content_next/), 2]
User-Side Solutions These steps can often resolve the issue if it is related to your browser's local cache:

• Bypass the cache: Perform a hard reload of the page using Ctrl+Shift+R (or Command+Shift+R on Mac).
• Clear site-specific data:

1. Click the lock icon (or 'i' in a circle) next to the website address in the URL bar. 
2. Select "Clear cookies and site data...". 
3. Reload the page. 

• Clear all browser cache and cookies:

1. Go to the Firefox menu (☰) > Options (or Settings). 
2. Select "Privacy & Security" from the left sidebar. 
3. In the "Cookies and Site Data" section, click "Clear Data...". 
4. Ensure both "Cookies and Site Data" and "Cached Web Content" are checked, then click "Clear". 

• Clear local/session storage: Open the developer console (F12), go to the Console tab, and run and then reload the page. [2, 3, 4, 5, 6]

Developer/Server-Side Solutions If the error persists across different users, the problem likely lies on the server side:

• Verify the MIME type: Ensure the server is sending with the correct or HTTP header, not . An incorrect MIME type can cause this error.
• Check file deployment: Confirm that the asset is correctly included in the deployment package and is accessible at the expected URL. The file might be missing or in the wrong build output directory.
• Manage caching: If the file has been updated, ensure the old version isn't being served from a stale cache (e.g., a CDN or server cache). Implement proper versioning or a cache-busting mechanism for dynamic content like .
• Check server compression: Issues with how the server compresses the file (e.g., Gzip or Brotli) can sometimes lead to the browser failing to decompress it, resulting in a corruption error. Ensure compression is configured correctly.
• Avoid multiple redirects: Firefox may throw this error if there are multiple, non-standard location redirects in the HTTP response headers. Check for and resolve any excessive redirect chains. [1, 8, 9, 10, 11, 12]

AI responses may include mistakes.

[1] https://www.reddit.com/r/firefox/comments/138q8ln/getting_message_ns_error_corrupted_content_next/
[2] https://support.mozilla.org/en-US/questions/1232935
[3] https://davidjb.com/blog/2017/11/resolving-an-ns_error_file_corrupted-error-in-mozilla-firefox/
[4] https://askubuntu.com/questions/110649/how-can-i-stop-firefox-throwing-a-ns-error-file-corrupted-error
[5] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Clear-Site-Data
[6] https://learn.microsoft.com/en-us/answers/questions/1345357/same-website-accessible-in-chrome-but-not-in-edge
[7] https://es.linkedin.com/advice/0/what-steps-troubleshoot-web-application-wont-load-mmq3e?lang=es
[8] https://community.cloudflare.com/t/ns-error-corrupted-content/701660
[9] https://community.cloudflare.com/t/ns-error-corrupted-content/701660
[10] vitejs/vite#18759
[11] https://stackoverflow.com/questions/79036988/ns-error-corrupted-content-in-live-server-with-typescript-generated-js-files
[12] https://support.mozilla.org/en-US/questions/1232773

There couple other remoteEntry.js which are loading just fine.

I can't explain it. The file is there or it wouldn't load on the AMD64 platform.

I'd try clearing the browser cache first.

Tested with Chrome and Android Chrome, the same.

Same NS_ERROR_CORRUPTED_CONTENT error? Or different on those other platforms?

If you can give me a public address I can try and load the site from my phone which is android/arm64.

404 and same was with FF too + that error msg. Need to dig in what packages are actually installed arm vs amd.

I can't give access, sorry.

Docker image is this one, if you want to test locally.

https://github.com/KEGustafsson/signalk-server-dockers/pkgs/container/signalk-server/567758995?tag=latest

404 should be easy enough to debug, just look at the access log and what's on the disk. I have a hard time understanding how arch would be in the picture, but 🤷 .

Oh, so bt plugin includes another React and rjsf in the plugin configurator. A quick way around that would be to make that a full blown, whole page webapp and embed just a static page with a link to the webapp.

But since you already have a nontrivial amount of configuration UI I think the best way forward would be to make the component use server's reactstrap instead of rjsf.

@KEGustafsson I'm not able to recreate the issue.

Test went like this:

1. Installed and ran docker container on RPi4b
2. installed bt-sensors from appstore/restarted SK
3. ran in Chrome on MacOS (AMD64) - config worked
4. ran in Chrome on Android phone (ARM64) - config worked

Note: The server reported permission issues running the bt-plugin but I think that's a known issue with a known solution

This image has already fallback included for this dual rjsf, so it is rendering also arm64, but not using plugin files if it fails.

In arm64, do you see the same configuration page as with amd64?
Code is not included PR (yet).

I can't spot any differences between amd64 and arm64 server-admin-ui and bt-sensors-plugin-sk packages and versions. Both seems to be exactly the same.

Yes, on the client side, the config screens appeared identical in Chrome/Firefox/Safari on the AMD64 (Macbook Air Early 2020/MacOS 15.6) and Chrome/Firefox on the ARM64 (Pixel 6a/Android 16) client.

I am still getting an error on the server:

DBusError: Failed to execute program org.bluez: Permission denied...

How do I clear that condition?

Solved!
Issues was the arm64 was using bt-sensors-plugin-sk files directly from Github (latest fix for BT stuck problem) and it was never build so there were neither ./public files available.

Working fine now!
Sorry for all the mess!

I think, Plugin Config page appearance starts to be very similar compared to the old one.