usbrelayd crashing

[dezanche]

I built the usbrelayd daemon according to the instructions but it fails to run. The logs are not much help but my knowledge is limited:

root@rock64:~/usbrelay# systemctl status usbrelayd

• usbrelayd.service - USB Relay MQTT service Loaded: loaded (/etc/systemd/system/usbrelayd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2021-12-20 17:52:48 MST; 2min 23s ago Process: 26034 ExecStart=/usr/bin/python3 /usr/local/sbin/usbrelayd ${BROKER} (code=exited, status=1/FAILURE)

  Main PID: 26034 (code=exited, status=1/FAILURE)

Dec 20 17:52:47 rock64 systemd[1]: usbrelayd.service: Failed with result 'exit-code'. Dec 20 17:52:48 rock64 systemd[1]: usbrelayd.service: Service RestartSec=1s expired, scheduling restart. Dec 20 17:52:48 rock64 systemd[1]: usbrelayd.service: Scheduled restart job, restart counter is at 5. Dec 20 17:52:48 rock64 systemd[1]: Stopped USB Relay MQTT service. Dec 20 17:52:48 rock64 systemd[1]: usbrelayd.service: Start request repeated too quickly. Dec 20 17:52:48 rock64 systemd[1]: usbrelayd.service: Failed with result 'exit-code'. Dec 20 17:52:48 rock64 systemd[1]: Failed to start USB Relay MQTT service.

The test.py script works as it should. Did I mess up the BROKER definition in the .conf file? I simply inserted the IP address of the MQTT broker. N

[darrylb123]

The usbrelayd.conf needs to be in /usr/local/etc and the file contents must have a BROKER=hostname or IP address line which must point to a working mqtt daemon (like mosquitto) of some kind running on the normal port.

Example environment file for usbrelayd

BROKER variable is the hostname or IP address of the mqtt broker to be

passed to the service BROKER=nodered

For example, my local mqtt host is nodered which is resolvable from DNS in my network. I could easily have used it's IP address instead.

My mosquitto mqtt host is not configured for authentication. If you require authentication, you will need to modify the daemon code to suit. Feel free to send me your modifications if this is the case.

On Tue, Dec 21, 2021 at 11:04 AM Nicola De Zanche @.***> wrote:

I built the usbrelayd daemon according to the instructions but it fails to run. The logs are not much help but my knowledge is limited:

@.***:~/usbrelay# systemctl status usbrelayd

• usbrelayd.service - USB Relay MQTT service Loaded: loaded (/etc/systemd/system/usbrelayd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2021-12-20 17:52:48 MST; 2min 23s ago Process: 26034 ExecStart=/usr/bin/python3 /usr/local/sbin/usbrelayd ${BROKER} (code=exited, status=1/FAILURE)

Main PID: 26034 (code=exited, status=1/FAILURE)

Dec 20 17:52:47 rock64 systemd[1]: usbrelayd.service: Failed with result 'exit-code'. Dec 20 17:52:48 rock64 systemd[1]: usbrelayd.service: Service RestartSec=1s expired, scheduling restart. Dec 20 17:52:48 rock64 systemd[1]: usbrelayd.service: Scheduled restart job, restart counter is at 5. Dec 20 17:52:48 rock64 systemd[1]: Stopped USB Relay MQTT service. Dec 20 17:52:48 rock64 systemd[1]: usbrelayd.service: Start request repeated too quickly. Dec 20 17:52:48 rock64 systemd[1]: usbrelayd.service: Failed with result 'exit-code'. Dec 20 17:52:48 rock64 systemd[1]: Failed to start USB Relay MQTT service.`

Did I mess up the BROKER definition in the .conf file? I simply have the IP address of the MQTT broker. N

— Reply to this email directly, view it on GitHub https://github.com/darrylb123/usbrelay/issues/75, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTSUVOLXRL24PZG4RKRAYDUR7HCRANCNFSM5KO7BV4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

[dezanche]

Thanks Darryl, that's all set up correctly: conf file with hostname, no authentication.

I tested my broker (I haven't used MQTT before this) following the testing procedure here. It's in the docker container described in the link and the broker responds.

Where are the confirmation messages from the daemon supposed to be printed? I don't see any confirmation that it even gets to the point of finding the USB module (lines 62-66 in usbrelayd). A confirmation of successful or unsuccessful connection to the broker may also be helpful.

[darrylb123]

Use journalctl -f to see the output of usbrelayd. It should display connection and relay messages.

If you're running the mqtt daemon it in a docker container, won't the IP/port be different? I have almost no experience with docker so I can't really help there.

What was the test you performed?

Darryl

On Thu, 23 Dec 2021, 11:43 am Nicola De Zanche, @.***> wrote:

Thanks Darryl, that's all set up correctly: conf file with hostname, no authentication.

I tested my broker (I haven't used MQTT before this) following the testing procedure here https://hometechhacker.com/mqtt-home-assistant-using-docker-eclipse-mosquitto/. It's in the docker container described in the link and the broker responds.

Where are the confirmation messages from the daemon supposed to be printed? I don't see any confirmation that it even gets to the point of finding the USB module (lines 62-66 in usbrelayd). A confirmation of successful or unsuccessful connection to the broker may also be helpful.

— Reply to this email directly, view it on GitHub https://github.com/darrylb123/usbrelay/issues/75#issuecomment-999982322, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTSUVMDQNV3U7MOTUC5D2LUSJ5FBANCNFSM5KO7BV4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[darrylb123]

These are the error messages from journalctl -f I get when my BROKER= points to a host without an mqtt daemon:

systemd[1]: Started USB Relay MQTT service. python3[401373]: Modules Connected: 1 python3[401373]: detected unhandled Python exception in '/usr/local/sbin/usbrelayd' abrt-server[401374]: Not saving repeating crash in '/usr/local/sbin/usbrelayd' python3[401373]: Traceback (most recent call last): python3[401373]: File "/usr/local/sbin/usbrelayd", line 72, in python3[401373]: client.connect(mqttBroker) python3[401373]: File "/usr/lib/python3.9/site-packages/paho/mqtt/client.py", line 941, in connect python3[401373]: return self.reconnect() python3[401373]: File "/usr/lib/python3.9/site-packages/paho/mqtt/client.py", line 1075, in reconnect python3[401373]: sock = self._create_socket_connection() python3[401373]: File "/usr/lib/python3.9/site-packages/paho/mqtt/client.py", line 3546, in _create_socket_connection python3[401373]: return socket.create_connection(addr, source_address=source, timeout=self._keepalive) python3[401373]: File "/usr/lib64/python3.9/socket.py", line 844, in create_connection python3[401373]: raise err python3[401373]: File "/usr/lib64/python3.9/socket.py", line 832, in create_connection python3[401373]: sock.connect(sa) python3[401373]: ConnectionRefusedError: [Errno 111] Connection refused systemd[1]: usbrelayd.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: usbrelayd.service: Failed with result 'exit-code'.

On Thu, Dec 23, 2021 at 5:27 PM Darryl Bond @.***> wrote:

Use journalctl -f to see the output of usbrelayd. It should display connection and relay messages.

If you're running the mqtt daemon it in a docker container, won't the IP/port be different? I have almost no experience with docker so I can't really help there.

What was the test you performed?

Darryl

On Thu, 23 Dec 2021, 11:43 am Nicola De Zanche, @.***> wrote:

Thanks Darryl, that's all set up correctly: conf file with hostname, no authentication.

I tested my broker (I haven't used MQTT before this) following the testing procedure here https://hometechhacker.com/mqtt-home-assistant-using-docker-eclipse-mosquitto/. It's in the docker container described in the link and the broker responds.

Where are the confirmation messages from the daemon supposed to be printed? I don't see any confirmation that it even gets to the point of finding the USB module (lines 62-66 in usbrelayd). A confirmation of successful or unsuccessful connection to the broker may also be helpful.

— Reply to this email directly, view it on GitHub https://github.com/darrylb123/usbrelay/issues/75#issuecomment-999982322, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTSUVMDQNV3U7MOTUC5D2LUSJ5FBANCNFSM5KO7BV4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[dezanche]

Thanks for the tip, checking the journalctl messages helped! The problem was not finding the python module:

python3[2425]: ModuleNotFoundError: No module named 'paho'

However apt shows the package was installed:

'python-paho-mqtt/oldstable,oldstable,now 1.4.0-1 all [installed]

The same thing happened if I tried to import the module from a test script.

The error was that paho was installed for Python 2.7 instead of 3.7

About the MQTT in docker, this page has the installation instructions and simple test commands (about half way down the page) to make sure the messages are being passed.

Docker containers can connect to the host network and use the same IP address, and you use different ports to talk to each other and avoid conflicts. After a brief learning curve dockerized applications create less headaches for people like me who don't have a whole lot of experience and time. For my home assistant setup I'm now using 4 containers: home-assistant, motioneye, MQTT and Portainer, which is a web interface for docker and is itself a docker container.

[darrylb123]

I set up the mosquitto add-on in home assistant VM. That works too.

On Fri, 24 Dec 2021, 6:18 am Nicola De Zanche, @.***> wrote:

Thanks for the tip, checking the journalctl messages helped! The problem was not finding the python module:

python3[2425]: ModuleNotFoundError: No module named 'paho'

However apt shows the package was installed:

'python-paho-mqtt/oldstable,oldstable,now 1.4.0-1 all [installed]

The same thing happened if I tried to import the module from a test script.

The error was that paho was installed for Python 2.7 instead of 3.7

About the MQTT in docker, this page https://hometechhacker.com/mqtt-home-assistant-using-docker-eclipse-mosquitto/ has the installation instructions and simple test commands (about half way down the page) to make sure the messages are being passed.

Docker containers can connect to the host network and use the same IP address, and you use different ports to talk to each other and avoid conflicts. After a brief learning curve dockerized applications create less headaches for people like me who don't have a whole lot of experience and time. For my home assistant setup I'm now using 4 containers: home-assistant, motioneye, MQTT and Portainer, which is a web interface for docker and is itself a docker container.

— Reply to this email directly, view it on GitHub https://github.com/darrylb123/usbrelay/issues/75#issuecomment-1000507158, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTSUVJGEGWC75XYQFW63ZTUSN72DANCNFSM5KO7BV4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[dezanche]

Unfortunately I wasn't able to use the VM with my system. How is the device name assigned by the daemon? Again, this might be a stupid question having never used MQTT but I'm seeing a blank name:

[darrylb123]

The device name is the serial. If it is blank, then the serial is not set. Use usbrelay to change the serial. Check the documentation. The serial should be unique.

On Sun, 26 Dec 2021, 11:36 am Nicola De Zanche, @.***> wrote:

Unfortunately I wasn't able to use the VM with my system. How is the device name assigned by the daemon? Again, this might be a stupid question having never used MQTT but I'm seeing a blank name: [image: image] https://user-images.githubusercontent.com/41122973/147396636-8a608ddf-756e-4891-aca6-accd5c4da4d1.png

— Reply to this email directly, view it on GitHub https://github.com/darrylb123/usbrelay/issues/75#issuecomment-1001092007, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTSUVLT5NWFUDDKDFLAFT3USZWSLANCNFSM5KO7BV4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[darrylb123]

Are you using a ucreatefun relay? They cannot have the serial changed and the state cannot be queried. They are not very useful in this situation. I did not really focus on them due to their limitations. I have one. I'll test it.

Darryl

On Mon, 27 Dec 2021, 7:14 am Darryl Bond, @.***> wrote:

The device name is the serial. If it is blank, then the serial is not set. Use usbrelay to change the serial. Check the documentation. The serial should be unique.

On Sun, 26 Dec 2021, 11:36 am Nicola De Zanche, @.***> wrote:

Unfortunately I wasn't able to use the VM with my system. How is the device name assigned by the daemon? Again, this might be a stupid question having never used MQTT but I'm seeing a blank name: [image: image] https://user-images.githubusercontent.com/41122973/147396636-8a608ddf-756e-4891-aca6-accd5c4da4d1.png

— Reply to this email directly, view it on GitHub https://github.com/darrylb123/usbrelay/issues/75#issuecomment-1001092007, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTSUVLT5NWFUDDKDFLAFT3USZWSLANCNFSM5KO7BV4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[dezanche]

It does have a serial number (6QMBS below) so it should carry through to the daemon. I am able to listen and publish to it just leaving it blank so for now I'd like to leave the serial number as it is.

root@rock64:/home/home-assistant# usbrelay -d libusbrelay: 0.7-61-g6ff30aa364 usbrelay: 0.7-61-g6ff30aa364 enumerate_relay_boards()Found 1 devices Device Found type: 16c0 05df path: /dev/hidraw0 serial_number: 6QMBS Manufacturer: www.dcttech.com Product: USBRelay8 Release: 100 Interface: 0 Number of Relays = 8 Module_type = 1 6QMBS_1=0 6QMBS_2=0 6QMBS_3=0 6QMBS_4=0 6QMBS_5=0 6QMBS_6=0 6QMBS_7=0 6QMBS_8=0

Nick

[dezanche]

Actually, the MQTT commands are not making it to the relay board, while I am able to set them using usbrelay. I'm not sure what the daemon is seeing:

root@rock64:~# systemctl status usbrelayd

• usbrelayd.service - USB Relay MQTT service Loaded: loaded (/etc/systemd/system/usbrelayd.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2021-12-26 14:47:48 MST; 3min 16s ago Main PID: 23556 (python3) Tasks: 2 (limit: 4773) Memory: 5.5M CGroup: /system.slice/usbrelayd.service `-23556 /usr/bin/python3 /usr/local/sbin/usbrelayd rock64

Dec 26 14:50:48 rock64 python3[23556]: State: stat//4 OFF Dec 26 14:50:48 rock64 python3[23556]: Subscribed: cmnd//4 Dec 26 14:50:48 rock64 python3[23556]: State: stat//5 OFF Dec 26 14:50:48 rock64 python3[23556]: Subscribed: cmnd//5 Dec 26 14:50:48 rock64 python3[23556]: State: stat//6 OFF Dec 26 14:50:48 rock64 python3[23556]: Subscribed: cmnd//6 Dec 26 14:50:48 rock64 python3[23556]: State: stat//7 OFF Dec 26 14:50:48 rock64 python3[23556]: Subscribed: cmnd//7 Dec 26 14:50:48 rock64 python3[23556]: State: stat//8 OFF Dec 26 14:50:48 rock64 python3[23556]: Subscribed: cmnd//8

[darrylb123]

That is odd. I use exactly the same relay board and it looks like this:

@.***:~ $ sudo systemctl status usbrelayd ● usbrelayd.service - USB Relay MQTT service Loaded: loaded (/etc/systemd/system/usbrelayd.service; disabled; vendor preset: enabled) Active: active (running) since Thu 2021-11-04 13:29:27 AEST; 1 months 23 days ago Main PID: 536 (python3) Tasks: 2 (limit: 2164) CGroup: /system.slice/usbrelayd.service └─536 /usr/bin/python3 /usr/local/sbin/usbrelayd mqtt.thebonds.lan

Dec 28 06:44:43 nodered python3[536]: Subscribed: cmnd/WATER/5 Dec 28 06:44:43 nodered python3[536]: State: stat/WATER/6 OFF Dec 28 06:44:43 nodered python3[536]: Subscribed: cmnd/WATER/6 Dec 28 06:44:43 nodered python3[536]: State: stat/WATER/7 OFF Dec 28 06:44:43 nodered python3[536]: Subscribed: cmnd/WATER/7 Dec 28 06:44:43 nodered python3[536]: State: stat/WATER/8 OFF Dec 28 06:44:43 nodered python3[536]: Subscribed: cmnd/WATER/8 Dec 28 06:44:43 nodered python3[536]: received message: cmnd/WATER/6 OFF Dec 28 06:44:43 nodered python3[536]: received message: cmnd/WATER/7 OFF Dec 28 06:44:43 nodered python3[536]: received message: cmnd/WATER/8 OFF @.***:~ $

Does journalctl -f give you any hints? Perhaps change the serial??

Darryl

On Mon, 27 Dec 2021, 7:56 am Nicola De Zanche, @.***> wrote:

Actually, the MQTT commands are not making it to the relay board, while I am able to set them using usbrelay. I'm not sure what the daemon is seeing:

@.***:~# systemctl status usbrelayd

• usbrelayd.service - USB Relay MQTT service Loaded: loaded (/etc/systemd/system/usbrelayd.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2021-12-26 14:47:48 MST; 3min 16s ago Main PID: 23556 (python3) Tasks: 2 (limit: 4773) Memory: 5.5M CGroup: /system.slice/usbrelayd.service `-23556 /usr/bin/python3 /usr/local/sbin/usbrelayd rock64

Dec 26 14:50:48 rock64 python3[23556]: State: stat//4 OFF Dec 26 14:50:48 rock64 python3[23556]: Subscribed: cmnd//4 Dec 26 14:50:48 rock64 python3[23556]: State: stat//5 OFF Dec 26 14:50:48 rock64 python3[23556]: Subscribed: cmnd//5 Dec 26 14:50:48 rock64 python3[23556]: State: stat//6 OFF Dec 26 14:50:48 rock64 python3[23556]: Subscribed: cmnd//6 Dec 26 14:50:48 rock64 python3[23556]: State: stat//7 OFF Dec 26 14:50:48 rock64 python3[23556]: Subscribed: cmnd//7 Dec 26 14:50:48 rock64 python3[23556]: State: stat//8 OFF Dec 26 14:50:48 rock64 python3[23556]: Subscribed: cmnd//8

— Reply to this email directly, view it on GitHub https://github.com/darrylb123/usbrelay/issues/75#issuecomment-1001246436, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTSUVJFRAUXOH32LWZSTSDUS6FQPANCNFSM5KO7BV4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[dezanche]

Hi Darryl, thanks for spending time on this! I did change the serial by accident yesterday and then changed it back. No change.

I don't see anything helpful from journalctl -f:

Dec 27 15:17:14 rock64 python3[23556]: State: stat//1 OFF Dec 27 15:17:14 rock64 python3[23556]: Subscribed: cmnd//1 ... Is it possible that the problem and differences come from installing usbrelay using apt-get install while usbrelayd was built using the files in the github repo? N

[darrylb123]

Very much yes, you must build the latest source from GitHub to use usbrelayd. The code installed from apt-get is years old. The maintainer of the debian package does not respond.

Just follow the dock. You must build usbrelay and python interface library. It's very straight forward.

Darryl

On Tue, 28 Dec 2021, 8:59 am Nicola De Zanche, @.***> wrote:

Hi Darryl, thanks for spending time on this! I did change the serial by accident yesterday and then changed it back. No change.

I don't see anything helpful from journalctl -f:

Dec 27 15:17:14 rock64 python3[23556]: State: stat//1 OFF Dec 27 15:17:14 rock64 python3[23556]: Subscribed: cmnd//1 ... Is it possible that the problem and differences come from installing usbrelay using apt-get install while usbrelayd was built using the files in the github repo? N

— Reply to this email directly, view it on GitHub https://github.com/darrylb123/usbrelay/issues/75#issuecomment-1001790107, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTSUVNQB3AW2DJBA4PDYNTUTDVT5ANCNFSM5KO7BV4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[dezanche]

I built the library correctly following the steps under "Python Extension" (using "make python"). In fact this test script (run using python3) publishes the correct information (stat/serial/state) to the MQTT broker:

import usbrelay_py
import paho.mqtt.client as mqtt

count = usbrelay_py.board_count()
print("Count: ",count)

boards = usbrelay_py.board_details()
print("Boards: ",boards)

for board in boards:
    print("Board: ",board)
    print(board[0])
    relay = 1
    relay_state = "ON"
    topic = "{0}/{1}/{2}"
    topic_str = topic.format("stat",board[0],relay)
    print("State: ", topic_str)
client = mqtt.Client("Switch")
client.connect("Rock64") 
client.publish(topic_str, relay_state)

I know for sure that the system is not trying to run this with python2: the test script will throw an error because the usbrelay_py extension is not present for python2. So I tried running the daemon directly from the command line and it works fine (both at the terminal output below and at the broker):

python3 usbrelayd rock64
Modules Connected:  1
State:  stat/6QMBS/1 OFF
Subscribed:  cmnd/6QMBS/1
State:  stat/6QMBS/2 OFF
Subscribed:  cmnd/6QMBS/2
State:  stat/6QMBS/3 OFF
Subscribed:  cmnd/6QMBS/3
State:  stat/6QMBS/4 OFF
Subscribed:  cmnd/6QMBS/4
State:  stat/6QMBS/5 OFF
Subscribed:  cmnd/6QMBS/5
State:  stat/6QMBS/6 OFF
Subscribed:  cmnd/6QMBS/6
State:  stat/6QMBS/7 OFF
Subscribed:  cmnd/6QMBS/7
State:  stat/6QMBS/8 OFF
Subscribed:  cmnd/6QMBS/8

So I'm ever more baffled...

UPDATE: The daemon publishes the correct information if I run it as root by editing the User = line in usbrelayd.service (probably not a good idea in the long term...), so there's a problem with the usbrelay user.

[darrylb123]

Make sure you are using only the new code. Make sure you remove the out of date usbrelay package first. Then make the whole thing. The python library uses libusbrelay which must be up to date. $ make clean $ make $ sudo make install $ make python $ sudo make install_py

On Wed, 29 Dec 2021, 10:11 am Nicola De Zanche, @.***> wrote:

I built the library correctly following the steps under "Python Extension" (using "make python"). In fact this test script (run using python3) publishes the correct information (stat/serial/state) to the MQTT broker:

import usbrelay_py import paho.mqtt.client as mqtt

count = usbrelay_py.board_count() print("Count: ",count)

boards = usbrelay_py.board_details() print("Boards: ",boards)

for board in boards: print("Board: ",board) print(board[0]) relay = 1 relay_state = "ON" topic = "{0}/{1}/{2}" topic_str = topic.format("stat",board[0],relay) print("State: ", topic_str) client = mqtt.Client("Switch") client.connect("Rock64") client.publish(topic_str, relay_state)

I know for sure that the system is not trying to run this with python2: the test script will throw an error because the usbrelay_py extension is not present for python2. So I tried running the daemon directly from the command line and it works fine (both at the terminal output below and at the broker):

python3 usbrelayd rock64 Modules Connected: 1 State: stat/6QMBS/1 OFF Subscribed: cmnd/6QMBS/1 State: stat/6QMBS/2 OFF Subscribed: cmnd/6QMBS/2 State: stat/6QMBS/3 OFF Subscribed: cmnd/6QMBS/3 State: stat/6QMBS/4 OFF Subscribed: cmnd/6QMBS/4 State: stat/6QMBS/5 OFF Subscribed: cmnd/6QMBS/5 State: stat/6QMBS/6 OFF Subscribed: cmnd/6QMBS/6 State: stat/6QMBS/7 OFF Subscribed: cmnd/6QMBS/7 State: stat/6QMBS/8 OFF Subscribed: cmnd/6QMBS/8

So I'm ever more baffled...

— Reply to this email directly, view it on GitHub https://github.com/darrylb123/usbrelay/issues/75#issuecomment-1002331185, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTSUVMMRJBQ2S7HKDVSNGTUTJGZPANCNFSM5KO7BV4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[dezanche]

Hi Darryl,

on my system I had to add the user usbrelay to the group plugdev

usermod -a -G plugdev usbrelay

because

ls -l /dev/hid*
crw-rw---- 1 root plugdev 237, 0 Dec 23 12:17 /dev/hidraw0

This was preventing it from accessing the device (/dev/hidraw0). Then I changed the User = line in usbrelayd.service back to the original usbrelay, reloaded the config and restarted the daemon and now it's working as it should.

Thanks! Nick

[darrylb123]

What distribution are you using? I'll add that to the documentation.

On Fri, 31 Dec 2021, 8:12 am Nicola De Zanche, @.***> wrote:

Hi Darryl,

on my system I had to add the user usbrelay to the group plugdev

usermod -a -G plugdev usbrelay

because

ls -l /dev/hid* crw-rw---- 1 root plugdev 237, 0 Dec 23 12:17 /dev/hidraw0

This was preventing it from accessing the device (/dev/hidraw0). Then I changed the User = line in usbrelayd.service back to the original usbrelay, reloaded the config and restarted the daemon and now it's working as it should.

Thanks! Nick

— Reply to this email directly, view it on GitHub https://github.com/darrylb123/usbrelay/issues/75#issuecomment-1003197306, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTSUVJTBJSGMHNMMGD2663UTTKOPANCNFSM5KO7BV4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[dezanche]

I'm running Debian GNU/Linux 10 (buster). I downloaded the image for Openmediavault: https://github.com/ayufan-rock64/linux-build/releases/ It's running on a headless Rock64 SBC and I haven't added much to it except in the form of Docker containers

[darrylb123]

Did you us the 50-usbrelay.rules file. It should have made the device rw for everyone. The rules file will start usbrelayd whenever a usb relay is plugged in

[dezanche]

I did use the 50-usbrelay.rules file as described. Is the access controlled by the MODE="0666" statement? Maybe there's a way I can revert and try again, although I'm happy with the system now.

[darrylb123]

Yes, it is. But it means that anyone can operate the relay. I'd be interested in seeing the contents of your udev rules file. Sounds a better solution...

On Wed, 5 Jan 2022, 12:48 pm Nicola De Zanche, @.***> wrote:

I did use the 50-usbrelay.rules file as described. Is the access controlled by the MODE="0666" statement? Maybe there's a way I can revert and try again, although I'm happy with the system now.

— Reply to this email directly, view it on GitHub https://github.com/darrylb123/usbrelay/issues/75#issuecomment-1005336048, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTSUVLJCPBKTNZG7EMOPRTUUOWRLANCNFSM5KO7BV4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[dezanche]

I didn't modify the udev rules files you provided:

root@rock64:~# more /etc/udev/rules.d/50-dct-tech-usb-relay-2.rules 
SUBSYSTEM=="usb", ATTR{idVendor}=="16c0",ATTR{idProduct}=="05df", MODE="0666"
KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05df", MODE="0666"
root@rock64:~# more /etc/udev/rules.d/50-usbrelay.rules 
SUBSYSTEM=="usb", ATTR{idVendor}=="16c0",ATTR{idProduct}=="05df", MODE="0666"
KERNEL=="hidraw*",  ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05df", MODE="0666" TAG+="systemd" ENV{SYSTEMD_WANTS}="u
sbrelayd.service"

I ran the usermod command above once as root. Indeed, there might be a more elegant solution but I don't really know how these udev rules files work.

[darrylb123]

Ah, of course. You should only have one udev file. Remove the first file.

On Sun, 9 Jan 2022, 7:55 am Nicola De Zanche, @.***> wrote:

I didn't modify the udev rules files you provided:

@.:~# more /etc/udev/rules.d/50-dct-tech-usb-relay-2.rules SUBSYSTEM=="usb", ATTR{idVendor}=="16c0",ATTR{idProduct}=="05df", MODE="0666" KERNEL=="hidraw", ATTRS{busnum}=="1", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05df", MODE="0666" **@.**:~# more /etc/udev/rules.d/50-usbrelay.rules SUBSYSTEM=="usb", ATTR{idVendor}=="16c0",ATTR{idProduct}=="05df", MODE="0666" KERNEL=="hidraw", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05df", MODE="0666" TAG+="systemd" ENV{SYSTEMD_WANTS}="u sbrelayd.service"

I ran the usermod command above once as root. Indeed, there might be a more elegant solution but I don't really know how these udev rules files work.

— Reply to this email directly, view it on GitHub https://github.com/darrylb123/usbrelay/issues/75#issuecomment-1008160991, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTSUVL7N2NKQWTJGSMJ3YDUVCXFFANCNFSM5KO7BV4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>