Feature Discussion: (smart) grinder integration and assisted dial-in #707

The E64 WS is a recipe-driven grinder with three dosing modes:
 Manual: start/stop grinding manually.
 Grind-by-Time: grind until the recipe's time target is reached.
 Grind-by-Weight: grind until the internal load cell reaches the target dose. The same load cell can identify a previously registered portafilter and select its associated recipe.
Recipes also store a reference disc distance (DD, in microns), dose settings, and an optional Grind-by-Sync (GbS) flag. The HMI can select/edit recipes with its buttons and rotary encoder. It also provides quick manual DD/dose editing and purge; these are controls rather than additional dosing modes. The local web UI is available in either the grinder's access-point mode or station mode.
GbS is the closed-loop mode: a compatible espresso machine or Sync Scale provides a brew event, principally the observed brew time. The grinder compares that with the recipe target and its AGSA motor adjusts the electronic burr distance finer when the shot is too fast, or coarser when it is too slow. It is intended as small ongoing corrections after an initial dial-in, not as a single-shot guarantee. The built-in Assisted Dial-In wizard is a separate workflow that asks for coffee/shot parameters and brew time, suggests a DD, and can refine/assign the resulting recipe.
For the E64 WS image I inspected, the local control surface is:
HTTPS REST: POST /rest_api/<route>
TLS WebSocket: wss://<grinder-ip>:9997/?token=<short-lived-local-token>
Messages: JSON request/response envelopes
The recovered WebSocket registry includes state/config/log reads and named actions such as StartGrindManual, StartGrindGbw, StartGrindGbt, Stop, SetAgsaTargetDdValue, AddBrewEvent, and GbsCreateReport. The normal action envelope is {"type":"GrinderAction","data":{"actionType":"..."}}. This is separate from the vendor cloud API; the local WSS client does not need to call the cloud, although the officially documented Sync Scale → grinder GbS path is cloud/Machine-to-Machine based.
The E64 firmware contains a brew-event parser and an AddBrewEvent action, but we have not yet proven that a locally injected event is accepted by every firmware revision or causes a physical GbS adjustment. That makes two useful Decaid paths possible: a safe host-side recommendation mode, and an explicit, owner-enabled E64 event/actuation adapter after live validation. A Decent- attached scale or OpenScale can be normalized as an independent mass source; flow-only data must not be treated as weight.
API map
The API split is roughly:
local device Mahlkönig Sync cloud / mobile app
------------ -----------------------------
HTTPS REST /rest_api/* HTTPS https://sync.mahlkoenig.com/api/*
JSON WSS :9997 scale WSS scale.sync.mahlkoenig.com/socket/device
HMI/driver state + actuation accounts, pairing, recipes, events, analytics
local onboarding/Wi-Fi cloud device binding and firmware presentation
The local REST surface is PHP behind lighttpd. The recovered routes include session/login (ping, check_session, login, logout, update_session), device information (get_machine_info), Wi-Fi/onboarding (scan_wifi, get_wifi_info, request_onboarding), and operational or maintenance functions (reboot, get_fw_update_state, download_database, and download_machine_logs). Firmware and ESP/splash uploads are separate local PHP pages rather than normal REST routes. They should be treated as maintenance surfaces, not as part of a generic grinder driver.
The local WSS registry has 52 records: six state/config reads, provisioning and Wi-Fi messages, and 39 GrinderAction variants. The read families cover driver state/config, logs, ADC/config-manager settings, and machine info. The important control variants cover manual/time/weight grinding, stop, tare and calibration, AGSA/DD adjustment, brew-event insertion, and GBS report creation. The remaining variants expose fans, lights, language, setup state, simulated buttons/rotary input, endurance tests, ESP maintenance, and configuration updates. Exact names, payload keys, development flags, callbacks.
Local WSS requests use msgId; ordinary replies use the corresponding refId, while action replies normally contain data.success. The local web login creates a short-lived bearer token used in the WSS query string. The examined binary contains no per-message HMAC/signature scheme. These are static findings for one firmware image, not a promise that every command is enabled or safe on a production unit.
The cloud/mobile side is a different API. The Android APK contains the cloud root https://sync.mahlkoenig.com/api/, auth/token-provider code, and these route families:
 authentication and account lifecycle: security-service/auth/token, security-service/auth/refresh, password/reset and registration routes;
 device/pairing: mobile-service/device/query, device-union queries, offboarding, profile/store/region and invitation routes;
 grinder and brew history: mobile-service/grind-event/find and count, device-event/brew-event/find and count, error events, and grind totals;
 recipes: recipe presets, cloud-recipe query/slot/create/status/merge, and recipe-threshold services;
 scale/live data: ScaleApiClient plus wss://scale.sync.mahlkoenig.com/socket/device;
 dashboards, chat/help, Firebase messaging/analytics/crash/performance, remote configuration, and firmware/app-version status models.
The APK also contains local provisioning candidates such as /api/v2/network/list, /api/v2/network/connect, and /api/v2/network/forcescan, alongside /rest_api/* onboarding routes. A route literal proves only that the string is present: the exact HTTP method, headers, body, response schema, retry policy, and authorization are not all recoverable from the stripped Flutter AOT snapshot. In particular, the APK does not contain a literal E64 RequestDriverState or GrinderAction string, so stock-app-to-local-WSS compatibility remains unproven.