Rotary encoder to display update performance

[ChestersGarage]

Hello All,

I have some configs that are not performing as well as I had hoped, and I'm looking for some help with maybe changing my implementation to improve performance.

I'm currently using rules to translate the input of my rotary encoder to a dimmer value, and update the screen for each encoder step.

This works and has the best functionality - keeping the text centered and using OFF and HIGH for 0% and 100% respectively., but screen update rate is around three-quarters of a second, and all the encoder steps are buffered and continue counting off long after I have stopped rotating the encoder - unusable for my case.

Rule1
ON Rotary1#Pos1 DO IF (%value%==100) DisplayText [zs4x20y20]HIGH
ENDIF ENDON
ON Rotary1#Pos1 DO IF (%value%>9 AND %value%<100) DisplayText [zs4x30y20]%value%%
ENDIF ENDON
ON Rotary1#Pos1 DO IF (%value%<10 AND %value%>0) DisplayText [zs4x40y20]%value%% 
ENDIF ENDON
ON Rotary1#Pos1 DO IF (%value%==0) DisplayText [zs4x35y20]OFF
ENDIF ENDON
ON Rotary1#Pos1 DO Channel1 %value% ENDON

I also tried using a string of IF-ELSEIF-ELSE conditions instead of a bunch of individual triggers. But that was even worse.

This rule has the best screen update speed, being pretty close to real-time. But it's ugly.

Rule1
ON Rotary1#Pos1 DO DisplayText [zs4x30y20]%value%%
ENDON
ON Rotary1#Pos1 DO Channel1 %value% ENDON

I deliberately update the channel dimmer last because it's driving a heater element, not a light. So I don't care if that takes a moment to be updated.

I read in another post here that complex rules are known to become slow, which has prompted this post. I have not delved into Berry scripts or anything else yet - just been using rules. Happy to try anything offered.

Is there a better way to do what I'm looking for? I tried this, however 1-second display updates is much too slow. I'm looking for near-realtime updates, if it's possible.

I'm using:

• Seeed Studio XIAO ESP32C6 board with a custom template:
  {"NAME":"Seeed Studio XIAO ESP32C6","GPIO":[0,0,0,3872,0,0,0,0,0,0,0,0,0,0,3872,0,32,416,7552,6752,6784,0,640,608,0,0,6210,0,0,0,0],"FLAG":0,"BASE":1}
• SH1116 (SSD1306-compatible?) 0.96" OLED display and EC11 encoder. Display is aligned and appears to be working fine. But maybe some tuning there will help?

My current display.ini

:H,SSD1306,128,64,1,I2C,3c,*,*,*
:S,0,2,1,0,30,20
:I
AE
D5,80
A8,3F
D3,00
40
8D,14
20,00
A1
C8
DA,12
81,9F
D9,F1
DB,40
A4
A6
AF
:o,AE
:O,AF
:A,00,10,40,00,02
:i,A6,A7
#

Thank you!

[sfromis]

One general speed factor when using rules would be to suppress logging of commands, and publish to MQTT of command results, like _DisplayText ...; that underscore at the start suppresses both logging and also publish of MQTT result messages when executing commands. Of course, these can be handy to have for debugging, but does cost some processing.

For better performance, maybe also try replacing
ON Rotary1#Pos1 DO IF (%value%==100) DisplayText [zs4x20y20]HIGH ENDIF ENDON
by:
ON Rotary1#Pos1==100 DO _DisplayText [zs4x20y20]HIGH ENDON
and so on for the others.

And instead of:
ON Rotary1#Pos1 DO DisplayText [zs4x30y20]%value%% ENDON
ON Rotary1#Pos1 DO Channel1 %value% ENDON
fewer steps needed if using:
ON Rotary1#Pos1 DO Backlog0 _DisplayText [zs4x30y20]%value%%; _Channel1 %value% ENDON

However, while rules are not as such "slow", the limited flexibility does make things more difficult, and you need to know many "less intuitive" details. Therefore, I'd suggest using the much more powerful Berry language.

Not sure if using HASPmota/LVGL (with Berry) would speed up processing, instead of using DisplayText commands (when having logging/publish suppressed), but you'd get additional styling options. And while having PSRAM is "strongly recommended", you can get by without for simpler/smaller displays like SH1106.

[ChestersGarage]

Thank you for the suggestions. I tried a number of approaches with your advice in mind, and just now came upon this, which performs well. I decided I needed to lighten up the load a bit and narrowed things down to one font and size, which looks nicer too. It didn't seem to perform any better with the underscores on DisplayText. I'm thinking the current performance is not limited by rule processing. But it's plenty fast for my needs.

I ordered the IF structure to hit the most common cases earliest.

SetOption43 100
Rule1
ON Rotary1#Pos1 DO Backlog0 IF (%value%>9 AND %value%<100) DisplayText [zs4x30y20]%value%%
ELSEIF (%value%==100) DisplayText [zs4x18y20]HIGH
ELSEIF (%value%<10 AND %value%>0) DisplayText [zs4x40y20]%value%%
ELSE DisplayText [zs4x29y20]OFF
ENDIF; Channel1 %value% ENDON

The line breaks are necessary to not get rule code in the display text.

When I used parallel ON Rotary... triggers, I was getting funny issues with how the executions were queued up, and the display would show a different value than the dimmer was actually set to. I suspect a lot of race conditions there.

This updates the screen in near-realtime when the rotary encoder is changing at a moderate rate. These EC11 encoders can't handle being rotated very fast.