OK, that’s a newly introduced regression from this PR:
Edit:
Here’s the issue
I just upgraded to the latest SNAPSHOT (Build #3386) and since then my oh-cell have changed layout.
The f7-chips as f7-list-item have moved to the same line as the “Title”
I have two similasr setups and both affected.
I suspect that it has something to do with:
Code for the two cells is as follows?
Cell 1.txt (2.1 KB)
Cell 2.txt (3.5 KB)
Any suggestions please?
EDIT: This is what they used to look like
Fix PR is now open, see Fix action `options` regression by florian-h05 · Pull Request #1813 · openhab/openhab-webui · GitHub.
1 Like
@JustinG sorry to ping you. But i think you may know what the iisue could be in this?
Would you mind having a look?
I’m still on the 4.0 milestone, so I haven’t encountered this yet. The PR you’ve found is almost certainly the proximal cause. From the screen shots, it just looks like your items are now in a container with slightly different settings than before. Use the dev tools to check out the structure of the cell and see if there are flex options or display options that need to be adjusted to get your previous arrangement back.
If you still can’t get the format you want back, open up a new thread and the issue can get worked out there.
You should also probably file an issue citing that PR, the discussion there indicates that some downstream issues are expected from this, so you should make the devs aware.
I’ve just checked, the problem that @Mark_VG encounters is no regression from that PR, but a consequence of the fix.
Before the PR, the slot name was ignored and the f7-chips were placed “anywhere”. PR Pass slot names down in generic-widget-component by michalsrb · Pull Request #1798 · openhab/openhab-webui · GitHub fixed that, the f7-chips are now placed inside the title slot of f7-list-item, which is correct. To have them appear under the Lights via List title, they should go into the subtitile slot (see List Item Vue Component | Framework7 Vue Documentation for docs):
YAML code
component: oh-cell
config:
on: true
title: Lights via List
slots:
default:
- component: f7-list
config:
style:
--f7-list-index-font-size: 1px
--f7-list-index-item-height: 1px
--f7-navbar-bg-color: white
--f7-navbar-border-color: white
--f7-navbar-font-size: 0px
--f7-navbar-height: 0px
--f7-navbar-link-color: black
--f7-navbar-text-color: black
z-index: 0
virtualList: true
slots:
default:
- component: oh-list-item
config:
action: popup
actionModal: widget:ak_universal_switch_widget_v1-MVG
actionModalConfig:
closePopup: true
colorItem: LoungeRoom_Color
dimmerItem: LoungeRoom_Brightness
header1: Lounge Lights
sceneSelect: LoungeRoom_Scene
switchItem: LoungeRoom_Switch
tempItem: LoungeRoom_ColorTemperature
icon: f7:lightbulb
iconColor: '=(items.LoungeRoom_Switch.state === "ON") ? "null" : "gray"'
iconUsesState: true
title: Lounge Lights
- component: oh-list-item
config:
action: popup
actionModal: widget:ak_universal_switch_widget_v1-MVG
actionModalConfig:
closePopup: true
colorItem: RileyRoom_Color
dimmerItem: RileyRoom_Brightness
header1: Riley Lights
sceneSelect: RileyRoom_Scene
switchItem: RileyRoom_Switch
tempItem: RileyRoom_ColorTemperature
icon: f7:lightbulb
iconColor: '=(items.RileyRoom_Switch.state === "ON") ? "null" : "gray"'
iconUsesState: true
title: Riley Lights
- component: oh-list-item
config:
action: popup
actionModal: widget:ak_universal_switch_widget_v1-MVG
actionModalConfig:
closePopup: true
colorItem: EthanRoom_Color
dimmerItem: EthanRoom_Brightness
header1: Ethan Lights
sceneSelect: EthanRoom_Scene
switchItem: EthanRoom_Switch
tempItem: EthanRoom_ColorTemperature
icon: f7:lightbulb
iconColor: '=(items.EthanRoom_Switch.state === "ON") ? "null" : "gray"'
iconUsesState: true
title: Ethan Lights
header:
- component: f7-list
config:
mediaList: true
slots:
default:
- component: f7-list-item
config:
title: Lights via List
slots:
subtitle:
- component: f7-chip
config:
icon-color: '=(items.LoungeRoom_Switch.state === "ON") ? "null" : "gray"'
iconF7: lightbulb
text: Lounge
- component: f7-chip
config:
icon-color: '=(items.RileyRoom_Switch.state === "ON") ? "null" : "gray"'
iconF7: lightbulb
text: Riley
- component: f7-chip
config:
icon-color: '=(items.EthanRoom_Switch.state === "ON") ? "null" : "gray"'
iconF7: lightbulb
text: Ethan
Works again now:
2 Likes
Loaded snapshot #3392 to fix memory leak. All good there 
However, can not seem to edit the overview page (settings → pages) Trying to force the issue by adding /layout/overview yields a blank screen. This morning I get no error messages, but last night the top lines of the error messages (while trying to get to the edit) are;
2023-04-01 19:53:33.510 [WARN ] [ache.cxf.phase.PhaseInterceptorChain] - Interceptor for {http://internal.karaf.core.openhab.org/}LoggerResource has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not send Message.
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:67) ~[bundleFile:3.4.5]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[bundleFile:3.4.5]
at org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:90) ~[bundleFile:3.4.5]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[bundleFile:3.4.5]
and
2023-04-01 19:53:33.530 [WARN ] [ache.cxf.phase.PhaseInterceptorChain] - Interceptor for {http://internal.karaf.core.openhab.org/}LoggerResource has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: XML_WRITE_EXC
at org.apache.cxf.jaxrs.interceptor.JAXRSDefaultFaultOutInterceptor.handleMessage(JAXRSDefaultFaultOutInterceptor.java:106) ~[bundleFile:3.4.5]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) ~[bundleFile:3.4.5]
at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:112) ~[bundleFile:3.4.5]
at org.apache.cxf.phase.PhaseInterceptorChain.wrapExceptionAsFault(PhaseInterceptorChain.java:374) ~[bundleFile:3.4.5]
Two other minor snapshot observations
- I have a custom Zwave binding in the addons folder. Normally this is loaded late (> 200) now it is loaded first? The problem I had was that after the clean-cache from loading the snapshot I normally get a message about openhab-transport-serial, but with the early loading the state went to RESOLVED and no error message in openhab log. After installing the “transport” feature, I needed to do a bundle:restart. Normally (with a later loading queue) it starts up on its own. (hope this makes sense)
- I get this these new messages on startup. Appears to be no lasting effect since the binding works.
2023-04-01 18:15:10.351 [WARN ] [core.thing.internal.ThingManagerImpl] - A thing handler factory claims to support 'systeminfo:computer-openhab' for thing 'systeminfo:computer:openhab' for more than 120s, but the thing type can't be found in the registry. This should be fixed in the binding.
2023-04-01 18:15:10.428 [WARN ] [core.thing.internal.ThingManagerImpl] - Could not normalize configuration for 'systeminfo:computer:openhab' because the thing type was not found in registry.
-
If you drop the binding after the initial startup, it get’s a high number (and is loaded late), if you have it in the folder when the cache is clean, then it’ll get loaded very early. On my systems this has always been the case.
-
This is only a warning. It’ll be fixed when Add an AbstractStorageBasedTypeProvider by J-N-K · Pull Request #3407 · openhab/openhab-core · GitHub is merged and the bindings are changed to use it.
1 Like
I see this issue of not being able to edit the overview page too. Build 3394. Has it been solved or is anyone working on it?
This one is probably minor. I’m on #3395 and I noticed that the new ItemStateUpdateEvent is being logged to events.log. I would expect it to not be logged since the ItemStateEvent isn’t logged by default either.
Adding:
<Logger level="ERROR" name="openhab.event.ItemStateUpdatedEvent"/>
<Logger level="ERROR" name="openhab.event.GroupStateUpdatedEvent"/>
to log4j2.xml suppresses this event. I’ll see if I can find which repo the “real” log4j2.xml file is and submit a PR. But for those who need a work around now, there you have it.
1 Like
Thanks, I’m still playing catchup I guess.
I will try to review this ASAP, I think it will be tomorrow.
When doing an upgrade are changes to log4j2.xml merged onto existing log4j2.xml or is the current file overwritten or preserved?
There won’t be a merge but I’m not positive if it’s overwritten or if you are given the option to overwrite it for apt/yum. In Docker I believe it just gets overwritten (though a complete backup of everything is made first). Manual installs are up to you to preserve your changes.
I’m having an issue with the newer snapshots relating to changes to files not being detected. The only way I can currently get OH to detect the change is by deleting/moving the file out and back in. This is happening across things/items/rules as well as addon jars (which I have to manually uninstall/install in karaf). jars seem to be worse than the config files, deleting/moving/copying in new versions don’t trigger the update like normal. I’m running OH inside of a docker on my Synology and updated to the newest snapshot today (3395). This isn’t an issue on my non-docker install that I run on my ubuntu dev box so I’m concerned that it’s something specific with how we watch files and what docker does and does not report to the container. To note, this is obviously all files that are located inside of a mapped mount point so that it survives reset.
Our own watch service is not used for jars, so it must be something more general. Maybe Java version or something like that.
This is all pulled in from the official docker image so I’d assume the java version is what it needs to be. My non-docker version seems fine. My concern is that something in the way a native OS versus a container report/monitor for file changes is just slightly different enough that we’re not catching it.
EDIT: I did some more tests. I’ll change my original statement to be “It won’t track files that have been created since OH started”. I went back and updated a few old files and it updated them immediately.
What type of files? If it’s only configuration, then it’s probably a bug if it’s also .jar, it’s docker related.