New Suuntolink to Replace Moveslink2

margusl

@Dimitrios-Kanellopoulos , yes, we do get smlzips on Android with A3P / Traverse - https://forum.suunto.com/post/57111 .
Not sure if they follow the same structure as for Spartans and S. Though most SML tools still expect classic Moveslink2-style XML SMLs, while smlzips are zipped (not gz-ed) jsons (samples.json, summary.json) . And last time I checked those smlzips still lacked power. And it doesn’t matter much for Ambit1 / 2 users.

mountainherder

@Dimitrios-Kanellopoulos, just to give you one more data point: @margusl’s folder structure is very similar to mine after syncing my watch.

.
├── ./blob_storage
│   └── ./blob_storage/d76f0e9d-4ea0-45a6-9791-f9d310b318c4
├── ./cacert.pem
├── ./Cache
│   ├── ./Cache/data_0
│   ├── ./Cache/data_1
│   ├── ./Cache/data_2
│   ├── ./Cache/data_3
│   ├── ./Cache/f_000001
│   ├── ./Cache/f_000002
│   ├── ./Cache/f_000003
│   ├── ./Cache/f_000004
│   ├── ./Cache/f_000005
│   ├── ./Cache/f_000006
│   ├── ./Cache/f_000007
│   ├── ./Cache/f_000008
│   └── ./Cache/index
├── ./Code Cache
│   └── ./Code Cache/js
│       ├── ./Code Cache/js/2ab3d68638e1f582_0
│       ├── ./Code Cache/js/61eb8826be844072_0
│       ├── ./Code Cache/js/815d3f396b507780_0
│       ├── ./Code Cache/js/8aaa4c58c851cb5d_0
│       ├── ./Code Cache/js/c719a65d0471102d_0
│       ├── ./Code Cache/js/index
│       └── ./Code Cache/js/index-dir
│           └── ./Code Cache/js/index-dir/the-real-index
├── ./Cookies
├── ./Cookies-journal
├── ./databases
│   ├── ./databases/Databases.db
│   └── ./databases/Databases.db-journal
├── ./descr+################+2.4.17
├── ./Devices.xml
├── ./GPUCache
│   ├── ./GPUCache/data_0
│   ├── ./GPUCache/data_1
│   ├── ./GPUCache/data_2
│   ├── ./GPUCache/data_3
│   └── ./GPUCache/index
├── ./KompostiSettings.xml
├── ./library.xml
├── ./Local Storage
│   └── ./Local Storage/leveldb
│       ├── ./Local Storage/leveldb/000003.log
│       ├── ./Local Storage/leveldb/CURRENT
│       ├── ./Local Storage/leveldb/LOCK
│       ├── ./Local Storage/leveldb/LOG
│       ├── ./Local Storage/leveldb/LOG.old
│       └── ./Local Storage/leveldb/MANIFEST-000001
├── ./Network Persistent State
├── ./Preferences
├── ./QuotaManager
├── ./QuotaManager-journal
├── ./sds.log
├── ./ServiceAdapter.xml
├── ./Session Storage
│   ├── ./Session Storage/000003.log
│   ├── ./Session Storage/CURRENT
│   ├── ./Session Storage/LOCK
│   ├── ./Session Storage/LOG
│   ├── ./Session Storage/LOG.old
│   └── ./Session Storage/MANIFEST-000001
├── ./sgee.7d
├── ./suuntoapp.1.log
├── ./suuntoapp.log
├── ./suuntolink_data.json
├── ./SuuntolinkLauncher.log
├── ./suuntolink.log
├── ./suuntolink_ui.log
└── ./TransportSecurity

11 directories, 60 files

I was able to follow the instructions @margusl provided and extract the sml files via MovesLink (for use in GoldenCheetah). Thanks for looking into this!

Mff73

i am not that skilled in info tech, but no SML in Suuntolink folder for my Ambit one neither. I get them from Android (if i need, but in fact i use the fit file now from SA )

A bit off topic here, but just to comment on something i tried and it works = change a workout Ascent and Descent total in SA.

Switch off internet connection on Android smartphone before syncing workout
Edit and save the summary.json file into the entryxxxxxxxxxxx.zip files and change ascent/descent values for the global workout (not all laps/splits ascent value).
Once internet is on again, SA will sync to servers and new ascent is saved.

i find no way to change after syncing to servers.

Dimitrios Kanellopoulos

Also a question. Are you syncing to SA with the Ambit or to Movescount?

Another question OSX/Win ?

I am going to ask Suunto for this since I am still in Germany and cannot help.

lexterm77

Also,

Are temperature graphs still there?

Dimitrios Kanellopoulos

Guys if you are on windows are you looking into

C:\Users\<username>\AppData\Roaming\Suuntolink

for *.json and *.json.gz files. ?

mountainherder

@Dimitrios-Kanellopoulos Yes. For me the only file .json file is

C:\Users\<username>\AppData\Roaming\Suuntolink\suuntolink_data.json

There are none in the sub-directories. That file consists of the following (with tokens and unique identifiers redacted):

{
  "language": "en",
  "recommended_config_checked": true,
  "slversion": "3.1.3",
  "devices": {
    "################": {
      "name": "Suunto Ambit3 Peak",
      "manufacturerName": "",
      "askoAccessToken": "",
      "askoRefreshToken": "",
      "askoUser": "username",
      "syncedLogs": [
        1595490873,
        1595142447,
        1591985815,
        1592062177,
        1592155549,
        1592329067,
        1592418024,
        1592589666,
        1592675773,
        1592849754,
        1592897531,
        1593109625,
        1593199763,
        1593253985,
        1593452909,
        1593544075,
        1593627150,
        1593709463,
        1593878758,
        1593974145,
        1594064561,
        1594148438,
        1594325551,
        1594406503,
        1594555052,
        1594836687,
        1594921100,
        1595100948
      ],
      "syncTime": 1595551558217,
      "userkey": "####################################",
      "email": "",
      "manufacturer": ""
    }
  },
  "toggles": { "autostart_suuntolink": false }
}

margusl

@Dimitrios-Kanellopoulos , that’s exactly where those file lists we provided above are from.

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!