-
Notifications
You must be signed in to change notification settings - Fork 127
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
Switch mow motor direction less frequently #71
Conversation
Rapid changes in mow direction can cause voltage spikes. Do this less frequently. I'm assuming the point of this is just to distribute wear on the blade edges so doesn't need to be done that often, just needs to average out over a number of weeks.
This PR isn't fully clear to me. The "pseudo" randomization is simply based on the second when the mow-motor get started, and not every second.
Furthermore I see another drawback: |
GPS timeout stops and starts the mow motor |
Probably can just randomly choose the direction when starting the mow area |
What do you worry about? The voltage spike which could happen if: GPS-Timeout occurs -> Motor goes off, but GPS-Fix happen again exactly GPS-Wait time before, so that Motor get immediately started again? (and probably in opposite direction) |
gps_wait_timeout only applies to undocking I think |
Draft for now, will run more testing of the voltage spikes issue |
I agree with @Apehaenger on this one, since the time is only used to "randomize" whenever the motor state changes, it should not make a difference at all. To my understanding, we could also use milliseconds here or a real random value instead of seconds without really changing the behavior of it. |
Issue this was trying to address is if GPS is flapping the mow motor is stopped and started very frequently, basically performing a full direction reversal. This builds up a lot of charge in the caps and can trigger an over-voltage error. I was probably running with a low gps timeout thou to force this though. If we just set to gps timeout minimum to a few seconds, maybe 5s, then it shouldn't be as much of an problem. The change itself just sets the direction on the 2^12th bit (so switches at most once every 4096 seconds), then the frequency setMowerEnabled is called doesn't matter. How about using 2^6th seconds instead instead to switch at most once every 64s? |
Yes, with a short GPS timeout it can indeed be a problem. The issue I see with increasing the time is that since we are using the wall time, any person who is scheduling the mow using home-assistant will always get the same mowing direction: Since undocking and GPS will add some randomness in the second-range it will probably be random with the current implementation. If we do it on hourly or minute basis, then I think for people with schedules it will effectively disable the mowing direction randomness. Probably the "correct" thing to do would be to randomize on the transition from Idle to Undocking instead of in the enable mower method. |
I'm sorry, but I can't follow your doubts. |
Shifting more won't fix ow's issue, even if we shift to one hour. It will only make it less frequent. Imagine we divide so that the direction only changes each hour and the motor gets stopped at 00:59:59 and then re-enabled at 01:00:00, it will see a rapid direction change (assuming it is still spinning in one direction). |
Adding the missing caps seems to have resolved the issue at the hardware level anyway so fine with leaving this as is, at least for now |
I'm still leaving this open for now, so that we can move the randomization to whenever the mowing starts instead of whenever the motor state is changed at some point. I think this makes it absolute sure that the direction is randomized and we don't do it too often. |
Rapid changes in mow direction can cause voltage spikes. Do this less frequently.
I'm assuming the point of this is just to distribute wear on the blade edges so doesn't need to be done that often, just needs to average out over a number of weeks.