Unless someone will be able to quickly spot the bug, I tend to agree with @hmerk that first step unfortunately could be to revert the commit from that PR. It should be easy since only one PR was merged after that with only three lines changed.
It will be a little harder to reapply all that refactoring though since it contains more than 1,000 lines of changed code. However, that’s probably second priority, at least short-term. It seems that it was untested, at least there is no documentation or confirmation of successful tests.
Let’s give @dalgwen a chance first to pinpoint the issue - and thanks for stepping in!
OK, it’s definitely the commit with the null annotation refactoring.
Before trying to find the issue, I have reverted it on a branch made from the 4.0.0 tag, and made a JAR release.
Testers other than me, you are welcome to confirm if it works for you (do not forget to uninstall the binding from you runtime environment before installing the JAR in you addons folder).
EDIT : testers, see below for another jar to test
Now, as you said, it is not an easy task . I will try to pinpoint it but cannot give a date.
No proof, just experience out of decades in IT business. One change here or there leads to a problem on something what has been working flawless before. And all over sudden the before perfectly working part is then often the bad guy …
@hmerk You didn’t got the point, in majority of cases its not just one root cause …
But I’m happy it got most probably identified here, identifiying one specific pull request.
Sure, I can understand that, but on the other side any individual need to have namable time for testing.
I don’t have that actually, I also pause my other OS maintenance activity almost to zero. So, I need to count on stable (conservative) releases … I would have been ok to go another while with OH3.4.4 on openhabian, but all over sudden …
Seems you are on top of it. If you need any help, let me know.
If you set the binding with trace logging enabled, try to replicate it and send me the log file could make it easier for me to also have a look.
Ok, parallel to some meetings, I managed to try test that given .jar, from here:
Albeit throwing some unknown log messages, plugin does work and bring my EnOceanPi bridge back to business. Thanks @dalgwen
One message got my attention, unable to resolve and import usbserial:
==> /var/log/openhab/openhab.log <==
2023-07-25 16:07:17.915 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.enocean-4.0.0.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.enocean [236]
Unresolved requirement: Import-Package: org.openhab.core.config.discovery.usbserial
The EnOceanPi bridge in RPI4 doesn’t need usbserial, its connected serial via RPi GPIO and normally all needed serial features are resolved automatically correctly.
I leave it running like that and look forward to maybe see updated packages for openhabian …
Thanks for all your contribution and passion working on openhab & openhabian
That’s right, I could have pinned the OH3 packages and might have been really done, knowing something is rolling in the middle of the summer … unlike the last releases rather end of the year.
However, its now running, my automations are up and running again with that workaround and a final stable enocean release might roll in sometime in the future.
Hello all. You can find the relative test release here. It fixes the issues introduces in OH 4.0.0 (at least, the easy to spot ones)
This is a test release. It could have other bugs and it is less stable than the previous (revert) release you could find here. But if you manage to take some time and test it, making a fix for everyone else in the next release will be faster.
Disclaimer : I’m not a maintainer or regular contributor of this binding and just happen to fix this because I encountered the issue. I probably won’t be able to help further
Thank you for your time and effort, I will try to setup a second Pi as a testsetup with openhab and enocean devices.
It looks like the maintainer of this enocean binding @fruggy83 isn’t active anymore.So what is the further procedure in such a case? Will the binding then be removed from openhab in a future release if there is no one who can maintain it?
@dalgwen Thanks for you efforts, that former try (revert release) is far better here, does run basically almost flawless, except that search for feature “usbserial” on startup …
That newer one (4.1.0-SNAPSHOT) causes a lot messages like that:
==> /var/log/openhab/openhab.log <==
2023-07-26 18:48:03.408 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2023-07-26 18:48:03.409 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
2023-07-26 18:48:03.410 [WARN ] [erial.internal.SerialPortManagerImpl] - No SerialPortProvider found for: /dev/ttyAMA0
2023-07-26 18:48:03.411 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
==> /var/log/openhab/openhab.log <==
2023-07-26 18:48:24.430 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBaseActuatorHandler of thing enocean:measurementSwitch:enoceanpi:05141CF6 tried checking if channel generalSwitchB is linked although the handler was already disposed.
2023-07-26 18:48:24.432 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBaseActuatorHandler of thing enocean:measurementSwitch:enoceanpi:05141CF6 tried checking if channel lastReceived is linked although the handler was already disposed.
2023-07-26 18:48:24.434 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBaseActuatorHandler of thing enocean:measurementSwitch:enoceanpi:05141CF6 tried checking if channel
Especially the transceiver shutdown pack does come every 30-60sek.
Looks like EnOcean is going down and up constantly every 30-60sek …
It’s way too soon to worry about that. @fruggy83 has been actively reviewing pull requests, last in March 2023 (that’s only four months ago). @zhivka.dimova has contributed several pull requests recently (for 3.4 as well as 4.0). And @dalgwen just contributed by quickly identifying and fixing the root cause for the 4.0 regression caused by recent refactoring. So the binding still seems actively maintained and nowhere near dead.
It does happen from time to time that bindings are completely abandoned. For cloud bindings that can become a problem overnight in case it’s broken by service changes, and there’s no one willing or capable to fix it. For local bindings it would usually take much longer until the lack of activity would become a real problem - at least for old devices no longer receiving firmware updates.
When a binding is in the official repository and bundled with openHAB, it will automatically receive the minimum required maintenance. For 4.0 that included some changes in all binding’s metadata and also securing Java compatibility, for example by refactoring some bindings using deprecated API’s. A few bindings in 4.0 did not receive the needed attention to avoid some warnings in the logs during startup, but they are still working and bundled with openHAB.
Having the binding added to addons.cfg and placed in the addons folder might lead to having two versions loaded and therefore causing trouble.
Only use either way.
Sure, was same opinion and have taken it out of the list in addon.cfg before testing first workaround … but to my surprise, enocean binding got not loaded on startup at all. I cleaned also cache in prior …
But will try it again …
Still the question about the order? What comes first, just for my understanding … ?
Cannot really comment on the order, but bindings (.jar) placed in the addons folder might miss some depending bundles (serial, upnp, coap, etc.), therefore you might see instructions for test versions where you should load some transport bundles first. In some cases it might help to install another binding using that transport.
This leads me to think that „properly installed“ bindings (ui or addons.cfg) are loaded before bindings in the addons folder.
. I will try to pinpoint it but cannot give a date.
