"Open" does not work with Home Assistant (anymore?)

[djmaze]

At least with a 2022.11.x version of HA, using the "open" function of my new Nuki Smart Lock 3.0 does not work. It works fine from the official app. But when calling the service lock.open from within HA, I get an error in the logs. The backtrace ends like this:

  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 943, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 715, in _handle_entity_call
    await result
  File "/usr/src/homeassistant/homeassistant/components/mqtt/lock.py", line 241, in async_open
    self._config[CONF_PAYLOAD_OPEN],
KeyError: 'payload_open'

Having a look at the entity in HA, I see that it has supported_features: 0. HA seems to need an explicit config option to be set though, and that seems to be missing here.

[haseat]

Having a look at the entity in HA, I see that it has supported_features: 0.

Works fine for me, but my Nuki 3 has supported_features: 1 in HA. You might want to have a look why it's different in your HA installation.

[djmaze]

Is this a HA thing? Or rather esphome? I did not configure anything in HA pertaining to this, just using MQTT.

[djmaze]

Maybe this only works via the API and not via MQTT?

[djmaze]

It seems payload_open is missing from the configuration, as described in the HA documentation.

I manually added the key "pl_open": "OPEN" (see abbreviations here) to the MQTT discovery topic for the lock. Now I can successfully trigger the lock.open service from within HA.

I am not exactly sure who's at fault here. From a cursory look it seems to me like esphome is missing the required code for supporting the open command in the mqtt config, but this is my first look at this codebase.

[uriyacovy]

Hi @djmaze, I didn't test the component with MQTT component, so I don't have much to add. If you post your yaml, maybe we can try to help further. However, what is the reason you are not using the native HA API? AFAIK, the API is much more recommended.

[djmaze]

I am using MQTT mostly on my devices because it is the only reliable way for use cases where you want to keep the wake time low and doing deep sleep most of the time.

Of course in this case I need a device which is running all the time, so it might make sense to just using the API. Still, this is a bug.

I don't think there is much to see in my configuration:

esphome:
  name: mobile-thermometer

  libraries:
    - Preferences
    - https://github.com/nkolban/ESP32_BLE_Arduino/
    - https://github.com/uriyacovy/NukiBleEsp32

external_components:
  - source: github://uriyacovy/ESPHome_nuki_lock

esp32:
  board: esp32dev

lock:
  # Required:
  - platform: nuki_lock
    name: Nuki Lock
    is_paired: 
      name: "Nuki Paired"
  # Optional:
    battery_critical:
      name: "Nuki Battery Critical"
    battery_level:
      name: "Nuki Battery Level"
    door_sensor:
      name: "Nuki Door Sensor"
    door_sensor_state:
      name: "Nuki Door Sensor State"

wifi:
  ssid: "xxxxxxx"
  password: "xxxxxxx"

  manual_ip:
    static_ip: xxx.xxx.xxx.xxx
    gateway: xxx.xxx.xxx.xxx
    subnet: xxx.xxx.xxx.xxx

logger:

ota:
  safe_mode: true
  password: 'xxxxxxxxxxx'
  port: 3232

mqtt:
  broker: 'xxx.xxx.xxx.xxx'
  discovery: true
  username: 'xxxxxx'
  password: 'xxxxxxxxxxx'

light:
  - platform: status_led
    name: "Status"
    pin: GPIO27

[djmaze]

For now, I am doing a custom mqtt.publish as a workaround. This works for me:

service: mqtt.publish
data:
  topic: DEVICENAME/lock/nuki_lock/command
  payload: OPEN

[uriyacovy]

Thanks for finding the workaround!

[djmaze]

Well.. I think this is still a bug which should be fixed.

[uriyacovy]

The component is not currently implement as an MQTT lock. I am quite surprised that it works as it is does now, but you can try to play with it a bit and see if you can turn it to a native MQTT lock.