Skip to content

feat(gateway): expose the gateway's enforced read-only flag as an entity and warn on mismatch - #5220

Merged
springfall2008 merged 1 commit into
mainfrom
feat/gateway-read-only-entity
Sep 26, 2026
Merged

springfall2008 merged 1 commit into
mainfrom
feat/gateway-read-only-entity

Conversation

@mgazza

@mgazza mgazza commented Sep 24, 2026

Copy link
Copy Markdown
Collaborator

The problem

PredBat mirrors its own read-only setting to the gateway with a set_read_only command, but that mirror has no readback. The ack carries no value, and a gateway that was offline at the moment of the transition only catches up on the 30-minute re-send. PredBat therefore has no way to confirm what the gateway is actually enforcing, and a user has no way to see it.

The change

GatewayStatus gains optional bool read_only = 18, matching the firmware schema, reporting the flag as it is actually enforced: write-class commands rejected and autonomous mode disabled.

_inject_entities now publishes it two ways:

  • binary_sensor.<prefix>_gateway_read_only, friendly name "Gateway Read-Only (enforced)"
  • a read_only attribute on the existing gateway_online sensor

The field is proto3 optional, so absent is UNKNOWN rather than false. On firmware predating the field no entity is written at all and the attribute is None, instead of claiming the gateway is controllable when nothing has reported either way.

When the reported value disagrees with the last state PredBat requested, a warning is logged once per transition into disagreement, and the latch clears as soon as the two agree again. A gateway stuck in disagreement therefore does not fill the log. This path is observe-only and sends no commands.

Wire compatibility

Field 18 was free in GatewayStatus. The regenerated gateway_status_pb2.py changes only the serialized descriptor and the offsets that follow from it. The gencode version stamp is unchanged at 7.34.1.

Tests

Five new cases in TestInjectEntities in apps/predbat/tests/test_gateway.py:

  • present and true publishes the entity True
  • present and false publishes the entity False
  • absent writes no entity and leaves the attribute None
  • a mismatch warns exactly once, repeats do not re-warn, agreement clears the latch and a later mismatch warns again
  • nothing sent yet means nothing to compare, so no warning

./run_all --test gateway passes: 286 cases, no failures.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EMnoLH9ponFsj2kg6agJXm

…and warn on mismatch

PredBat mirrors its own read-only setting to the gateway with a set_read_only
command, but that mirror has no readback: the ack carries no value, and a gateway
that was offline at the transition only catches up on the 30-minute re-send. So
PredBat could never confirm what the gateway was actually enforcing.

GatewayStatus gains `optional bool read_only = 18` (matching the firmware schema),
reporting the flag as enforced: write-class commands rejected and autonomous mode
disabled. _inject_entities publishes it as
binary_sensor.<prefix>_gateway_read_only and as a read_only attribute on the
gateway_online sensor.

The field is proto3 optional, so absent means UNKNOWN rather than false. On
firmware predating the field no entity is written at all and the attribute is
None, rather than claiming the gateway is controllable when nothing has reported
either way.

When the reported value disagrees with the last state PredBat requested, a warning
is logged once per transition into disagreement and the latch clears as soon as
the two agree, so a stuck gateway does not fill the log. This path is observe-only
and sends no commands.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EMnoLH9ponFsj2kg6agJXm
@springfall2008
springfall2008 merged commit acc04b8 into main Sep 26, 2026
2 checks passed
@springfall2008
springfall2008 deleted the feat/gateway-read-only-entity branch September 26, 2026 08:25
springfall2008 added a commit that referenced this pull request Sep 27, 2026
…9-27

docs(debug-journal): fold in the 2026-09-27 queue slice (15 candidates); correct entries overtaken by the #5126/#5251/#5220/#5231/#5216/#5247/#5256 merge batch
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.

2 participants