@BambamNZ I’ve created this issue to track the request:
I’m also adding some detail on how refresh intervals currently work within the configuration below and in the issue:
Currently the integration will obey an update_interval setting in the YAML configuration, but defaults to 15 seconds. When API call detects that the user is online, this is decreased to 2 seconds to give more frequent data. If we receive a 429 response from the API for polling too frequently, the online update interval will be throttled back by 0.25s on the next retry until 429s are no longer received.
if you wish to reduce the offline polling frequency, you can add an update_interval setting in your YAML configuration for the integration. However, the disadvantage here when compared to your proposed switch is that if you happen to log on to Zwift and start cycling within 60 seconds, you are likely to miss the first bit of incoming data. Once online, data will update every 2 seconds (subject to throttling from the server)
I’ll also add that I don’t often get free time to work on this integration these days, so I am incredibly open to contributions from anyone that wishes to help update the integration to support requested features and some of the upgrades the integration needs to support many of the newer functionalities within Home Assistant (UI configuration, reloading, multiple instances of the integration,etc)
I still use the integration myself pretty dang frequently, so I will quickly become aware of anything that breaks functionality and can help fix.
Thanks, @snicker - I’ll check that out the next time I log in and let you know what I see.
I’d also like to contribute, but I’m just now dipping my toe into all this, so I’ve probably got a lot to learn before I’m useful. I’ll do what I can, though, because I love this integration.
I did verify today that I do still have this data coming from the Zwift API on my account, so the value is still there. I am just now wondering if the value is absent if unconfigured for a user on the server side, and if absent, we should assume imperial. @gsarjeant please report back and if so, I can modify the integration to behave correctly (or offer a configuration setting to force it)
Is it possibly just a string/boolean issue? It looks like is_metric is directly returning the value from the API if it exists, so if that’s a string that is lowercase false, perhaps python is interpreting it as truthy?
@snicker FYI I think I was wrong. It looks like is_metric() only affects the units that are displayed, and that’s correct on my end. I see “miles” in the display on Home Assistant. It’s just the distance coming out of the API that’s metric. I ssh’d into my Home Assistant and modified is_metric() so it always returned False and there was no change in behavior (I restarted Home Assistant just in case that’s necessary).
Makes me wonder if Zwift is always reporting distances in metric and the conversion to imperial happens in the app for those of us who use it. That would be a simpler implementation on their end. But then I feel like someone else who’s using imperial units would have noticed this.
Or maybe nobody uses imperial and I’m about to get my Zwift card revoked.
@snicker Just FYI, I’m working on a PR for this. I have the distance and speed working, but somehow I’ve messed up the gradient in the process. I suspect I don’t actually understand how Zwift is reporting altitude. I’m hoping to work that out this weekend and get the PR over.
