EnOcean USB300 initialization fails with OH 4.0.0.M3 and OH 4.0.0.#3512

[fnu (Frank)]

@fnu

Will try to find time to test that given .jar.

Ok, parallel to some meetings, I managed to try test that given .jar, from here:

EnOcean USB300 initialization fails with OH 4.0.0.M3 and OH 4.0.0.#3512

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 pinp…

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

[hmerk (Hans-Jörg Merk)]

@fnu

I would have been ok to go another while with OH3.4.4 on openhabian,

You could have marked openHAB hold and openHABian would not update it, nor would a plain apt update/upgrade.

[dalgwen (Gwendal Roulleau)]

I managed to pinpoint several issues and I made a pull request for them.
Now the bridge is up, and I have basic button working with my rocker switch.

However, I cannot guarantee that there are no more issues.

Two options if a fix release is on the table :

• a revert (with this commit)
• a backport for the (partial?) fix from the PR above

[fnu (Frank)]

@hmerk

You could have marked openHAB hold and openHABian would not update it, nor would a plain apt update/upgrade.

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.

[hmerk (Hans-Jörg Merk)]

@fnu

something is rolling in the middle of the summer … unlike the last releases rather end of the year.

That’s not correct, we have two releases in the year since a long time. One normally end of June and one around Christmas.

[dalgwen (Gwendal Roulleau)]

@dalgwen

I managed to pinpoint several issues and I made a pull request for them.

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

[dirkdirk (Dirk)]

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?

[fnu (Frank)]

@dalgwen

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)

Ok, will give it a try, but a question for my information, do I need to rename that file to

org.openhab.binding.enocean-4.0.0.jar

being able to try test it?

@dirkdirk

Will the binding then be removed from openhab in a future release if there is no one who can maintain it?

That would be a pitty, IMHO there’s no other compareable EnOcean integration within any of the other home automation solution out there.

[fnu (Frank)]

@fnu

do I need to rename that file

Can answer myself, no need to rename …

@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 …

[laursen (Jacob Laursen)]

@dirkdirk

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?

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.

[fnu (Frank)]

@fnu

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.usbseria

@fnu

except that search for feature “usbserial” on startup …

My memory came back, having that message already 5 years ago and it got solved by loading installing another binding before EnOcean:

New openHab2 EnOcean binding

Hi Tino (@flynux), as I wrote above, your “raw” link gave me the correct file in size good to go. Installing and deinstalling 2.4.0 enocean binding doesn’t solve my issue, but I guess I have it run now. I tried several bindings from repo I might use in the future, already, e.g. avm for my fritzbox, network & WOL for general purpose, nothing did help up to now. But since I own a Yamaha RX-S600D, I gave that feature a last chance directly after the last post. To my surprise,…

But my approach since years is not install bindings using CLI or GUI, I have rather my bindings defined in addons.cfg:

binding = astro,avmfritz,enocean,hpprinter,network,ntp,openweathermap,shelly,vdr,yamahareceiver

So, are the bindings then loaded in that given order? Means placing enocean to the end might do the trick again?

Or is a binding manually placed “/usr/share/openhab/addons” loaded in any case on first step?

[hmerk (Hans-Jörg Merk)]

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.

[fnu (Frank)]

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 … ?

[hmerk (Hans-Jörg Merk)]

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.

[fnu (Frank)]

@hmerk

Having the binding added to addons.cfg and placed in the addons folder might lead to having two versions loaded and therefore causing trouble.

You’re right, but in my case it was the solution … basically starting with false acting & false conclusion, my bad.

Before testing that first .jar from here:

EnOcean USB300 initialization fails with OH 4.0.0.M3 and OH 4.0.0.#3512

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 pinp…

I have taken “enocean” out of my list in addon.cfg. After clean cache and restart of OH4, I haven’t seen any EnOcean devices in my setup anymore, so conclusion enocean binding has not been loaded and added it again to my addons.cfg. That made it work somehow, as you say most probably with parallel loaded enocean bindings … internal & external …

Today I started over clean, no enocean in addon.cfg, just .jar in addons folder, no enocean bridge and no devices after OH4 start. Checking karaf console for active bindings, enocean is missing:

