Merge pull request #333 from quartiq/minimq-0.13

mqtt: minimq 0.13

Author: jordens

miniconf_mqtt/CHANGELOG.md

@@ -8,6 +8,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [UNRELEASED](https://github.com/quartiq/miniconf/compare/miniconf_mqtt-v0.21.0...HEAD) - DATE
 
+### Changed
+
+* MQTT network operations now take caller-owned `minimq::Connection` handles. `Miniconf::new()`
+  still returns the durable `minimq::Session` used to establish each connection, and
+  `Miniconf::startup()` reads the connect event directly from the handle.
+
 ## [0.21.0](https://github.com/quartiq/miniconf/compare/miniconf_mqtt-v0.20.0...miniconf_mqtt-v0.21.0) - 2026-06-10
 
 ### Changed

miniconf_mqtt/Cargo.toml

@@ -24,7 +24,7 @@ miniconf = { version = "0.21.0", features = [
     "defmt",
     "json-core",
 ], default-features = false, path = "../miniconf" }
-minimq = "0.12"
+minimq = "0.13"
 embassy-time = "0.5.1"
 embedded-io = "0.7"
 defmt = "1.0.1"

miniconf_mqtt/README.md

@@ -2,16 +2,17 @@
 
 `miniconf_mqtt` exposes a [`miniconf`](../miniconf/README.md) tree over MQTT using
 [`minimq`](../../minimq/README.md).
-It owns Miniconf MQTT protocol state; the caller owns both the MQTT session and the settings tree.
+It owns Miniconf MQTT protocol state; the caller owns the MQTT session, live connection, and
+settings tree.
 
 ## Quick start
 
 See the runnable example in [examples/miniconf.rs](examples/miniconf.rs).
 
 For simple services, `miniconf_mqtt` provides two complete unbounded helpers on top:
 
-- `miniconf.startup(&mut session, &settings, connect_event)`
-- `miniconf.serve(&mut session, &mut settings, on_unhandled)`
+- `miniconf.startup(&mut connection, &settings)`
+- `miniconf.serve(&mut connection, &mut settings, on_unhandled)`
 
 They are the easiest way to serve a Miniconf tree over MQTT when you do not need stepwise control,
 bounded queued follow-up, or exact control over unrelated inbound traffic during protocol work.
@@ -28,9 +29,9 @@ For precise control, `miniconf_mqtt` exposes four explicit building blocks:
 Typical flow:
 
 1. construct Miniconf MQTT state and session with `Miniconf::new(prefix, config)`
-2. call `let event = session.connect(io).await?`
-3. call `miniconf.startup(&mut session, &settings, event)`
-4. in steady state, call `miniconf.serve(&mut session, &mut settings, on_unhandled)`
+2. call `let mut connection = session.connect(io).await?`
+3. call `miniconf.startup(&mut connection, &settings)`
+4. in steady state, call `miniconf.serve(&mut connection, &mut settings, on_unhandled)`
 5. use `Publisher::root(Settings::SCHEMA)` or `Publisher::by_key(Settings::SCHEMA, key)` for explicit app-side retained
    republish
 
@@ -40,10 +41,10 @@ Retained settings recovery is a cold-boot step:
 
 ```rust
 let mut load = miniconf_mqtt::LoadRetained::new();
-load.run(&mut miniconf, &mut session, &mut settings).await?;
+load.run(&mut miniconf, &mut connection, &mut settings).await?;
 
 let mut startup = miniconf_mqtt::Startup::connected(&mut miniconf);
-startup.run(&mut miniconf, &mut session, &settings).await?;
+startup.run(&mut miniconf, &mut connection, &settings).await?;
 ```
 
 `LoadRetained` applies only retained `settings/<leaf>` publications with `auth=""`, waits for
@@ -53,7 +54,7 @@ retained pruning remains a client/tooling operation.
 
 Use it only before the first Miniconf MQTT startup of a device process. On a device reconnect or
 network glitch, keep the live settings in RAM authoritative and call
-`miniconf.startup(..., connect_event)`:
+`miniconf.startup(...)`; it reads the connect event from the live connection:
 
 - `ConnectEvent::Connected`: the broker did not resume the MQTT session, so Miniconf republishes
   schema, settings, `set/#`, and `alive`
@@ -103,8 +104,8 @@ Stepwise APIs:
 
 Practical boundary:
 
-- use `Session::poll()` to wait for any later session progress
-- use `Session::recv()` when you specifically want the next inbound publish
+- use `Connection::poll()` to wait for any later session progress
+- use `Connection::recv()` when you specifically want the next inbound publish
 - `Startup::step()` may consume and discard inbound publishes while bootstrapping
 - `Publisher::step()` must not consume unrelated inbound publishes
 - `Service::step()` must not consume unrelated inbound publishes
@@ -118,9 +119,9 @@ Bounded cooperative serving:
 let mut service = Service::<4>::new();
 
 loop {
-    let _empty = service.step(&mut miniconf, &mut session, &settings).await?;
+    let _empty = service.step(&mut miniconf, &mut connection, &settings).await?;
 
-    if let Some(inbound) = session.poll().await? {
+    if let Some(inbound) = connection.poll().await? {
         match service.handle(&mut miniconf, &mut settings, &inbound) {
             ServiceEvent::Unhandled => { /* app traffic */ }
             ServiceEvent::Changed(_) | ServiceEvent::Busy | ServiceEvent::Idle => {}

miniconf_mqtt/examples/miniconf.rs

@@ -34,12 +34,15 @@ async fn main() -> Result<(), Box<dyn core::error::Error>> {
     loop {
         defmt::info!("connecting to mqtt://{=str}", broker.as_str());
         let io = tokio::net::TcpStream::connect(&broker).await?;
-        let event = session.connect(FromTokio::new(io)).await?;
-        miniconf.startup(&mut session, &settings, event).await?;
-        defmt::info!("mqtt session ready event={}", defmt::Debug2Format(&event));
+        let mut connection = session.connect(FromTokio::new(io)).await?;
+        miniconf.startup(&mut connection, &settings).await?;
+        defmt::info!(
+            "mqtt session ready event={}",
+            defmt::Debug2Format(&connection.connect_event())
+        );
 
         loop {
-            match miniconf.serve(&mut session, &mut settings, |_| ()).await {
+            match miniconf.serve(&mut connection, &mut settings, |_| ()).await {
                 Ok(Event::Unhandled(())) => {}
                 Ok(Event::Changed(idx)) => {
                     defmt::info!("settings updated key={}", idx);