The problem
The switchbot_cloud lock entity derives its state from a single equality check:
# homeassistant/components/switchbot_cloud/lock.py
self._attr_is_locked = coord_data["lockState"].lower() == "locked"
switchbot-api (pinned at 2.13.0 in the manifest) models seven possible values (switchbot_api/models.py, SwitchbotCloudDeviceLockState):
| value |
.lower() == "locked" |
entity reports |
locked |
True |
locked ✅ |
unlocked |
False |
unlocked ✅ |
latchBoltLocked |
False |
unlocked ❌ |
halfLocked |
False |
unlocked ❌ |
locking |
False |
unlocked ❌ |
unlocking |
False |
unlocked ❌ |
jammed |
False |
unlocked ❌ |
So the door is reported as unlocked whenever it is latch-bolt locked, half locked, mid-movement, or jammed.
This matters most on European night-latch doors, where latchBoltLocked is the normal resting state rather than an edge case — the entity then reads unlocked essentially all the time, while the physical door is secured.
The same integration already handles all seven values correctly on the sensor side: #168607 added SwitchbotCloudDeviceLockState to sensor.py, which builds its options from get_states(). The lock entity was never updated to match, so sensor.<lock>_lock_state and lock.<lock> disagree about the same device from the same coordinator payload.
Two visible consequences beyond the wrong state:
- Because the entity is stuck at
unlocked, the lock card permanently offers the Open button, and lock.lock looks like a no-op (the entity is already showing what the user expects to change).
jammed is silently swallowed. LockEntity has _attr_is_jammed for exactly this, and a jammed lock currently presents as a cleanly unlocked one — the failure mode is invisible.
What version of Home Assistant Core has the issue?
core-2026.8.2 (also present on dev at time of writing)
What was the last working version of Home Assistant Core?
Not a regression — present since the entity was introduced.
What type of installation are you running?
Home Assistant OS
Integration causing the issue
switchbot_cloud
Link to integration documentation on our website
https://www.home-assistant.io/integrations/switchbot_cloud/
Diagnostics information
SwitchBot Lock Pro, deviceType: Smart Lock Pro, firmware V3.8, paired to a Hub Mini. EU night-latch door.
Confirmed in current dev homeassistant/components/switchbot_cloud/lock.py:
self._attr_is_locked = coord_data["lockState"].lower() == "locked"
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
Suggested fix: map the full enum instead of comparing against one string, and use the LockEntity attributes that already exist for the remaining states:
from switchbot_api import SwitchbotCloudDeviceLockState
LOCKED_STATES = {
SwitchbotCloudDeviceLockState.LOCKED,
SwitchbotCloudDeviceLockState.LATCH_BOLT_LOCKED,
SwitchbotCloudDeviceLockState.HALF_LOCKED,
}
def _set_attributes(self) -> None:
if coord_data := self.coordinator.data:
state = SwitchbotCloudDeviceLockState(coord_data["lockState"])
self._attr_is_locked = state in LOCKED_STATES
self._attr_is_locking = state is SwitchbotCloudDeviceLockState.LOCKING
self._attr_is_unlocking = state is SwitchbotCloudDeviceLockState.UNLOCKING
self._attr_is_jammed = state is SwitchbotCloudDeviceLockState.JAMMED
Note the webhook path delivers the same values uppercased ("LOCKED"), which is what #179206 is about on the sensor side — whatever normalisation lands there should be shared with this entity rather than duplicated.
Happy to open the PR if the approach looks right.
The problem
The
switchbot_cloudlock entity derives its state from a single equality check:switchbot-api(pinned at 2.13.0 in the manifest) models seven possible values (switchbot_api/models.py,SwitchbotCloudDeviceLockState):.lower() == "locked"lockedunlockedlatchBoltLockedhalfLockedlockingunlockingjammedSo the door is reported as unlocked whenever it is latch-bolt locked, half locked, mid-movement, or jammed.
This matters most on European night-latch doors, where
latchBoltLockedis the normal resting state rather than an edge case — the entity then readsunlockedessentially all the time, while the physical door is secured.The same integration already handles all seven values correctly on the sensor side: #168607 added
SwitchbotCloudDeviceLockStatetosensor.py, which builds its options fromget_states(). Thelockentity was never updated to match, sosensor.<lock>_lock_stateandlock.<lock>disagree about the same device from the same coordinator payload.Two visible consequences beyond the wrong state:
unlocked, the lock card permanently offers the Open button, andlock.locklooks like a no-op (the entity is already showing what the user expects to change).jammedis silently swallowed.LockEntityhas_attr_is_jammedfor exactly this, and a jammed lock currently presents as a cleanly unlocked one — the failure mode is invisible.What version of Home Assistant Core has the issue?
core-2026.8.2 (also present on
devat time of writing)What was the last working version of Home Assistant Core?
Not a regression — present since the entity was introduced.
What type of installation are you running?
Home Assistant OS
Integration causing the issue
switchbot_cloud
Link to integration documentation on our website
https://www.home-assistant.io/integrations/switchbot_cloud/
Diagnostics information
SwitchBot Lock Pro,
deviceType: Smart Lock Pro, firmware V3.8, paired to a Hub Mini. EU night-latch door.Confirmed in current
devhomeassistant/components/switchbot_cloud/lock.py:Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
Suggested fix: map the full enum instead of comparing against one string, and use the
LockEntityattributes that already exist for the remaining states:Note the webhook path delivers the same values uppercased (
"LOCKED"), which is what #179206 is about on the sensor side — whatever normalisation lands there should be shared with this entity rather than duplicated.Happy to open the PR if the approach looks right.