Tristate Buttton. Which primitive must I use? (Switch, Pushbutton...)

[nastiliano]

Hello everyone.

I'm using "Switch" primitive class with polling in my code and it works great to implement opening/closint contacts like relays, but now I want to implement a "tristate" user button. Pushing the same button it have to implement a sequence like this: OPEN-STOP-CLOSE-STOP-OPEN...

But trying to modify my code rising de "debounce_ms" even to 1000, or putting "await time" inside the "close_func"... It doesn't work neither, because the speed of the coros calls are brutal amd my sequence is crazy...

There are an apropiate primitive class to do it?

Thank you very much
Best regards.

[2dof]

Based on pushbutton.py You can implement
state machine : a counter 0 -1 -2 ( OPEN-STOP-CLOSE) , every button click : counter+1. when counter=2 then change counting direction (counter-1) , when coutner =0 and button click, again change counting direction (counter+1) . value of counter is your state indicator.

usually there should be additional signal form open/close indicator to implement complete state machine, without that for init state (STOP) we do not know in what direction: OPEN or CLOSE we should go, then we have to guess (not to safe).
for example (not to safe):

CNT,direction = 1, 1 
async def click_on( ms):
   global CNT,direction
    if CNT ==2:
       direction=-1
    elif CNT ==0:
       direction=1
    CNT+=direction
    print(CNT)
    await asyncio.sleep_ms(ms)

edit: I guest you want control 3 state via 2 DIO pins ( for example : 1 0, 0 0, 0 1 ) then instead of "counter" you can directly implement state machine based on a Boole’a sequence machine and manipulate DIO ( still additional open/close indicator should be added)

[peterhinch]

Or use an event based approach:

import uasyncio as asyncio
from primitives import Switch
from machine import Pin

async def foo(evt):
    while True:
        for n in range(3):
            evt.clear()  # re-enable the event
            await evt.wait()  # minimal resources used while paused
            print("Press no.", n + 1)

async def main():
    sw = Switch(Pin(1, Pin.IN, Pin.PULL_UP))
    sw.close_func(None)  # Use event based interface
    await foo(sw.close)  # Pass the bound event to foo

asyncio.run(main())

[nastiliano]

Thanks!!!

The event based aproach is great!

I was reading about using ESwitch either Switch but I didn't understand how to implemend. Now I'm using Switch class, but really the debouncing is a little bit problen even increasing it to 1000ms. Always is very speedy reading.

[peterhinch]

I'm very surprised you are getting bounce - no switch bounces for 1s. I think there is a hardware problem. Have you defined the Pin with Pin.PULL_UP or used an external pullup resistor?

[nastiliano]

Hello,

I mean, using "Switch" without event aproach (using Coros: "open_func" and "close_func" with boolean variables in a Pin) works for me but I'm using wire to close the contact and ESP32 is reading a lot of "open_func" or "close_func" (if you don't simulate the close correctly like a real switch).

For this reason, I couldn't implement correctcly "a states machine", because when I closed the wire my variables changed their values very speedy: 1,2,3,1,2,3...

I like much more the "event aproach" because this "problem" is solved (this speedy reading), and now I wondering If I'f be better re-code all my coro aproach with event aproach.

What do you think? Should I use coro aproach, event aproach or it depends for what?

PD: I'm not defining Pin.PULL_UP, I'm using an external pullup resistor.

Thank you very much.

[peterhinch]

I think you need a real switch :) I can't see how the event based approach is fixing the problem of spurious contact closures. A real switch is the fix.

Re event driven vs callbacks, callbacks are the traditional approach. In schedulers I've used (and written) the Event class was implemented by polling so was inefficient. uasyncio V3 has an ingenious and highly efficient Event class which lends itself to a style of programming which does not use callbacks. In my opinion this produces cleaner code with control flow that is easier to follow.

But there is no fundamental difference in capability: both approaches work. The choice is yours.

[peterhinch]

Re ESwitch all you need is:

import uasyncio as asyncio
from primitives import ESwitch
from machine import Pin

async def foo(evt):
    while True:
        for n in range(3):
            evt.clear()  # re-enable the event
            await evt.wait()  # minimal resources used while paused
            print("Press no.", n + 1)

async def main():
    sw = ESwitch(Pin(1, Pin.IN, Pin.PULL_UP))
    await foo(sw.close)  # Pass the bound event to foo

asyncio.run(main())

The only advantage of ESwitch over Switch is minimalism - both work in the same way. You'll need the file primitives/events.py.

[nastiliano]

Hello again.

