New Suuntolink to Replace Moveslink2

[Dimitrios Kanellopoulos]

Thanks. I’ll ask and investigate this for you

[lexterm77]

For A3P (pid001b) sample id 31 bike power (uint16) data type is same as on S series, there shouldn’t be a reason whatsoever for excluding it from transfer to SA, uint16 is datatype on S9B because thats how is transfered from powerpod(s).

[margusl]

@lexterm77 said in New Suuntolink to Replace Moveslink2:

there shouldn’t be a reason whatsoever for excluding it from transfer to SA

Oh but Suuntolink does not exclude power data, samples are sent to SA service, though summary values (min/max/avg) are indeed missing - https://forum.suunto.com/post/57611
Apparently it doesn’t make much difference at SA service end nor in app itself.

The way I see it, roles and responsibilities between Suuntolink and Suunto App are quite different when comparing data flows during syncing, at least for Ambits.

Suuntolink uses different API endpoint for syncing activities, something specifically crafted only for Ambit line (or at least it seemes it’s currently used only for Ambit line). So Suuntolink is free to send out pretty much anything it can and crafting something SA-compatible out of it is the role for that Amibit-specific-API-endpoint. In a way it’s quite neat, in theory it adds possibility to add Ambit-specific pieces to Suuntolink sync layer without touching that part in mobile apps (less braking changes and test cases for SA, less affected users when something goes wrong). And handling most of that data processing/transforming at server side with a piece that only affects Ambit users has the same benefit, there’s less risk breaking things for majority of users. And generally such proxy layers are also helpful for keeping down the complexity of data models.

But for end users it just means that if something is taken as granted for Spartans/S-line, it might take a looong time (infinity in the worst case) before it gets (re)implented for Ambits in SA.

[fethiyetour]

This post is deleted!