Remove phantom pedal strokes.

[jeremydk]

If the last cadence received by gymnasticon is non-zero, we continue to fire off phantom pedal strokes (which continuously reset the pingInterval). We can remove the pingInterval resetter from onPedalStroke, and force the cadence to zero if we receive a ping request (i.e. no stats received in the last second).

I've tested this from my Peloton and all looks good, but would need to have someone validate the flywheel behavior.

This should address #32

[ptx2]

Just gave it a try on the Flywheel bike. I did notice something that might need a look into. It seems possible to get in a situation where we stop generating pedal strokes depending on the timing of ping interval and stats events.

It's possible to reproduce with the bot like this:

gymnasticon --bike bot --bot-power 60 --bot-cadence 50 --bot-host 127.0.0.1 --bot-port 3000

I think the issue is with setting simulation.cadence to 0 periodically.

I realized there is actually a timer in there to handle this already but I made a typo so it's not actually firing ;-) If you rename opts.bikeStatsTimeout to opts.bikeReceiveTimeout in the statsTimeout Timer initialization, it will bail shortly after the bike stops sending data, the idea being that systemd will restart it. I pushed up a change which uses that timer to fix the immediate problem but there's an unsolved problem I'm running into where if you exit a ride and re-enter, Zwift appears to require you to manually rechoose the power/cadence sensors before they'll work again. Out of time for today but I pushed up what I have so far here: https://github.com/ptx2/gymnasticon/compare/peloton-stats-timeout

[ptx2]

Ok I just reverted those changes and pushed up something different to that same branch. It just sends the app a single zero stats event after the user has left the ride. I've tested it a bit here and looks good -- what do you think?

[jeremydk]

That proposed change makes sense to me -- scopes us just to the peloton, and uses the fact that the serial connection is very chatty, so a 1s timeout makes a lot more sense. Wasn't a fan of letting systemD flap the service -- it would work but it felt a bit off to me.

[ptx2]

I wasn't a huge fan either :-) I'll go ahead and merge that in. Thanks for the help finding and fixing this!