meshcore-client

Commit Graph

Author	SHA1	Message	Date
Strycher	4d7921d2f7	feat(#89 ): verify broker enable/disable actually applied before confirming A firmware build can ACK a broker enable/disable as success without applying it (HV4; meshcore-firmware#179). The quick toggle and the editor save previously trusted the ACK and showed a success snackbar, so an ack-but-no-op looked like it worked. Both paths now SET, wait a short settle, re-read the slot, and report what the device ACTUALLY did: - applied -> confirm - notApplied -> warn "possible firmware issue"; the editor stays and re-seeds to the device's true state instead of popping a false success - unverified -> re-read failed (e.g. an enable that rebooted the device) Every device is treated identically: the UI reflects the re-read, never assuming a change took that the device didn't confirm. - BrokerConfig.classifyApply pure classifier + BrokerApplyOutcome (unit-tested) - ObserverConfigService.applySettleDelay - wired into mqtt_brokers_screen quick toggle + broker_editor_screen save - widget test for the ACK-but-not-applied path Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	4 weeks ago
Strycher	2ac0755361	fix(#80 ): only URL/port gate a broker enable; firmware owns the rest On-hardware feedback: JWT owner defaults to the device pubkey and IATA override is optional by definition, so gating a save on them is wrong -- they have under-the-hood firmware defaults. BrokerConfig.enableError now checks only the structural fields with no default: URL present, port in range. The JWT field checks are gone; the firmware enforces JWT completeness with its defaults, and a genuinely-bad enable surfaces the firmware's reason via the failure messaging added earlier. The editor's pre-save check and the list's quick Enable both follow. Tests updated to the new contract (a JWT broker with blank owner/audience now enables; a structurally-complete quick Enable confirms). Full suite green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	4 weeks ago
Strycher	0c737f2052	fix(#80 ): broker enable/disable feedback + don't validate a disable On-hardware test feedback: - Long-press Enable/Disable was silent on success AND failure. It now confirms on success and, on failure, surfaces the device's reason (lastError) instead of nothing. - The client now refuses to quick-Enable a broker that can't work (incomplete required fields, e.g. JWT without audience/owner) and says why -- so it never reports "enabled" on a broker that won't run. (Firmware should reject too.) - The editor blocked a DISABLE on blank/invalid fields. Validation now gates ENABLING only -- disabling a slot with partial values is fine; it won't be active. Validation rules shared via BrokerConfig.enableError (editor pre-save + list quick-Enable). Full suite green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	4 weeks ago
Strycher	67db108520	feat(#80 ): brokers screen + Observer-pane entry The broker pool gets its own screen, reached from a "MQTT brokers" row in the Observer pane (replacing the read-only inline list and its stale "pending firmware support" note). - MqttBrokersScreen: a tile per broker (tap -> editor, long-press -> Enable / Disable / Edit / Clear), and a + FAB that opens the next empty slot (disabled when all 10 are full) -- matching channels_screen's FAB-add pattern. Each action re-reads only the affected slot, never the full pool dump. - Observer pane: the broker section is now a navigational row showing "N configured - M enabled"; the editor is wired in end-to-end. 3/3 screen tests green; full suite green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	4 weeks ago

4 Commits (4d7921d2f72979cd9e63a2a7ea777cbb63eb6a7b)