openHAB 4.3 Release Discussion

That certainly indicates that HTTP/2 got broken in OH core during your upgrade. However I just tested myself on a clean install, and it works OK, so the issue may be that some Jars got lost in the upgrade process. Did you try clean-cache?

Maybe. Pinging @wborn ??

Thanks @AndrewFG, clearing cache helped.

Coming back to this post from myself earlier: Actually I cannot choose any profiles for any channel link. Is anyone experiencing the same? All the profiles are always greyed out.

Hi Rich, thx for help.
My thought was that the ā€œnew log-viewerā€ works like frontail as it uses the same log-set in the karaf-console. As that’s what I observe when comparing the the setup of karaf-console and UI-log-viewer.
But the result of views in frontail and UI-Log-View are not the same.
For example:

2024-12-19 00:04:49.282 [INFO ] [e.model.script.miniswitch_snzb01p_02] - single - ON Lampe ausgeschaltet: Bastel-Keller
2024-12-19 00:04:54.819 [INFO ] [e.model.script.miniswitch_snzb01p_02] - single - OFF Lampe eingeschaltet: Bastel-Keller

This is logged in frontail but not in UI-log-viewer. Maybe I have to tinker a bit to better understand the new feature. But in my opinion the logs should be the same as the same log-levels are used, isn’t it ?
And I found a new log-message that I never observed in the past

2024-12-19 00:11:59.873 [INFO ] [b.core.io.websocket.log.LogWebSocket] - WebSocket error: java.util.concurrent.TimeoutException: Idle timeout expired: 10000/10000 ms

Thje way it works is there is a log appender that publishes all the logs to a websocket which the log viewer subscribes to and shows. Everything configured to log, no matter what file or destination it’s configured to go to will appear in the log viewer.

All Frontail does is spit out the contents of openhab.log and events.log.

That’s probably an indication something went wrong with the log viewer.

I have now some performance issues with OH4.3.0. If I try to open more than one browser window then when opening a 2nd window Chrome browser gives an error message

ERR_CONNECTION_TIMED_OUT

Same problem with Edge and Firefox.

I didn’t have this problem with OH4.2.0 so I could easily open up e.g. three browser windows.

I’m running OH in Windows 11 machine, Intel NUC8i7BEH with 16GB RAM.

Upgrade for me from OH 4.2.3 went well (OpenHABian bookworm on RPI4) in general.

There was one notable issue.
I have a Hue Emulation running, which until now never had any glitches after an update.

Now, it seems like something has changed - probably the UIDs of the published lights.

This lead to the effect that in my Rademacher Homepilot, which is linked to the emulator, all published lights are still present under the same names, but as new devices. This broke all links to the old devices.

I had to manually re-link about 60 scenes to these new devices…but at least things are up again.

Do you have multiple tabs open?

Always! With rules, with thing, with MainUI to configure all parallel, in the previous version too, and there was no problem.

Edge is blocking after 3-4 click when I choose eg. thing/channel/item,…:frowning: On the Firefox it’s working a little bitlonger, but after few click the efect is the same. Temporary I’m working on Firefox, but scripts in Blocky are not presented in Firefox :frowning: Everything on Windows of course.

Clock widget - my setup is screwed, and only the text color I could fix with the stylesheet, but I have a white border, I can’t get rid off currently.

Did you try the example I posted?

In my case background and text color can be set but the ā€œbackgroundā€ option inside widget does nothing.

I also noted that Clock Widget is no longer clickable or at least has no action when clicked even when you set a page.

stylesheet: |
    .col > div {
      color: black;
      background-color: lightgreen
}

EDIT: Use the following widget code (Edit YAML button):

component: oh-clock-card
config:
  style:
    background: green

The background property broke during my refactoring, setting the card style is now much easier, so I decided to remove the background property now.

I have fixed this as well, will also get backported to 4.3.1: `oh-card`: Fix action & tap-hold action not working by florian-h05 Ā· Pull Request #2931 Ā· openhab/openhab-webui Ā· GitHub

