Question about blinking an LED

[belveder79]

I've used some rule code to implement a blinking LED triggered by a button, which can be interrupted with another button press. The problem is that the rule does not work if there is no interruption but the blinkcount is simply reached:

var1 0
BlinkTime 5
BlinkCount 5
rule1 on Button1#state do if (var1==0) Power1 blink; var1 1; else Power1 blinkoff; var1 0 endif endon

If blinkcount is reached, it stops, but the var1 is obviously not reset to 0.

I was not able to define a rule using Power#state to reset it once the {"POWER1":"Blink OFF"} message appears.

Is there a particular trigger called instead of #state? Something like #blinkoff?

[belveder79]

So as it seems (according to more reading and Gemini), the way to deal with this was something like these rules, which use an additional RuleTimer to reset the variable after the blink times out, calculated somehow like:

given BlinkCount 5 and BlinkTime 5 (which is 0.5s), calculates to BlinkCount * (BlinkTime * 2 / 10) equals to 5.

So taking these values, we have to wait for 5 seconds to trigger resetting the variable, but likely we can spare an extra second to make sure it is executed after finishing. So the solution could be something like RuleTimer 6 (5+1)

rule1 ON Power1#Boot DO var1 0; BlinkTime 5; BlinkCount 5 ENDON
rule2 ON Button1#state DO if (var1==0) Power1 blink; var1 1; RuleTimer1 6; ELSE Power1 blinkoff; var1 0 ENDIF ENDON
rule3 ON Rules#Timer=1 DO var1 0 ENDON

did not test it, but does that make sense?

I was thinking about writing a berry script to do this, but I think that the problem remains the same, right? I can hook into triggers like Button1#state, but resetting var1 would still be based on a timer...

any thoughts?

[sfromis]

Standard rule mechanisms should handle Blink OFF just fine. This works for me:
on Power2#data=Blink OFF do var1 off endon
Hence you need no timer calculations and all that.

#state is for internally generated numeric states, not for JSON messages.
#data is for JSON messages (which are not a #state) with only one field.

Of course, you can set a much higher BlinkCount up to 32000, but this does not make much difference if you really want it to blink indefinitely.

In Berry, you can easily have a function to blink until canceled, without needing restarts:

def blinker()  # Blinks Power2, index is relative to 0
  tasmota.set_power(1, ! tasmota.get_power(1))
  tasmota.set_timer(500, blinker, "blinker") 
end

blinker()  # to start
tasmota.remove_timer('blinker')  # to cancel

[belveder79]

thx, I did not think about that data hook before, but that makes sense.

Just to be on the safe side: ON Power1#data=Blink OFF DO ... does NOT work for me.

What works is ON Power#data=Blink OFF DO ..., because this is not specific to a particular PowerX source.

In any case it does not matter, because since there is only one Blink-Timer, you cannot let 2 or more LEDs blink asynchronously anyway with different Blink timers (unless you do this in Berry), so if this is not sufficient, Berry is the solution.

[sfromis]

Both ways are specific to a particular Power channel. Needing to use Power or Power1 depends on whether you have multiple channels. If you only have one channel, Power1 would still work if you enable SetOption26. In other words, use exactly what you already see in messages.

Still, you did post about having {"POWER1":"Blink OFF"} which would mean that just triggering on Power instead of Power1 would not work.

But yeah, when you by "asynchronously" include having different BlinkTime values, Berry is indeed a good approach. Of course, you could do different blinking with rules too, but using rules becomes stretching it when going above simple cases, especially as you probably need more logic than the blinking.

[belveder79]

Thx for clarification...

But yeah, when you by "asynchronously" include having different BlinkTime values, Berry is indeed a good approach. Of course, you could do different blinking with rules too, but using rules becomes stretching it when going above simple cases, especially as you probably need more logic than the blinking.

Well, usually I come from the Berry side asking weird questions, to be pointed to a one-liner rule doing the job elegantly :-)
This time I tried to go with rules, and see how far I can stretch it, before I need to do Berry coding...

[sfromis]

Yes, many simple and common use cases works well with rules (or is already a builtin Tasmota feature), but rules being rather quirky means that you need to know a lot of peculiar details, like the #data thing above.

While Berry code tends to get longer than oneliners, I consider it more readable, and much easier to extend as your ideas proliferate. And lots of extra features not available with simple rules. Of course, there are still peculiar details to get around some "surprising" aspects.

[belveder79]

Right... ok, now I tried to implement things in Berry, but I found some "surprising" aspects there. I just have two buttons and two relays, so in order to act upon a button press, I wrote a berry script with a simple setup:

class BlinkerDriver
  def init()
  end
  def button_pressed(cmd, idx)
    print("command: ",cmd," - Index ",idx) 
  end
end
BD = BlinkerDriver()
tasmota.add_driver(BD)

