Hello
great job
Could you compile CH341.ko?
Here is the driver: GitHub - juliagoda/CH341SER: CH341SER driver with fixed bug
CH341SER_LINUX.ZIP - 南京沁恒微电子股份有限公司
i have a DS720+ i think the driver must be the same as the DS918+ (intel celeron)
I would also be interested in having the cp210x.ko
thank you
DS720+ is geminilake, not apollolake. I don’t know how (in)compatible those platforms are, but my guess is that an apollolake-compiled version should work fine.
I’ll take a look at the ch341 driver, the (apollolake) cp210x.ko is here: cp210x.ko · GitHub
Let me know if it loads, otherwise I’ll have to set up a geminilake crosscompile environment.
Thanks for helping me
I’m not in DSM 7 to try, I’m too afraid to lose my zigbee2mqtt.
If it doesn’t work it’s complicated to go back to DSM 6.
I can compile the ch341 module that comes with the Linux kernel source just fine. I don’t think I have any CH341 devices laying around to test it on, though. The module you’re pointing to seems very outdated, it doesn’t compile, but it’s likely the included one will work.
I’ve set up a proper Github repository for modules and packages: GitHub - robertklep/dsm7-usb-serial-drivers: Synology DSM 7 USB serial drivers
1 Like
Can you make some for geminilake?
thanks
This topic is for ZWave - you can check this one in regard to Synology and VMM.
Mmm. I’m on 920+ with dsm7. At times my conbee2 stick gets removed from the VM settings even when there is not reboot. It can happen after a few hours. At times it will last for days before it disappears.
Can’t seem to find out what is causing it. Only notice it when I can’t control my lights and have to go to settings to add it back
I’ve seen someone else having the same error on my Discord server. Not using Conbee II, but error looks the same. Not sure why this would happen. Did you try rebooting Synology?
@robertklep I see that you used the 25426 branch which is not the version of the kernel that runs on the original released DSM 7.0 (there you have linux 4.4.59 and DSM 7.0 comes with 4.4.180; at least that what I can see on my DS718+).
Not sure how you convinced the module to load if the versions are different.
Did you tweak the Makefile manually and changed the version? Or it just worked also with a different version.
I’ve tried to cross compile the kernel from the 7.0 Beta folder and that one was even older and surely it did not load.
I only extract the relevant driver files from the sources on Sourceforge, the actual crosscompilation is done against the official Synology DSM 7 toolkit for the different platforms (as explained here).
So basically, I’m taking the driver source file from 4.4.59, but it’s compiled against 4.4.180 (at least, I assume that’s what the toolkit uses, I’m haven’t really looked at the specifics on how the crosscompilation process works 
).
I don’t think the sources for the actual current branch (41890) are available (yet).
By the way, I’m not compiling the actual kernel, just the two USB serial modules, using this project as a template: GitHub - SynologyOpenSource/HelloKernel: This is synology example package for cross-compiling kernel module.
I experienced this on DSM6 when i had to reboot the vm - but not always only sometimes …
That is te reason why I have my conbee connected to the docker container from Marthoc. That works 100% of the time.
It is also the reason that I’m not upgrading to DSM 7. To much uncertainty
Had some time today and figured why it worked. You basically used the old kernel files (the modules themselves) and compiled them (cross compiled) for the platform without using any kernel version information. And because the modules likely did not change (or better said the system calls in the modules are the same in the 4.4.59 and 4.4.180) and the kernel cannot check the module version (actually it just throws a warning that kernel version information is not present in the module) then it just works loading it.
Still waiting for Synology to publish the real kernel sources so I can properly compile them.
PS: A small tip for who wants to load @robertklep modules with modprobe: You need to run depmod -a but that is not present (at least not on my NAS). It is enough to create a symlink called depmod towards the real executable called kmod and then you can run it. That will allow you to use modprobe instead of insmod (which will load all the other needed kernel modules automatically, ie usbcore, if that is not loaded already)
2 Likes
Hi @jprates
Did you already upgrade to DSM7? If so - did your Aeotec Gen5 stick start to work out-of-the-box or you had to add these startup scripts provided by Carsten? I mean these ones
I’d really like to upgrade to DSM7 for a couple of reasons, but I’ll wait until the dust on DSM7 settles and the USB topic is clear.
I think if we don’t have USB support from Synology - adding it on our own may be risky as they may somehow cut it down with some DSM 7 upgrade and these solutions may stop working for good at some point.
Let me know how it went. I’ve got the same ZWave stick as you.
Thanks!
It worked out of the box, no scripts needed whatsoever, its working fine ever since the upgrade.
1 Like
Nice! Great to hear that. ZWave is my only show stopper for migrating to DSM7. Thanks for letting me know!
Oh maybe one more question: are you running HA within VMM or in DSM Docker?
Virtual Machine.
You’re welcome, glad to assist.
1 Like
After rebooting then, it’s been 24 days and never had any disconnection issues on the DSM7 so far.
1 Like
I believe the topic is clear: Synology stopped supporting these devices, and the community has to find its own ways to get them working again.