I don’t think this issue really related to the openHAB version, rather to some recent browser changes … see Enable http/2 for https & Set Keep-Alive header for http Ā· Issue #4466 Ā· openhab/openhab-core Ā· GitHub for more information. We are working on fixing this.

Thank you! :smiley:

That’s understood, but is there a way to expand the log buffer similar to the frontail file hack that change the the number of buffer lines. I’m using 2000 lines which gives me a 12 hr live system performance overview.

Also, is there a way to use frontail in OH4.3?
If not, how can I gain access to the latest OH4.2 now when OH4.3 is default openhabian setup?

There are performance considerations to adjusting the buffer but it was my understanding that log viewer already uses 2000. But there was lots of last minute changes to address performance that I didn’t follow closely. Maybe it’s shorter but I doubt it. @chris, the developer who added log viewer has reported he routinely has millions of lines of log per day.

@chris, what’s the limit? Should an issue be created to make this configurable or does that open a performane can of worms?

Frontail is a completely independent third party software. You can install it on any machine to expose any file you want it to. It’s abandon ware with known and severe security vulnerabilities which will never get fixed which is why it’s on the chopping block right now. But automatic removal of it by openHABian was premature and in the next day or two there will be an update to openHABian that restores the ability to install Frontail.

openhabian-config has a menu option to choose the version of OH you want or you can fix the version using the apt command. But the version of OH running has nothing to do with Frontail being installed or not.

Just to be clear:

  • openHAB is it’s own product with it’s own release cycle
  • openHABian is a completely separate product (i.e. openHAB !== openHABian) with its own release cycle
  • Frontail is an abandonded and vulnerable third party product that openHABian can install and configure to serve up openHAB’s log files

Hi Rich, thx for answering.
But at the moment I think that the new log-viewer is not what ā€œI likeā€ as I do not understand the handling and some messages (web-socket…)

…as I didn’t changed anything. Just made an upgrade via openhabian. Under normal circumstances I only get Log-Messages from my Rules. But in the new Viewer the screen shows ā€œnothingā€ ???
A cutout of frontail:

2024-12-19 16:38:13.668 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid OH4_danny
2024-12-19 16:38:33.424 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
2024-12-19 16:38:37.522 [INFO ] [nding.http.internal.HttpThingHandler] - Using the secure client for thing 'http:url:health'.
2024-12-19 16:46:01.231 [INFO ] [g.openhab.core.model.script.testTime] - testTime is testTime (Type=DateTimeItem, State=1970-01-01T16:46:00.000+0100, Label=Zeit-Item für Tests ohne pattern, Category=null)
2024-12-19 17:33:08.823 [INFO ] [re.model.script.miniswitch_snzb01_02] - single - OFF Lampe eingeschaltet: Arbeitszimmer
2024-12-19 17:33:21.895 [INFO ] [re.model.script.miniswitch_snzb01_02] - single - ON Lampe ausgeschaltet: Arbeitszimmer

I switched off (set to warning or error) all unnecessary. As I don’t need an info every half a second what my items spit out.

Cheers, Peter

Rather unlikely on two browsers - as I wrote above both Edge and FireFox :frowning:

Hey,

after updating to 4.3 I have a problem with my dimmer items specifically there representation in the WebUI.

I have the underlying thing defined like this:

Type dimmer : brightness "Brightness" [ stateTopic="", commandTopic="", min=0, max=255, step=1]

Then I add a Dimmer Thing ontop ether using the WebUI or a config file like this:

label: Helligkeit
type: Dimmer
category: Light
tags:
  - Point

So there is not many configuration to it, the Profile of the Mapping is configured to ā€œStandardā€.

In the previous version the oh-slider item converted by default the value range from 0-255 to a 0-100% range and I was able to drag the slider.

Now it still does this conversion in the value that is displayed for the Item but the slider is no longer moveable, when I go into the configuration of a default Widget I see that the Step is configured to a value smaller than 1.
When I change this to 1, the Widget works in the preview on the page, but no longer after saving.

Im currently a bit lost in how I should configure this correctly or where the error comes from.

EDIT: It works after saving, so for some reason the step can set itself to an incompatible value.