Skip to content

fix: align Bengle MMR units with firmware - #605

Draft
ODevStudio wants to merge 1 commit into
mainfrom
odev/bengle-firmware-mmr-contract
Draft

fix: align Bengle MMR units with firmware#605
ODevStudio wants to merge 1 commit into
mainfrom
odev/bengle-firmware-mmr-contract

Conversation

@ODevStudio

Copy link
Copy Markdown
Collaborator

Summary

  • Problem: Decaid encoded Bengle MatSetPoint in tenths, but the pinned firmware consumes whole degrees.
  • Why it matters: a requested 60 C cup-warmer target was sent as raw 600 instead of raw 60.
  • What changed: align MatSetPoint with x1 firmware units, update wire tests, and add a test-only JSON contract for every declared MMRItem, BengleMmr, BengleSteamMmr, and BengleScaleMmr value.
  • What did NOT change (scope boundary): no dependency, parser package, generator, permissions/ranges contract, A013 layout contract, serial-protocol contract, or runtime network access.

Firmware source: tadelv/Bengle MMR.def at 2377c7e0e48e9ee2c43cf02ad2f82028252f56e8

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore / infra
  • Plugin (DYE2 or bundled skin)

Scope (select all touched areas)

  • BLE transport / device comms
  • REST API / handlers
  • WebSocket API
  • Machine state / shot logic
  • Scale / weight / flow
  • Profiles / beans / grinders / workflows
  • WebUI skins
  • Plugins / JS runtime
  • UI / Flutter widgets
  • Storage / Drift database
  • CI / build / infra
  • Docs / specs

Linked Issues

Root Cause (if bug fix)

  • Root cause: MatSetPoint followed the x10 convention used by several temperature registers even though its firmware entry uses multiplier 1.
  • Missing detection or guardrail: app MMR declarations had no contract pinned to a reviewed firmware revision.
  • Contributing context (if known): v13Model also demonstrates why effective wire scaling must follow the actual firmware path rather than copying a nominal table column.

Regression Test Plan (if bug fix or refactor)

  • Coverage level that should have caught this:
    • Unit test
    • Integration test (mock transport edge)
    • End-to-end test (simulate=1 + curl/websocat)
    • Existing coverage already sufficient
  • Target test or file: test/unit/models/device/impl/bengle/mmr_contract_test.dart and test/models/device/bengle_cup_warmer_test.dart
  • Scenario the test should lock in: all 34 app MMR declarations match the pinned address, length, and effective scales; cup-warmer writes use raw 60 and clamp at raw 80.
  • If no new test added, why not: N/A

Documentation Obligations (required)

  • API spec updated: assets/api/rest_v1.yml or assets/api/websocket_v1.yml (if REST/WebSocket changed)
  • API docs updated: doc/Api.md (if user-facing endpoint changed)
  • Plugin docs updated: doc/Plugins.md (if events/API changed)
  • Skin docs updated: doc/Skins.md (if skin behavior changed)
  • Profile docs updated: doc/Profiles.md (if profile handling changed)
  • Device docs updated: doc/DeviceManagement.md (if device flows changed)
  • N/A - no docs affected

The REST contract remains degrees Celsius in the existing 0..80 range.

Security Impact (required)

  • New or changed REST endpoints? (Yes/No): No
  • New or changed WebSocket topics? (Yes/No): No
  • New or changed network calls? (Yes/No): No
  • BLE/USB surface changed? (Yes/No): Yes
  • File system access changed? (Yes/No): No at runtime; one unit test reads its tracked JSON fixture.
  • Plugin sandbox boundary changed? (Yes/No): No
  • If any Yes, explain risk and mitigation: the existing cup-warmer write uses the firmware's x1 encoding instead of x10. The public 0..80 C validation is unchanged, and transport tests assert raw writes and reads.

User-Visible Changes

Cup-warmer REST values remain degrees Celsius in the 0..80 range, but Bengle firmware now receives the correct whole-degree wire value.

Verification

Local gates (run before pushing)

  • dart format lib test - no remaining changes
  • flutter analyze - clean (no new warnings)
  • flutter test - all pass
  • ./scripts/fetch_dye2_plugin.sh - DYE2 plugin installed into assets/plugins/dye2.reaplugin/

Focused tests: 4 passed. The full suite ran to completion; its only failure was the pre-existing Windows CRLF-sensitive assertion in test/connect_result_schema_test.dart.

The fetch script could not be rerun because WSL startup is denied and jq is unavailable in this Windows shell. The existing bundled DYE2 v0.1.4 manifest, API version, permissions, and createPlugin entry point were validated locally.

Manual verification (if applicable)

  • OS / platform tested: Windows
  • Simulated devices? (simulate=1): No
  • Real hardware? (DE1/Bengle/scale): No
  • What you personally verified and how: compared the fixture with the pinned firmware source through a read-only GitHub API request, then ran the contract and mock-transport cup-warmer tests.
  • Edge cases checked: duplicate-free app and firmware names, complete enum coverage, effective x1 v13Model, whole-degree MatSetPoint, and the 80 C clamp.
  • What you did not verify: real Bengle hardware or a native Windows live app. The local native build is blocked by VS2019/CMake and universal_ble runtime incompatibilities.

Evidence

  • Test output (failing before + passing after)
  • Log snippets
  • Screenshot / recording (UI changes)
  • curl / websocat output (API changes)

Before correcting MatSetPoint, the new contract test reported x10 instead of x1. Afterward all 4 focused tests passed.

Compatibility & Migration

  • Backward compatible? (Yes/No): Yes
  • Config / env changes needed? (Yes/No): No
  • Database migration needed? (Yes/No): No
  • If any No or Yes, explain exact steps: no migration or configuration changes are required.

Risks & Mitigations

  • Risk: the fixture represents one firmware revision and must not silently imply future firmware compatibility.
    • Mitigation: the repository, commit, and path are asserted in the test; adopting a newer contract requires an explicit fixture pin update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant