EnOcean USB300 Dongle Not Recognized After Update - Configuration Error "Port Could Not Be Found"

[jackmule (Jackson)]

Hello OpenHAB Community,

after a recent update, I noticed that my EnOcean USB300 Dongle stopped sending commands. The device was working perfectly before, but now it’s listed as “OFFLINE” with a “CONFIGURATION_ERROR: Port could not be found” message in the OpenHAB interface.

Here’s what I’ve tried so far:

1. Device and Port Verification:

   • The device is recognized by the system:

     openhabian@openhabian:~ $ dmesg | grep ttyUSB0
     [    6.770089] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
     

   • The port permissions seem correct:

     openhabian@openhabian:~ $ sudo ls -l /dev/ttyUSB*
     crw-rw---- 1 root dialout 188, 0 29. Aug 12:50 /dev/ttyUSB0
     

   • The openhabian user is part of the necessary groups:

     openhabian@openhabian:~ $ groups openhabian
     openhabian : openhab adm tty dialout cdrom sudo audio video plugdev games users input render netdev bluetooth spi i2c gpio openhabian
     

2. Configuration Details:

   • Thing Configuration:

     UID: enocean:bridge:FT3G3VBX
     Label: Enocean USB300 Dongle (FT3G3VBX)
     Thing Type UID: enocean:bridge
     Configuration:
       - rs485BaseId: "00000000"
       - path: /dev/ttyUSB0
       - rs485: false
       - enableSmack: true
       - espVersion: ESP3
       - sendTeachOuts: false
     

   • System Info:

     Runtime Version: 4.2.1 (Release Build)
     Java Version: 17.0.12 (Raspbian)
     OS: Linux 6.1.21-v8+ (arm architecture)
     

3. Troubleshooting Steps Taken:

   • Restarted both the OpenHAB service and the Raspberry Pi itself.
   • Verified that the serial port /dev/ttyUSB0 is available and correctly assigned.
   • Checked group memberships to ensure openhabian has access to the port.

Despite these checks, the dongle still fails to connect. I’m running out of ideas and would greatly appreciate any suggestions or insights into what might be causing this issue or how I might resolve it.

Thanks in advance for your help!

[rlkoshak (Rich Koshak)]

@jackmule

1. • Checked group memberships to ensure openhabian has access to the port.

openhab needs access to the port, not openhabian. openhabian is the user you log into the machine with. openhab is the user that openHAB runs under so that’s the user that needs access to that port.

So do step 1 and 3 again but this time for user openhab. I can’t say for sure if that will help but what you’ve done with user openhabian definitely wont as that’s irrelevant to the problem.

[jackmule (Jackson)]

@jackmule

groups openhabian

Thank you for the info! Unfortunately, that doesn’t seem to be the cause yet.

openhabian@openhabian:~ $ groups openhab
openhab : openhab tty dialout audio bluetooth gpio

[rlkoshak (Rich Koshak)]

I don’t know this binding nor the technology so can’t be of much more help except to say that it’s almost certainly not a permissions problem.

[dirkdirk (Dirk)]

@jackmule

EnOcean USB300

I am using the same dongle with latest version of openhab on Raspi. No problems at all. So it is not related to the binding or openhab version in general. Just for your information

[jackmule (Jackson)]

Thank you for the additional information that it still works for you. Unfortunately, I still haven’t figured out exactly what the problem is.

In the openHAB logs, I see:

2024-08-30 16:01:29.238 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘enocean:bridge:FT3G3VBX’ changed from OFFLINE (CONFIGURATION_ERROR): Port could not be found to OFFLINE (CONFIGURATION_PENDING): opening serial port…
2024-08-30 16:01:29.252 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘enocean:bridge:FT3G3VBX’ changed from OFFLINE (CONFIGURATION_PENDING): opening serial port… to OFFLINE (CONFIGURATION_ERROR): Port could not be found

sudo stty -F /dev/ttyUSB0
speed 9600 baud; line = 0;
-brkint -imaxbel

It seems that the serial interface can be accessed. Apart from installing updates, I have not changed any configurations etc. in the last few weeks.

