It’s natively supported via BreakAway for some time now. (some hacks required when creating workouts via Intervals.icu Workout Builder. Then the workouts are sync’ed to the app and you can get auto-switching)
would be great if/when this is native in the workout builder tho
Does “freeride slope=5%” entered as a step in ICU workout editor pass through and actually set your trainer slope to 5%? or just switch to freeride without the 5%?
Breakaway looks great, but I don’t have any iOS devices. I have Windows and Android. Auuki will work on super cheap repurposed Phones, Chromebooks and tablets in the browser.
Auuki supports auto switching, but as far as I can tell, the only command I can pass through to Auuki from the workout editor is “freeride” which will set it to slope mode, but won’t change the slope.
I can go in and modify the xml, but that is a bit tedious.
FYI… I’m running BreakAway on an 12yr old iPad Mini 2 (2013) on iOS12
I also remember there was discussion about getting slope to be sent to zwift under freeride but the discussion ended as currently zwift’s parser is very strict and doesn’t (yet?) accept slope.
Currently the editor will not pass through any slope related settings to the xml / zwo file. I’ve experimented, then opened the zwo in notepad and the slope related notations are gone. I’ve also gone in reverse by editing a zwo in notepad, testing it in Auuki to confirm that the slope notation worked, then imported the zwo into the editor and the slope notations were scrubbed.
Maybe you @dmarinov and @david could agree on a format / notation to use in the editor that would work in your app and Auuki (as well as others if possible)
The auto switching from erg to slope is so nice…really opens up some new / improved ways to build some great intervals into a workout.
Well my proposition is to extend the zwo format with custom attributes.
Zwo being an xml based format makes it the best candidate for extension:
such practice already exists
xml is s easy to parse / parse-print
Currently the format has the following naming convention:
Power for power on <SteadyState /> and other single target elements
OnPower and OffPower for <IntervalsT /> and other multi target elements
Adding the following will be inline with the current naming conventions:
Slope for <SteadyState /> and other single target elements
OnSlope and OffSlope for <IntervalsT /> and other multi target elements
That boils down to adding another target attribute. Given that the bluetooth FTMS protocol for trainers supports Power, Resistance and Slope targets, this is only natural to have those in the workout format.
The value of the target could be either an Int with agreed precision similar to the way it’s defined in bluetooth FTMS or just a Float.
PROs:
custom attributes are already a common way to extend xml based formats
custom attributes would not create conflicts with the existing parsers, because they can simply ignore the attributes they don’t support
It’s easy to add support to the existing parsers and parser-printers for custom attributes
the feature will be unique for the apps that support it
CONs:
the feature will be unique for the apps that support it
while it doesn’t break compatibility across the industry it creates a complication
the custom attributes naming may conflict with future attributes created by Zwift, although this is solvable by just using a prefix like Data where Slope would become DataSlope, similar to the way that same issue is resolved in HTML
I think that setting Slope targets in workouts should be supported. Don’t know if creating a custom extension to the zwo format is the right course of action, but it seems to provide the least friction with the existing software. Anyway I am open to ideas.
My Current implementation is to use the JSON format and add the “hack”. #x.x% SLOPE#
in the text of the workout.
in any case, the implementation backend comes down to how intervals.icu wants to implement it. When it’s implemented, the slope target will just get parsed and output to JSON /ZWO or whatever format that supports it/supports slope.
I could implement something like that, but I am afraid this approach will move too much complexity towards the User, and people just won’t use the feature that much, because it might be too technical.
I created a basic workout with this syntax and I see that it adds the Slope target as a message attribute to a <textevent /> element inside the exported zwo file.
@dmarinov If @david allowed statements such as slope = “5.0” (for example) to pass through into the zwo, what would Zwift do with that value? It does not support slope so would it just ignore it? If Zwift ignores it then there would be no downside to allowing a statement like that to pass through?
@Max_Nelson
Parsers should be able to ignore the Slope attribute if they don’t know what it is.
Just ran a test with Zwift. And can confirm that it works. Zwift ignores the slope targets and uses only the power targets in ERG mode, while Auuki sets the power targets and runs the trainer in slope mode.