[feauture request] Add function "rotary raw" to rotary encoder

[hawa-lc4]

Hi everyone,
I'm using rotary encoder (type KY-040) in several environmental related projects as a control element to set temperature or humidity values but not as a slider to control light.
The current implementation of rotary encoder is aligned to set light values which have limits (e.g. from 0% to 100%) and fixed rotary steps which can be set. My need is no fixed lower or upper limit nor a step boundary for all this varies on the settings needed individually in the certain project.

To fit my needs I've modified the "support_rotary.ino" file to report the raw information about the rotary changes regarding up or down and whether button is pressed or not. This information is published using MQTT and can be used in scripting or rules.
My changes are based on support_rotary.ino (version 14.1.0.2) and have an additional parameter "ROTARY_RAW" to be defined in user_config_override.h controlling whether the option is used or not.

The coding adds the following lines to "tasmota\tasmota_support\support_rotary.ino"
(@@ -263,0 +263,4 @@ void RotaryHandler(void) {):
#ifdef ROTARY_RAW
Response_P(PSTR("{\"Rotary%d\":{\"Btn\":%d,\"Pos\":%d}}"), index +1, button_pressed, rotary_position);
MqttPublishTeleSensor();
#endif // ROTARY_RAW

Please let me know your opinion on this idea and thank you for considering.

Günter

[sfromis]

You do not need any new payload for using the rotary in rules instead of controlling a light, as this is already supported, selected via SetOption98

Here's an example of how you can get values from a 16-position rotary

Rule1 on Rotary1#Pos1 do var1 %value% endon on Rotary1#Pos2 do var2 %value% endon
Backlog SetOption43 16; SetOption98 1; Rule1 1

And here's a trick if you just want increment/decrement instead of a value. Asking for a one-value rotary effectively produces a direction:

Rule1 on Rotary1#Pos1==1 do var1 Incremented endon on Rotary1#Pos1==0 do var1 Decremented endon
Backlog SetOption43 1; SetOption98 1; Rule1 1

However, these values available to triggers are not pushed as series of console/MQTT messages.

And a bit of hair-splitting.... You ask for "raw", but the rotary does not have any raw position, only direction ticks. The bounded position is a feature on top of the raw input.

Looks like you did not read the docs about using a rotary encoder....
https://tasmota.github.io/docs/Rules/#use-a-rotary-encoder

[hawa-lc4]

@sfromis
Thanks for your quick response here.
To be honest, I'm aware of the docs article you mentioned but did not read it fully for I usually only use scripting language. I find it more flexible than using rules, it allows more complex coding and ESP8266 doesn't support Berry scripting either.
SetOption98 seems to be valid for rules only, isn't it? Or is there something similar to be used in scripting language?

My expression "rotary raw" may be misleading but it was the best name that came to my mind when working on that.
I also remember to have read an discussion or issue article about this topic where this expression was used, but I'm not able to find this one again. :(

Edit: maybe SetOption43 set to "1" as per your rules example does the trick..... (to be evaluated :)

[sfromis]

No, SetOption98 is not for rules only, it is to provide a JSON payload, just not published via MQTT. I've also used it with Berry, and I'd clearly expect it to also work with scripting, for the JSON payload mentioned in the docs I linked. Other JSON payloads from Tasmota tends to work there too....

Since your suggestion specifically mentioned "and can be used in scripting or rules", I was not guessing that you already knew of it being available with rules, if you even tried to use the same with scripting, or if you saw any issues other than not knowing if it might also work with the scripter.

As a base feature of Tasmota, most docs relate to using rules, without explicitly also mentioning what you can do with the scripter optional feature, hence the wording "rule trigger" does not mean only rules. Most of what you can do in rules can also work with the scripter, when it is not a specific feature tied to the rules language syntax.

My "trick" with SetOption43 1 lets you get the direction, but if you also want a counter, that's up to you to manage.

[hawa-lc4]

Thank's for your clarification on the effects of SetOption98 regarding rules and scripting language and the meaning of Tasmota docs regarding "using rules" in common. For me it sounds in most cases like a "the one OR the other" but not both in similar way.

I've tried already with SetOption98 but failed. So I'll have to go back to my workplace again and check why I've failed querying the JSON response correctly.

[sfromis]

Rudimentary test case:

>D
pos=0
>E
pos=Rotary1#Pos1
print %pos%

When it comes to SetOption43 1 for only direction, that technique does not work for distinguishing between Pos1 and Pos2 (button pushed), as the triggering position update will be the same min/max value when twisting further in the same direction.

[hawa-lc4]

Back to this issue:

• basically things are working as you explained using SetOption98 ON together with SetOption43 1.
• the test is really only a very rudimentary way to check the information needed can be queried.
  However many commands issued in script or even during a restart trigger the event even no changes have been done to the rotary encoder itself causing the parameter in scope changes randomly up or down depending on the last information given by the encoder.

Conclusion: please forget about my request.