Well anyway, it does work now. lsusb shows the product id is now "0921", and Ekos recognizes the device and can loop in guiding to get images. No idea why it's working.

I don't know why that error shows up in the logs indicating that fxload failed. The argument for -D is supposed to be "$env{DEVNAME}", and the fact that it's an empty string certainly seems wrong since every rule in /lib/udev/rules.d/85-qhyccd.rules has the same command argument, which makes a person think it's important...

I grep'd all .rules files on the system and the only one specifying vendor ID "1618" and product ID "0920" is the QHYCCD ruleset under /lib.

So, something else must be loading the firmware, or otherwise hooking the device up? Mystery to me...

Have you also checked /etc/udev/rules.d? Any rules there that match 1618:0920?
udev does not stop with the first matching rule it finds. It executes all of them.
I suspect it finds two rules: one with the error and one successfully loading the firmware.

Hello Oduig,

After looking at several non related issues, I have learned a few things about rules and Ubuntu-Mate. As for the QHYCCD brand of devices, I think I will create a distinct QHY5L-II rule. This prevent the blow out of any KSTARS rule overwrites.

The rules for QHYCCD are INDI-QHYCCDcamera.rule and INDI- QHYCCD.rule. A # is a comment field. The QHYCCD rule has many lines commented out. After reviewing the models, 1618:0921 is not listed. 1618:0920 is listed.

1618:0941 is the PoleMaster. 1618:0940 has a rule. None exist for 1618:0941.

If wildcard is used, then like families of devices would be working. I used a wildcard in getting another USB device to work. That was assigning a TTY port.

I added rules to the default QHYCCD rule files for the missing products that I have. Only one problem exists. The fxload and the -D (devpath) is pretty important. The OS refuses to load QHY5II.hex. This is fx3load being called out.

I will create a custom QHYCCD rule for the two newer devices not supported yet. This should cover me. I would like to know why the -D option is required for UBUNTU- MATE. Usbfs is an old distro of linux. All other QHYCCD models have -D blank.

I grep'd through the rules under /etc/udev/rules.d. There are only 3-4 files there, one of which I put there to assign fixed serial port names to my focuser and telescope.

I did a "sudo find / -name '*.rules' -print" to make sure there weren't unexpected places where rules files were lurking. This correctly found all the rules files under /etc/udev and /lib/udev, as well as under the INDI git repo clone, and no other places.

I've reading about the "udevadm monitor" command this morning. Might this be useful to seeing what's going on when the camera is plugged in? "udevadm test" might be useful, too...

Hello CRW4096,

Yes. Udevadmin looks like a good place to find DEVPATH. The device path is needed with the rules. This tool is the way to get it.

Hello,

Success! I have both QHY5L-II and PoleMaster recognized by EKOS. I created custom rules from 85-QHYCCD.RULES and 85-QHY-CAMERAS.RULES. I preserved the original files in a specific folder. I updated the rules and rebooted the PI. EKOS picked both devices up using Device Manager.

What are the contents of the 2nd file?

@AradoSKYindi:
Where are the INDI-QHYCCDcamera.rule and INDI- QHYCCD.rule coming from? The original INDI 3rdparty drivers come with a QHYCCD rule file called "85-qhyccd.rules".
In this file both pairs 1618:0920 and 1618:0921 can be found. For the first pair the firmware is loaded with the help of "fxload". Then the QHYCCD device renumerates and comes back as 1618:0921, which triggers the second rule which just sets the permission to read/write for everybody.
Same holds for 1618:0940 and 1618:0941.

Ideally there should not be any tinkering necessary with the rules files. I was suspecting that maybe another package or manual editing interfered with the original rules files.

Also a -D without an argument does not make sense. Something must be wrong there.

CS
Guido

@AradoSKYindi:
You have both 85-QHYCCD.RULES and 85-QHY-CAMERAS.RULES?
Maybe one is a leftover from an older install or different package.

Ah, I see, Jasem also wonders what is in the second file...

CS
Guido

Hello,

I downloaded AstroBerry from this site. Whatever is in the default package is what I have. I have since upgraded to Ubuntu-Mate 18.04.

The following are my two QHYCCD components that EKOS could not see after a KSTARS update. 1618:0921 is the QHY5L-II. 1618:0941 is the PoleMaster. I looked in /etc/udev/rules.d and found 85-QHYCCD.rules and 85-QHY-CAMERAS.rules. I searched both files for my hardware. I found older revisions 1 digit off.

I did notice a large section of Vendor provided stuff commented out. I looked for QHY5II entries. The family resemblance was 1 digit off. So, I decided to save off the originals, then pare down the file to put the Action and ATTR for both models. I also included turn off MTP check and and check not related to the devices.

I created an 85-QHYCCD-local.rules and an 85-QHY-CAMERAS-local.rules. This will keep my specific needs from being overwritten. I installed the rules , rebooted, and KSTARS worked. In fact, both products appeared under QHYCCD.

Hello Oduig,

My version of both original rules files did have 0920 and 0940. The lone 0921 was commented off. No ACTION commands to FXLoad anything were attributed to 0921 or 0941.

I added/changed my files to focus exclusively on my two QHYCCD products. Both files are needed. One contains code. The other contains configuration settings. This worked.

Be aware that udev executes ALL rules that match. Not only the first one.

However if the same rules filename exists in /etc/udev/rules.d and /lib/udev/rules.d only the one in /etc is used.
That allows you to disable rules files from /lib by creating symlinks to /dev/null under the same name in /etc, without interfering with the rules files installed by packages under /lib, who are subject to being updated.

Guido