Follow-up: I ran the test, and I can answer my own question 5. The eviction path does not release the app’s JS context, and the shared heap is exhausted inside a single four-minute exercise. Method: fresh reboot, one exercise, three apps enabled, triggering the eviction repeatedly by switching screens and opening/closing the map. After each eviction I re-enabled my app from the SuuntoPlus menu without ending the exercise. Four evictions in four minutes # time how long my app survived after being enabled 1 14:48:40 118 s 2 14:49:07 14 s 3 14:49:57 33 s 4 14:50:27 15 s 118 s the first time, 21 s on average afterwards — an 87% collapse. The heap is at 99.5% Two lines from the firmware itself, 16 seconds before the first eviction: 14:48:24 : WRN UI_FRAMEWORK : JsTotMem 129980/133120 (97.6%) 14:48:29 : WRN UI_FRAMEWORK : JsTotMem 132412/133120 (99.5%) This is the only figure the system has ever given me about its own limits, and it is not documented anywhere. An earlier report on this forum (topic 15490) describes the watch freezing at essentially this same level. Nothing is ever released None of the four evictions is followed by JS discard. The first and only one in the whole session appears at 14:50:35, when I stop the exercise. So every Disable → Load script → Enable cycle instantiates the module scope again while the previous one is still held. That also reframes the “three apps” case. It is not that a third app is too big — my own footprint is 12.4 KB, resident main.js plus the single mounted template. It is that three apps cycling through evictions exhaust a shared pool that nothing empties until the exercise ends. One caveat on reading this The intervals between evictions look almost constant (27, 50, 30 s). That number measures how fast I re-enabled the app by hand, not the watch. Survival time is the honest metric. And the last three survival times being similar does not mean it stabilised — it means the pool was already full before I started measuring. At 99.5%, any re-enable trips the release callback almost immediately. So, concretely Is Zapp X:Disable without a following JS discard expected to leak the module scope? If yes, a firmware eviction is not a recoverable event — it permanently consumes shared heap, and the watch degrades within a single session. Is there a supported way to make an app release its context on eviction, or to be re-enabled cleanly within the same exercise? What is the intended budget per app against the 133 120 B shared heap when three apps are enabled, which is the configuration FW 2.50.26 added? I have the full logs and the built blob available if that helps, and I am happy to run any test you would like measured.

@Starfish2045 Hi, I Had a similar issue, getting an error inside VSC while trying to find the connected watch and found that manually running the SDSApplicationServer did work out, but after an update to the VSC Extension it stopped working because the extension closed the external instance i ran in the beginning. Tried modifying the SDS.js with no success. Would you mind posting the change you’ve made?

@brechtvb Thanks a lot for your reply! I really appreciate you sharing your experience and the Bosch eBike project. It looks like a great starting point for understanding how BLE communication works in Open SuuntoPlus. My goal is actually quite simple. I’d like to connect to a GoPro and display information such as: Recording status Battery level Remaining storage or recording time At least for the first version, I don’t even need camera control. I’ll definitely take a look at the project you shared. If I make any progress, I’ll post an update here so others can benefit as well. Thanks again!

Fixed. “modificationTime”: was wrong in the manifest.json.