openHAB 5.1 Milestone discussion

3 posts were split to a new topic: Oh-state-series renders into the future

In event.log, I see now new text like (source: org.openhab.core.thing$mqtt:topic:b97b166d:Signal)

.9 (source: org.openhab.core.thing$sensorcommunity:conditions:0d1e4377be:humidity)
2025-12-15 09:03:54.915 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'i_Sonne_Daheim_Azimut' changed from 135.79479039219 to
 138.82095753827628 (source: org.openhab.core.thing$astro:sun:local:position#azimuth)
2025-12-15 09:03:54.916 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'i_Sonne_Daheim_Elevation' changed from 5.8717131421123
75 to 7.553036872675328 (source: org.openhab.core.thing$astro:sun:local:position#elevation)
2025-12-15 09:03:54.919 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'i_Sonnenstrahlung_Direkt_Daheim' changed from 1.368293
9751698224 to 4.49018638537009 (source: org.openhab.core.thing$astro:sun:local:radiation#direct)
2025-12-15 09:03:54.919 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'i_Sonnenstrahlung_Diffus_Daheim' changed from 38.73463
214821401 to 48.96566357136757 (source: org.openhab.core.thing$astro:sun:local:radiation#diffuse)
2025-12-15 09:03:54.921 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'i_Sonnenstrahlung_Total_Daheim' changed from 40.102926
12338383 to 53.45584995673766 (source: org.openhab.core.thing$astro:sun:local:radiation#total)
2025-12-15 09:03:55.597 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'i_mqtt_Sonoff4CH_1_Signal' changed from 54 to 56 (sour
ce: org.openhab.core.thing$mqtt:topic:4c3bd982:Signal)
2025-12-15 09:04:03.666 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'i_Avm200Watt_5' changed from 4.220 to 4.290 (source: o
rg.openhab.core.thing$avmfritz:FRITZ_DECT_200:192_168_1_1:087610393046:power)
2025-12-15 09:04:17.902 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'i_ActiveCall' changed from 071959030, to UNDEF (source
: org.openhab.core.thing$avmfritz:fritzbox:192_168_1_1:active_call)
2025-12-15 09:04:17.902 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'i_CallState' changed from ACTIVE to IDLE (source: org.
openhab.core.thing$avmfritz:fritzbox:192_168_1_1:call_state)
2025-12-15 09:04:22.415 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'i_mqtt_BlitzwoIFSHP6_7_Signal' changed from 92 to 94 (
source: org.openhab.core.thing$mqtt:topic:5b8cafd7:Signal)
2025-12-15 09:04:30.177 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'i_mqtt_BlitzwoIFSHP6_5_Signal' changed from 46 to 48 

can this be hide somehow?

I have had a bit of a problem with persistence.

On docker upgrade I got this message;

[main] INFO org.openhab.core.tools.UpgradeTool - Executing persistenceCopyDefaultStrategy: Move persistence default strategy configuration to all persistence configuration without strategy defined
[main] INFO org.openhab.core.tools.internal.PersistenceUpgrader - Setting default strategy on persistence configurations without strategy '/openhab/userdata/jsondb/org.openhab.core.persistence.PersistenceServiceConfiguration.json'
[main] ERROR org.openhab.core.tools.internal.PersistenceUpgrader - Cannot access persistence configuration database '/openhab/userdata/jsondb/org.openhab.core.persistence.PersistenceServiceConfiguration.json', check path and access rights.

Then my dsl files were rejected;

2025-12-15 07:52:10.983 [WARN ] [el.core.internal.ModelRepositoryImpl] - DSL model 'mapdb.persist' has errors, therefore ignoring it: [2,1]: no viable alternative at input 'default'
2025-12-15 07:52:10.984 [INFO ] [el.core.internal.ModelRepositoryImpl] - Unloading DSL model 'mapdb.persist'
2025-12-15 07:52:10.985 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading DSL model 'jdbc.persist'
2025-12-15 07:52:10.997 [WARN ] [el.core.internal.ModelRepositoryImpl] - DSL model 'jdbc.persist' has errors, therefore ignoring it: [3,1]: no viable alternative at input 'default'

There appears to be no persistence or graphs and can’t reach the configure menu for them.

I’m trying to going back to M3. Still not sure. Will update when I know

Same here. restoreOnStartup through mapdb did not work anymore.
Going back to M3 fixed it 


Can you show your persist DSL files? There is a breaking change in M4, deprecating the default persistence. It is handled automatically when you don’t have a persist file with the upgrade tool, but it looks like you have 1. a persist file and 2. no write access to the json db folder for the upgrade tool to work.

Not sure this is the same issue, see also openHAB 5.1 Milestone discussion - #148 by helmar74. How did you upgrade? Did the upgrade tool run? Do you have your persistence defined in .persist files, or managed through the UI?

Manually, as always. I have a manual installation.

.persist files.

Nothing in the logs 


Edit: ahhh, here we go:


2025-12-15 10:07:57.298 [WARN ] [.core.model.core.internal.ModelRepositoryImpl] - DSL model 'rrd4j.persist' has errors, therefore ignoring it: [4,1]: no viable alternative at input 'default'

Looks like the default strategy needs to be removed.

Then show your .persist files.

See here: Persistence no default strategies and persistence configuration health check by mherwege · Pull Request #4682 · openhab/openhab-core · GitHub

Strategies {
everyMinute	: "0 * * * * ?"
everyDay        : "0 0 0 * * ?"
default = everyChange
}
Items { 
gRestore* : strategy = everyChange, restoreOnStartup
}


 see edit above :innocent:

Same persistence issue. In Main UI, these menus won’t even open. Back to M3 and they are accessible.

Should have been announced as a breaking change 


It actually is in the breaking changes list, but may lack some detail. Unfortunately, it was rushed through a bit (the code had been developed a long time ago already though).

1 Like

How did you upgrade? Do you have your configuration in .persist files, or is it defined in the UI?

Upgraded through apt. All defined in the UI.

Ubuntu 24.04

X86

I’m back on M3 for now. I see by the discussion a breaking change. I had already figured it was the default. My mapdb.

Strategies {
 default = everyChange
}
Items {
  * : strategy = everyChange, restoreOnStartup

The only thing I don’t understand going forward is the write access issue. I have a full jsondb and it is in the docker container like everything else.

services:
  openhab:
    image: "openhab/openhab:5.1.0.M3"
    restart: always
    network_mode: host
    volumes:
      - "/etc/localtime:/etc/localtime:ro"
      - "/etc/timezone:/etc/timezone:ro"
      - "/etc/cont-init.d:/etc/cont-init.d"
      - "./openhab_addons:/openhab/addons"
      - "./openhab_conf:/openhab/conf"
      - "./openhab_userdata:/openhab/userdata"
    environment:
      CRYPTO_POLICY: "unlimited"
      EXTRA_JAVA_OPTS: "-Duser.timezone=America/New_York"
      OPENHAB_HTTP_PORT: "8080"
      OPENHAB_HTTPS_PORT: "8443"
      USER_ID: "1000"
      GROUP_ID: "1000"

and

Edit: Also maybe of interest

reckhoff@raspberrypi:~/openhab $ grep ':1000:' /etc/group
reckhoff:x:1000:openhab

EDIT2: Just noticed on my other system (that I updated last night) that I can’t get UI persistence menus like @kjknauss to work. I have no text files there. Persistence seemed to be working so I didn’t notice.

It is already fixed with Follow-up fixes and enhancements for #3123 by florian-h05 · Pull Request #3589 · openhab/openhab-webui · GitHub. I tried in the latest snapshot and it is working there.

Hi,

openHAB 5.1.0.M4
In Blockly, the block for rounding is a bit broken. Existing commands, for example, produce the message ‘ReferenceError: Input “DECIMALS” doesn’t exist on “math_round”’ and new ones are ignored right from the start.

I can confirm this is fixed in latest snapshot. Thanks!

Overall, I have been testing 5.1 milestone builds and snapshots over the last few days/weeks, and my (quite large) system is running very stable and (almost) without errors. Many thanks to everyone who is working on further development, fixing bugs and investing a lot of energy and time every day!

The only thing I still have is follwing bug in MainUI. I don’t know if it’s a big deal, but maybe someone else can take a look at it?

. . . and a duplicate:

2 Likes

Is there any activity on the release roadmap in order to fix the OH Alexa skill again? It only works in one direction Alexa → OH but it doesn’t update any item state OH → Alexa since a while.

Major issue is that flexible number items (Other.RangeValue) can’t longer be retrieved by Alexa.

See also OH 5.0.3 item states are not retrieved/updated by Alexa and https://community.openhab.org/t/value-of-currenttemperature-item-not-displayed-in-alexa/167378

Hello,

I’ve upgraded yesterday to last snapshoot #4995.Was previously on #4945 from 24/11.
I’m experiencing strange behavior with me lights (Knx binding).
I can switch on the light, I can dim them, but no way to switch off.
If I use a dimmer, I can of course set dim level to 0, that will switch of the light.
But If I use a toggle widget, when I switch off the toggle, it have no effect on the light.
My light are defined as type dimmer.

Does anyone see something similar ?
I’ve don’t try to downgrade for now, but will give it a try today so see if it fix it.

Laurent.

Type dimmer : lightBureau “Light Bureau” [ switch=“0/0/180+0/3/180”, position=“0/2/180+0/4/180”, increaseDecrease=“0/1/130” ]

And in items:

Dimmer Lumiere_Bureau “Lumiùre Bureau [%.1f %%]”
(gBureau,gBureauLight) [ “Light”, “Lighting” ] {
channel=“knx:device:bridge:generic:lightBureau”,
}