I can see this issue too.
I’ve submitted a fix:
3 Likes
Oohh… question: Do you enable “Retain” in the “Settings” for each device? (You can set it globally, but I don’t see it in the UI. It’s just retain: true underneath the device_options: top level key in configuration.yaml. I also have to set it individually in the config file for each group.) openHAB has always been a bit finicky with devices that don’t send their discovery messages as retained. It’s supposed to cache the discovery JSON on the channel, but newly adding the device from the inbox can’t do that.
I don’t fully understand why it faild so completely the first time. I think it’s a matter of when OH starts up it runs into trouble with the dependencies and fails. If you copy the jar file back after OH starts it’s not as fatal of a situation. 
Are the changes in this snapshot jar file not merged in the 4.3 release? Why are you using this jar in the first place? Maybe you don’t need it any longer.
Good question… How can I verify this? I’ve got .jar files for the Shelly, ESPHome and Unifi Protect bindings. I didn’t notice them being mentioned in the release notes?
I’m not sure what you mean. I don’t have a file configuration.yaml
I have default settings for my mqtt bridge: LWT and birth messages are retained by default but normal messages are not retained by default through thing definition for the bridge: retainMessages=false
Did you get the jar files from the marketpalce or download them from github. They have “snapshot” in the name. That usually means that the changes have been merged and on the next milestone release and full release includes all those changes.
Only if these jar files were created outside the usual build and distributed outside the normal build are the changes not merged. Otherwise the changes have been merged and remain merged from the date they are included in the snapshots forward.
In fact, by not using the offical binding you are missing out on all the new features and bug fixes made after you downloaded the jar file.
The general rule of thumb is if you download an official binding’s jar file, you only use it until the next release on the repo you are using.
- snapshot repo: there really is no reason to download the jar file at all unless you are helping test a change before it gets merged. All the changes merged into OH from the day before are included.
- milestone repo (aka testing repo): All the changes since the previous milestone are included
- release: all the changes since the last release
There are all sorts of details not presented here so I can’t give a difnitive answer whether you need these jars or not. I suspect the answer is no. Installing an add-on using the jar file for an official add-on is a temporary thing. As soon as there is a release on whatever release stream you are using, you should remove the jar and and install the official binding.
Just upgraded from 4.2.3 to 4.3.1.
After the upgrade the WebUi wasn’t accessible at all. I have a habit of having the frontail logviewer open during updates (yeah, yeah, I know it’s deprecated) and at first things seemed normal until everything just stopped and i got a few
[WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.100.13:8080/[...]
messages.
Restarted the systemd service manually and stuff now seems to work fine. I saved the frontail output if anybody wants to have a look at it. Just say where I should put it. It’s not that small for a logfile.
2 Likes
Exactly, the health issues button is only shown if there are health issues.
1 Like
Just upgraded from 4.2.3 to 4.3.1 and got problems with EnOcean binding.
Just for my measurement switches I got the following error message. On the other side mechanical handles works fine.
Anyone some idea?
2025-01-03 10:58:17.174 [TRACE] [ernal.transceiver.EnOceanTransceiver] - Received Sync Byte
2025-01-03 10:58:17.176 [TRACE] [ernal.transceiver.EnOceanTransceiver] - >> Received header, data length 10 optional length 7 packet type 1
2025-01-03 10:58:17.180 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - RADIO_ERP1 with RORG _4BS for xxxxxxxx payload A50000510Cxxxxxxxx0001FFFFFFFF5200 received
2025-01-03 10:58:17.181 [ERROR] [ernal.transceiver.EnOceanTransceiver] - Exception in informListeners
java.lang.NullPointerException: Cannot invoke “org.openhab.binding.enocean.internal.eep.EEPType.getEEPClass()” because “eepType” is null
at org.openhab.binding.enocean.internal.eep.EEPFactory.buildEEP(EEPFactory.java:63) ~[bundleFile:?]
at org.openhab.binding.enocean.internal.handler.EnOceanBaseSensorHandler.packetReceived(EnOceanBaseSensorHandler.java:159) ~[bundleFile:?]
at org.openhab.binding.enocean.internal.transceiver.EnOceanTransceiver.lambda$0(EnOceanTransceiver.java:372) ~[bundleFile:?]
at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]
at org.openhab.binding.enocean.internal.transceiver.EnOceanTransceiver.informListeners(EnOceanTransceiver.java:372) [bundleFile:?]
at org.openhab.binding.enocean.internal.transceiver.EnOceanESP3Transceiver.processMessage(EnOceanESP3Transceiver.java:149) [bundleFile:?]
at org.openhab.binding.enocean.internal.transceiver.EnOceanTransceiver.receivePackets(EnOceanTransceiver.java:305) [bundleFile:?]
at org.openhab.binding.enocean.internal.transceiver.EnOceanTransceiver$1.run(EnOceanTransceiver.java:230) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:840) [?:?]
This could look like a possible regression of:
Since a NullPointerException is thrown, it’s safe to categorize as a bug, so perhaps you can create an issue for this?
Updated to 4.3.1 and it broke all my zigbee2mqtt things.
How do I fix it now without waiting for 4.3.2 !?
@Gargam3L0 Try dropping this into your addons folder, and disable the built in bundle of the same name. Note you need to rename the file and remove the .txt extension first.
org.openhab.binding.mqtt.homeassistant-4.3.2-SNAPSHOT.jar.txt (221.9 KB)
I can’t seem to make it work. Probably something I am doing wrong.
- I copied and renamed the jar file into the addons folder.
- Removed built in MQTT binding.
- The restart log throws a waning and none of my MQTT things are working now.
2025-01-03 16:54:31.467 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.mqtt.homeassistant-4.3.2-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.mqtt.homeassistant [332]
Unresolved requirement: Import-Package: org.openhab.binding.mqtt.discovery
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:445) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.7.4]
Don’t remove the built in MQTT binding. Just disable the built in mqtt.homeassistant bundle. You can do this in karaf. Sorry I’m typing this on my phone can’t give you an example.
looks like this worked:
bundle:list
then I see:
350 │ Active │ 80 │ 4.3.1 │ openHAB Add-ons :: Bundles :: MQTT Broker Binding
351 │ Active │ 81 │ 4.3.1 │ openHAB Add-ons :: Bundles :: MQTT EspMilightHub
352 │ Active │ 81 │ 4.3.1 │ openHAB Add-ons :: Bundles :: MQTT FPP
353 │ Active │ 81 │ 4.3.1 │ openHAB Add-ons :: Bundles :: MQTT Things and Channels
354 │ Active │ 82 │ 4.3.1 │ openHAB Add-ons :: Bundles :: MQTT HomeAssistant Convention
355 │ Active │ 82 │ 4.3.1 │ openHAB Add-ons :: Bundles :: MQTT Homie Convention
356 │ Active │ 82 │ 4.3.1 │ openHAB Add-ons :: Bundles :: MQTT Ruuvi Gateway
357 │ Active │ 80 │ 4.3.1 │ openHAB Core :: Bundles :: MQTT Transport
358 │ Active │ 80 │ 1.0.4 │ reactive-streams-jvm
359 │ Active │ 80 │ 4.3.2.202501031301 │ openHAB Add-ons :: Bundles :: MQTT HomeAssistant Convention
and then:
bundle:stop 354
Then restarted OH service.
Issue created:
1 Like
Anyone by any chance having problems with HomematicIP-items not updating anymore, even though they can still be controlled via OH? Details described here.
I had the problem around two years ago (and got it fixed somehow), but now they started to come up again after my update to 4.3.0 without having changed anything else, so I guess it’s related?
Hi all…
I fixed this issue with a new widget design.
I mainly used formatting styles like --f7-list-font-size: 16px, --f7-list-item-min-height: 40px and --f7-list-item-padding-vertical: 0px to make it fit my limited space. During development I was thinking about a new tab-design for my wall-mounted tablet.
Jan
For those who are interested in the widget code:
uid: Raumtemperatur
tags: []
props:
parameters: []
parameterGroups: []
timestamp: Jan 2, 2025, 8:50:34 PM
component: f7-card
config:
title: Raumtemperatur
slots:
default:
- component: f7-list
config:
style:
--f7-list-font-size: 16px
--f7-list-item-min-height: 40px
slots:
default:
- component: f7-list-item
config:
style:
--f7-list-item-padding-vertical: 0px
background: '=(Number.parseFloat(items.ShellyHTSauna_Luftfeuchtigkeit.state) >
60 ) ? "#FF8585" : ""'
box-shadow: none
margin-left: 0
margin-right: 0
stylesheet: |
.item-inner {
display: inline-block;
}
slots:
inner-start:
- component: f7-row
config:
style:
align-items: center
height: 100%
justify-content: space-between
slots:
default:
- component: f7-col
config:
style:
text-align: left
width: 25
slots:
default:
- component: oh-icon
config:
icon: bedroom
style:
vertical-align: middle
width: 30
- component: f7-col
config:
style:
text-align: right
vertical-align: middle
width: 40
slots:
default:
- component: f7-row
config:
style:
align-items: center
justify-content: flex-start
slots:
default:
- component: oh-icon
config:
icon: temperature
style:
vertical-align: middle
width: 16
- component: Label
config:
style:
margin-left: 5px
text: =items.ShellyHTSauna_Temperatur.state
- component: f7-col
config:
style:
text-align: right
vertical-align: middle
width: 35
slots:
default:
- component: f7-row
config:
style:
align-items: center
justify-content: flex-end
slots:
default:
- component: oh-icon
config:
icon: humidity
style:
vertical-align: middle
width: 16
- component: Label
config:
style:
margin-left: 5px
text: =Math.round(Number.parseFloat(items.ShellyHTSauna_Luftfeuchtigkeit.state))+
" %"```Hi all,
I found some time to identify the problem why the popups on my iPad (iOS) aren’t fitting the Popup-Window. I assume there is a little typo / bug in the css. (Thank you @florian-h05 for this hint).
Development tools have shown the difference which you can see on the pictures attached.
The height of the --oh-chart-page is calculated:
--oh-chart-page-height: calc(100% - var(--f7-safe-area-top) - var(--f7-safe-area-bottom) - var(--f7-navbar-height))
On iOS it is calculated as:
--oh-chart-page-height: calc(100dvh - var(--f7-safe-area-top) - var(--f7-safe-area-bottom) - var(--f7-navbar-height))
The 100dvh instead of the 100% is causing the trouble. In the Development Tools I can change it to 100% which is overwritten once the page is reloaded (of course).
I tried using stylesheets on the Page directly like:
> ```
> config:
> stylesheet: >
> .device-ios .oh-chart-page-chart { --oh-chart-page-height: calc(100% -
> var(--f7-safe-area-top) - var(--f7-safe-area-bottom) -
> var(--f7-navbar-height)); }
> fixedType: grid
> hideNavbar: true
> hideSidebarIcon: true
> label: Tablet
> layoutType: fixed
> order: "1"
> scale: false
> screenHeight: 1700
> screenWidth: 2100
> showFullscreenIcon: false
> sidebar: true
> visibleTo:
> - role:administrator
> - role:user
> blocks: []
> masonry: []
> grid:
> - component: oh-grid-item
> config:
> h: 1
> w: 1
> x: 0
> y: 0```
But this is well-ignored.
Does anybody has an idea where this can be changed?
I added the .css from the development-tools if helpful. But they are dynamically generated, so no chance to change 
Thank you very much!
Jan
.oh-chart-page-chart {
overflow: hidden;
position: absolute !important;
top: calc(var(--f7-safe-area-top) + var(--f7-navbar-height));
width: 100%;
--oh-chart-page-height: calc(100% - var(--f7-safe-area-top) - var(--f7-safe-area-bottom) - var(--f7-navbar-height));
height:var(--oh-chart-page-height) !important
}
.oh-chart-page-chart.with-tabbar {
height:calc(var(--oh-chart-page-height) - var(--f7-tabbar-labels-height)) !important
}
.oh-chart-page-chart.with-toolbar {
height:calc(var(--oh-chart-page-height) - var(--f7-toolbar-height)) !important
}
.oh-chart-page-chart.sheet-opened {
height:calc(var(--oh-chart-page-height) - var(--f7-sheet-height)) !important
}
.device-ios .oh-chart-page-chart {
--oh-chart-page-height: calc(100dvh - var(--f7-safe-area-top) - var(--f7-safe-area-bottom) - var(--f7-navbar-height))
}
If I had noticed your messages earlier I would have been able to tell you … Charts: Apply iOS-related fixes only to iOS devices by florian-h05 · Pull Request #2717 · openhab/openhab-webui · GitHub
This is more or less a known limitation on iPad, and was introduced when I fixed the issue that charts weren’t rendering when opened initially on iOS devices.
To fix the limitation with popups, it is required to apply the 100% instead of 100dvh only inside of popups.