SberCommandDispatcher¶
Интерпретация входящих Sber MQTT-сообщений и диспатч side-эффектов.
Владеет обработчиками handle_command, handle_status_request,
handle_config_request, handle_error, handle_change_group,
handle_rename_device, handle_global_config.
Извлечён из SberBridge в v1.25.1 для изоляции Sber-протокольной
логики от транспорта и HA state forwarding (SRP). Держит ссылку на
родительский SberBridge, так как ряд handler'ов мутирует состояние
моста (entities, redefinitions, acknowledgements) и инициирует publish.
Sber MQTT command dispatcher.
Handles commands, status/config requests, errors, change_group and
rename_device messages from the Sber cloud. Extracted from
:class:SberBridge to isolate Sber-protocol command interpretation
from transport and HA state forwarding (SRP).
The dispatcher owns no reference to :class:SberBridge. Everything it
may touch arrives through :class:DispatcherDeps: the collaborators it
drives (publisher, redefinitions store, DevTools hub, ack audit) plus
callables for the few bridge-owned operations it triggers. Narrowing
this bundle is what keeps the bridge free to reshape its internals.
DispatcherDeps
dataclass
¶
DispatcherDeps(hass, stats, ack_audit, publisher, redefinitions, devtools, get_entities, get_enabled_entity_ids, schedule_confirm, note_cloud_reported, refresh_repair_issues)
Everything :class:SberCommandDispatcher is allowed to reach.
publisher
instance-attribute
¶
Publish coordinator used for state / config / echo responses.
redefinitions
instance-attribute
¶
Store fed by change_group / rename_device payloads.
devtools
instance-attribute
¶
Collector aggregate that records the command correlation trace.
get_enabled_entity_ids
instance-attribute
¶
Returns the ordered list of exposed entity IDs.
schedule_confirm
instance-attribute
¶
Asks the bridge to (re)arm the delayed state confirm for one entity.
note_cloud_reported
instance-attribute
¶
Records entity ids the cloud named, into the persistent registry.
A command addressed to a device is the strongest evidence the protocol offers — Sber does not command a device it does not hold — and it used to be thrown away: only the in-memory session mark was set, so a restart forgot it. A bridge driven purely by voice and app commands therefore learned nothing that survived (issue #57).
refresh_repair_issues
instance-attribute
¶
Asks the bridge to recompute its HA repair-issue set.
SberCommandDispatcher
¶
Interprets incoming Sber MQTT payloads and dispatches side effects.
Each handle_* method corresponds to one topic suffix in the Sber
down/* namespace. The bridge's _mqtt_dispatch table routes
incoming messages to the matching handler.
Initialize the dispatcher bound to its dependency bundle.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
deps
|
DispatcherDeps
|
Narrow dependency bundle assembled by the bridge. |
required |
Source code in custom_components/sber_mqtt_bridge/command_dispatcher.py
handle_command
async
¶
Handle a command from Sber cloud → execute HA service.
During the reconnect grace period, commands are rejected and current HA states are re-published so that Sber cloud accepts HA as the authoritative source of truth.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
payload
|
bytes
|
Raw MQTT payload from |
required |
context
|
Context | None
|
Optional HA context to attribute the resulting
service calls to (e.g. a user-scoped context for
WS-initiated replays). A fresh anonymous |
None
|
Source code in custom_components/sber_mqtt_bridge/command_dispatcher.py
handle_status_request
async
¶
Handle a status request from Sber cloud.
If Sber asks about entities not in our current set, automatically re-publishes the device config so Sber is aware of the correct list. A status_request also counts as Sber acknowledgment.
Source code in custom_components/sber_mqtt_bridge/command_dispatcher.py
handle_config_request
async
¶
Handle config request from Sber cloud — send device list.
Forced past the unchanged-payload check. The cloud asked us a direct question, and answering it with silence because the answer has not changed is wrong twice over: Sber gets nothing (it asks precisely when its own copy is in doubt), and the publish that records what the cloud holds never happens — leaving the registry empty for the whole session with no second chance (issue #57).
Source code in custom_components/sber_mqtt_bridge/command_dispatcher.py
handle_error
¶
Handle error message from Sber cloud.
Parses the error payload, stores the detail in stats for repair issue creation, and logs the error.
Source code in custom_components/sber_mqtt_bridge/command_dispatcher.py
handle_change_group
async
¶
Handle device group/room change from Sber.
Values are validated (string type, length limit) and stored
through :meth:RedefinitionsStore.async_update so cloud input
goes through the same normalization as the WS API — invalid or
missing values clear the corresponding key instead of persisting
arbitrary payloads.
Only stores the redefinition locally. Does NOT re-publish config to avoid an infinite loop: Sber sends change_group → we publish config → Sber sends change_group again → loop forever.
Source code in custom_components/sber_mqtt_bridge/command_dispatcher.py
handle_rename_device
async
¶
Handle device rename from Sber.
The new name is validated (string type, length limit) and stored
through :meth:RedefinitionsStore.async_update; payloads with a
non-string or oversized name are rejected without touching the
persistent store.
Only stores the redefinition locally. Does NOT re-publish config to avoid potential loops.
Source code in custom_components/sber_mqtt_bridge/command_dispatcher.py
handle_global_config
¶
Handle global config from Sber (http_api_endpoint).