Finally I will use "Switch polling aproach" (for my code, I think is the best aproach).

Buuuffffffffffffffffffff.... I've been trying for 3 days different things and it's impossible to get only 1 coro call to implement my "tristate swich", always my code enter twice.

I'm gonna explain my code:

#MAIN CLASS
...
firm_mode = DEVICE_CLASS.firm_mode
factory_defaults = DEVICE_CLASS.factory_defaults
...
async def firmware():
    while True:
        await firm_mode()
        await factory_defaults()
        await uasyncio.sleep_ms(50)

async def main():
    try:
        await uasyncio.wait_for(wifi_config() , 10)
        wifi_ok = True
    except uasyncio.TimeoutError:
        wifi_ok = False
    
    if wifi_ok:
        async_server = uasyncio.start_server(Wifi , server_IP , port)
        await uasyncio.gather(async_server , firmware())
    else:
        print("Show connection error")

uasyncio.run(main())



#DEVICE CLASS 
...
def __init__(self)
    self.input_1 = Switch(machine.Pin(36 , machine.Pin.IN))
    ...
    async def input_1_enabled():
        global input_1_enabled_flag
        input_1_enabled_flag = True
        print("ENABLED")
    
    async def input_1_disabled():
        global input_1_disabled_flag
        input_1_disabled_flag = False
        print("DISABLED")

        self.input_1.close_func(input_1_enabled)
        self.input_1.open_func(input_1_disabled)
...
async def firm_mode(self):
    ...

async def factory_defaults(self):
    ...

Executing this code, using a real swich or a wire to close the input I always receive ENABLED twice (at the terminal) and DISABLED too. It's impossible enter just 1 time into input_1_enabled/input_1_disabled coros.

Could you help me please?

Thank you very much.
Best regards.

[2dof]

I have rearrange your device code (snapshoot beneath). I do know know you assigned close_func and open_func inside input_1_disabled() and why You defined both function inside init() ( I guess it is just a typo in snapshoot) , but from my code , for testing from (I used pin 4 in my esp32) I wired to gnd (simulation a real switch) and got onlu single run of function:
wire to GND -> printed ENABLED
disconnect from gnd -> DISABLED

Also I tested Your code (afterr correction position of self.input_1.close_func(..) /self.input_1.open_func() functions and it works like my version i.e close switch -> call close_func (once) , open switch -> call open_func (once).
Do you want that behaviour?

(input_1_enabled_flag and input_1_disabled_flag are implemented as class Attributes )

from machine import Pin   
from primitives import Switch
import uasyncio as asyncio

class Three():
    def __init__(self):
  
        self.input_1 = Switch(Pin(4, Pin.IN, Pin.PULL_UP))
        self.input_1.close_func(self.input_1_enabled)
        self.input_1.open_func(self.input_1_disabled)
        
        self.input_1_enabled_flag = False
        self.input_1_disabled_flag = False
        
    async def input_1_enabled(self):
      
        self.input_1_enabled_flag = True
        print("ENABLED")
        
    async def input_1_disabled(self):

        self.input_1_disabled_flag = False
        print("DISABLED")

#--my app 
async def my_app():
 
    sw = Three()
    print(sw.input_1.__call__())      # just check actual switch state (for test) 
    await asyncio.sleep(100)  # Dummy application code
    
    
# run      
print('run')
asyncio.run(my_app())  # Run main application code 

[nastiliano]

Yes! This is just what I want.

Mmmm.... I see (sometimes I'm a little bit silly :)
I think my problem is that I have the coros inside the constructor.

Tomorrow I'll try to recode and I will execute again.

Thank you, thank you very much.

[2dof]

coros in the constructor are not a bad or something ( there are internal functions - "not seen from autss de of class)), but since you creating a class it is usually better implement functions as their member (of course you can implement this function outside class and then pass them via constructor).
Since I made 'flags' as member of class then for more compact - functions are also members of this class.

I tried to repeat behaviour from your code like you described, bit i have got that like i described. maybe it is matter of debounce_ms value defined in switch class (it is 50 ms )

[nastiliano]

Hello.

Today I recoded the coro functions outside the init (constructor) and it works perfectly.

Thank you very much.
Best regards.

[peterhinch]

@2dof A couple of minor points. The methods input_1_enabled and input_1_disabled do not need to be defined as async. They will work just as well as synchronous methods. There is no need to issue sw.input_1.__call__(): sw.input_1() will do equally well.

[nastiliano]

I removed "async" from these functions and it works good in the same way.

Thank you very much.

Best regards.