I think I need to decouple the standard behaviour of Button-Relays with some SetOption (don't remember). Anyway, what happens is this:

command:    - Index  65792
...
command:    - Index  65792
command:    - Index  256
command:    - Index  16842752
command:    - Index  65792
...
command:    - Index  65792
command:    - Index  257
command:    - Index  16842753
command:    - Index  65792
...

If I press Button 1 it is 256 and if I press Button 2 it is 257, but why is there no cmd and why are there all those spurious firings in between? I tested this on 2 different ESP32 platforms and there is no difference having one or two buttons or a button overall.

[sfromis]

As indicated in the docs, there's sample code for decoding the values at:
#21711 (comment)
And having no cmd is related to common argument lists being used for different features. Just ignore that parameter.

Still, it would likely be easier to instead use tasmota.add_rule('Button1#state==1', ... etc, use values to match your use case. And yes, SetOption73 can be used to decouple Button default actions from power channel like Relay. In most use cases, the additional detail available with the button_pressed callback may not be very useful, but you just might benefit if wanting "more advanced" control.

[belveder79]

that works, thx. I still had to include the 'last_state' in an if clause, because the 65792 % 256 is zero as well, in order to keep buttons 1 and 2 (0 and 1) and not indexing it to something else...

[sfromis]

The finer details of that decoding is why I suggested a simpler approach, assuming that your use case is simple button pushes. Tasmota already has the logic to handle those straightforwardly.

[belveder79]

Ok, I need to pick this up again for a special reason.

I'm using this piece of hardware:

https://de.aliexpress.com/item/1005010476235902.html

The driver for blinking a led which actually triggers the MOSFET works perfectly (connected as Relays on GPIO16 and GPIO17 for the dual one).

But say you want to put the device into sleep mode with ULP. What happens is that the respective GPIOs go to "on" mode, which means that while the ESP goes to sleep, the LEDs turn on. I have this script which I took from some examples and use regularly for ULP business:

import ULP
ULP.wake_period(0,20000)
var c = bytes().fromb64("dWxwAAwAzAAAABgAgwOAcg8AANA8AIBwEAAJggkBuC4wAMBwKAAAgAkB+C8PASByMADAcBAAQHIzA4ByDwAA0DMAAHAfAEByVABAgFMDgHJCA4ByDwAA0AsAAGgAAACwQwOAcg4AANAKAABycABAgBoAIHIOAABoAAAAsFMDgHJCA4ByDwAA0AsAAGgzA4ByDgAA0BoAAHIaAEByDgAAaGMDgHIOAADQGgAAcg4AAGhzA4ByDwAA0C8AIHC4AECAAAAAsDAAzCkQAEByuABAgAEAAJAAAACw")
ULP.load(c)
c = nil
var gpio = 26 #wait for serial
var rtc_io_num = ULP.gpio_init(gpio,0) # GPIO to input 
ULP.set_mem(55,2) #edge_count_to_wake_up, debouncing does not seem to be perfect
ULP.set_mem(56,rtc_io_num) #rtc_gpio_number
ULP.run()
ULP.sleep()

Is there a way to prevent this by doing some ULP.gpio_init for GPIOs 16 and 17, or is this somewhere in the binary blob code? I never built a binary blob myself so I need some directions here...

[sfromis]

While I can't answer about how it works with ULP, using gpio 16/17 is an unfortunate choice. With the original ESP32 variant, these pins are used for PSRAM if the board has this feature. To work well with such boards, the default builds of Tasmota includes support for PSRAM, which will poll those pins at boot time (which includes deep sleep wakeup). If at all possible, I'd recommend using other gpios.

To be clear, I'm not sure that this is the explanation, but it does make things "more complicated". It is also possible to do a custom build without support for PSRAM to avoid the mentioned boot time behavior.

When it comes to "Is there a way to prevent this", that depends on debugging why it happens. And possibly exactly what happens on the pins when.

[belveder79]

Thanks a lot for this pretty good explanation. It clarifies a few things... Unfortunately the choice of GPIOs is a design decision by the board vendor, who choose 16/17. That is indeed bad, but really hard to change without cutting traces and adding replacement wires somewhere.

I did not know about the PSRAM check, but it is good to know, thx. I flashed the NO-PSRAM version but it did not solve the problem - the switches still go on once it goes to deep sleep. What I noticed however is that the GPIO16/17 are indeed not checked on boot time, because the LED was flickering on boot time with the regular version, and this stopped now.

To my understanding, the code that the binary blob is created from could potentially just set the two GPIOs to 0, but since I'm not fit assembler code, I'd need someone with some more experience to provide the right instructions...

[belveder79]

after rewiring GPIO 17 to GPIO 5 it's still the same, so even cutting traces doesn't help here...

The docs mention a BC337 transistor to switch devices off irrespective of the GPIO status. So if I get this correct, I'd need to put the transistor inbetween the terminals and the led, and switch it from a separate GPIO... makes sense?

[belveder79]

or even better, if the traces are cut put it between the control GPIO and the relay, to not fry it by the load...