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, orusb-devices. I normally just uselsusband let tab completion in my shell guide me. In my case, the path is/dev/bus/usb/003/007.udevadmto identify the device attributes for rule writing. In my case, I usedudevadm 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 expectingATTRSnotATTR, 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 udevis 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