Shutters: The ShutterStop command triggers a reverse run of the shutter in certain situations #10166
Closed
10 of 14 tasks
Labels
Shutter related
Type - Issue specific to Shutters
Comments
|
@Bascht74 , yes, great and excellent analysis. There is no more investigation required on my side. Thx. I have an idea, how to change the shutterstop function to make it work. Will submit it later today. |
stefanbode
added a commit
to stefanbode/Sonoff-Tasmota
that referenced
this issue
Dec 18, 2020
improved stop procedure to avoid overrun due to rounding issues between % and the real_position
Merged
arendst
added a commit
that referenced
this issue
Dec 18, 2020
|
@stefanbode Thanks! This is a very elegant way to solve it :-) I got the idea, much easier... |
|
Hi @stefanbode I tried it, and it worked! Great! Sebastian |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
PROBLEM DESCRIPTION
A clear and concise description of what the problem is.
I use the shutter function of Tasmota in conjunction with Shelly 2.5 and the latest DEV firmware.
In certain situations the
ShutterStopcommand triggers a reverse run of the shutter motor instead of simply stopping. Normally this should not happen according to @stefanbode, but the shutter should simply stop with some "inaccuracy".REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
Backlog Template; Module; GPIO 255:Backlog Rule1; Rule2; Rule3:Status 0:(Please use
weblog 4for more debug information)TO REPRODUCE
Steps to reproduce the behavior:
EXPECTED BEHAVIOUR
A clear and concise description of what you expected to happen.
I expected the shutter to stop when the
ShutterStopcommand is entered, rather than briefly moving backwards a bit.SCREENSHOTS
If applicable, add screenshots to help explain your problem.
./.
ADDITIONAL CONTEXT
Add any other context about the problem here.
@stefanbode I first suspected timing problems (milliseconds in the log :-), but it seems to me rather to come from the way
ShutterStopis implemented. Some code forCmndShutterStopI think it might be because (if I observe this correctly in the log and understand the code correctly)
ShutterRealToPercentPositionreturns an absolute percentage. But for certain positions in the lower third (0-30%),shutterset50percentmakes this range larger than in the range (31-100%). This results in values that deviate more from the current position and thus trigger these backward movements in some cases.Possibly (I am not a programmer) it would be interesting to accept internally at
XdrvMailbox.payloadalso a number with one decimal place (10.5 instead of 11) and to letShutterRealToPercentPositiondetermine accordingly also a more exact position with one decimal place. This would then be "better" processed byCmndShutterPosition(), so that no more backward movement takes place.By the way, this would eliminate another problem:
In the lower area the shutter is mostly stopped a little bit delayed, because it has to run a little bit further in this area because of the larger steps due to
shutterset50percent, since the real positions are much further apart. This is especially noticeable when you also press a button and the shutter reacts much more delayed than in the upper area. If you use a long-push, it is also slightly annoying, because you think that the command arrives delayed (WAF :-)... and you could set the shutter with the
shutterpositioncommand more precisely in lower areas... (eg.shutterposition 1.5)I also think that without
shutterset50percentthe problem does not occur or occurs extremely rarely.I hope you get what I mean.
My mother language is German as yours, but I try to keep it in English, even it is difficult for me to write my thoughts...
P.S.
I looked at the log an the theoretical runtime:
If I got it right, it should run (theory 50ms * (144 - 27) = ) 5.850 ms and it did (see log) 5.836 ms, even with weblog 4.
So pretty accurate stuff!
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: