I don’t know for how long it ran stable before the fix, so please update when either it fails, or when it has significantly passed the previous amount of stability. 
EDIT: Sorry, I misread. You installed from the UI? Then you would get the official 4.0.1 version of the binding which is known to cause problems. If you then also copied the .kar file into your addons directory, you would be running two instances. I may have misunderstod…
@laursen:
Till now everything looks good. But what have I done? Does this helps?
openhab> bundle:list -s | grep binding
...
287 x Active x 80 x 0 x wrap_file__var_lib_openhab_tmp_kar_org.openhab.binding.enocean-4.1.0-SNAPSHOT_org_lastnpe_eea_eea-all_2.2.1_eea-all-2.2.1.jar
288 x Active x 80 x 4.1.0.202307291812 x org.openhab.binding.enocean
openhab>
Or is there another way to check the current version?
It looks correct, if you had been running the official version from the distribution, the version number would have been 4.0.1, not 4.1.0. Thanks for confirming!
Still don’t have that much time, I gave the .kar a one time chance, but no success. OH4 does start up with a book of Java exceptions and afterwards no enocean bridge or devices available.
Best result for me still your latest 4.1.0–SNAPSHOT .jar, with sideloaded “serial” binding. Maybe not that elegant, but does run stable since days and I have really seen worse workarounds
===
Meanwhile I fixed also the content of “/etc/apt/sources.list.d/openhab.list” and imported key using depricated apt-key … something is fishy with the automated toolset in openhabian(-config), as it does erdicate the openhab repository from above apt .list automated …
Thanks, that’s fine, the objective was to fix the bug, not to produce a well-functioning .kar. 
The pull request is merged and I hope @Lolodomo will include it in 4.0.2. 
Big thanks @All who helped here.
I updated to OH4.0.1 a couple of hours ago and the EnOcean binding (4.0.1) works fine so far.
Just a heads up: There are still some quite serious bugs in the 4.0.1 version of the binding. The fixes will be included with 4.0.2, but until then you can find JAR/KAR files in this thread.
Off-topic, but could use some help @laursen what is the proper command for creating a kar with all dependencies. Build on snapshot, runs on stable.
Need it for some other binding fix testing.
Thanks for the heads up.
I switched to org.openhab.binding.enocean-4.1.0-SNAPSHOT.jar - Google Drive now by
(as described here openHAB 4 migration FAQ 
)
After a restart with a cleaned cache (i did not try without) there was just one warning right at the beginning …
2023-08-13 13:13:34.752 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.enocean-4.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.enocean [236]
Unresolved requirement: Import-Package: org.openhab.core.config.discovery.usbserial
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) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) ~[?:?]
… but everthing came up fine afterwards and is running now flawlessly.
Thanks again for the support 
That warning is a matter of sequence, same here. The local jar Binding is loaded very first, before all other, so without having the dependencies in place on startup … will get resolved when that code level will be part of OH packages and no jar file is needed anymore.
Ok, so, apt found openhab 4.0.2 update in openhabian repository and enocean binding does run flawless again. Thanks to everybodies contribution, I appreciate … 
Do not forget to revert any sideloaded binding workaround and removing .jar out of addons folder, before next OH start after updating the packages.
===
Little offtopic, one thing is still there since quite a while, means already with OH3. openhab service does startup automated after reboot flawless, and also by using
systemctl start openhab.service
But then service does restart again directly by itself, no error or warning visible in logs at any point. Doesn’t harm or is causing issues, just extends startup time … but, I would expect one start loop might be enough?
Unfortunately there are some more bugs in this version.
The temperature and humidity reading is incorrect. The problem was fixed in the latest openocean version which I used with OH3.4.4.
Now with 4.0.2 I needed to use the official binding. It looks like the changes @fruggy83 made in the openocean version are not merged into the binding.
Maybe someone can take a look at this and merge the latest openocean version (already with several bug fixes) into the official enoceanbinding?
Please see here what happened after the upgrade to the enoceanbinding 4.0.2:
Unrelated to this thread, but I see you created a new one:
Yes, first I posted here.
Then I realized open a new thread and issue would be much smarter.
Sorry.
Hello Dirk,
Would you be so kind as to reshare you Openocean 4.0.0?
Thanks!
Hi algol,
because the latest fixes of openocean were merged into 4.1, I am not using it anymore.
I use the offical openhab enocean binding which is working absolutely fine for me.
I am at openHAB 4.1.1 - Release Build without any problems regarding enocean. (Still missing some devices but they are not available in openocean either)
Please see here:
OK thanks, I’ll try and work it out with the official binding. It is unfortunately giving me trouble…
