Skip to content

Boundary: library and product

What lives in the library

The library (lib/idryer-core/) contains:

  • The entire network stack: WiFi, HTTP, MQTT, TLS.
  • The provisioning/claiming protocol.
  • The cloud state machine (CloudStateMachine).
  • UART bridge and frame protocol.
  • Integration clients (Bambu, HA, Moonraker).
  • Device interfaces (IWifiManager, ICredentialStore, IHttpClient, IProfile).
  • Arduino implementations of those interfaces.
  • MQTT topics and publish/subscribe logic.

The test for code belonging in the library: any product with any hardware can use it without modification.

What lives in the product

The product (src/) contains:

  • IProfile implementation — configuration, info payload, applyConfig.
  • Business logic specific to the device (LED control, drying, heating).
  • onInvoke / onSetCommand handlers.
  • Product sensors and telemetry publishing.
  • Peripheral initialization (FastLED, Wire, ImprovWiFi).
  • Composition root in main.cpp.

The test for code belonging in the product: without changing the hardware or configuration, it is meaningless.

Concrete examples

Code Where it lives Why
MqttClient library every product needs MQTT
CloudStateMachine library provisioning/claiming is the same for all
ArduinoWifiManager library WiFi connection does not depend on the product
LedStripProfile product specific to Storage Link TODO: use consistent Storage name throughout the doc
LedStripExecutor product controls FastLED, not needed by other devices
Sht31ClimateSensor product a specific sensor for a specific product
StorageTelemetryPublisher product knows the Storage Link telemetry format
IProfile library contract that the library calls
BambuClient library integration is reused across iDryer and iHeater

Interfaces as the boundary

The library knows about the product only through IProfile. All interaction goes through five methods:

profile->onOnline();               // library → product: first time going online
profile->loop();                   // library → product: every cycle
profile->buildInfoJson(buf, len);  // library → product: info payload needed
profile->getConfig(doc);           // library → product: config needed
profile->applyConfig(id, val);     // library → product: set command received

The product knows about the library through MqttClient (for publishing telemetry/events) and through ActionDispatcher callbacks (for commands).

What must not cross the boundary

  • The library must not include product headers.
  • The product must not call CloudStateMachine::handleProvisioning() or other private stack methods directly — only through the public API.
  • Product telemetry is published directly via s_mqtt.publishTelemetry() — the runtime does not see it.