@condorinst/mobile-bridge 0.23.0 → 0.23.1

package/docs/bridge-contract.md

@@ -32,7 +32,7 @@ Four numbers coexist. Only one tells you what the device can do.
 | `nativeVersion` | `0.18.0` | **The capability signal.** The bridge schema the app on this device implements. No Canvas release is in the field yet; the first one implements `0.18.0`. Later releases will coexist with it on phones for a while, so read it at runtime — never assume the latest. |
 | `shellVersion` | `0.6.0` | The Condor shell wrapping your iframe. |
 | client protocol | `0.5.0` | The postMessage protocol `BridgeClient` speaks. |
-| package | `0.23.0` | The npm version you compiled against. |
+| package | `0.23.1` | The npm version you compiled against. |
 
 ```ts
 const ack = await BridgeClient.handshake({ clientVersion: '1.0.0' });
@@ -423,8 +423,8 @@ stops it. Send `add` for each device after the list arrives.
 - **"Disconnected" is the normal state.** An ActLumus is not connected all the
   time: it opens a short BLE session to sync every few minutes
   (`devicesConfig[].bleConnectionPeriod`, in minutes) and the app disconnects
-  it as soon as the sync ends, successful or not — unless `realTime` is on for
-  that device (below).
+  it as soon as the sync ends, successful or not. With `realTime` on, the app
+  does not disconnect it, but the session still ends within minutes (below).
   Show the last sync time (`devicesTelemetry[].updataDateTime`) rather than a
   red "offline" badge.
 
@@ -444,11 +444,15 @@ connected, and their ack does **not** mean "done":
 - **Do not disable these actions while the device is disconnected.** Say what
   will happen instead: "The clock will be set at the next sync" / "The memory
   will be erased after the next sync uploads its data".
-- **`realTime` keeps the session open.** With it on, the app does not
-  disconnect the device after the sync: readings keep flowing until you switch
-  `realTime` off (then the session ends) or the BLE link drops. Readings stop
-  when the session ends and resume at its next session while `realTime` stays
-  on. There is no "last connection" field: the last sync
+- **A live session is short.** With `realTime` on, the app does not
+  disconnect the device after the sync, and switching `realTime` off ends the
+  session. But on a real device (an ActLumus Plus on an Android tablet, twice)
+  the session ended about **3 minutes** after it started, with `realTime` still
+  on — the link or the device ends it, not the app. Design "live" as a few
+  minutes per sync, not a continuous stream: say "connected now" only while
+  readings arrive, and expect the next readings at the next session
+  (`bleConnectionPeriod`). Readings stop when the session ends and resume at
+  its next session while `realTime` stays on. There is no "last connection" field: the last sync
   (`devicesTelemetry[].updataDateTime`) is the closest one. The app switches `realTime` off for every
   device when it restarts — switch it on again from your screen when you need
   it, and off when the person leaves that screen.

package/docs/device-testing.md

@@ -175,7 +175,7 @@ under it, as on the phone.
 | `scenario` | the scenario in use, after every override |
 | `log` | everything sent, answered and dropped: `{ at, kind, command?, key?, detail, args?, payload? }[]`. `detail` is a shortened line; `args` (sent) and `payload` (reply) are complete |
 | `setStatus({ internet: false })` | changes `systemStatus` and emits it, as the app does; without internet `sensorLog` fails, and it recovers with `{ internet: true }` |
-| `setConnected(deviceId, true \| false)` | starts or ends a device's BLE session: `deviceConnection` (if you sent `add`), the `deviceLightSensors` stream (if `realTime` is on) and the sync's `deviceNotification` steps, 200 ms apart, ending in `pipeline_done_notification`. As on the phone, the session then **ends by itself** — unless `realTime` is on for that device, which keeps it open until `realTime` goes off |
+| `setConnected(deviceId, true \| false)` | starts or ends a device's BLE session: `deviceConnection` (if you sent `add`), the `deviceLightSensors` stream (if `realTime` is on) and the sync's `deviceNotification` steps, 200 ms apart, ending in `pipeline_done_notification`. As on the phone, the session then **ends by itself**; with `realTime` on it lasts until `realTime` goes off or 3 min after it started (`realTimeSessionMs`), whichever comes first |
 | `emit(key, payload)` | any native event, typed as in `docs/bridge-contract.md` — e.g. `emit('language', { deviceLocale: 'pt-BR', appLanguage: 'pt', resolvedLanguage: 'pt' })` |
 | `setConfirmations('accept' \| 'decline' \| 'ask')` | answers the app's confirmation dialog for you |
 | `pressBack()` | the OS back button |
@@ -200,6 +200,7 @@ scenario; every field is optional:
   "logPeriodS": 300,
   "firstSessionAfterMs": null,
   "sessionFailAt": "get_data_log",
+  "realTimeSessionMs": 30000,
   "history": { "days": 14, "dockHours": [7], "gapHours": [2, 3], "gapDates": ["2026-10-18"] },
   "sensorLogFailOnRequest": 3,
   "userDeviceError": "NETWORK",
@@ -300,7 +301,7 @@ dev.kill();                                          // node, not npx: no orphan
 
 The harness does nothing on its own after load, except one session (the first
 device of the `default` scenario connects after 3 s, syncs, and disconnects
-about 4 s later unless `realTime` is on). Internet loss, a
+about 4 s later, or up to 3 min later with `realTime` on). Internet loss, a
 device disconnecting, or a reading arriving are things your test does through
 `window.condorDev`.
 

package/examples/minimal-home/package.json

@@ -14,7 +14,7 @@
     "node": ">=18"
   },
   "dependencies": {
-    "@condorinst/mobile-bridge": "^0.23.0"
+    "@condorinst/mobile-bridge": "^0.23.1"
   },
   "devDependencies": {
     "@types/node": "^22.0.0",

package/llms-full.txt

@@ -1,4 +1,4 @@
-# @condorinst/mobile-bridge 0.23.0 — full documentation
+# @condorinst/mobile-bridge 0.23.1 — full documentation
 
 Generated from the files listed below, in reading order. Payload types are
 canonical in dist/index.d.ts; the machine-readable contract is
@@ -138,12 +138,12 @@ build. Copy it, then install, so its `package.json` is the one you keep:
 
 ```bash
 mkdir my-home && cd my-home
