I went back and tested blockly in the M3 version and was able to reproduce the issues that were reported. The upgrade to v11 does seem to address those issues for me (I tried in both firefox and chrome on macos).
I have no clue how to use Blockly, but I gave it a try as well, and as far as I could tell, drag and drop, snapping etc. all worked fine with the blockly-v11 branch, while with main it’s completely crazy and snaps when things are far apart and not when you want them to, won’t stop “dragging” when you release etc.
So, from my very inexperienced POV, it seems to work.
I downloaded the jar file and put it in my addons folder, restarted OH, and force refreshed the browser page and I’m not seeing any difference. Given the other reports I have to assume I’m doing something wrong.
Since I’ve never properly understood how Karaf decides which bundle to use if there are multiple of the same available (when you drop it in the addons folder, the web UI is provided “twice”), I can’t really speak to what needs to be done to make this work.
But, what I did is quite easy (if you’re somewhat familiar with Git), I cloned/added as remote: GitHub - jsjames/openhab-webui: Web UIs of openHAB
I then checked out the blockly-v11 branch, did a npm install (I think, because it complained about some dependency missing) and then npm start from the openhab-webui/bundles/org.openhab.ui/web folder. By pointing the browser to port 8081 on the computer running the dev server, you have this up and running in a couple of minutes, without interfering with your actual OH installation at all.
It’s a shame that this involves some command-lining, which I assume excludes a lot of people; it’s a really quick and easy way to test changes to the web UI.
2 Likes
@rlkoshak - you have to bundle:stop the ‘openHAB UI :: Bundles :: Main UI’ and then bundle:start the new one that shows up in the bundle:list.
3 Likes
That did it. @florian-h05 I can also confirm that the weirdness with Blockly is no longer there with v11.
The behavior is so extreme I would recommend to whom ever makes these decisions to not release 5.1 until that Blockly PR gets merged. Blockly is unusable otherwise.
I have already reviewed the changes and am currently testing if there are any regressions. This PR will get merged before the next milestone.
UPDATE: I have just merged the Blockly upgrade PR.
5 Likes
Hello forum.
I discovered a new behaviour in the Javascript logging. Saw changes 19702 in M3, maybe related.
Before M3, I could directly use ‘console.info("Hello”)’ for information and/or debugging. Now the scripts still work (hopefully !), but nothing gets logged, not even an error message.
It can be recovered by adding “console.loggerName = ‘org.openhab.custom’ ” in the code, but this would imply a great deal of efforts to modify all the scripts.
It sounds like your logging configuration has disabled the log for org.openhab.automation.jsscripting.rule or is otherwise corrupted.
1 Like
Thank you for the clue.
I looked at /srv/openhab-userdata/etc/log4j2.xml . But no obvious problem.
And nothing about org.openhab.automation.jsscripting.rule .
So where should I look,and for what ?
How to restore a valid default configuration ?
Ok, it is in the ‘Configure JavaScript Scripting‘ Add-On settings in the GUI.
The org.openhab.automation.jsscripting was set to Warning and only console.warn worked.
Setting it to default sets it to Info and then console.info and console.warn work. Not very clear behaviour for me. And not very clear why it worked before.
Thank you again anyway.
It’s not so mysterious, but it might not be equally obvious how this works for everybody. If you’re used to a logging system, and in particular if you’re used to a Java logging system. These are the levels:
ERRORWARNINFODEBUGTRACE
In addition, you can potentially select OFF (no logging whatsoever), ALL (everything) or DEFAULT (which is defined as INFO in OH).
Log levels always include those above them, so if you set a logger to DEBUG, all DEBUG, INFO, WARN and ERROR messages will be shown. If you set it to WARN, only WARN and ERROR will be shown. ALL and TRACE are effectively the same. So, when you configure a logger with WARN, INFO messages will be suppressed.
Thank you. Great info.
Maybe a line of decription or a link to the information in the Add-Ons setting pages would be appreciated.
I naively thought the Logging level was increasingly verbose.
So, Info would be the minimum and my intuitive order was:
INFO
WARNING
ERROR
DEBUG
TRACE
So in my mind INFO=INFO, ERROR=ERROR+WARNING+INFO. Aso …
When all has failed, RTFM !
But with OH, Javascript, Add-Ons, Network, Zigbee, now Matter, MQTT,aso …, that makes a lot to read !
1 Like
There is an error in main ui if you go on an item and click analyze and than click any duration and than click on the arrow right. you can predict the future see screenshot
It’s 15:57 but I see what will the state of the item 19:57…
This was merged 4 hours ago:
I don’t know exactly what it does, but there’s a good chance that this behavior has changed.
That’s not an error. You can use this to forecast values.
However, in that case it should be displayed in a different color and be more intelligent, since I am always out of my home at 7 p.m.
I updated my Testsystem from OH 5.0.3 to OH 5.1.0 M4.
all of my persisted data are now “null” in BasicUI
both persistence bundles are active:
329 │ Active │ 80 │ 5.1.0.M4 │ openHAB Add-ons :: Bundles :: Persistence Service :: MapDB
330 │ Active │ 80 │ 5.1.0.M4 │ openHAB Add-ons :: Bundles :: Persistence Service :: RRD4j
historical data in diagrams are working
it look’s like the state isn’t restored on startup correctly.
here’s the config of mapdb.persist:
Strategies{
jedeMinute : “0 * * * * ?”
jedeStunde : “20 0 * * * ?”
//jedenTag : “40 0 0 * * ?”
// Geändert 01.02.2002. Bisher:
//default = everyChange
// Auf:
default = everyChange, restoreOnStartup
}
Items{
* : strategy = everyChange, restoreOnStartup
// Für Folgende Items existieren Charts, daher werden diese JedeMinute persistiert
// Zisterne und Hauswasserwerk
i_mqtt_WemosMiniAkku_1_Temperatur,i_Zisterne_FuellstandLiter,i_Zisterne_FuellstandCm,i_Hauswasswerk_Status_Numerisch,i_Hauswasswerk_Status,i_Zisterne_FuellstandProzent,i_Zisterne_Volt,i_Zisterne_BatIcon : strategy = jedeMinute
//Aussenwerte
Aussentemperatur,LuftfeuchtigkeitAussen,LuftdruckAussen,HelligkeitAussen : strategy = jedeMinute
// Drucker pr001
i_Drucker_pr001_Tinte_Schwarz, i_Drucker_pr001_Tinte_Cyan,i_Drucker_pr001_Tinte_HellCyan,i_Drucker_pr001_Tinte_Magenta,i_Drucker_pr001_Tinte_HellMagenta,i_Drucker_pr001_Tinte_Gelb : strategy = jedeMinute
// Elektrogeräte Waschraum
g_WaschraumStromWatt,i_Avm200Watt_2,i_Avm200Watt_3,i_Avm200Temp_2 : strategy = jedeMinute
// Entkalkungsanlage
gEntkalkungsanlage,i_Entkalkungsanlage_FuellstandCm : strategy = jedeMinute
//Brandmelder
//Brandmelder Gruppen
g_Brandmelder_Feuer,g_Brandmelder_Battery,g_Brandmelder_Test,g_Brandmelder_Mute : strategy = jedeStunde, everyChange, restoreOnStartup
// Einzelne Items jeder Brandmeldergruppe. Gruppe mit * am Schluss
g_Brandmelder_Feuer* : strategy = jedeStunde, everyChange, restoreOnStartup
g_Brandmelder_Battery* : strategy = jedeStunde, everyChange, restoreOnStartup
g_Brandmelder_Test* : strategy = jedeStunde, everyChange, restoreOnStartup
g_Brandmelder_Mute* : strategy = jedeStunde, everyChange, restoreOnStartup
//Sirenengruppen
g_Sirenen : strategy = jedeStunde, everyChange, restoreOnStartup
g_Sirenen* : strategy = jedeStunde, everyChange, restoreOnStartup
//Hilfsitem
i_Feueralarm_aktiv : strategy = jedeStunde, everyChange, restoreOnStartup
//Brandmelder
//i_mqtt_Brandmelder_1_Fire,i_mqtt_Brandmelder_1_Battery,i_mqtt_Brandmelder_1_Test,i_mqtt_Brandmelder_1_Mute : strategy = jedeMinute
// ODL
i_Odl_Messwert : strategy = jedeMinute
// INET Speed
g_updownstream,INET_DOWN,INET_UP,INET_PING : strategy = jedeMinute
g_inetspeed, i_speedtest_resultdown, i_speedtest_resultup, i_speedtest_latency : strategy = jedeMinute
// Ölpreis
i_Aktueller_Oelpreis : strategy = jedeMinute
// HND
i_HndRegen1hNumber,i_HndRegen6hNumber,i_HndRegen24hNumber : strategy = jedeMinute
// Garagen
i_Autostatus_links,i_Autostatus_rechts : strategy = jedeMinute
//i_Drucker*, g_WaschraumStromWatt*, i_Avm200Watt_2*, i_Avm200Watt_3*, i_Avm200Temp_2* ,gEntkalkungsanlage*, i_Entkalkungsanlage*, i_Zisterne*, i_HndRegen*, i_Hauswasswerk*, Aussen*, Luft*, Hell*, i_Odl*, g_updownstream*, INET*, i_Aktueller_Oelpreis* : strategy = jedeMinute
// BlitzwoIF1
i_mqtt_BlitzwoIFSHP2_1_Energie_Total,i_mqtt_BlitzwoIFSHP2_1_Energie_Heute,i_mqtt_BlitzwoIFSHP2_1_Energie_Gestern,i_mqtt_BlitzwoIFSHP2_1_Energie_Aktuell,i_mqtt_BlitzwoIFSHP2_1_Energie_Volt,i_mqtt_BlitzwoIFSHP2_1_Energie_Strom,i_mqtt_BlitzwoIFSHP2_1_Energie_Leistungsfaktor : strategy = jedeMinute
}
With openhab 5.0.3 restore of item state was working well on startup.
Also tried clean cache, which doesn’t change anything.
UPDATE: this error is shown in openhab.log:
2025-12-15 08:13:14.121 [WARN ] [el.core.internal.ModelRepositoryImpl] - DSL model ‘mapdb.persist’ has errors, therefore ignoring it: [8,2]: no viable alternative at input ‘default’
Did something change here or is this a bug?
it was a error in my configuration.
commented out:
//default = everyChange, restoreOnStartup
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
}
now item states were restored on startup.
Sorry!