Version 5.1.M4, lost TAGs (not displayed anymore, still present in widgets) in Developer tools→Widgets …
Also, TAGs are not searchable anymore.
V5.0.3
V5.1.M4
Regards
/Sas
I’ve created a fix for this.
1 Like
In next release ?
Regards
/Sas
That’s my fault, sorry. I modified oh-toggle and broke this.
I have already created a fix.
Both fixes will be included in RC1.
3 Likes
The fix isn’t merged yet.
Yes, I’ve find the PR!
I thought I’ve already fixed this in Upgrade to Blockly v11 and respective plugin versions by jsjames · Pull Request #3398 · openhab/openhab-webui · GitHub, but it seems I left out some occurences.
Let’s give it another try (and my IDE isn’t able to find any faulty occurences anymore): Blockly: Fix ReferenceError due to non-existing input by florian-h05 · Pull Request #3610 · openhab/openhab-webui · GitHub
2 Likes
Let me share my thoughts on the M4 upgrade.
[openHAB] Listing important changes for version 5.1.0:
Warning: CORE: Persistence default strategies are removed and not applied automatically anymore. Managed persistence configurations are updated automatically.
If you have a file based configuration, you may need to update your configuration.
But what exactly to do is unclear.
In my case, commenting out the default strategies (//default = everyChange) helped (all my items had a strategy assigned, of course).
[openHAB] Running JSON Database upgrade tool (${OPENHAB_RUNTIME}/bin/upgradetool.jar).
[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 '/var/lib/openhab/jsondb/org.openhab.core.persistence.PersistenceServiceConfiguration.json'
[main] ERROR org.openhab.core.tools.internal.PersistenceUpgrader - Cannot access persistence configuration database '/var/lib/openhab/jsondb/org.openhab.core.persistence.PersistenceServiceConfiguration.json', check path and access rights.
This error is incomprehensible because I’ve never had such a file in this directory.
I have everything configured in text files. Based on the above, this shouldn’t be an error, but rather a warning.
If this is an error, the application should create this file itself—at least an empty one.
It would be intressting what to do to get mapd persistence fixed in a filebased configuration…
Thanks ahead.
For the moment, I commented out “default” in Strategies section:
Strategies{
jedeMinute : "0 * * * * ?"
jedeStunde : "20 0 * * * ?"
//jedenTag : "40 0 0 * * ?"
// Geändert 01.02.2002. Bisher:
//default = everyChange
// Auf:
// Geändert (auskommentiert) 15.12.2025 wegen fehlendem Restore beim startup
//default = everyChange, restoreOnStartup
}
Items{
* : strategy = everyChange, restoreOnStartup
Is this correct and everything I have to do?
@helmar74 Yes, that’s all you have to do.
@kristofejro Both have already been fixed, more descriptive text and removed the warning message.
3 Likes
openHAB 5.1.0.M4: if I open rule/blockly script, I receive this error: ReferenceError: Input “tag” doesn’t exist on “oh_sendCloudNotification”. It is not possible use notification block now
Same issues as above, only different occurrence. I have already fixed this one, see openHAB 5.1 Milestone discussion - #179 by florian-h05.
1 Like
Yes, this is new in 5.1, and no it is not (currently) configurable – unless you can somehow modify log lines via configuration in log4j2.xml (I use log4j2.xml to completely filter out log lines for my rapidly changing-but-not-particularly-interesting items like from astro binding). I’m not sure how easy it would be to make it configurable in openHAB proper, either. That string is the result of simply calling toString() on the event object, which has many different implementations.
It was added to assist users in debugging their system and rules. While in your log snippet, it looks like all of them are item state changes due to events being sent from a binding, this is not always the case. AutoUpdateManager can change items, as can rules. You can even have an item bound to multiple channels, so knowing exactly which channel sent the update can be useful. It definitely would not be feasible to automatically only log the source if it’s from a binding update AND the item is only bound to one channel.
I just updated to M4. So far looks pretty solid.
Only thing i noticed - but this is not related to M4 and was there before already - is that marketplace bindings are gone after update and i need to reinstall them manually. I don’t know if this ever worked but would be nice if it does.
Also. Not a new issue but still exists and isreally annoying:
Openhab UI hangs until I close another Openhab browser tab - Setup, Configuration and Use / Runtime - openHAB Community
Enable http/2 for https & Set Keep-Alive header for http · Issue #4466 · openhab/openhab-core
Looks like there is not really a workaround right now? Currently i’m always working with 3 Browsers to do configuration. Edge, Chrome and Firefox with only one tab open in each.
Use HTTPS from port 8443, or put openHAB behind a reverse proxy with HTTP/2 enabled for HTTPS.
For plain HTTP, there is no solution yet.
This is somewhat deliberate and operating as designed. The problem is there is no guarantee that marketplace bundles have been updated to work with the new version of OH. And it can be the case that when an incompatible binding is loaded openHAB itself will crash. So the add-ons get removed during clearing the cache but you need to make a deliberate action to reinstall the marketplace add-ons.
@florian-h05 You are a hero! 
Installed latest snapshot, clicked around in MainUI and it never happened again! THANKS!
1 Like
Don’t the marketplace bundles have version constraints? How about we only drop the bundles when version constraints are no longer met by the new openhab version, and keep them otherwise?