You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,11 +10,13 @@
10
10
11
11
- Added `ZeroNetProfileEsp8266`, a constrained MQTT-first preset for Wemos / ESP8266.
12
12
- Added `ZeroNetProfileEsp8266Http`, an opt-in HTTP-first constrained preset for Wemos / ESP8266 so HTTP and MQTT can be tuned separately instead of forcing one compromise path.
13
+
- Hardened `ZeroHttpPump` with optional phase-specific timeout budgets and configurable intra-tick phase progress, then used that in the ESP8266 HTTP-first preset so the constrained Wemos path can progress connect/write faster without changing the global default pacing.
13
14
- Refined `ZeroNetProfileEsp8266` so HTTP stays truly off by default, MQTT idle churn is lower, and the official Wemos live compare now shows MQTT delivery with timing that beats the naive baseline in the same window.
14
15
- Added optional offline queue gating in `ZeroHttpPump` and `ZeroMqttPump` so constrained boards can refuse backlog when link or transport is down.
15
16
- Reduced scheduler contention in the ESP8266 preset by staggering network task start offsets and lowering idle network task cadence.
16
17
- Updated the ESP8266 preset to recommend `kIdleYield` instead of `kIdleSleep`, which materially reduces live timing jitter in the official Wemos validation node.
17
18
- Tuned the ESP8266 preset toward MQTT-first delivery with lighter MQTT dispatch pressure, producing a repeatable Wemos run where MQTT delivery stays live while timing remains at or better than baseline.
19
+
- Improved the ESP8266 HTTP-first preset so live HTTP delivery is now real and controlled (`http_rate` can hit `100%` in the official compare) while average lag drops sharply versus the naive baseline; the path remains experimental because worst-case lag and misses still need more cleanup.
18
20
- Added generic compare workloads for `EnvMonitor`, `TelemetryGateway`, and `IndustrialLoop`.
19
21
- Added repeatable ESP32 compare runners plus a cross-target workload compile matrix.
20
22
- Improved telemetry gateway tuning so module throughput rises without queue buildup.
-**ESP32:** use the default network module configs first, then validate against your real endpoint.
121
121
-**ESP8266 / Wemos:** start with `ZeroNetProfileEsp8266`. It is a constrained MQTT-first preset that disables periodic HTTP dispatch by default, prevents offline queue buildup, lowers idle MQTT churn, staggers lighter network task cadence, and recommends a lighter idle strategy. In current validation it is the preferred path for Wemos MQTT delivery, while HTTP remains degraded/off by default unless you deliberately opt back in.
122
-
-**ESP8266 / Wemos (HTTP-specific):** use `ZeroNetProfileEsp8266Http` only when your node is intentionally HTTP-first. It keeps the same constrained timing discipline, but does not try to combine HTTP and MQTT in the same default path. Treat it as an opt-in experimental profile until your own endpoint validation confirms live delivery under your Wi-Fi conditions.
122
+
-**ESP8266 / Wemos (HTTP-specific):** use `ZeroNetProfileEsp8266Http` only when your node is intentionally HTTP-first. It keeps the same constrained timing discipline, but does not try to combine HTTP and MQTT in the same default path. Current validation now shows real HTTP delivery with clean request success under the official local compare, but it is still marked experimental because misses and worst-case lag are not yet as tidy as the MQTT-first constrained path.
123
123
124
124
Current best module tradeoff reference (ESP32, `LEAN_NET`, manual pattern vs module pattern):
Copy file name to clipboardExpand all lines: docs/wiki/Beta-Modules.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,7 +19,7 @@ They are already useful and validated on desktop plus ESP32 smoke tests, but the
19
19
Recommended default:
20
20
21
21
- For constrained ESP8266 boards, start with `ZeroNetProfileEsp8266`. It is the recommended MQTT-first constrained preset: HTTP stays degraded/off by default, offline queueing is rejected, idle MQTT churn is lower, and the preset uses a lighter recommended idle strategy plus staggered network task starts so the board stays more predictable without hand-tuning every interval.
22
-
- If your board is intentionally HTTP-first, use `ZeroNetProfileEsp8266Http` as a separate opt-in path. It keeps the constrained timing discipline but avoids pretending that one default cadence can serve HTTP-heavy and MQTT-heavy nodes equally well. Treat it as experimental until your own endpoint validation confirms live delivery.
22
+
- If your board is intentionally HTTP-first, use `ZeroNetProfileEsp8266Http` as a separate opt-in path. It keeps the constrained timing discipline but avoids pretending that one default cadence can serve HTTP-heavy and MQTT-heavy nodes equally well. The official Wemos compare now shows real HTTP delivery on this path, but it is still experimental because miss count and worst-case lag remain rougher than the MQTT-first constrained preset.
0 commit comments