Rademacher USB stick timeout when activating pairing mode (green LED is constantly blinking)

[homemation]

Hello,

thanks for all your great efforts for bringing great functionality to the world!

Done so far:

Followed your manual to for udev using the serial. Reinserted the stick: alias works

Issue:

Initializing the stick with "duofern_cli.py --code <your chosen 4 digit hex code here>" shows "Permission denied for TtyS0". Can be fixed with chmod a+rw. -> then works. However I don't get why this is necessary (and it's also not pointed out in your manual). When starting pairing mode with "duofern_cli.py --pair --pairtime 60" then following exception is thrown: entering pairing mode Traceback (most recent call last): File "/home//.local/bin/duofern_cli.py", line 301, in stick._initialize() File "/home//.local/lib/python3.7/site-packages/pyduofern/duofern_stick.py", line 550, in _initialize raise DuofernTimeoutException("Initialization failed ") pyduofern.exceptions.DuofernTimeoutException: Initialization failed

Please note that the stick is constantly blinking the green LED. When insterted for few seconds the red & green LEDs are constantly on, then only the green LED is blinking and the red one is off.

THANK YOU SO MUCH FOR YOUR SUPPORT!!!

[gluap]

@homemation the permissions of serial devices strongly depend on the linux distro you're using, so I only covered what I had to do on my system when I wrote the document. If it's a multiuser system i'd stay away from a+rw - everyone get's access to the device that way. On some distros you can gain write permissions to serial devices by adding yourself to the dialup group, but as it depends on the distro I won't cover that in detail in the docs.

The log (as well as the stick blinking constantly, normally it should settle after initialization) seems to indicate that pyduofern never manages to talk to your stick. Two issues people have had in the past that would match your problem description:

• Used the wrong stick - There seem to be different sticks from rademacher, not all of them duofern. Someone bought a different stick, iirc it was zigbee or z-wave, neither will work with pyduofern. - Looking at lsusb -v infos should give you an indication of whether you have the right stick.
• Spoke to the wrong USB Device - Your Log seems to indicate that you were connecting to ttyS0, which is often a builtin serial port while the duofern sticks almost always register as ttyUSB0 or some similar device name. But this naming is also distribution dependent so hard to judge based only on the name. I'd suggest to double-check that the device you udev'ed really is your duofern stick.

[homemation]

Thanks for your quick reply and your suggestions!

The stick I use is according to its sticker a 70000093.

Here some output of udevadm: KERNELS=="4-4" SUBSYSTEMS=="usb" DRIVERS=="usb" ATTRS{removable}=="removable" ATTRS{devpath}=="4" ATTRS{tx_lanes}=="1" ATTRS{idProduct}=="6001" ATTRS{bDeviceSubClass}=="00" ATTRS{rx_lanes}=="1" ATTRS{authorized}=="1" ATTRS{ltm_capable}=="no" ATTRS{bConfigurationValue}=="1" ATTRS{idVendor}=="0403" ATTRS{avoid_reset_quirk}=="0" ATTRS{configuration}=="" ATTRS{bMaxPower}=="90mA" ATTRS{bDeviceProtocol}=="00" ATTRS{maxchild}=="0" ATTRS{urbnum}=="3227" ATTRS{bNumConfigurations}=="1" ATTRS{serial}=="...my serial..." ATTRS{quirks}=="0x0" ATTRS{busnum}=="4" ATTRS{manufacturer}=="Rademacher" ATTRS{bMaxPacketSize0}=="8" ATTRS{bcdDevice}=="0600" ATTRS{bmAttributes}=="a0" ATTRS{version}==" 2.00" ATTRS{devnum}=="8" ATTRS{speed}=="12" ATTRS{bDeviceClass}=="00" ATTRS{bNumInterfaces}==" 1" ATTRS{product}=="DuoFern USB-Stick"

Is there a possibility to get verbose logging from the stick? Somewhere I've read about ATTR debug verbose, but didn't get how to enable...

BTW: This is the Linux I'm using: SMP Debian 4.19.181-1 (2021-03-19) x86_64

Thanks again!

[gluap]

you can run the cli with --debug to get more verbose output.

The udev configuration above looks good, the question is whether pyduofern actually talked to that device. Above you wrote:

Initializing the stick with "duofern_cli.py --code <your chosen 4 digit hex code here>" shows "Permission denied for TtyS0".

I would expect this to say "Permission denied for duofernstick" if it had failed to talk to the duofernstick device node created by the udev steps. (or something like that, but not ttyS0)

If you run duofern_cli with --help it will display the help.

You might want to try --device=/dev/duofernstick as one of the arguments.

[homemation]

Thanks for your hint!

I've explicitely granted permission for dev/duofernstick, but still not luck... As the stick is always constantly blinking, I suspect it's something wrong. When I tried it for the first time, it had version 2.0. Now it was updated via Homepilot 2 device to 2.2. Probably it has to do with it?

This is the output for the command:

duofern_cli.py --device=/dev/duofernstick --pair --pairtime=60

The following devices are configured:

entering pairing mode Traceback (most recent call last): File "/home//.local/bin/duofern_cli.py", line 301, in stick._initialize() File "/home//.local/lib/python3.7/site-packages/pyduofern/duofern_stick.py", line 474, in _initialize self._read_answer("INIT1") File "/home//.local/lib/python3.7/site-packages/pyduofern/duofern_stick.py", line 459, in _read_answer response = bytearray(self.serial_connection.read(22)) File "/home//.local/lib/python3.7/site-packages/serial/serialposix.py", line 596, in read 'device reports readiness to read but returned no data ' serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

[gluap]

IIRC the stick blinks when plugged in until it is initialized. So I agree: Blinking means something is wrong.

The error seems to indicate that the stick disconnects before even responding to the first package sent by pyduofern.

This could be due to a change of protocol as a result of the upgraded firmware as you suggest - but also indicate that something is amiss in the serial setup, or even with the USB port used.

[gluap]

Closing as this is not active at the moment and likely specific to the setup discussed. feel free to reopen.