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

[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/…”?

[fnu (Frank)]

Ok, spend some more time to clean install from scratch using openHABian image 1.8, restoring my file based setup. Setup comes now up with openhab 4.0.1.

All my devices are listed, seeming to work, but logs show constantly every 60sec:

2023-07-29 12:39:13.511 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2023-07-29 12:39:13.513 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.
2023-07-29 12:39:13.513 [WARN ] [erial.internal.SerialPortManagerImpl] - No SerialPortProvider found for: /dev/ttyAMA0
2023-07-29 12:39:13.514 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler EnOceanBridgeHandler tried updating the thing status although the handler was already disposed.

EnOcean devices can be switched resp. are delivering telemetric data and my EnOcean TF sensors are delivering humidity & temperatur. But unsure if enocean bridge is going down and up every 60sec …

[laursen (Jacob Laursen)]

I went back in the thread and it seems you didn’t have this issue with the fully reverted version that @dalgwen provided as a JAR? That would mean there are more issues with the refactoring. I don’t know if @lsiepel would be able to help analysing this?

[fnu (Frank)]

@laursen

I went back in the thread and it seems you didn’t have this issue with the fully reverted version that @dalgwen provided as a JAR?

Yes, that’s correct.

But, I have seen same repeating log messages with 4.1.0-SNAPSHOT by @dalgwen from above.

[Edit]
Needed serial features are in place:

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

And I added again that to /etc/default/openhab, memory settings were given by installation …

EXTRA_JAVA_OPTS="-Xms192m -Xmx768m -Dgnu.io.rxtx.SerialPorts=/dev/ttyAMA0"

[backflip (Stefan Keller)]

I’m sorry to confusing you all. I did some trying with my EnOcean USB300 issue.
Environment:
Nuc i5 with Ubuntu 22.04.2 LTS
OH 4.0.1

After a few hours where I was happy beacuse my gui said everything looks god, suddenly I got some log entries:

 tail -f /var/log/openhab/*.log | grep -e ERROR -e WARN
2023-07-29 12:55:05.365 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_ERROR): Port could not be found to OFFLINE (CONFIGURATION_PENDING): opening serial port...
2023-07-29 12:55:05.375 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_ERROR): Port could not be found
2023-07-29 12:56:05.380 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_ERROR): Port could not be found to OFFLINE (CONFIGURATION_PENDING): opening serial port...
2023-07-29 12:56:05.388 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_ERROR): Port could not be found
2023-07-29 12:57:05.392 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_ERROR): Port could not be found to OFFLINE (CONFIGURATION_PENDING): opening serial port...
2023-07-29 12:57:05.402 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'enocean:bridge:f424041d7c' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_ERROR): Port could not be found

The strange thing is, that even there is a config error and the thing (EnOcean Bridge) is not running, because the port was not found, the EnOcean rollershutter is working (at least at the last hour, and it is still working). I’m using EnOcean for the blind buttons (and other stuff) and control the homematic rollershutter.

[lsiepel]

I’ll look into this this weekend, probably this evening.