[dirkdirk (Dirk)]

You could try to use another usb port or to delete the gateway and add it as a new thing.
The usb300 should be auto detected.
Maybe this will help.

[jackmule (Jackson)]

Thanks, I’m trying this right now after the current backup has gone through. If this does not work, I will try a backup from March 2024. If neither works, I suspect that the USB stick has a defect. It has been in use since mid 2020. I’ll be back with an update.

[Beasty (Sebastian)]

I am pretty sure this is a port problem where the initial port, where your Gateway was connected, is occupied by something else. I am no expert on this but I know for sure that I have the same problem.

Try this: Shutdown your pi via “sudo init 0”
Remove the EnOcean Stick from the USB port.
Restart your pi and wait for OH to fully boot. Then reconnect your EnOcean Stick.

If this helps, I can try to give you further instructions.

[jackmule (Jackson)]

Very strange. I had restarted the system and the OpenHAB service a few times, but nothing helped. I had also already tried various USB ports. Now I had shut down the system, removed the SD card to copy it with Win32DiskImager on my pc and when I brought the system back to power to try to remove the thing, it is already showing as online and everything is working again .

I also checked with

sudo lsof /dev/ttyUSB0

to see if there were other processes causing problems here. But I didn’t find anything in this regard yesterday either. Empty output yesterday. And now:

sudo lsof /dev/ttyUSB0
COMMAND PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
java    863 openhab  195u   CHR  188,0      0t0  366 /dev/ttyUSB0

[rlkoshak (Rich Koshak)]

@jackmule

In the openHAB logs, I see:

What’s in openhab.log? When there is an error that’s where it’s going to be logging. events.log is only going to log out the event that the Things went offline but not much about why.

[jackmule (Jackson)]

@rlkoshak

openhab.log

Just a quick note, it’s currently working again (even though I don’t understand the cause). But there was nothing noteworthy in the log:

