Skip to content
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

Closed
Istaroth opened this issue Jun 2, 2024 · 3 comments
Closed

Unnecessary stop before up/down #20

Istaroth opened this issue Jun 2, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@Istaroth
Copy link
Contributor

Istaroth commented Jun 2, 2024

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:

  1. (preferred) just delete the stop/step commands in lines 49-51 and 64-66
  2. insert some short delay between the stop/step and up/down
@ttherbrink ttherbrink added the bug Something isn't working label Jun 4, 2024
@Istaroth
Copy link
Contributor Author

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).
It also does not make sense, as for motors in rest, the stop/step command starts the motors and the directly following up/down stops them shortly and starts them again, which is bad for the 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.

@ttherbrink
Copy link
Contributor

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?

@Istaroth
Copy link
Contributor Author

Istaroth commented Jun 13, 2024

Uhm, no.
My interpretation:

  • up/down when already in motion will only switch (or keep) direction - but this seems to be the intended behavior, no stop needed before
  • stop/step stops motion or initiates a short step when in rest.
    (Referring to chapter 6.2 which is on page 13/25 but the 24th page in the document ;-))

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Development

No branches or pull requests

2 participants