GET /api/channels always returned [] and /api/status kept myNodeNum: null even with the bridge connected. Root cause (client-side, not device): the service wrote nothing on connect, and Meshtastic firmware only streams initial sync data (myInfo, nodeInfos, channels, configCompleteId) after receiving a ToRadio with want_config_id. All official clients send it right after connecting; we didn't.
Change
codec.ts — new buildWantConfigToRadio(wantConfigId) (verified oneof case "wantConfigId" against installed @meshtastic/protobufs)
mesh.service.ts — on socket connect: random non-zero uint32 nonce → framed want-config ToRadio written to the bridge; existing handlers (myInfo / configCompleteId / channel / packet) already consume the resulting stream, untouched
spec: new test captures the first outbound frame, decodes it as ToRadio (want-config case, value > 0), then feeds back myInfo + configCompleteId and asserts status().myNodeNum is set; fixed the send-test helper to scan all outbound frames (first frame is now want_config)
Verification
npm run build ✓
npm test — 13/13 passed (was 12, +1 new)
v0.1.4, CHANGELOG entry added
## Problem
`GET /api/channels` always returned `[]` and `/api/status` kept `myNodeNum: null` even with the bridge connected. Root cause (client-side, not device): the service wrote **nothing** on connect, and Meshtastic firmware only streams initial sync data (myInfo, nodeInfos, channels, configCompleteId) after receiving a ToRadio with `want_config_id`. All official clients send it right after connecting; we didn't.
## Change
- `codec.ts` — new `buildWantConfigToRadio(wantConfigId)` (verified oneof case `"wantConfigId"` against installed @meshtastic/protobufs)
- `mesh.service.ts` — on socket connect: random non-zero uint32 nonce → framed want-config ToRadio written to the bridge; existing handlers (myInfo / configCompleteId / channel / packet) already consume the resulting stream, untouched
- spec: new test captures the first outbound frame, decodes it as ToRadio (want-config case, value > 0), then feeds back myInfo + configCompleteId and asserts `status().myNodeNum` is set; fixed the send-test helper to scan all outbound frames (first frame is now want_config)
## Verification
- `npm run build` ✓
- `npm test` — 13/13 passed (was 12, +1 new)
- v0.1.4, CHANGELOG entry added
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
GET /api/channelsalways returned[]and/api/statuskeptmyNodeNum: nulleven with the bridge connected. Root cause (client-side, not device): the service wrote nothing on connect, and Meshtastic firmware only streams initial sync data (myInfo, nodeInfos, channels, configCompleteId) after receiving a ToRadio withwant_config_id. All official clients send it right after connecting; we didn't.Change
codec.ts— newbuildWantConfigToRadio(wantConfigId)(verified oneof case"wantConfigId"against installed @meshtastic/protobufs)mesh.service.ts— on socket connect: random non-zero uint32 nonce → framed want-config ToRadio written to the bridge; existing handlers (myInfo / configCompleteId / channel / packet) already consume the resulting stream, untouchedstatus().myNodeNumis set; fixed the send-test helper to scan all outbound frames (first frame is now want_config)Verification
npm run build✓npm test— 13/13 passed (was 12, +1 new)