Shutter: position percentage not updated and stat SHUTTER1 not published #9906
Comments
|
I have encountered the same problem. |
do you find both issue? issue 1) shutter percentage not updated if blink it is used. and issue 2) the percentage thanks! |
|
I was not precise enough, my fault. Since I do not use blink, I can´t tell anything about issue 1, but I can confirm issue 2 - percentage of shutter is not updated. Test situation: Console output with Tasmota 8.5.0 - working fine: Same test, this time Tasmota 8.5.1: What you can see is that SHUTTER1 only gets updated at the end position (0), but not if you stop somewhere between 1 and 99. btw: After downgrading to 8.5.0 you have to refresh config settings - I have just reloaded an old backup from 8.3.1 which worked fine. |
ascillato2
added
bug
|
@stefanbode, |
|
@ascillato2 closed my issue #10033 and I don't think it's related to this one |
|
Hello i solved with this solution but obviously it is not the correct way Enable rule: ON Rules#Timer=1 DO RuleTimer1 0 ENDON ON Rules#Timer=1 DO shutterposition1 ENDON ` ON Rules#Timer=1 DO RuleTimer2 0 ENDON ON Rules#Timer=1 DO shutterposition2 ENDON |
|
Hi, do you guys also have the problem that it doesn't have any effect when inverting the relays in the template? I changed the sonoff dual r2 module template (Relay to Relay_i), saved (incl. auto reboot) but it doesn't invert anything. Is this a bug or did I miss something? |
|
hi, i'm not using a sonoff but i'm tested on a esp8266 nodemcu, and i select inverted relay and i works perfectly as inverted |
|
Thanks for your reply, I also use ESP8266 D1 mini, with the latest Tasmota version, but somehow changing relays in the template to inverted doesn't take effect. Also when I select "none" or whatever, it doesn't change a thing. Do I understand the way how saving/loading a template works correctly? ->Take a preset, change things u want and save/restart and that's it. Or do I have to load/activate this changed template separately in a way I couldn't find yet? Thanks guys! |
|
but let's wait a moment, i not used template, i manually configure the relay inside configuration -> configuration module
|
|
Ah I now I see, when you load the Sonoff Dual R2 preset in the Config the relays are hidden, I cannot change the behavior. |
|
All, |
|
The issue will be left open since it is solved. Undo all the PRs from Stefan will bring back other solved issues. Thats is imho not a good idea. |
|
hi...Well, for what it's worth i think the same of @Jason2866
hope that @stefanbode can come back and take a look on both 👍 |
|
hi team, sorry for being off some time. Lots of work before Christmas. I will work through and check If I can understand and find the root cause |
|
I can reproduce the error on direct change on relays. It works fine as long as normal open/close or any shuttercomand is used. I will fix this but also point out that switching the relay is not the best way to operate with shutters. There are shutterbuttons and also nice command you can call from backlog |
reporting now also after manual relay change
hi Stefan and thanks so much for your answer, i appreciate. you mean instead of use blinktime? 👍 i use blinktime configuration because in this case i can trigger relay1 (up) or relay2(down) with a shortpress for 0,5seconds, and trigger relay1(up) or relay2(down) with a longpress for whole time shutterOpen or Shutterclose. i used this rule: what's your suggestion? Related to ISSUE2 |
ascillato2
added
fixed
|
Fixed with #10135 Thanks |
|
@ascillato2 can you please left open this post for issue1 ? now i trigger maually power1 4 times: as you can see the position is still 35% but the shutter was moved, and percentage is not correctly updated. as far as i understand with old version 8.1 this not happened. |
ascillato2
added
Shutter related
|
Reopening as requested |
ascillato2
changed the title
|
Hi, maybe you can test this without the Blink method. The problem of the Blink is, that this is not handled correctly. If the relay 1 is triggered it should be: |
|
@stefanbode, does your fix also fix issue #9800? |
hi, i tested with power On / Off and the position now is updated. ok, so we can not use blink to trigger relay for some seconds on shortpress. in this case with shorpress => i trigger relay for 0,5seconds but in this case the delay 5 => 0,5second is not respected, the relay is activated for 1second (i think 1 second is the limit) there are other rules that can perform it? |
|
Hi @megamarco833: I would suggest to rewrite the rule a bit to get the proposed solution: This would increment or decrement the position with 2%. And yes there is a limit of minimal runtime because TASMOTA is not that quick. I would assume minimum runtime is somewhere of 0.5seconds. |
|
Hi @stefanbode i adapt your suggestion for 4 shutters: i introduce a ShutterStop because in this way if i want to stop a longpress movement i can simply shortpress a button. issued shutterposition4 and see that it's 59% now shortpress again and relay move, but not 2% (was59) now it go to 65% it seams that firmware count also the first command, but phisically the relay was not triggered....it will cause a wrong percentage positioning of the blind...correct? here i pressed 5 times the switch but relay was triggered only 3 times: why this happen? |
|
The answer in this case is easy. There is a minimum runtime required. 2% seem to low for the minimum time. You can see in the first Shutterchange 2 that the target change from 61->63 but nothing happened. Then you hit again and it changed to 65 (63+2) and this is enough to start a move. As I can see the move takes less than a second. Also quite low. Assumption: You minimum for a change is 4 Second Use case: I can see 4 presses, not 5 (UL: SWITCH7#STATE=2 performs "backlog ShutterStop4; ShutterChange4 2") Because of the short runtime after the first press, the position was already 21 and not 20 (small overrun) At the next presses, there was no overrun. Small overrun can happen because of WIFI and other processes running. The Firmware is aware of the overrun but will not go backward. |
|
hi @stefanbode my system is a test now so i not have connected a real shutter.
but on "real shutter" where the open duration will be more than 15seconds, i can trigger relay (with a shortpress) for less than a second?
ok, but considering for example 5 consecutive shortpress (so regulation of 2%, if it is possible) and considering that somewhere during this 5 consecutive shorpress some overrun can happen, it will cause a wrong / misalignment "real" position percentage of blind vs tasmota software position ? last question if i have to control relays that are on ESP_B and buttons are on ESP_A
that's correct? thanks! |
|
Correct shuttercloseduration drive the minimum time. 10 seconds does mean 2% are 0.2 sec. This are only 4 cycles (50ms TASMOTA hard coded). Very tough. If the runtime is 20seconds then 2% are 8 cycles and this will work. The code requires at least 3 cycles = 0.15sec. Anyhow I assume this short time might create issues. Pulsetime relays will never work here. Just to be aware. shutterbutton can be used for other usecase. It will not solve the very short runtime. As mentioned above, independent from the total runtime, the limit is the number of cycles. I tested a bit around and 4 cycles (0.2sec) are the absolute minimum. |
|
No, the position is always correct measured. It "knows" that it moved a bit too far and corrected this on the next move.
|
so if i understand correctly i can setup a percentage regulation with a shorpress that must have a numbers of cycles for OPEN and close that could be minimum 4 cycles.
with new commit of today about milliseconds timestamp on tasmota, it will help to drive better the shutter, so also this percentage regulation with low numbers? |
|
All correct, without the last sentence. The millisecond timestamp does not bring any benefit here. There are three different methods of how you can hook in with procedures. e.g. to stop the shutter at the right time: With this combination I can assure position calculation is always correct no matter of the load and the WIFI network and do the operations with logging and so on outside the RealTimeClock (RTC) in a normal procedure. Doing RTC at 10ms or less is a very bad idea because we do not have a high-end processor. There is some give-and-take required to assure it runs smooth. |
PROBLEM DESCRIPTION
A clear and concise description of what the problem is.
two issue (or possible issue)
stat/%topic%/SHUTTER1with the percentageREQUESTED 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:
ISSUE 1.
i would like to control my blind configured with:
relay1 = OPEN relay2 = CLOSEswitch1 short press = relay1 ON for 0,5seconds switch1 long press = relay1 ON till 100% open switch2 short press = relay2 ON for 0,5seconds switch2 long press = relay2 ON till 100% closei think to use this:
blinktime 5 (5=0,5sec)
blinkcount 1
switchmode1 5 // 5=to manage short/long press
switchmode2 5
power1 3 (3=blink)
so start from actual position that is 55%
now i trigger manually power1 10times just to be sure that the moviments of the blind shuld change the percentage.
as you can see the initial shutterposition1 was 55% and after triggering manually
power1 3the shutterposition1 is still at 55%so it seams that the percentage is not updated using
power1 3it is a bug or i'm missing something? thanks
ISSUE 2.
the percentage
stat/%topic%/SHUTTER1in the previous firmware was published every time after the final moviment.now i see that it is not reported every time after a moviment
fw 8.2 (where was published every time topic SHUTTER percentage
fw 9.1 where not alwasys is published the topic SHUTTER percentage
it seams that it is updated only when i move the cursor, but not when power is triggered, here the log
EXPECTED BEHAVIOUR
A clear and concise description of what you expected to happen.
SCREENSHOTS
If applicable, add screenshots to help explain your problem.
ADDITIONAL CONTEXT
Add any other context about the problem here.
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: