This topic can be used for any discussions around the openHAB 4.3 Milestone builds as it has been announced in openHAB 4.3 Milestone Builds .
Looking forward to this new release! The Mqtt home assistant discovery updates in particular look very interesting to me 
Very cool, thanks! Did the update this morning and all is good. The only issue I see is with some links and charts I have on my overview layout page. Two charts that I had added to the overview page worked fine pre-upgrade and now show an error message that the content has been blocked. Same thing for 3 video feed URLās that I have on the overview page.
Iāve tried 3 different browsers, mobile vs desktop and none of them display the charts/video feeds. However I can access the video feeds via their own URLās directly with no issues (and this URL is the same one used in the widget on the overview). Additionally, I have the exact same video feed URLās used as the background for particular cards on the oob homepage and they work fine there. Just not on the overview page itself, weird.
Cheers
This is related to the changes in the UIās content security policy. Please file an issue on the UI repository with the details of blocked content and the errors in your browser console.
Can you please try this on desktop, open the browser dev tools there and tell me the error messages that the console logs?
I need to know which part of the CSP is the āproblemā ā¦
This error message is generated for both the video feed urlās and also the charts (substitute the urlās of course).
Refused to frame āhttp://192.168.50.5:8080/ā because it violates the following Content Security Policy directive: ādefault-src āselfāā. Note that āframe-srcā was not explicitly set, so ādefault-srcā is used as a fallback.
Maybe related to the above issue: I noticed that external frames within the UI are not displayed anymore (message says āblockedā).
Example page
config:
label: Tab Manni
layoutType: responsive
sidebar: false
blocks:
- component: oh-block
config: {}
slots:
default:
- component: oh-grid-row
config: {}
slots:
default:
- component: oh-grid-col
config: {}
slots:
default:
- component: oh-webframe
config:
height: calc(100vh - var(--f7-navbar-height) - var(--f7-tabbar-labels-height) - var(--f7-safe-area-top) - var(--f7-safe-area-bottom) - 2rem)
src: http://192.168.1.90/control
grid: []
Iām using the docker version running on ubuntu server, and immediately after updating I am now getting the following error during start of the container:
Launching the openHAB runtime...
Cannot parse null string
Error occurred shutting down framework: java.lang.NumberFormatException: Cannot parse null string
java.lang.NumberFormatException: Cannot parse null string
at java.base/java.lang.Integer.parseInt(Integer.java:630)
at java.base/java.lang.Integer.parseInt(Integer.java:786)
at org.apache.karaf.main.ConfigProperties.<init>(ConfigProperties.java:251)
at org.apache.karaf.main.Main.updateInstancePidAfterShutdown(Main.java:232)
at org.apache.karaf.main.Main.main(Main.java:197)
Iām a bit lostā¦
edit:
Not knowing what to do, and having my WaF in the gutter, I restored the 4.2.1 and everything is getting back up now - Maybe something wrong in the docker image??
Can anyone assist?
@pleedell and @Larsen: Thanks for your reports, as @JustinG said this is related to the CSP changes of Main UI:
We have modified the CSP to be more strict to improve protection against XSS etc., but obviously embedding broke and I havenāt noticed.
As I donāt see a problem in allowing embedding of any source, so I have created a PR to fix that regression: CSP: Allow embedding any source by florian-h05 Ā· Pull Request #2741 Ā· openhab/openhab-webui Ā· GitHub
2 Likes
Thx much, happy to help out where I can with testing.
Can anyone help me with this issue?
I am not familiar with the docker / karaf side of things, but perhaps you could post these:
- docker compose file or docker command
- conf/services/*.cfg
- Any other startup stuff you might be doing, e.g. environment vars etc?
For those who donāt want to wait for the next milestone:
If you have a reverse proxy in place, set the CSP header through the proxy (the CSP header always takes precedence over the meta tag in the HTML), you can find the fixed header here: openhab-webui/bundles/org.openhab.ui/web/src/index.html at 22a42c3607e39160afa7dd3921734c93d9bab9f1 Ā· openhab/openhab-webui Ā· GitHub
Another option is to update the UI bundle:
Access the Karaf console (usually through āopenhab-cli consoleā, default password is habopen), find out the UIās bundle number:
bundle:list org.openhab.ui
Then, go to the Jenkins CI server, select the largest Job from openHAB-WebUI [Jenkins], click on Build Artifacts and copy the link to the org.openhab.ui-4.3.0-SNAPSHOT.jar from the bundles/org.openhab.ui/target folder.
Then update the bundle on your machine:
bundle:update BUNDLE_ID LINK_TO_BUNDLE
In investigating this issue, found I have a problem with updating the Zstick configurations on OH4.3M1, so it might be an issue with the 4.2 release too (as the linked issue was on OH4.2.1). I know the ZW binding has not changed in this area for some time. On a whim I did put the org.openhab.core.config in Debug, but it was not conclusive. Has there been any changes that affect configuration either in OH4.2.1 that have carried over to 4.3M1? Basically what is happening with a config update is the binding goes offline. It comes back fine, with the changed configuration, but in the case in the issue above the exclusion is time sensitive, so nothing happens.
FWIW- I am on OpenHab 4.3.M1 running in a docker on Rpi3b with Aeotec 500 chip zstick.
2024-09-05 09:24:24.510 [DEBUG] [g.zwave.internal.ZWaveHandlerFactory] - bundle org.openhab.binding.zwave:4.3.0.M1 (252)[org.openhab.binding.zwave.internal.ZWaveHandlerFactory(323)] : Querying state active
2024-09-05 09:24:24.512 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - bundle org.openhab.binding.zwave:4.3.0.M1 (252)[org.openhab.binding.zwave.internal.ZWaveConfigProvider(322)] : Querying state active
2024-09-05 09:25:24.725 [DEBUG] [nfig.core.status.ConfigStatusService] - There is no config status provider for entity zwave:serial_zstick:53710c99ce available.
2024-09-05 09:25:24.726 [DEBUG] [onfig.core.ConfigDescriptionRegistry] - No config description found for 'thing:zwave:serial_zstick:53710c99ce', using alias 'thing-type:zwave:serial_zstick' instead
2024-09-05 09:25:48.351 [DEBUG] [onfig.core.ConfigDescriptionRegistry] - No config description found for 'thing:zwave:serial_zstick:53710c99ce', using alias 'thing-type:zwave:serial_zstick' instead
2024-09-05 09:25:48.403 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing receive thread
2024-09-05 09:25:48.462 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Stopped ZWave thread: Receive
2024-09-05 09:25:48.464 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Stopping ZWave network
Edit: Created docker container with same things except on OH4.1.2 and there is no problem. Must be something in earlier 2024.
Working:
oh4-1-2-exclude.txt (7.8 KB)
Also ran on OH4.3M1 with all OH core in debug. Something does look amiss
no-exclude-dev.txt (24.3 KB)
Lastly noticed that the UI code tab for the controller shows exclusion is ātrueā. That is supposed to quickly turn back to false, not be persisted.
zstickconfig.txt (1.7 KB)
1 Like
After moving to 4.3.0.M1, Zoneminder has stopped working. Seeing this on the server thing:
Strangely the monitors show online, but arenāt reporting alerts or motion. Tried the usual delete and recreate the thing, uninstall/install binding. Log shows nothing in Debug mode.
Correction: Log does show:
Initializing handler for thing 'zoneminder:server:5477f8f8a5' takes more than 5000ms.
ā¦at start up.
Short feedback regarding the issue with external sources between milestone and snapshot #4255
- External frames within the UI work in the snapshot, so this is solved
- video-feeds in a video card are not working, so this issue is still remaining. The card is black and the log shows no entries. Please info if I should change any log levels to dig deeper.
1 Like
Hi Florian
maybe you want to have a look at this āuglyā bug which is still in 4.3 M1:
Thanks. BR
@florian-h05 regarding video streams in latest snapshot (#4272).
The video card now tries to load the stream but the wheel keeps spinning forever.
(If I should report somewhere else (or not at all 
), do specific tests or logging just tell me)
What does the browser console show?
in Chrome itās:
Refused to create a worker from 'blob:http://...' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' 'unsafe-eval'". Note that 'worker-src' was not explicitly set, so 'default-src' is used as a fallback.
...
Understand this error.....js:2 VIDEOJS: SecurityError: Failed to construct 'Worker': Access to the script at 'blob:http://...' is denied by the document's Content Security Policy.
Uncaught SecurityError: Failed to construct 'Worker': Access to the script at 'blob:http://...' is denied by the document's Content Security Policy.
1 Like