usbrelayd mqtt connection issue

[dezanche]

Hello,

Decided to get this working again after an update to my OpenMediaVault system broke the daemon.

I'm getting issues connecting to the MQTT broker. I pulled the latest and build the daemon. Verified broker settings in /etc/usbrelayd.conf look correct (same settings I use in MQTT Explorer) and replacing hostname with IP address doesn't change the error:

root@rock64:~/usbrelay# python3 usbrelayd rock64
MQTT Broker:  192.168.0.114
MQTT Client:  MyUSBRelay
Modules Connected:  1
Traceback (most recent call last):
  File "/root/usbrelay/usbrelayd", line 125, in <module>
    client.connect(mqttBroker, port=mqttport) 
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/paho/mqtt/client.py", line 914, in connect
    return self.reconnect()
           ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/dist-packages/paho/mqtt/client.py", line 1073, in reconnect
    sock.do_handshake()
  File "/usr/lib/python3.11/ssl.py", line 1379, in do_handshake
    self._sslobj.do_handshake()
ConnectionResetError: [Errno 104] Connection reset by peer

Of course I get this also when I run it as a service. Upgrading to the latest 'paho-mqtt' (using pip) doesn't fix the errors, but they are slightly different. I don't want to experiment too much with upgrades to Python packages because this is an OpenMediaVault system and it tells me that the environment is externally managed so I don't want to break something else.

Any idea how to fix this connection issue?

The python test script works (BTW in the readme the filename of the script should be updated). I don't know what else to try.

[darrylb123]

I have access to an openmedia vault server. I shall try it. Is the mqtt daemon running on the openmedia vault?

…

