-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Shutter] Inverted shutter behaves not like expected #19114
Comments
For me, the issue also occurs. Version 12.5.0 works as expected. |
uups missed that conversation. Let me check. where is get messed up. The idea of INVERTED that ONLY the reporting 0..100% is inverted. and that shutterposition 20 for example executes a shutterposition 80. There was some updates on the WEBUI that now updates during the move. And the WebUI was not correct with the INVERTED. Let me double check on this. |
When a shutter is used in inverted mode it behaves not like expected. In version 12 everything was OK. I tried to show it in the following table:
|
At the moment I can't test it, as I am enjoying the sun of Greece instead of the rain in Germany. I'll test it, as soon as I am back. |
We can change. I replace you in greece and you can test in rainy, cold germany. Let me know where to go. :-) |
Hmm. 🤔 NO! 😂 |
I think we can close this. @SteWers will check after holiday, but I'm confident to pass the test. |
I think so, too. |
Looks like something got lost in the change - see #19328 |
@stefanbode: I saw you found a bug. The problem from @sukram3001 seem not be present on an ESP8266. But there are a few things, which are till not solved. In short:
|
@SteWers can you please reopen the issue? I can confirm that this is only partially resolved. |
@NoName1311 I think, it's better, when you open a new issue. This is very old, and I cannot see any problems with the last dev on an ESP8266. |
yes open a new one. or just post here on the closed one. Both fine for me to get it fixed |
I tested it with 13.1.0 and the bugs mentioned above were still there. I will test it again with the next release and then open a new issue if necessary. Thank you for your good work |
Can you please check against the actual development branch. Thx |
Please excuse my late reply. Today I downloaded and tested the development branch V13.1.0.3. In this version the issue is resolved. Thank you again for the good work. |
hello there again :) imho this problem is not fully resolved. my configuration:
In your table above "ShutterPosition UP" and "ShutterPosition DOWN" are not mentioned. expected on ShutterInvert 0 and ShutterInvert 1:ShutterPosition UP -> Shutter moves to top position in my case:ShutterPosition DOWN resolves in "Command: Error" (regardless of the ShutterInvert Mode and of the current position) |
Regression accepted. Will fix. Up down does not work on inverted shutter |
@stueB : Thanks for bringing it up. A fix is on its way. Pls let me know if you still have issues. Tested on ESP32 and ESP8266 |
Hello, I have another problem with tasmota 14.0.0, esp8266 and the invert function. |
Hmm, strange that calling a position screw it all up. Can you attach some log files with loglevel 4. I am on holiday with limited testing equipment. Please do it when shutter is at 30% to get most info. |
I've tested a few scenarios. It looks like a web query will always swap the invert function for opening and closing on the first mqtt command. |
sorry for the delay. weather was very good on holiday. I found the root cause of the behavior and will work on it. Due to limited testing it will take some time. I was able to reproduce the issue. |
There is a fix submitted a few minutes ago to the DEV branch. Please give it a try. should now work with MQTT |
Just tested dev branch. If I now drive to 0, it goes to 100 and vice versa. |
Isn't this as it should be? |
No, exactly the opposite happens when controlled via MQTT |
Maybe we need some control over which relay does what. So I can configure that relay1 is moving the shutter up, and relay2 is moving the shutter down? |
Be back from holiday and now have access again to the testbench. I can agree that the fix was only one part and need an additional fix. Submitted: #21663 |
I’ve finally managed to test it, and it’s been working with no problems with my settup so far. |
Great, I am finally the guy from the xkdc comic but I am really interested in having the behavior that was fixed here, any other option to invert the direction of shutterclose and shutteropen, not just the position? Basically the regression was the behavior I needed |
If you just need it revert then simple switch the gpio on relay 1 and 2 |
Not the avenue for this, maybe I'll write in discussion but physical wiring
is inverted and so if you invert Relay 1 and 2 you actually invert button
behavior, shutterinvert seemed the correct solution
…On Sun, Oct 27, 2024, 1:42 PM stefanbode ***@***.***> wrote:
If you just need it revert them simple change relay 1 and 2
—
Reply to this email directly, view it on GitHub
<#19114 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMW7EGXZAJ3SJM65N3EUIDZ5TGT7AVCNFSM6AAAAAA2KHCWNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBQGAYDAOBUGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Maybe you write down what is your actual configuration and what do you want to archive. Relay 1 is up and 2 is down. This is mandatory. Is it is mounted in the wall and you cannot change them just flip the gpio on the configuration page. Now shutterclose and open should do what you want. If your integration now has a problem if 0 or 100 is required for the open position then use Shutterinvert. That's all you need. |
PROBLEM DESCRIPTION
Inverted shutter behaves not like expected.
REQUESTED INFORMATION
Backlog Template; Module; GPIO 255
:Backlog Rule1; Rule2; Rule3
:Status 0
:weblog
to 4 and then, when you experience your issue, provide the output of the Console log:TO REPRODUCE
Steps to reproduce the behavior:
EXPECTED BEHAVIOUR
When a shutter is used in inverted mode it behaves not like expected. In version 12 everything was OK. I tried to show it in the following table:
The text was updated successfully, but these errors were encountered: