Ok - that confirms my suspicion: the problem is not the plugin. Since the driver is in the Linux Kernel for several years already, I also do not think that is a Kernel level driver issue.
I updated the readme.md for the plugin yesterday and maybe you can additionally try to follow the updated instructions there. Instead of using cat I replaced it by od, which allows us to actually see the binary data sent by the Kernel driver in hex:
od -x -w32 /dev/input/by-path/platform-rotary\@4-event
After issuing this command, you should get one line of output for every “tick” of the encoder.
But I think the actual problem is somewhere in your hardware. Hardware is difficult to diagnose without a multimeter or even better an oscilloscope (since a multimeter is slow and will not show you transitions of states).
I do not own a KY-040, but from what I see on the web, it is basically sold on Maker-Webshops and is probably coming from some Chinese companies under different brands. I did not find out, what rotary encoder is actually used, so there may be different versions available. As I mention in the readme, the KY-040 is basically a standard rotary encoder with two pull-ups for the two rotary channels already included.
If you get output from cat only after 2 turns and then after 15 turns, that must have something to do with poor digital signal, broken rotary or a problem with the GPIO hardware. The rotary is a very simple device - it is basically just 3 switches (two rotation channels CLK/DT and one push-button). Depending on the type and the number of detents per rotation both rotational channel switches should open and close several times (10-30) within a single rotation. In your case this does not seem to be the case.
The difference between the two plugins is basically the speed of reaction on interrupts, as far as I can see and a better gray code logic in the Kernel driver. So I assume, that the Kernel driver is interpreting your signal as a problematic/bouncy input and not reacting on most of the events. The onoff_rotary does not have a lot of fancy gray code verification and may still operate with problematic signals. BTW: another difference is that you are running the old plugin on Volumio 2 (Jessy) and the new one on Volumio 3 (Buster). There may be subbtle differences due to the OS as well - I’ve seen weak Power-Supplies slightly drop voltage with different OS versions and a usual USB-Charger with 5.0V is actually already supplying too low voltage to the RPi which may decrease your 3.3V already (look for the brown-out warnings of the RPi).
Some questions:
- Do you have a multimeter or oscilloscope? Then you could measure the voltage at the Pins 4 and 27 and see if it changes when dialing.
- Do you know the following info for KY-040 (maybe @Mr100000Volt can help us here):
2.1 Number of detents per rotation of KY-040?
2.2 Correctsteps-per-periodsetting? (see here for details)
2.3 Value of the resistors in the KY-040 board (I found 200Ω online)? (According to online sources, GPIO 27 is internally pulled low by default and if that is true on your RPi and the external PU of the KY-040 is not matching, then it could be, that the voltage on the GPIO is below the required V_IH of 1.6V as in this example for external PD and internal PU). Maybe you could try to connect to GPIO 5 (internally pulled up) instead of 27? If the external pull-up is larger than the internal pull-down (>50kΩ), the voltage at the input with open rotary switch will be lower than 1.6V. - Did you try to set
steps-per-period=2or4instead of1? Here it looks like it is a SPP=2 rotary. If you use SPP=1 then you will already need 2 ticks for one step.
I think something with option 2 is most likely - it could explain, why you sometimes get an event (because the voltage may vary around 1.6V). It could also be caused by a cold solder joint or a too thin or squeezed cable - anything that increases the pull-up resistance significantly and thus reduce the voltage at the GPIO.