On Sun, 9 Nov 2025 at 06:26, Nicola De Zanche ***@***.***> wrote: *dezanche* created an issue (darrylb123/usbrelay#127) <#127> Hello, Decided to get this working again after an update to my OpenMediaVault system broke the daemon. I'm getting issues connecting to the MQTT broker. I pulled the latest and build the daemon. Verified broker settings in /etc/usbrelayd.conf look correct (same settings I use in MQTT Explorer) and replacing hostname with IP address doesn't change the error: ***@***.***:~/usbrelay# python3 usbrelayd rock64 MQTT Broker: 192.168.0.114 MQTT Client: MyUSBRelay Modules Connected: 1 Traceback (most recent call last): File "/root/usbrelay/usbrelayd", line 125, in <module> client.connect(mqttBroker, port=mqttport) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/dist-packages/paho/mqtt/client.py", line 914, in connect return self.reconnect() ^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/dist-packages/paho/mqtt/client.py", line 1073, in reconnect sock.do_handshake() File "/usr/lib/python3.11/ssl.py", line 1379, in do_handshake self._sslobj.do_handshake() ConnectionResetError: [Errno 104] Connection reset by peer Of course I get this also when I run it as a service. Upgrading to the latest 'paho-mqtt' (using pip) doesn't fix the errors, but they are slightly different. I don't want to experiment too much with upgrades to Python packages because this is an OpenMediaVault system and it tells me that the environment is externally managed so I don't want to break something else. Any idea how to fix this connection issue? The python test script works (BTW in the readme the filename of the script should be updated). I don't know what else to try. — Reply to this email directly, view it on GitHub <#127>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSUVPXBLT6ALVSCMGWYHD33ZGXBAVCNFSM6AAAAACLRKRKSSVHI2DSMVQWIX3LMV43ASLTON2WKOZTGYYDGOJTGU2DKMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[darrylb123]

I'm not a debian user and I installed OMV and tried to build it.
How did you install the python build environment (pip install build)? Can you post the commands you used to build it?

BTW, I'm not sure that python3.11 works, the last major change was to allow it to work on the latest python. I installed on Fedora 43 with python3.14 from the packages and it works fine.

[dezanche]

Thanks,
The MQTT broker is the eclipse-mosquitto docker image running on the same OMV system.

To build I had to use apt install python3-build to avoid the error that says that the packages are managed externally (there to prevent messing up the OMV system). I also had to install the .whl using pip instead of make install.

BTW, when I updated the paho-mqtt package to the latest one (2.?) I also got some deprecation statements so I reverted back.

I can't change the Python version on the whole system. I'm afraid it will break something else.
But in my experience with Python, it's mostly the versions of the packages that make or break compatibility. It would help to have a requirements.txt file with the required packages and versions that are known to work. Unfortunately Python packages are continuously changing and it takes time to keep a project up to date.
I'm increasingly convinced that this service should run in a docker container of its own to avoid these issues. I've never created my own docker images so that could take some time.

[darrylb123]

There are docker build instructions, but they are years old and are not for usbrelayd. Out of interest, I installed the fedora packages on fedora 43. Worked perfectly. I'll look at a docker container, it's time I learned how to make them.

…

On Tue, 11 Nov 2025, 4:17 pm Nicola De Zanche, ***@***.***> wrote: *dezanche* left a comment (darrylb123/usbrelay#127) <#127 (comment)> Thanks, The MQTT broker is the eclipse-mosquitto docker image running on the same OMV system. To build I had to use apt install python3-build to avoid the error that says that the packages are managed externally (there to prevent messing up the OMV system). I also had to install the .whl using pip instead of make install. BTW, when I updated the paho-mqtt package to the latest one (2.?) I also got some deprecation statements so I reverted back. I can't change the Python version on the whole system. I'm afraid it will break something else. But in my experience with Python, it's mostly the versions of the packages that make or break compatibility. It would help to have a requirements.txt file with the required packages and versions that are known to work. Unfortunately Python packages are continuously changing and it takes time to keep a project up to date. I'm increasingly convinced that this service should run in a docker container of its own to avoid these issues. I've never created my own docker images so that could take some time. — Reply to this email directly, view it on GitHub <#127 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSUVKPWEAE4WUF5BQKCO334F5PJAVCNFSM6AAAAACLRKRKSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMJVGE3DEMJXGE> . You are receiving this because you commented.Message ID: ***@***.***>

[dezanche]

Sorry I can't help you there. It sounds simple though. You start with a base image (some Linux) and add the pieces you need.
After it's built you run it making sure to give the container access to the correct /dev/
Did you have to manually install Python packages in Fedora? If yes which ones?

[darrylb123]

No, I installed the package and it pulled in the dependant Python packages and hidapi.

…

On Sat, 15 Nov 2025, 9:06 am Nicola De Zanche, ***@***.***> wrote: *dezanche* left a comment (darrylb123/usbrelay#127) <#127 (comment)> Sorry I can't help you there. It sounds simple though. You start with a base image (some Linux) and add the pieces you need. After it's built you run it making sure to give the container access to the correct /dev/ Did you have to manually install Python packages in Fedora? If yes which ones? — Reply to this email directly, view it on GitHub <#127 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSUVOLZEX3KSUDKMOPUJD34ZN67AVCNFSM6AAAAACLRKRKSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMZUHE4TEOBZGA> . You are receiving this because you commented.Message ID: ***@***.***>

[darrylb123]

I've done a little work on implementing usbrelayd in docker.
Seems to work fine
You will find the doco at the end of README.md
Added some checking which might give more sensible error messages.
Can you test on your openmediavault server?

[darrylb123]

Your initial error was caused by the word False in the default usbrelayd.conf file.
It is the TLS driver complaining.

[dezanche]

Oh thank you, I deleted False from the TLS line and the daemon works!

I built the docker container on my OMV system (7.7.20-1 Sandworm, based on Debian 12 bookworm, armhf architecture) without errors.
I haven't run it yet, but I suspect you don't need to use privileged mode. You should be able to pass the /dev/hidraw0 or whatever the device gets mapped to using the docker run option like --device=/dev/hidraw0:/dev/hidraw0

[darrylb123]

That's true, I tried it just passing --device and it worked fine. I just thought the device might come up differently if another USB device is inserted and break usbrelayd. You might like to pull and build the latest version from git. I added better checking on the availability of the MQTT broker and updated to the latest paho-mqtt API. I updated the doco to show how to make docker restart the container on boot and failure.

…

On Fri, 21 Nov 2025 at 14:06, Nicola De Zanche ***@***.***> wrote: *dezanche* left a comment (darrylb123/usbrelay#127) <#127 (comment)> Oh thank you, I deleted False from the TLS line and the daemon works! I built the docker container on my OMV system (7.7.20-1 Sandworm, based on Debian 12 bookworm, armhf architecture) without errors. I haven't run it yet, but I suspect you don't need to use privileged mode. You should be able to pass the /dev/hidraw0 or whatever the device gets mapped to using the docker run option like --device=/dev/hidraw0:/dev/hidraw0 — Reply to this email directly, view it on GitHub <#127 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSUVLVZRUXQAFENPAOOMD352FU5AVCNFSM6AAAAACLRKRKSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNRRGMYDQNZXHE> . You are receiving this because you commented.Message ID: ***@***.***>