I ran openHAB 4.3.4 on a RPI 4, with an USB enocean gateway.
I have a eltaco FAM14 system with dimmers (FUD14) and switches (FMS14).
Everything is working.
I made a backup of the system with openhabian.
On my QNAP a made a new virtual machine and installed a fresh debian13 OS.
After that I installed openHAB 5.2.0.
In openhabian-config a made a recovery with the backup from the RPI.
I start the VM machine and everything start without problems.
I can acces my openhab by ip:8080. All the bindings are working…
Except the enocean switches.
I can control my dimmers, send and receive messages (checked with dolphin viewer)
But if i press a rockerswitch (I have 15 of them) no commands from all the rockerswitches are send into the system. (with dolpin viewer no switch commands are send, receiving commands are working)
Can somebody help me with this problem?
Kind regards Arie
Have you mapped the host’s serial device path or USB device path directly to the container? You’ve said nothing about it, but a container doesn’t automatically have access to hardware devices - that must be configured specifically. I’ve never done this with Docker, but it can be quite a pain with VMs. I’m guessing it’s a bit easier with Docker though.
The device must be forwarded, most likely as a USB device. Must such USB dongles use USB-to-serial, but I don’t know if the binding supports using a serial port, or if it expects to see the USB device itself.
I believe @Nadahar has identified the problem. Not saying this is the only solution (If that is indeed the issue), but I use usbipd to attach a serial device to WSL (debian) in Win11 to run test OH instances. I also run these in docker so need to bring them into the container (devices: - '/dev/serial/by-id/usb-0658_0200-if00:/dev/zwaveoh.
You can google/AI, but the basic command is usbipd wsl attach -b x-xx (get with usbipd wsl list) for windows. I also connect a remote serial device from a RPi3b to a Rpi4 (both on trixie) with usbipd. I used this tutorial maybe that could help.
Just in case QNAP doesn’t support /serial/by-id/ (my Synology doesn’t), I added these two statements in my docker create script in order to have access to an Aeotec Z-Stick Gen5+ USB dongle. Of course you would need to change /dev/ttyACM0 to whatever your dongle is identified as.
This is a little ambiguous. What is “the system” here? Where are the commands comming from? openHAB? The device? Both? Does OH see anything at all and does OH receive anything at all? If the Enocean Bridge Thing is ONLINE and there is anything comming into OH or leaving OH properly, device passthrough is not the problem. If it were the Thing wouldn’t be ONLINE and nothing would work.
QNAP, like Synology, is notoriously challenging to get OH working on if there is a requirement for USB devices. Adding Docker on top just makes it that much more challenging. But if OH inside the container can send or receive even just the one message, that part is working and something else is going on. Otherwise it should just be offline as if you pointed the Enocean binding to a device that doesn’t exist.
I agree that it’s unclear what is references when, but I read it as if devices that don’t rely on the Enocean binding work from OH, while the Enocean switches do not. Combining my “interpretation of the description” with the fact that a USB dongle is needed and the move to Docker was enough for me to assume that it’s about device passthrough.
But OP is seeing messages with Dolphin Viewer which is the like an Enocean sniffer and not related to other bindings (which are reported to work). So it’s important to distinguish the source of those messages. And there is no mention on whether the Enocean Things are online or not. It very well could be a passthrough issue. But if any of those messages seen by Dolphin viewer came from OH and the Enocean Things are online, it’s not.
I don’t think there is enough information posted to diagnose the problem one way or the other.
I agree, there’s not enough information to be sure, but it’s enough for me to guess
Think of it this way: We know that the installation was moved to a container on a QNAP, and OP never mentioned anything about forwarding the hardware. Wouldn’t that be one of the things you’d explain that you had done when making such a post, if you had? And, if this hasn’t been done, there can’t be communication between OH and the dongle as far as I can understand.
