Siri, Alexa, Hey Google, etc

[Frits1980]

Since it is impossible to touch a screen during training I was wondering if it would be interesting if we could give voice commands to ORM for instance to take a brake and pause or to start or end a recording session. Or maybe even change the metrics on screen.

like I said it’s just an idea. 😊

[JaapvanEkris]

Since it is impossible to touch a screen during training I was wondering if it would be interesting if we could give voice commands to ORM for instance to take a brake and pause

Direct interfacing with Siri, Alexa and Google is extremely complex, so it must be done via a home automation system and MQTT. We don't have the luxury of spending a lot of unpredictable CPU cycles to secondary functions, and MQTT is extremely lightweight and predictable as it is designed for IoT environments. In the 0.9.6 version, MQTT allows sending a single type of command: the updateIntervalParameters. As pauses are handled automatically (similar to the PM5 and RP3) by stop pulling the handle, there is not much added value there, but it could be done.

or to start or end a recording session.

You can't. You either record or you don't, and that binary approach is a very conscious decission. Recordings are closely tied to the workout. Especially more complex recorders, like the Garmin FIT-recorder, also report the workout plan and relate all underlying data in relation to that same workout plan. This makes the recordings extremely valueable for websites like intervals.icu, as it can use that to compare plan and execution. This also makes recordings extremely state dependent, and starting/interrupting dataflows outside the normal workflow a recipe for disaster. In essence, throwing away the workoutplan or parts of its execution is very sure way to generate files that cause havoc in consumers of these files. So, the only way to start or stop a recording is by resetting the entire workout.

As stopping/pausing the entire workout is easily done a physical stop, it comes down to the above thing.

Or maybe even change the metrics on screen.

Lars and Abasz designed the GUI to be a multi-client setup, which is a good thing as you can have a small screen showing essentials and a big screen showing a lot more. Abasz enriched that by allowing to modify the screen layout and store that on the device itself. So you can have a different layout for each monitor (which is extremely smart, as we have an 8 and 12 tile configuration). Side-effect is that you are never talking about THE screen, but always talking about A screen.

And that level of complexity, calling a screen ID and a tile number and metric is just too complex for a voice command interface. And users will have to remember it all.

[Abasz]

Technically having different layouts associated with different "users" should not be that difficult as it would only require changing the settings object it an array (or an object where key is the user) with a drop down in the settings and loader (which now only does things in startup but can be changed to be dinamic)

The user management that would require more work (it's a full crud operation flow). And I am not sure if that makes sense.

What im saying is that allowing a fixed number of "screens" that are selectable should be easy with the current GUI code.

There were there reasons there has not been work put into the gui (at least from my side): (i) Jaap mentioned that some students work on it (ii) it's core with the very light weight lit framework and the bidirectional socket communication was not designed to be easily extensible and robust, especially not for a non-frontend developer, so I/we would have required a lot of effort with it (iii) ORM is compatible with numerous apps that can serve as a GUI, many are much nicer and has more features and until the workout creator did not exist there's were not much reason (apart from the force curve!! Which is about to change) for not using them (and run ORM headless) unless you need to change peripheral settings constantly (which is not a wide spread scenario).

If I was to ever touch it again, probably I would move it to angular as I'm much more familiar with it, it has material UI designed components that makes life much simpler as well as I have ESP Rowing Monitor's GUI written in that.

[JaapvanEkris]

(i) Jaap mentioned that some students work on it (ii) it's core with the very light weight lit framework and the bidirectional socket communication was not designed to be easily extensible and robust, especially not for a non-frontend developer, so I/we would have required a lot of effort with it

Yeah, point ii sums up the lack of progress from i :)

(iii) ORM is compatible with numerous apps that can serve as a GUI, many are much nicer and has more features and until the workout creator did not exist there's were not much reason (apart from the force curve!! Which is about to change) for not using them (and run ORM headless) unless you need to change peripheral settings constantly (which is not a wide spread scenario).

I admit, although finding out how these apps work and mapping it to our internal structure is a nightmare, if it works it is extremely convenient. Especially as these apps remember preset trainings, etc..