2024-08-29 13:29:45.916 [INFO ] [org.openhab.core.Activator ] - Starting openHAB 4.2.1 (Release Build)
2024-08-29 13:29:47.282 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to ‘Europe/Berlin’.
2024-08-29 13:29:47.295 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Location set to ‘12345’.
2024-08-29 13:29:47.297 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to ‘de_DE’.
2024-08-29 13:30:09.042 [INFO ] [.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2024-08-29 13:30:23.210 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
2024-08-29 13:31:32.553 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2024-08-29 13:32:32.576 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2024-08-29 13:33:24.660 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2024-08-29 13:34:26.045 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
2024-08-29 13:35:26.064 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Transceiver shutdown
…

When it worked again:

2024-08-30 16:12:15.579 [INFO ] [org.openhab.core.Activator ] - Starting openHAB 4.2.1 (Release Build)
2024-08-30 16:12:16.258 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to ‘Europe/Berlin’.
2024-08-30 16:12:16.271 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Location set to ‘12345’.
2024-08-30 16:12:16.273 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to ‘de_DE’.
2024-08-30 16:51:43.638 [INFO ] [.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2024-08-30 16:51:53.112 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
2024-08-30 16:52:00.928 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver initialized
2024-08-30 16:52:00.935 [INFO ] [ernal.transceiver.EnOceanTransceiver] - EnOceanSerialTransceiver RX thread started
2024-08-30 16:52:00.936 [INFO ] [nternal.handler.EnOceanBridgeHandler] - EnOceanSerialTransceiver RX thread up and running

[rlkoshak (Rich Koshak)]

If it happens again you should put the binding into debug mode so you can see what happens before those “Transceiver shutdown” messages. Often the reason will be logged out and that can provide more info for diagnosing the problem.

[jackmule (Jackson)]

Unfortunately, the problem has been back since the last update. I’ll try to take a closer look after a family reunion tomorrow :).

I see, among other things, in the log:

http://192.168.8.30:9001/?filter=Not+all+dependencies+satisfied%2C

2025-05-17 23:30:27.487 [DEBUG] [ocean.internal.EnOceanHandlerFactory] - bundle org.openhab.binding.enocean:4.3.5 (252)[org.openhab.binding.enocean.internal.EnOceanHandlerFactory(321)] : Not all dependencies satisfied, cannot activate

After installing OpenHAB Serial Binding, it works again. It’s just strange that it worked before the update?

[jackmule (Jackson)]

Unfortunately, the problem has returned after updates now:

openHAB 5.0 Release Discussion

During my first attempt to install Java 21 (Temurin), the dpkg process froze. I had to kill it manually: sudo kill <your_pid> Then I cleaned up the lock files: sudo rm /var/lib/dpkg/lock-frontend sudo rm /var/lib/dpkg/lock And repaired the configuration: sudo dpkg --configure -a On the second try, the Java upgrade worked fine. My system (openHABian on Bookworm) was previously on Java 17. When I initially ran sudo apt upgrade, it failed because the openHAB 5 pre-installation script correct…

openHAB 5.0 Release Discussion

Hm, strange. I actually installed the EnOcean binding via the UI on my old openHABian (bullseye). I installed openHABian (bookworm) just two or three weeks ago and then imported the backup (openHAB 4 old/new respectively - openhab-cli backup). Can importing the backup trigger this as well?

Based on the information provided here, I reinstalled the EnOcean binding via the OpenHAB interface at that time. This was now ensured.

In the log file with the binding set to debug, I see:

2025-10-27 10:18:07.059 … : Dependency not satisfied: $000
2025-10-27 10:18:07.060 … : Not all dependencies satisfied, cannot activate
2025-10-27 10:18:07.048 … : Changed state from satisfied to unsatisfiedReference
2025-10-27 10:19:37.720 … : Component can not be activated since it is in state disabled
2025-10-27 10:19:37.808 … : Dependency not satisfied: $000
2025-10-27 10:19:37.810 … : Not all dependencies satisfied, cannot activate
2025-10-27 10:19:40.336 … : dm $000 … added {org.openhab.core.io.transport.serial.SerialPortManager}…
2025-10-27 10:19:40.413 … : Changed state from unsatisfiedReference to satisfied
2025-10-27 10:19:40.628 … : Changed state from satisfied to active

It seems that my Think path was also reset after the update? I had entered the ID path here:

No process is blocking the dongle:

openhabian@openhabian:\~ $ ls -l /dev/serial/by-id/EnOcean
lrwxrwxrwx 1 root root 13 27. Okt 11:18 /dev/serial/by-id/usb-EnOcean_GmbH_EnOcean_USB_300_DB_FT3G3VBX-if00-port0 → ../../ttyUSB0
sudo fuser -v /dev/serial/by-id/usb-EnOcean_GmbH_EnOcean_USB_300_DB_FT3G3VBX-if00-port0

@rlkoshak Do you have any ideas about why this keeps happening? You wrote to me about it in July.

What I did first:

• Removed RXTX bundle (nrjavaserial); keep only openhab-transport-serial (jSerialComm).
• Set bridge back to stable /dev/serial/by-id/ path.

[rlkoshak (Rich Koshak)]

I do not and can only provide generic debugging advice which is the same as I posted above.

There is nothing in the openHAB upgrade process that would change the property of a Thing so I don’t know what could have caused that.

[jackmule (Jackson)]

Unfortunately, after the last update, nothing worked again. Same error status. I now have a suspicion as to what the problem is. It’s probably due to the outdated RXTX serial drivers, which until now have always been installed automatically, from “Serial Binding” I mean.

I now uninstalled org.openhab.core.io.transport.serial.rxtx and org.openhab.core.io.transport.serial.rxtx.rfc2217 using the bundle:uninstall command. I also removed the generic “Serial Binding” via the UI, which is known to automatically reinstall these problematic legacy drivers.

I replaced the old driver with the modern standard (jSerialComm / javacomm). feature:install openhab-core-io-transport-serial-javacomm
Found the exact feature name by listing available features with feature:list | grep serial

I verified that /etc/default/openhab file did not contain any old -Dgnu.io.rxtx… Java options that would force the old driver behavior. That was not the case.

So far, so good. Let’s see if it sticks with the next update or if the old RXTX drivers come back and it stops working again.