Espeasy: Multiple rotary encoders, only one works and alters both values

[oetelaar24]

I tested with a build from ESP_Easy_mega-20180504_normal_ESP8266_4096 and ESP_Easy_mega-20180606_normal_ESP8266_4096 on a Wemos D1 mini 4MB v3.0.0

Summarize of the problem/feature request

The problem is that when I specify two rotary encoders, only one works, and the one that works changes both values..
I've connected a KY-040 encoder to 3.3v and GND, and connected
A (CLCK) --> D6
B (DATA) --> D7
Switch. --> D2
Then connected a second KY-040 encoder to 3.3v and GND, and connected
A (CLCK) --> D3
B (DATA) --> D4
Switch. --> D5

Expected behavior

I expect both encoders to work separately and control only there own value. Turning the knob changing the value accordingly

Actual behavior

Turning the knob on the second encoder controls both encoders value, I see the following messages in the log:
1263321: QEI : 203
1263324: QEI : 204
1263421: QEI : 206
1263721: QEI : 211
The values also get pushed through to MQTT, for both encoders.
Turning the knob on the first encoder has no apparent effect.
Using the pushbutton of the encoders works as expected.

Only one encoder has to be physically connected to see this behaviour

Steps to reproduce

1. Specify two rotary encoders in the devices section
2. Connect one or two of them
3. Turn both knobs and see the outcome

Yes

Restarted, reflashed, powered down for days, no effect.

System configuration

Only OpenHAB specified for pushing MQTT info to mosquitto
Hardware:
Wemos D1 Mini V3.0.0

ESP Easy version: ESP_Easy_mega-20180606_normal_ESP8266_4096

ESP Easy settings/screenshots:

I hope this is enough information. Please let me know if you need more. Would be awesome to have this working. I'm trying to build a WiFi dimmer controller with 1 wemos and 2 encoders :-)

[papperone]

due to the recent many problems reported I woudl say we have a generic issue in handling properly multiple istances of the same plugin/device...
I think some guidelines shoudl be providede how to properly design a plugin to make it works in multice istance ( I do face the same issue with my 7-Led segment plugin and still need to understand the causa)

[TD-er]

Well it is not really recent, since I already fixed a number of them.
But I agree there should be a more generic approach for storing plugin-specific data per task-id.
I was trying to start some initiative with the ultra-sonic plugin, but that one crashes apparently and I haven't got time yet to have a look at it.
It could be both using the same pin, or some silly mistake I overlooked.

[flashtel]

Hi, I just got the same issue with 2x Rotary Encoder, quick google search has brought me here. I'm pretty sure it is broken. Thanks Paul

[TD-er]

Yesterday I added a pull request for the same problem with Ultrasonic distance sensor.
If that seems to work, then I will do the same for all other plugins, including this one.
The main problem is that plugins must store some internal values to keep their state. If using the same plugin more than once, those state variables are shared.

[flashtel]

Thanks for the update

Sent from my iPhone

On 10 Jun 2018, at 3:14 pm, Gijs Noorlander [e-mail] wrote:

Yesterday I added a pull request for the same problem with Ultrasonic distance sensor.
If that seems to work, then I will do the same for all other plugins, including this one.
The main problem is that plugins must store some internal values to keep their state. If using the same plugin more than once, those state variables are shared.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[papperone]

@TD-er can you please share more details on the right approach to properly handle multiple istances of the same plugin? I'm updating the 7DGT with the new functions requested in the forum (almost done so I shoudl be able to PR later today) but I'm still struggling to get multiple displays work together... :(

[TD-er]

My idea is to have the instance-specific (temporary) data in a separate struct and then use a std::map to store these.
As key to access it, you may want to use the task-number or something that has to be unique for that instance like the I2C address.

Don't forget to delete pointers in such a struct when you create them using new in the destructor of that struct and initialize all members in its constructor.

See for example:

https://github.com/letscontrolit/ESPEasy/blob/c8ee7976ccb2975d393b1ab246a88fcd9d1c9c82/src/_P013_HCSR04.ino#L15-L32

[papperone]

ok interesting to read, will give it a try... is above method being tested and confirmed working within ESPEasy framework?

[TD-er]

It is confirmed that keeping track of separate values like this works (see also BME280.ino), but for the Ultrasonic plugin, there seems to be some issue with reading, which is very likely related to something else.
I showed the ultrasonic plugin as an example because it uses a really simple struct and a pointer to keep some other object. (and thus needs a delete in the destructor)

Just keep in mind accessing an item in a map may give some overhead, so try to minimize the number of calls to find in the map (operator[]) and try to do it once in a function when you need it more often. (again see BME280)
It is a bit hard to hand over these structs to a function call as a (const) reference (using & ) since the Arduino environment then needs to have the struct and all functions using it to be forward declared.
It is not like C++ where you have .h files to do that.

[oetelaar24]

Thanks for your comments, ideas and solutions.
@TD-er , can you update us on the current status?

Thanks again!

[TD-er]

Today I had very little time to spend on espeasy (just got home from domotica meetup :) ) and tomorrow evening I have another appointment also.

Last few days I spent on another bug which I found that affects almost all time critical issues and almost all my Dev time went into that issue.
So at this moment I have not really an update on this one.

[Grovkillen]

Just as input. This one look nice
https://www.cnx-software.com/2018/07/03/multiple-rotary-encoders-to-arduino-esp8266-raspberry-pi/

[oetelaar24]

That does look nice, however, with the espeasy plugin working correctly, it would be easy to connect 3-4 encoders to a wemos :-)

[oetelaar24]

Hi @TD-er , I realise you are extremely busy with fixing a lot of bugs and feature requests, so I would like to know what I can do to maybe compile my own version of ESPEasy with the fix in it? I do know a little bit about programming, but it was some time ago I did it professionally, so I'm rusty at best :-)

Thanks in advance!

[mikester273]

Following this and the linked issues closely as I started a project with two encoders a year ago and encountered the behavior discussed above. I do not have enough programming knowledge to be of any assistance but I look forward to a fix and am grateful to you all for a really great project. Thanks!

[TD-er]

Should be fixed when PR #1932 is merged.
Can someone test the PR before I merge it?

[oetelaar24]

Yes! It works very well! 💯 🥇

[TD-er]

Great, then I will merge it
Thanks for testing.

[flashtel]

This just made my day.

Thank you so much, very much appreciated.

Paul

On 23 Oct 2018, at 1:58 am, Gijs Noorlander [e-mail] wrote:

Closed #1486 https://github.com/letscontrolit/ESPEasy/issues/1486.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/letscontrolit/ESPEasy/issues/1486#event-1918141158, or mute the thread https://github.com/notifications/unsubscribe-auth/AQZtozgvUNTyY2_0UmVHAW3EldAUCw3uks5ungcsgaJpZM4Ue0zo.