Roastwarden

Releases ·

Roastwarden 0.8.0

Other roasters, step three, which finishes "Any roaster" phase 2. A device can now keep its own field names, units (°F), MQTT topics and command syntax: the connection maps them, so nothing needs reflashing. A drum roaster's drum speed and damper are outputs like the heater and fan. Extra probes the owner declares (an exhaust, a third thermocouple, gas pressure) are kept with each roast, drawn, usable in alarms and exported to Artisan. An agent can add, map and check a new roaster (roast roaster add | map | check) without ever switching its control on. A simulated gas drum shows all of it working. The ESP32 works as before.

Added

  • Adding a roaster: roast roaster add | map | check (ROADMAP Next 47, Add a roaster): an agent (admin token) adds a roaster, its connection (presets: stock aArtisan, Tasmota, ESPHome, Artisan WebSocket) and its setup at control off; maps its fields (--field, --units, --topic, --column, --register, --command), trying the mapping on the newest message first (--try); and checks it. The server keeps each connection's newest raw message (GET /api/roaster/{id}/raw; MQTT, WebSocket, TC4 lines, Modbus registers) and previews a mapping on it (POST …/ingest/preview). The check (GET …/check; dashboard: the roaster's Check tab) judges the rate, BT and ET, units (°F at idle), declared outputs and channels, caps and control; the owner's write check (POST …/check/write) sends heater 10 % to a cold roaster and always ends with emergency stop. Roasters → a connection → Mapping edits the mapping with the live preview.
  • An admin token may set up a roaster while its control is off and stays off (session 23 decision, owner to confirm; Roaster kind and control level, "Tokens and the setup"): raising control stays the owner key's.
  • The simulated drum virtual_drum (Simulated roasters): a gas drum beside the fluid bed simulator that speaks its own MQTT in °F, set up through the normal connection, mapping and setup on first switch-on (Roasters → Simulator, PUT /api/virtual-roaster {"drum": true}, RUSTROAST_VIRTUAL_DRUM); turning point near 1:30 and first crack near 9 minutes at 60 % burner.
  • Hermes tasks 38 (set up a TC4 logger, control off) and 39 (check the simulated drum).
  • Ingest mapping and command templates (ROADMAP Next 45, Mapping a device's own names): a connection may carry its device's own field names, units, topics and command syntax, so a device works without reflashing. MQTT: a topic prefix and telemetry topic of its own, JSON paths per role (bt ← MAX31855.Temperature), °F, scale and offset, extra channels, per-field topics (ESPHome style: a sample on BT's message, fields older than 10 s left out), and command templates (heater → cmnd/roaster/Dimmer {value}); the server subscribes to the topics as connections change, and a topic belongs to one roaster (400 naming the other). The WebSocket client: the same, plus a poll message with {id} for devices that answer requests (Artisan's WebSocket protocol). TC4: units: F (UNITS;F) and columns for a device's own CSV; templates for its lines. Modbus: a role per register (migration 047; the register map editor's Role column), read as the role's field and written by its command, °F registers converted. A connection without these keys works as before; the ESP32's is unchanged. roast roaster show prints a mapping line per connection.
  • Drum and damper: two more outputs a roaster's setup may declare (no kind declares them), POST /api/roaster/{id}/control/drum|damper, gated like the fan (manual and full; undeclared 409 OUTPUT_NOT_DECLARED; shaped to the range), carried by every transport (a TC4 needs a template), kept with each sample, and a Drum and a Damper slider on the Roast page's Control tab only when declared. Not yet in Profile drive, alarm actions or the roast sequence.
  • Declared channels (ROADMAP Next 46, Extra channels): a roaster's setup declares the extra values it sends that the owner wants kept (an exhaust probe, a TC4's t3, burner pressure): key, label, unit (C, % or another, with an optional top), at most 8; migration 048. Each roast keeps a declared channel with every sample (session_telemetry.extras, from the in-memory setups); the scope draws it (°C on the temperature axis in the owner's unit, % on the output axis, another unit on its own right-hand axis) with a legend toggle, and so do the history chart and the PDF roast report. Alarms gain channel_above / channel_below with a channel key; the .alog export writes the channels as Artisan +Virtual extra devices (two curves each) and still writes no extra* key when none is declared. roast roaster show lists the channels and roast review prints each at CHARGE, first crack and DROP (channels). The Setup panel's Channels block declares them (keys offered from what the roaster sends now). The ESP32 and the virtual roaster declare none and are unchanged.