-npm pack @condorinst/mobile-bridge@^0.23.0 && tar -xzf condorinst-mobile-bridge-*.tgz
+npm pack @condorinst/mobile-bridge@^0.23.1 && tar -xzf condorinst-mobile-bridge-*.tgz
 cp -r package/examples/minimal-home/. . && rm -rf package condorinst-mobile-bridge-*.tgz
 npm install
 ```
 
-In a project you already have: `npm install @condorinst/mobile-bridge@^0.23.0`
+In a project you already have: `npm install @condorinst/mobile-bridge@^0.23.1`
 (the caret gives you patches only while the package is below 1.0.0) and copy
 `build.mjs` from `node_modules/@condorinst/mobile-bridge/examples/minimal-home/`.
 
@@ -338,7 +338,7 @@ Four numbers coexist. Only one tells you what the device can do.
 | `nativeVersion` | `0.18.0` | **The capability signal.** The bridge schema the app on this device implements. No Canvas release is in the field yet; the first one implements `0.18.0`. Later releases will coexist with it on phones for a while, so read it at runtime — never assume the latest. |
 | `shellVersion` | `0.6.0` | The Condor shell wrapping your iframe. |
 | client protocol | `0.5.0` | The postMessage protocol `BridgeClient` speaks. |
-| package | `0.23.0` | The npm version you compiled against. |
+| package | `0.23.1` | The npm version you compiled against. |
 
 ```ts
 const ack = await BridgeClient.handshake({ clientVersion: '1.0.0' });
@@ -729,8 +729,8 @@ stops it. Send `add` for each device after the list arrives.
 - **"Disconnected" is the normal state.** An ActLumus is not connected all the
   time: it opens a short BLE session to sync every few minutes
   (`devicesConfig[].bleConnectionPeriod`, in minutes) and the app disconnects
-  it as soon as the sync ends, successful or not — unless `realTime` is on for
-  that device (below).
+  it as soon as the sync ends, successful or not. With `realTime` on, the app
+  does not disconnect it, but the session still ends within minutes (below).
   Show the last sync time (`devicesTelemetry[].updataDateTime`) rather than a
   red "offline" badge.
 
