Skip to content

deps: floor ebus-mqtt-client at 0.5.0 - #85

Merged
dcj merged 1 commit into
mainfrom
deps/mqtt-client-0-5-0
Aug 22, 2026
Merged

deps: floor ebus-mqtt-client at 0.5.0#85
dcj merged 1 commit into
mainfrom
deps/mqtt-client-0-5-0

Conversation

@dcj

@dcj dcj commented Aug 22, 2026

Copy link
Copy Markdown
Contributor

Aligns the SDK's declared floor with what the device side already installs.

ebus-mqtt-client 0.5.0 holds retained QoS 0 publishes issued before the link is up and flushes them on connect, and stops warning about each one.

That window is one the SDK creates by design, not an edge case: a root built with mqtt_cfg= connects asynchronously, so a construction-time state_transition() can publish before CONNACK. doc/building-a-proxy.md already documents the consequence and tells a producer to wait for is_connected(), but the default path provokes it.

  • At the SDK's default QoS 2, paho already queued those publishes, so what changes is the warning burst: 3 per boot to 0, measured on a Gen3 lab panel.
  • At QoS 0, it is the difference between those retained publishes arriving and being dropped.

Being honest about what this floor is

Nothing in the SDK imports or requires anything new, and the full 706-test suite passes against 0.4.0, which is what is installed in my dev environment. So this is not a "the SDK breaks without it" floor.

It is the same kind of floor as 0.4.0's, whose comment already says "the SDK does not import it, but a consumer following that guidance needs it present". If you would rather floors mean strictly "required to function", this one should be dropped and the divergence documented instead — it is a marginal call and I would not argue hard for it.

It also aligns with meta-span's python3-ebus-sdk_0.23.1.bb, which already floors at 0.5.0 on the device side, so a dev install and a panel behave the same rather than differing in a way nobody would think to check.

No release

This rides with whatever the next release is. Bumping a floor is not worth a Yocto rebuild on its own, and the recipe already has 0.5.0.

🤖 Generated with Claude Code

0.5.0 holds retained QoS 0 publishes issued before the link is up and
flushes them on connect, and stops warning about each one.

That window is one the SDK creates by design rather than an edge case: a
root built with mqtt_cfg= connects asynchronously, so a construction-time
state_transition can publish before CONNACK. building-a-proxy.md already
documents the consequence and tells a producer to wait for
is_connected(), but the default path provokes it.

At the SDK's default QoS 2 paho already queued those publishes, so what
changes there is the warning burst: 3 per boot to 0, measured on a Gen3
lab panel. At QoS 0 it is the difference between those retained publishes
arriving and being dropped.

Honest about what this floor is: nothing in the SDK imports or requires
anything new, and the full suite passes against 0.4.0. It is the same
kind of floor as 0.4.0's, which the comment already describes as "the SDK
does not import it, but a consumer following that guidance needs it
present". It also aligns with meta-span's python3-ebus-sdk recipe, which
already floors at 0.5.0 on the device side, so a dev install and a panel
now behave the same.

No release cut for this; it rides with the next one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@dcj
dcj merged commit a7b0824 into main Aug 22, 2026
5 checks passed
@dcj
dcj deleted the deps/mqtt-client-0-5-0 branch August 22, 2026 21:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant