Issue with P079 since mega-20201227

TungstenE2 commented 3 years ago

Summarize of the problem/feature request

Hi all,

I recently discovered an issue with my chicken door operated using the P079 Wemos motor shield plugin.

https://espeasy.readthedocs.io/en/latest/Plugin/P079.html#p079-page

Installation and rules were running stable for a long time. I recently updated to ESP_Easy_mega_20210114_normal_ESP8266_4M1M.bin and I randomly discovered issues with my sunrise rule to open the door.

I realized that there where cleanup activities to the plugin with Release mega-20201227.

May be these cleanups are causing the issue?

@TD-er: could you check if the clean up done with mega-20201227 caused an issue?

I just rolled back to ESP_Easy_mega_20201130_normal_ESP8266_4M1M.bin and this seemed to fix the issue.

thx

Expected behavior

see above

Actual behavior

see above

Steps to reproduce

see above

System configuration

Hardware: Wemos D1 mini with wemos motor shield

ESP Easy version: mega-20201227

ESP Easy settings/screenshots: grafik

Rules or log data

giig1967g commented 3 years ago

Please keep us informed if the issue is solved, so we can close this incident.

Regarding your comments, they are absolutely valid. Will make the changes as soon as I have time (and Gijs approves them).

TungstenE2 commented 3 years ago

bad news, the issue reoccured this morning. The door did not fully open, but stopped after about 1 sec. So I went outside and checked the door and reed sensors. The door is a bit shaky in the close position and more firm in the open position. So the issue is caused as the door is moving a bit and the reed is triggered and since the latest releases the software is more sensitive.

grafik

I played a bit with the settings and de-bounce 200 and safe-button on was not a good combination. Seems like this caused the door even to bypass the close reed, as the reed usually stops the door a bit over the ground.

Possible solutions:

changing the door sliders so the door can not move any more in the lower position, in order to prevent false reed switch states. But this is a bit hard, as the door is hard to reach without to ball out my right arm...
solving this by setup configuration, but de-bounce and safe button did not fully do the trick by now
changing the rules in order to prevent this false reed triggers
changing the speed of the motor

TD-er commented 3 years ago

Just for understanding... Were the days when the door switch "bounced" a bit more wet compared to other days? A wet door may jam slightly and thus causing a more shaky movement.

TungstenE2 commented 3 years ago

no, not really. The door and the sliders are aluminium, so rain/wet should have no impact. the sliders are just not 100% straight, as it was hard to fix the screws. I only could work through a tiny side door.

TungstenE2 commented 3 years ago

small update:

3 days ago I repositioned the right door slider a bit, so the door has less space to move in the close position. I also set the de-bounce value to 250 (this is max value) and the safe button. This was working fine for 2 days, Thur, Fri when the door opens by sunrise.

But today (Sat) the door rules are supposed to open the door by 8:30 and again the door open rule started to open the door, but stoped again after 1 sec.

So I started to make up my mind what might be the difference between Fri and Sat. Differences are:

fixed time for Sat and Sun, instead of sunrise
at 8:30 the chicken are already waiting at the door to open, while at sunrise they are still sitting

So my assumption is, that the chicken waiting at the door makes the door magnet moving slightly and the reed contact is too sensitive and triggers the DoorStop rule, right after the motor was started. Seems like that recent code changes result in too sensitive and fast triggering, which was not the case before for a long time.

So I see following options for me:

changing the rules for weekends to open also with sunrise (my nighboors will get angry in summertime...)
changing the rules, that after motors was started, the DoorStop rule should not be triggered for 3 sec. (Not sure how to implement)

Further ideas?

tonhuisman commented 3 years ago

the DoorStop rule should not be triggered for 3 sec. (Not sure how to implement)

I'd code that something like this: (partial code only, replacing some existing code)

On Clock#Time=Sat,08:30 do
  Let 100,1 // Disable DoorStop temporarily
  TimerSet 7,3 // Delay for disabled DoorStop to be re-enabled
  TimerSet 1,60
endon

On Clock#Time=Sun,08:30 do
  Let 100,1 // Disable DoorStop temporarily
  TimerSet 7,3 // Delay for disabled DoorStop to be re-enabled
  TimerSet 1,60
Endon

On Reed1open#Switch=1 do
  If %v100%=0
    AsyncEvent,DoorStop // Queue command
    GPIO 15,0
  Endif
Endon

On Reed2close#Switch=1 do
  If %v100%=0
    AsyncEvent,DoorStop // Queue command
    GPIO 15,0
  Endif
Endon

On Rules#Timer=7 do
  Let 100,0 // Allow DoorStop to be activated again
Endon

TungstenE2 commented 3 years ago

Hi all, here comes a final update.

I updated the rules as suggested (syntax needed to be adjusted), and chicken door is working as expected again. Needed to enable a delay, as the new code is to sensitive for short reed switch triggers.