openhab> bundle:list -s | grep binding
253 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.astro
254 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.avmfritz
255 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.hpprinter
256 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.network
257 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.ntp
258 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.openweathermap
259 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.shelly
260 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.vdr
261 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.yamahareceiver
270 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.serial

Same using that 4.1.0-SNAPSHOT from here:

EnOcean USB300 initialization fails with OH 4.0.0.M3 and OH 4.0.0.#3512

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 encounter…

But I also figured out “transport-serial” not being installed with both externally loaded bindings, but that is a prerequisite to communicate with the enocean bridge:

openhab> feature:list -s | grep serial
openhab-core-io-transport-serial-javacomm         │ 4.0.0            │          │ Uninstalled │ distro-4.0.0             │
openhab-transport-serial                          │ 4.0.0            │          │ Uninstalled │ distro-4.0.0             │ Serial Transport
openhab.tp-serial-javacomm                        │ 4.0.0            │          │ Uninstalled │ distro-4.0.0             │
openhab.tp-serial-rxtx                            │ 4.0.0            │          │ Uninstalled │ distro-4.0.0             │

To get those feature(s) I try tested to load serial binding as workaround in my binding list at addon.cfg:

binding = astro,avmfritz,hpprinter,network,ntp,openweathermap,shelly,serial,vdr,yamahareceiver

After that both external enocean bindings are loading, also feature “transport-serial” with that “serial binding” workaround:

openhab> feature:list -s | grep serial
openhab-core-io-transport-serial-javacomm         │ 4.0.0            │          │ Uninstalled │ distro-4.0.0             │
openhab-transport-serial                          │ 4.0.0            │          │ Started     │ distro-4.0.0             │ Serial Transport
openhab.tp-serial-javacomm                        │ 4.0.0            │          │ Uninstalled │ distro-4.0.0             │
openhab.tp-serial-rxtx                            │ 4.0.0            │          │ Started     │ distro-4.0.0             │

openhab> bundle:list -s | grep binding
236 │ Active │  80 │ 4.1.0.202307252320     │ org.openhab.binding.enocean
254 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.astro
255 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.avmfritz
256 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.hpprinter
257 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.network
258 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.ntp
259 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.openweathermap
260 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.serial
261 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.shelly
262 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.vdr
263 │ Active │  80 │ 4.0.0                  │ org.openhab.binding.yamahareceiver

That 4.1.0-SNAPSHOT throws a lot messages like that:

2023-07-28 22:25:22.380 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
2023-07-28 22:25:22.381 [WARN ] [erial.internal.SerialPortManagerImpl] - No SerialPortProvider found for: /dev/ttyAMA0
2023-07-28 22:25:22.381 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
2023-07-28 22:26:22.382 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2023-07-28 22:26:22.384 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
2023-07-28 22:26:22.386 [WARN ] [erial.internal.SerialPortManagerImpl] - No SerialPortProvider found for: /dev/ttyAMA0
2023-07-28 22:26:22.387 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.

With the other one logs are more clean, albeit not perfect.

And I still get that unresolved requirement “usbserial” on startup with both external bindings.

[hmerk (Hans-Jörg Merk)]

I would completely upgrade to the new openHAB 4.0.1 Patch Release which provides a fixed version of the binding.

[fnu (Frank)]

Sure, will do, when available in openhabian repository.

[laursen (Jacob Laursen)]

It is already.

[backflip (Stefan Keller)]

I suffered with the same issue after upgrade from 3.4.2 to 4.0.0. After installing 4.0.1 my EnOcean USB300 is working proper again.

[fnu (Frank)]

Hmm, ok, then something got screwed in openhabian, apt doesn’t offer the update:

openhabian@openhabian:~ $ sudo apt policy openhab
openhab:
  Installiert:           4.0.0-1
  Installationskandidat: 4.0.0-1
  Versionstabelle:
 *** 4.0.0-1 100
        100 /var/lib/dpkg/status

Not even the source repository is shown, making in look like it got installed manually.

Installation is defined on:

What repository do I need at “/etc/apt/…”?