It shows the duration, not the time. I don´t know if there is a way to change this.
Aha! Okay thanks.
From what I can see it looks similar to what I experienced.
Maybe you can ask @florian-h05 to have a look.
since the update last night from 5.0.1 to 5.1.0, i don’t see any items anymore.. My items file is still in the same folder and hasn’t been changed.. Suggestions?
Thanks @Anpro and @florian-h05 - i added the stylesheet but it does not correct the behaviour
Check your logs, maybe an error is detected in your file when loaded ? In 5.1, I believe the only change for DSL .items files was a better check of valid item names.
After upgrading to 5.1 Release blockly is braking some of my rules.
it is this block
creating this code with 4.3.8 Release
(time.toZDT('2025-12-26')).plusMinutes(2);
the same block is creating this code with 5.1. Release
(time.toZDT('2025-12-26')).plusMinutes(2).plusNanos();
console.warn((zdtCompare((time.ZonedDateTime.now()), (time.toZDT(items.getItem('Lokale_Sonnendaten_CivilDusk_Start'))).plusMinutes(2).plusNanos(), 'before', 'minutes', 'dateandtime')));
creating this ERROR Code
Level
ERROR
Logger Class
org.openhab.core.automation.module.script.internal.handler.AbstractScriptModuleHandler
Message
Script execution of rule with UID 'Test2' failed: DateTimeException: Invalid value for NanoOfDay (valid values 0 - 86399999999999): NaN in @openhab-globals.js at line number 2 at column number 72736
As a workaround i usea second temporal unit with nanos
creating this code
console.warn((zdtCompare((time.ZonedDateTime.now()), (time.toZDT(items.getItem('Lokale_Sonnendaten_CivilDusk_Start'))).plusMinutes(2).plusNanos(((time.toZDT(items.getItem('Lokale_Sonnendaten_CivilDusk_Start'))).get(time.ChronoField.NANO_OF_SECOND) / 1000000 | 0) * 1000000 + (((time.toZDT(items.getItem('Lokale_Sonnendaten_CivilDusk_Start'))).get(time.ChronoField.NANO_OF_SECOND) / 1000) % 1000 | 0) * 1000 + 0), 'before', 'minutes', 'dateandtime')));
Hi @florian-h05 is that view from on a page or from the widget editor because it works in the widget editor
That’s from the overview page.
Hi @florian-h05 i checked and it works from the overview page but not on a fixed canvas layout page
Same here (different example)
Code:
component: oh-list-card
config:
footer: =
items.SZ_VJ_R_shellyplus2pm192168178113_Rollensteuerung_100offen_0geschlossen.state
+ " % / " +
items.SZ_VJ_R_shellyplus2pm192168178102_Rollensteuerung_100offen_0geschlossen.state
+ " % / " +
items.SZ_VJ_R_shellyplus2pm192168178112_Rollensteuerung_100offen_0geschlossen.state
+ " % / " +
items.SZ_VJ_R_shellyplus2pm192168178111_Rollensteuerung_100offen_0geschlossen.state
+ " %"
title: Schlafzimmer VJ
slots:
default:
- component: oh-list-item
config:
action: rule
actionRule: 59f35a0c32
badge: AUF
badgeColor: green
icon: Blinds-0
title: Öffnen
- component: oh-list-item
config:
action: rule
actionRule: 06b525a7d6
badge: ZU
badgeColor: red
icon: Blinds-100
title: Schließen
I can add more sample were the widgets don't look right on a layout page:
Additional example:
This is comes from: https://community.openhab.org/t/custom-rollershutter-widget-with-preset-configuration/116270?u=harald_pott with a slight modification.
Harald
Still not better here 
I have de-activated all the rules and scripts (Blockley) where I was using the MQTT-Library. Then I re-created the Docker Container.
Now in the OpenHab debug logs for MQTT I can see, that someone in OpenHab is still sending 10.000nds of MQTT messages (no rules active…). I am really wondering why the sytem is sending them at all - and why so many? Maybe a confusion with JS Library and MQTT-Blockly AddOn?
Normaly I have a few 1000 Messages, now you can see the OpenHab re-starts and tests, there are now 50.000 messages which is polluting the Zigbee Network…
Update: I just removed the MQTT-Library for Blockly and re-started → but nothing changed, someone is still sending all the messages.
Hi,
reading openHAB 5.1 Release blog post does raise questions regarding new Homekit Binding and Matter. Some weeks ago I got a new Nuki Door Lock device running using Matter back then, as the Nuki binding does not support the new locks.
In my case Homekit equals basically Matter, as my border routers are Apple TV devices. I like the idea to enable Homekit Binding parallel to the already since years running Home Kit AddOn. In that case I will get for sure my Nuki Lock back from the Apple TV(s) two times. One time by Matter, one time by Homekit …
So, thinking to the end, in case of Apple Home(kit) around with Thread / Matter capable Apple TVs, anyone should better drop Matter binding in favor for the new Homekit binding in OH.
What happens btw. with all the OH devices provided from OH by AddOn towards Home(kit)? Are they also coming back by Homekit binding?
I also use the MQTT library for Blockly without any issues.
But the phenomenon i had with postCommand:true, which i initially described as a kind of flickering, was nothing else than a loop, caused by the wrong MQTT setting, which can generate a mass of MQTT messages within a short time. My feeling is, that you might also have such a loop as root cause for your problem. The standard setup for MQTT channels should be postCommand:false.
Yes - that was the problem! Thanks so much…
I understood the first post wrong, so I verified earlier that in all my MQTT-commands the ‘postCommand:true’ is configured. Now I set all of then (even the ones that are posting MQTT messages) to false. And with this the message-flooding disappeared.
In general I am now wondering what this setting is good for? Because even if it is set to ‘false’ the MQTT-update is still sent…
Again - thanks so much for the tip, I assumed something deep inside with a JS-setting / bug or similar… I would have never found this one…
I must admit that I really don’t know what the setting is or where it’s used (I don’t use MQTT), but if it’s a new setting that can potentially surprise many users, would it be a good idea to set it to false by default?
@BrettLHolmes @Harald_Pott:
Please try adding the following stylesheet config property to the canvas layout page config:
stylesheet: |
.oh-canvas-item-content {
height: unset;
width: unset;
}
Report if that fixes the issue, please also check for regressions introduced by this change.