I’ve just upgraded to v2.5.8 by means of a new installation from openhabian v1.5. I use a text based config so it’s pretty quick to get most things up and running but I noticed that two of my USB connected devices (Alarm Decoder and RFXCOM) were not working. Looking in /dev, I can see that they have symlinked to gpiochip3 and gpiochip4 rather than ttyUSB0 and ttyUSB1.
There are posts on other forums that talk about broken symlinks with Buster but I’ve used openhabian v1.5 a few times and not encountered this problem before.
I appreciate that this is a Linux rather than an openHAB problem but as a community, I would think this members of this forum make more than average use of external devices so hoping someone has a solution.
Have you tried to edit /etc/udev/udev.conf and add udev_log=debug . Then restart udev with systemctl restart udev . I would expect to see information about the udev rules in the linux systems log file then.
Thanks. I used the same 10-local.rules file I’ve used before. The symlinks in the file are shown in /dev but they are linked to the wrong devices.
Although I have updated /etc/default/openhab2, I don’t think that is where the problem is because that contains the environment variables for java accessing the ports but the ports aren’t properly defined in Linux.
Thanks. I gave that a try, including a reboot but whilst there are lots of udev entries in various log files (syslog, debug, messages etc) nothing that refers either to the symlinks or any of the device IDs.
First please rename your rule file in case it contains only your local rule so that it contains the number 99 instead of 10. In case it contains system default values as well create a file that contains your own rules only and give it a name starting with 99. Rules are executed in their number order. The higher the number the later the rule will be executed and the higher the chance that the rule will not be overwritten/overruled by another rule.
Try to use a debug command instead of the symlink rule to see that/if your rule is executed
Change e.g.
This should create a file under /tmp once the rule is triggered. As the symlink action is not included the wrong link shall not be created. If it is still there there must be another rule.
Please share your udev rule.
To find all relaed entry / files that have entries you can run
find /var/log -type f -exec grep -l idvendor {} \;
the option to grep is a lowercase L.
Please replace idvendor with the string you use in your udev rule.
The output will list all files where the idvendor is being found.
Then you manually need to open the files.
To can leave out the option -l then all found matching rows will be shown.
Hi I had same problem with my new Buster that it it wasn’t working
But thank good to Dougie Lawson, see the link below. his proposal was to do this:
Run sudo apt update; sudo apt dist-upgrade -y and see if today’s new kernel works better for you.
And it worked magically for me, so I can use my Domoticz which has 3 different USB devices. I just created the user to post this message as I could only find this below to solve the symlink error
Run sudo apt update; sudo apt dist-upgrade -y and see if today’s new kernel works better for you.
@Wolfgang_S Thanks for the support. Results as follows:
There is one other file in rules.d, which was 99-com.rules. I renamed that to 98-com.rules and then tried my rules files as both 97-local.rules and 99-local.rules and had the same problem both ways around.
I then changed the rules as advised. The symlink is not created so mine must be the only rule that creates is. It did successfully create the file.
A quick note on the names of the symlinks. The alarm decoder one worked because that was a v1 binding. The others didn’t work with v2 bindings if they were “unusual” names. I now know about the environment variables so those will be updated to more useful names once I get over this problem.
Interestingly, the zwave symlink always works correctly.
I have now added SUBSYSTEM==“tty” to the rules.
At first I added it to just the alarm decoder rule and all rules three worked but I’ve had it before where the rules work randomly and when I tested it again, the RfxCom rule didn’t work.
I have now added it to all three rules, renamed the file back to 10-local.rules and tested it twice.
Results:
Alarm decoder and RfxCom rules are now reliable. I had to change the Zwave rule back because it wouldn’t work being called /dev/zwave, with or without the SUBSYSTEM==“tty”. Looks like that’s an openhab thing because the symlink was working.
@bjacobse Thanks for the tip. I had seen this on other forums. I am loathed to upgrade part of a package because it often causes as many problems as it solves. After all, the symlinks only broke because I did an upgrade to get an openHAB release that included the new Drayton Wiser binding!
