I made a script in /etc/udev/rules.d/local.rules
SUBSYSTEM=="usb", SYSFS{idVendor=="b58e"}, SYSFS{idProduct=="9e84"}, ACTION=="add", RUN+="notify-send USB"
I then reload udev with
sudo udevadm control --reload-rules
I've tried to remove everything but subsystem and run. I've tried the run '=' instead of '+=', I've tired ATTR instead of SYSFS. I tried "sudo service udev restart" and "sudo reload udev". I unplug the device, then plug it in again and it does not run the action. I tried renaming it 70-local.rules and changing permissions to a+x. I've tried changing 'subsystem' to 'bus'. I've tried setting run to be "/path/test.sh" which has the same command.
I'm not an expert and this isn't an answer, but I've found the following steps useful in identifying the appropriate attributes to trigger on:
udevadm, lsusb, or usb-devices. I normally just use lsusb and let tab completion in my shell guide me. In my case, the path is /dev/bus/usb/003/007.udevadm to identify the device attributes for rule writing. In my case, I used udevadm info -a --attribute-walk --root --name=/dev/bus/usb/003/007.ls -l /dev/bus/usb/003/007. My rule for this case looks like: SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", OWNER="stephen". I have a similar rule that puzzled me for a little while because the subsystem was expecting ATTRS not ATTR, which is why I recommend walking the attributes. The rule in this latter case became: `SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", OWNER="stephen".And, of course, man udev is always helpful. As you said, you should struggle to identify that your rule is triggering properly and may be best off just doing a quick ownership change on the device as I did for a first step. You can run into trouble with bad attributes or symbolic links sometimes and it's
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With