-
Notifications
You must be signed in to change notification settings - Fork 5
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
Unnecessary stop before up/down #20
Comments
I did some more research, and it seems (GPT et al) that it is regarded to be best practice to first issue a stop before sending an up/down. But I did not find any first hand information or advice for this (e.g. by any manufacturer of KNX motors). I deleted the stop/step in my personal branch of the app and tried it with my motors several days now. The timing problems are gone completely and the window covers are functioning reliably without any apparent problems for the motors. I would therefore reinforce the vote for solution 1. |
You might be correct there. If i read page 24 (http://knx.com.ua/attachments/article/132/KNX-basic_course_full.pdf) correctly it would imply that your blinds always do a step "up" first and then move to the direction you want. Is that correct? |
Uhm, no.
Real world behavior (of my blinds): sending the group address for "up" (without stop or anything else) when they are moving down will bring the to halt for approx. ½ sec. and then starts them again. No hard change of direction for the motor. |
The driver knx_windowcoverings is causing problems in my case.
In drivers/knx_windowcoverings/device.js lines 49-51 and 64-66 a stop/step-command is issued before the up/down command. With my windowcovers this leads to timing-problems and the coverings often do not react to the up/down command.
I did not issue a pull request as I am not sure what the initial reason for this implementation was. I see two possible solutions:
The text was updated successfully, but these errors were encountered: