MQTT Lock will not update status in Lovelace UI

Third party integrations
, , ,
1

Hi, I am new to Home Assistant and need some help. This is my first post, so please be easy on me. :grinning: I have been using Homeseer for several years now and wanted to try something new. I liked what I read about Home Assistant and had the Raspberry Pi laying around so I said why not. The more I use it, the more I understand, and the more I like it.

Pertinent details:
Home Assistant 0.113.3
HassOS 4.11 Ver: 4.19.127-v7
Raspberry Pi 3 B+
Mosquitto Broker (Add-In) Ver 5.1
Node-Red Ver 7.0.0

I have seen and am following @paulmona and his configuration of Home Assistant as his situation is similar to mine. I have a lot of Z-Wave devices. Mains powered switches and dimmers (Homeseer & Jasco), Battery Door Sensors (Homeseer), Garage Door Controller (Go Control), Thermostat (Trane), Dead Bolts (Schlage Connect BE468CEN716. It is this last item I am having a problem with.

I have left everything configured in Homeseer (pretty robust z-wave control). I have utilized Michael McSharryā€™s very fine mcsMQTT plugin for Homeseer to publish and subscribe these various devices to the MQTT broker. I have experimented with Node-Red to control many of these devices. I have setup a ā€œlistenerā€ in Node-Red to subscribe to topics from the MQTT broker and put the topic payloads into a debug component so that I can see them in the Node-Red debug panel.

My problem stems from trying to get the status of the lock to update in the Lovelace UI. As I am just starting out I am utilizing the default view Lovelace dashboard. I have not ā€œtaken controlā€ of the UI at this point.

In my config.yaml file I have the following line:

lock: ! include locks.yaml

In my locks.yaml file I have the following:

  - platform: mqtt
    name: "Back Door Lock"
    unique_id: "BackDoorLock"
    command_topic: "CRUD-06/mcsMQTT/Living_Room/Access_Control/Back_Door_Lock/Control"
    state_topic: "CRUD-06/mcsMQTT/Living_Room/Access_Control/Back_Door_Lock"
    payload_lock: "lock"
    payload_unlock: "unlock"
    value_template: "{{value[:-2] | lower }}"
    qos: 1
    retain: false
    optimistic: false

In Homeseer the devices use value/status pairs (VSP). The VSP for control of this lock is:

0/unlock
255/lock

the VSP for status of this lock is:

0/Unlocked
255/Locked

I can control the lock (either lock it or unlock it) with the payload of 0 or unlock and 255 or lock using either value (numeric or string). This works from Home Assistant with the device I have setup. The entity is: lock.back_door_lock.

I have followed this topic in the forum regarding getting the UI to update the status:

[Please Help! MQTT Lock Status Won't Update in HA, state_topic works]

When I ā€œLockā€ the door from Home Assistant the following is what I observe:

    • Physically the deadbolt locks the door.
    • The entity (lock.back_door_lock) shows ā€œunlockedā€
    • Node Red debug message shows "CRUD-06/mcsMQTT/Living_Room/Access_Control/Back_Door_Lock ā€œLockedā€

What am I doing wrong and how do I fix this?

Thanks for any help coming my way.

Chuck Rudolphy

EDIT:

Did I do something wrong? My post has been up for 3 days and no suggestions. Did I post this in the wrong catagory?

2

If I understood everything correctly, I think the problem is due to an incorrect value_template.

You stated that when you use the UI to lock the door, the deadbolt locks so it must have successfully received the lock payload. However, the UI fails to update its status and continues to report the deadbolt is unlocked. We know the deadbolt is publishing the correct status because you stated Node-red reported a value of Locked was published to CRUD-06/mcsMQTT/Living_Room/Access_Control/Back_Door_Lock. Thatā€™s the same topic used by state_topic therefore the problem must be that value_template is not extracting the correct value from the state_topic.

If the status is simply Locked then all we need to do is configure lock.back_door_lock to accept that as the representation for ā€˜lockedā€™ status. Because the status message is so simple (just a single word), we can add these two options:

    state_locked: "Locked"
    state_unlocked: "Unlocked"

and remove the existing value_template. That should do the trick; now the entity knows the values for lock status (Locked/Unlocked) and lock commands (lock/unlock). (For more information, see the documentation for state_locked).

NOTE

Alternately, it is possible to continue to use the value_template (without adding the two aforementioned options). The default status values are locked and unlocked so all your value_template needs to do is convert the received payload into lowercase like this:

    value_template: "{{value | lower}}"

So you have two ways to solve this:

  1. Use the two dedicated state-related options.
    or
  2. Use a (simplified) value_template.
3

@123 Taras, first let me thank you for responding to my post. I really appreciate your help and advice. I will follow the link you provided regarding documentation. However I thought I would update you on the remedy.

The value template did not work. My original value template was:
value_template: ā€œ{{ value [:-2] | lower}}ā€. The reason I tried this was because in the post i was following led me to believe that the ā€œstateā€ topic payload had to match the ā€œcommandā€ topic payload exactly. So I was trying to take the state payload of either ā€œLockedā€ or ā€œUnlockedā€ strip the last to characters to make them ā€œLockā€ or ā€œUnlockā€ then convert them to all lower case so that they would be ā€œlockā€ or ā€œunlockā€ to match exactly the ā€œcommandā€ topic payloads. I then took your suggestion first to change the value template to ā€œ{{value | lower}}ā€ and restart the server. This did not work. I could lock and unlock the door (physically) yet the status in the ui remained unchanged reporting ā€œunlockedā€.

I then commented out the value template and inserted the two dedicated state-related options as you wrote in your response. I am so happy to report that this worked! :grinning:. My ui is now updating the correct status. When the lock is ā€œUnlockedā€ it shows an icon of an unlocked padlock and the string shows ā€œLOCKā€. When the lock is ā€œLockedā€ it shows an icon of a locked padlock and the string shows ā€œUNLOCKā€.

However to add to this. When I restarted Home Assistant even though the lock was physically locked it started up displaying ā€œUnlockedā€. In the mcsMQTT plugin running in Homeseer the option to ā€œretainā€ at broker is available. I changed to so that it would retain the message at the broker. Upon a subsequent restart of Home Assistant the ui now displays the correct status upon restart.

Again thanks for your help! Now on to read the documentation you link to in your response.

Chuck

1 Like
4

Glad to hear it. Please mark my previous post with the Solution tag so other users know this topic has an accepted solution.

This is expected behavior if the status information is not stored on the MQTT Broker. Upon startup, Home Assistant connects to the broker, re-subscribes to all required topics and immediately receives their messages but only if the messages are retained on the broker. If they are not retained, the entity is given a default status (unlocked for a lock) and will be updated whenever a new message is published to the topic.

As a rule of thumb, status topics benefit from having retained messages but not command topics. The reason is that on startup, the retained command message is immediately received and some (undesired) action may take place (perhaps a garage door opens whenever Home Assistant restarts).