@@ -750,11 +750,15 @@ connected, and their ack does **not** mean "done":
 - **Do not disable these actions while the device is disconnected.** Say what
   will happen instead: "The clock will be set at the next sync" / "The memory
   will be erased after the next sync uploads its data".
-- **`realTime` keeps the session open.** With it on, the app does not
-  disconnect the device after the sync: readings keep flowing until you switch
-  `realTime` off (then the session ends) or the BLE link drops. Readings stop
-  when the session ends and resume at its next session while `realTime` stays
-  on. There is no "last connection" field: the last sync
+- **A live session is short.** With `realTime` on, the app does not
+  disconnect the device after the sync, and switching `realTime` off ends the
+  session. But on a real device (an ActLumus Plus on an Android tablet, twice)
+  the session ended about **3 minutes** after it started, with `realTime` still
+  on — the link or the device ends it, not the app. Design "live" as a few
+  minutes per sync, not a continuous stream: say "connected now" only while
+  readings arrive, and expect the next readings at the next session
+  (`bleConnectionPeriod`). Readings stop when the session ends and resume at
+  its next session while `realTime` stays on. There is no "last connection" field: the last sync
   (`devicesTelemetry[].updataDateTime`) is the closest one. The app switches `realTime` off for every
   device when it restarts — switch it on again from your screen when you need
   it, and off when the person leaves that screen.
@@ -1375,7 +1379,7 @@ under it, as on the phone.
 | `scenario` | the scenario in use, after every override |
 | `log` | everything sent, answered and dropped: `{ at, kind, command?, key?, detail, args?, payload? }[]`. `detail` is a shortened line; `args` (sent) and `payload` (reply) are complete |
 | `setStatus({ internet: false })` | changes `systemStatus` and emits it, as the app does; without internet `sensorLog` fails, and it recovers with `{ internet: true }` |
-| `setConnected(deviceId, true \| false)` | starts or ends a device's BLE session: `deviceConnection` (if you sent `add`), the `deviceLightSensors` stream (if `realTime` is on) and the sync's `deviceNotification` steps, 200 ms apart, ending in `pipeline_done_notification`. As on the phone, the session then **ends by itself** — unless `realTime` is on for that device, which keeps it open until `realTime` goes off |
+| `setConnected(deviceId, true \| false)` | starts or ends a device's BLE session: `deviceConnection` (if you sent `add`), the `deviceLightSensors` stream (if `realTime` is on) and the sync's `deviceNotification` steps, 200 ms apart, ending in `pipeline_done_notification`. As on the phone, the session then **ends by itself**; with `realTime` on it lasts until `realTime` goes off or 3 min after it started (`realTimeSessionMs`), whichever comes first |
 | `emit(key, payload)` | any native event, typed as in `docs/bridge-contract.md` — e.g. `emit('language', { deviceLocale: 'pt-BR', appLanguage: 'pt', resolvedLanguage: 'pt' })` |
 | `setConfirmations('accept' \| 'decline' \| 'ask')` | answers the app's confirmation dialog for you |
 | `pressBack()` | the OS back button |
@@ -1400,6 +1404,7 @@ scenario; every field is optional:
   "logPeriodS": 300,
   "firstSessionAfterMs": null,
   "sessionFailAt": "get_data_log",
+  "realTimeSessionMs": 30000,
   "history": { "days": 14, "dockHours": [7], "gapHours": [2, 3], "gapDates": ["2026-10-18"] },
   "sensorLogFailOnRequest": 3,
   "userDeviceError": "NETWORK",
@@ -1500,7 +1505,7 @@ dev.kill();                                          // node, not npx: no orphan
 
 The harness does nothing on its own after load, except one session (the first
 device of the `default` scenario connects after 3 s, syncs, and disconnects
-about 4 s later unless `realTime` is on). Internet loss, a
+about 4 s later, or up to 3 min later with `realTime` on). Internet loss, a
 device disconnecting, or a reading arriving are things your test does through
 `window.condorDev`.
 

package/llms.txt

@@ -7,7 +7,7 @@
 > pagination, permissions, system status and language.
 
 Every URL below is plain text over HTTPS, pinned to a released version, and
