Zwave2mqtt: [bug] Home Assistant 0.104 breaks Lock State Discovery

[shbatm]

Version
Docker: robertslando/zwave2mqtt:latest

Build/Run method

• [X] Docker
• [ ] PKG
• [ ] Manually built (git clone - npm install - npm run build )

Zwave2Mqtt version: 1.2.3
Openzwave Version: 1.4.1

Describe the bug
Home Assistant release 0.104 added a separate state value to MQTT Locks. The state is no longer correctly reported using the default discovery payload.

To Reproduce
Steps to reproduce the behavior:

1. Update Home Assistant to v0.104 or greater.
2. Locks in Home Assistant will show "unlocked" status.

Expected behavior
Update the default Home Assistant lock discovery payload to include the following to restore the lock status.

    "state_locked": true,
    "state_unlocked": false,

Additional context
Home Assistant Changelog: https://community.home-assistant.io/t/0-104-sentry-signal-messenger-intesishome-sure-petcare-kef/163707
Commit with Issue: home-assistant/home-assistant#29808

[robertsLando]

@shbatm Would this change break old hass instances?

[shbatm]

I don't think so (I think it'd just ignore those keys), but I will check it against my dev instance when I get a chance tomorrow.

[robertsLando]

@shbatm Please let me know if hass rejects the discovery payload if it identify unknown keys because I remember that unknown keys could cause the payload reject afaik

[pulgagr]

Mine is broken as well.
It is using lock: platform: mqtt.
And as soon as I have updated to 104, it will only change the status to unlocked. To change back to locked I have to go to Developer Tools, States, find my lock and type locked to set the state, but as soon as using home assistant to unlock it again it remains that way forever.

[shbatm]

@pulgagr -- You can make the change I listed in the bug description manually in the zwave2mqtt web page--this will restore the functionality in 0.104. You'll need to:
a) edit the payload for the _lock device.
b) Click Update and then Store on the same page.
c) Click rediscover
d) Delete the entity from HASS (I removed it using the Integrations page).
e) Restart HASS.

You should be able to do d) then c) without restarting, but it didn't work for me.

[shbatm]

@robertsLando -- I tested this with my dev instance and you're right, HASS rejects the payload. Tested with 0.97.0b1.

2020-01-17 18:27:16 ERROR (MainThread) [homeassistant.components.mqtt.lock] Exception in async_discover when dispatching 'mqtt_discovery_new_lock_mqtt': ({'payload_unlock': False, 'payload_lock': True, 'state_locked': True, 'state_unlocked': False, 'value_template': '{{ value_json.value }}', 'state_topic': 'zwave/frontdoor/98/1/0', 'command_topic': 'zwave/frontdoor/98/1/0/set', 'json_attributes_topic': 'zwave/frontdoor/98/1/0', 'device': {'identifiers': ['zwave2mqtt_frontdoor'], 'manufacturer': 'Schlage (Allegion)', 'model': '0x5044', 'name': 'BE469 Touchscreen Deadbolt', 'sw_version': '128.22'}, 'name': 'Front Door Lock', 'unique_id': 'zwave2mqtt_nodeID_3_3-98-1-0-cmd', 'platform': 'mqtt'},)
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/mqtt/lock.py", line 75, in async_discover
    config = PLATFORM_SCHEMA(discovery_payload)
  File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 267, in __call__
    return self._compiled([], data)
  File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 589, in validate_dict
    return base_validate(path, iteritems(data), out)
  File "/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py", line 427, in validate_mapping
    raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: extra keys not allowed @ data['state_locked']

[JasonSwindle]

Can confirm I'm impacted by this as well.

Home Assistant 0.104.2
Zwave2MQTT: robertslando/zwave2mqtt:arm64v8-2.1.0-dev

[robertsLando]

@shbatm @JasonSwindle What I suggest is to do like @shbatm said because if I update to fix this I would break every lock on older versions of hass.

The options to fix this are

1) Edit the main lock configuration here by just add:

'lock': {
    type: 'lock',
    object_id: 'lock',
    discovery_payload: {
      command_topic: true,
      payload_lock: 'true',
      payload_unlock: 'false',
     state_locked: true, // PROPERTY TO ADD
     state_unlocked: false, // PROPERTY TO ADD
      value_template: '{% if value_json.value == false %} false {% elif value_json.value == true %} true {% else %} unknown {% endif %}'
    }
  },

This would fix all the locks of all your devices.

2) Fix each single lock device from control panel. Just select a node from the table than go in node tab under the table and scroll to Hass devices section, here fix the lock device by adding the 2 property previously shown than press on store to make this discovery payloads persistent

3) Check the device id of your lock devices and add a configuration in custom_devices.json for those devices. Check readme for more info

4) Open an issue on hass to make those lock properties not required in payload with some default values so this would work as before

[raetha]

@robertsLando I can confirm another person affected by this issue.

Was wondering if there was some way you could add code that could either detect version of hass in use, or at least be a configuration setting that a user could set. Though I don't mind changing the individual node now, I guarantee this will be forgotten with future locks or other changes. And as of now, it isn't obvious to a new user why this doesn't work. I finally stumbled on this bug report after days of rebuilding my docker containers assuming that something was simply corrupt from my initial setup.

Because I use docker containers, changing the code is not ideal as that would require changing it after every container rebuild, again something to remember that isn't obvious.

So I appreciate and respect the decision not to break existing users on older hass versions, I'd love to see something that could help new users who aren't going to know why it isn't working. Or those who are heavily in a docker environment and want persistence without manual fixes after the fact.

Thanks for consideration.

[raetha]

Another option that I just found after reading the hass release notes would be to change the state to use "LOCKED" and "UNLOCKED" instead of "true" and "false". That might break some folks automation, but would match the default values and not require any other changes from what I can tell. In that case hass version wouldn't matter, but after upgrading might require updating some automation or other references to the existing lock state.

[robertsLando]

@raetha I think I will follow zigbee2mqtt way, seems they always make updates based on latest hass version