Thx for your support. Ticket can be closed. Please remember the changes discussed.

Rule set 1


On System#Boot do
  TaskValueSet 7,3,0 // DC Motor off
  endon

//## Taster Functions

//close door if Taster1 is pressed and door is not closed

On Taster1close#Switch do
    If [Taster1close#Switch]=1 and [Reed2close#Switch]!=1
        Event,DoorClose
    Else

endif
endon

//##

//close door if Taster2 is pressed and door is not open

On Taster2open#Switch do
    If [Taster2open#Switch]=1 and [Reed1open#Switch]!=1
        Event,DoorOpen
    Else

endif
endon

Rule set 2


//## Automatic Stop Functions

//stop motor if Reed1 or Reed2 triggered

On Reed1open#Switch=1 do
  If %v100%=0
    AsyncEvent,DoorStop // Queue command
    GPIO 15,0
  Endif
Endon

On Reed2close#Switch=1 do
  If %v100%=0
    AsyncEvent,DoorStop // Queue command
    GPIO 15,0
  Endif
Endon

//##

Rule set 3

//at sunrise time set timer1 for 1 Sec

// On Clock#Time=All,%sunrise% do 
//  Let,100,1 // Disable DoorStop temporarily using variable v100 set =1
//  TimerSet,1,1 //TimerSet 1 for DoorOpen Event, 1 Sek
//  TimerSet,7,3 // Delay for disabled DoorStop to be re-enabled, Timer 7, 3 Sek
// endon

On Clock#Time=Mon,%sunrise% do 
  Let,100,1 // Disable DoorStop temporarily using variable v100 set =1
  TimerSet,1,1 //TimerSet 1 for DoorOpen Event, 1 Sek
  TimerSet,7,3 // Delay for disabled DoorStop to be re-enabled, Timer 7, 3 Sek
endon

On Clock#Time=Tue,%sunrise% do 
  Let,100,1 // Disable DoorStop temporarily using variable v100 set =1
  TimerSet,1,1 //TimerSet 1 for DoorOpen Event, 1 Sek
  TimerSet,7,3 // Delay for disabled DoorStop to be re-enabled, Timer 7, 3 Sek
endon

On Clock#Time=Wed,%sunrise% do 
  Let,100,1 // Disable DoorStop temporarily using variable v100 set =1
  TimerSet,1,1 //TimerSet 1 for DoorOpen Event, 1 Sek
  TimerSet,7,3 // Delay for disabled DoorStop to be re-enabled, Timer 7, 3 Sek
endon

On Clock#Time=Thu,%sunrise% do 
  Let,100,1 // Disable DoorStop temporarily using variable v100 set =1
  TimerSet,1,1 //TimerSet 1 for DoorOpen Event, 1 Sek
  TimerSet,7,3 // Delay for disabled DoorStop to be re-enabled, Timer 7, 3 Sek
endon

On Clock#Time=Fri,%sunrise% do 
  Let,100,1 // Disable DoorStop temporarily using variable v100 set =1
  TimerSet,1,1 //TimerSet 1 for DoorOpen Event, 1 Sek
  TimerSet,7,3 // Delay for disabled DoorStop to be re-enabled, Timer 7, 3 Sek
endon

On Clock#Time=Sat,07:30 do 
  Let,100,1 // Disable DoorStop temporarily using variable v100 set =1
  TimerSet,1,1 //TimerSet 1 for DoorOpen Event, 1 Sek
  TimerSet,7,3 // Delay for disabled DoorStop to be re-enabled, Timer 7, 3 Sek
endon

On Clock#Time=Sun,07:30 do 
  Let,100,1 // Disable DoorStop temporarily using variable v100 set =1
  TimerSet,1,1 //TimerSet 1 for DoorOpen Event, 1 Sek
  TimerSet,7,3 // Delay for disabled DoorStop to be re-enabled, Timer 7, 3 Sek
endon

// Allow DoorStop to be activated again after Timer 7 has expired, set variable v100 =0

On Rules#Timer=7 do
  Let,100,0 
Endon

 //at sunset set timer2 for 20min

On Clock#Time=All,%sunset% do 
        timerSet,2,1200
endon

//When Timer1 expires, DoorOpen and set Day 1

 On Rules#Timer=1 do  
    If [Reed1open#Switch]!=1
        Event,DoorOpen
        TaskValueSet 7,1,1 
    Else
        Event,DoorStop
endif
endon

 //When Timer2 expires, DoorClose and set Day 0

 On Rules#Timer=2 do  
    If [Reed2close#Switch]!=1
        Event,DoorClose
        TaskValueSet 7,1,0
    Else
        Event,DoorStop
endif
endon

Rule Set 4

//Events

On DoorOpen Do
If [Reed1open#Switch]!=1
    WemosMotorShieldCMD 0 Backward 50
    TaskValueSet 7,3,1
endif
EndOn

On DoorClose Do
    If [Reed2close#Switch]!=1
    WemosMotorShieldCMD 0 Forward 50
    TaskValueSet 7,3,1
endif
EndOn

On DoorStop Do
    WemosMotorShieldCMD 0 Stop
    TaskValueSet 7,3,0
EndOn

TD-er commented 3 years ago

Just one remark. The "weekend" could be matched (or at least "should" :) ) with wkd and the other days of the week with wrk. That could make your rules slightly shorter. But please test it as we don't want to make them being locked up for too long.

TungstenE2 commented 3 years ago

nice, thx for the advice.

Where to find documentation on this?

Not mentioned in Rules documenttaion currently. https://espeasy.readthedocs.io/en/latest/Rules/Rules.html

TD-er commented 3 years ago

nice, thx for the advice.

Where to find documentation on this?

Not mentioned in Rules documenttaion currently. https://espeasy.readthedocs.io/en/latest/Rules/Rules.html

I think the question of "where" should be changed into "when" ;)

TungstenE2 commented 3 years ago

Hi all,

quick update:

I did the rule changes as suggested, but I randomly had cases were this was not working properly in the past weeks. So I changed the rules not to trigger the motor stop by reed sensor but just by timer.

//Events

On DoorOpen Do
If [Reed1open#Switch]!=1
    WemosMotorShieldCMD 0 Backward 50
    TaskValueSet 7,3,1
        TimerSet,3,20 //TimerSet 3 for DoorStop Event, 20 Sek
endif
EndOn

On DoorClose Do
    If [Reed2close#Switch]!=1
    WemosMotorShieldCMD 0 Forward 50
    TaskValueSet 7,3,1
        TimerSet,4,16 //TimerSet 4 for DoorStop Event, 16 Sek
endif
EndOn

On DoorStop Do
    WemosMotorShieldCMD 0 Stop
    TaskValueSet 7,3,0
EndOn

I understand that ESPeasy code should be updated and fine tuned for better performance, but in my case the setup was working fine with clear rules for a long time. After the changes in 11-2020 I had to implement several tweeks with your support in order to have same functionality back, as the new software was acting too sensitive in combination with the reed sensors. May be this can be improved again.

TD-er commented 3 years ago

I am working on a new PWM motor controller plugin which does allow for direct feedback from an encoder and using limit switches. (this to also allow for a proper PID controlled speed control and allowing for soft start/stop) If that's working well, I will also backport the limit switch code to other plugins where debounce code is needed.

Anyway I am diving into the GPIO related code as we speak and I do see a lot of opportunities where things can benefit from optimizations. Acting on a timer to control a motor is not a good idea, but I understand your decision.

Maybe we can combine this new PWM controller with other motor controller plugins. For example instead of switching a GPIO to start the motor, we can send an event from this (new) plugin. This way we can combine it with just about anything.

TungstenE2 commented 3 years ago

thx @TD-er but the issue is not with the motorshield plugin, but with the reed switch sensor and the too sensitive reaction to its triggers. The plugin P079 is working great.

I decided for the timer control, as it happend several times now that the motor was not stoped by the rules and was still powered in a blocked position for several hours. By using timer control I can avoid this and the motor will not be damaged.

TD-er commented 3 years ago

Timer as a fail safe is a good idea. One of the things I try to achieve with the PWM motor control is to have a very tight integration between encoder feedback and limit switches as this is something that's being done quite often. As soon as that's done, I can probably extend other motor plugins and/or integrate the other plugins along with this new one.

I will keep the timeout option in mind, which can maybe also a good feature for the PWM motor plugin.

TungstenE2 commented 3 years ago

ok, sounds good.

Do I get you right that you are about to build a generic motorshield plugin, which will include P079, so P079 is no longer needed in order to use Wemos motorshield?

https://espeasy.readthedocs.io/en/latest/Plugin/P079.html

TD-er commented 3 years ago

Well yes and no... I am making a generic motor shield which can drive those ordinary H-bridges and if the motor has some kind of encoder feedback you can use it to keep track of the position and it does support limit switches. (optional) That part is already working fine, but I'm now also trying to make it work on speed controlling using PWM to allow for soft start/stop and making the speed independent on the load. This does not yet work on the existing motor shields, but I'm thinking of either letting those interface with this new plugin, or maybe making the new plugin modular so existing shield plugins can be extended to also incorporate the new logic for close loop control.

So not sure what it will become in the end as I still have to think about what will be the most elegant way without code duplication. So it is too soon to talk about deprecating a plugin as having support for a motos shield on I2C for sure has its benefits.

tonhuisman commented 1 year ago

This seems to be solved, so can be closed.

letscontrolit / ESPEasy