-needs no authentication. Replace `0.23.0` with the version you depend on; the
+needs no authentication. Replace `0.23.1` with the version you depend on; the
 contract changes between minors while the package is below 1.0.0.
 
 The same files ship inside the npm tarball, so if you have run
@@ -16,27 +16,27 @@ The same files ship inside the npm tarball, so if you have run
 
 ## Start here
 
-- [AGENTS.md](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.0/AGENTS.md): The procedure, for agents and people alike — hard rules, the golden-path boot sequence, the harness, the validation loop, and which file owns each subject. Read before writing code.
-- [llms-full.txt](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.0/llms-full.txt): AGENTS.md and every document under docs/ concatenated into one file, for a single fetch.
+- [AGENTS.md](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.1/AGENTS.md): The procedure, for agents and people alike — hard rules, the golden-path boot sequence, the harness, the validation loop, and which file owns each subject. Read before writing code.
+- [llms-full.txt](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.1/llms-full.txt): AGENTS.md and every document under docs/ concatenated into one file, for a single fetch.
 
 ## Reference
 
-- [Bridge contract](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.0/docs/bridge-contract.md): Every observable key, every command, the three error shapes, and the capability matrix by native version.
-- [Machine-readable contract](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.0/contract/bridge-contract.json): The same contract as JSON. Also importable as `@condorinst/mobile-bridge/contract`.
-- [Limits](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.0/docs/limits.md): Every hard limit — payload size, rate limits, bundle size, timeouts — with what happens when you cross it.
-- [Troubleshooting](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.0/docs/troubleshooting.md): Why a command did nothing, and why the device list never came. Silence is the platform's dominant failure mode.
-- [Testing and publishing](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.0/docs/device-testing.md): The browser harness and scripted tests, what `validate` checks, publishing from the command line, the phone, and where errors go.
-- [TypeScript declarations](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.0/dist/index.d.ts): Authoritative payload shapes, with documentation on every member.
+- [Bridge contract](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.1/docs/bridge-contract.md): Every observable key, every command, the three error shapes, and the capability matrix by native version.
+- [Machine-readable contract](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.1/contract/bridge-contract.json): The same contract as JSON. Also importable as `@condorinst/mobile-bridge/contract`.
+- [Limits](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.1/docs/limits.md): Every hard limit — payload size, rate limits, bundle size, timeouts — with what happens when you cross it.
+- [Troubleshooting](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.1/docs/troubleshooting.md): Why a command did nothing, and why the device list never came. Silence is the platform's dominant failure mode.
+- [Testing and publishing](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.1/docs/device-testing.md): The browser harness and scripted tests, what `validate` checks, publishing from the command line, the phone, and where errors go.
+- [TypeScript declarations](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.1/dist/index.d.ts): Authoritative payload shapes, with documentation on every member.
 
 ## Guides
 
-- [Pilot onboarding](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.0/docs/pilot-onboarding.md): Checklist from zero to a bundle delivered to Condor.
-- [README](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.0/README.md): Package overview, install, quickstart.
-- [CHANGELOG](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.0/CHANGELOG.md): When each capability was introduced. The most precise record of what a given native version supports.
+- [Pilot onboarding](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.1/docs/pilot-onboarding.md): Checklist from zero to a bundle delivered to Condor.
+- [README](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.1/README.md): Package overview, install, quickstart.
+- [CHANGELOG](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.1/CHANGELOG.md): When each capability was introduced. The most precise record of what a given native version supports.
 
 ## Examples
 
-- [Minimal home](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.0/examples/minimal-home/src/main.ts): A complete, working client with the reference boot sequence. Copy this as your starting point, and run it with `npx condor-mobile-bridge dev`.
+- [Minimal home](https://cdn.jsdelivr.net/npm/@condorinst/mobile-bridge@0.23.1/examples/minimal-home/src/main.ts): A complete, working client with the reference boot sequence. Copy this as your starting point, and run it with `npx condor-mobile-bridge dev`.
 
 ## Optional
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@condorinst/mobile-bridge",
-  "version": "0.23.0",
+  "version": "0.23.1",
   "description": "TypeScript SDK for the JS↔Native bridge of the Condor white-label mobile app.",
   "license": "SEE LICENSE IN LICENSE",
   "private": false,