MQTT Cover can't get entity state correct for a Garage Door

Third party integrations
, , ,
1

Ok, I am back again. This template stuff has me baffled. I can’t seem to get my head around it. I am now dealing with a cover entity, my garage door. As before the physical device is a Go Control Zwave garage door controller that is setup as device in Homeseer. I have exposed it to the MQTT broker and successfully monitor messages both subscribed and published by Homeseer and Home Assistant. Additionally the up arrow icon (for open) and the down arrow icon (for close) in an entity card for lovelace work. I click on either and the messages sent via MQTT cause the garage door to physically open and close. My problem is I can’t get the entity card to display the correct status.

Pertinent details are:
Platform: Raspberry pi 3b+
OS: Hass.io version 4.12
Home Assistant: version 0.114.3
Node-Red Add on: version 7.1.0
MQTT Add on: version 5.1

Please see the following:

  - platform: mqtt
    name: "Garage Door"
    device_class: garage
    unique_id: "GarageDoor"
    state_topic: "CRUD-06/mcsMQTT/Garage/Access_Control/Garage_Door"
    command_topic: "CRUD-06/mcsMQTT/Garage/Access_Control/Garage_Door/Control"
    payload_open: "open"
    payload_close: "close"
    state_open: "open"
    state_opening: "opening"
    state_closed: "closed"
    state_closing: "closing"
    value_template: '{{ value.status }}'
    qos: 0
    optimistic: false

Homeseer works on value/status pairs as follows for this device:

0/close (control)
0/closed (status)
1 to 99/Stopped at Position x% (status)
252/closing (status)
253/stopped (status)
254/opening (status)
255/open (control)
255/open (status)

I can have it publish “$$VALUE:” which would be strings representing the numerical value or “$$STATUS:” which would be strings with the alpha content i.e “close”, “closed”, “closing”. Currently it is publishing “$$STATUS:”

For commands either 0/close or 255/open work interchangeably.

The documentation in their example uses:
value_template: ‘{{ value.x }}’
This as written didn’t work. After doing a bunch of googling I came across a post that said to use ‘{{ value_json.status }}’ this also didn’t work. In templating I found a reference that said you could use just “value” instead of “value_json”. This also didn’t work. Also I figure out the “x” had to be replaced with something other than “x”. I tried “status”, “state”, and “Garage_Door”, none of which worked. Like I said I am having a hard time getting my head around this. :confused:

I am sure it is me! :confounded: I just can’t find the guide I need to understand this. Once I get this behind me I have one other device to setup and that will be my Trane Z-wave thermostat. Then from there (I will have control of all of my devices) I can then start to automate things.

As always a big thanks in advance to anyone willing to help.
Chuck

Edit: 8/31/20
Anyone out there have any suggestions? @123 you have helped in the past can you help this time? I would appreciate any suggestions anyone has. Also if anyone can suggest a specific guide or written documentation that I could read and learn from it would be much appreciated.

Chuck

2

If I understood what you wrote, having set it to ‘$$STATUS:’, Homeseer is reporting the garage door’s state like this:

opening
open
closing
closed

That corresponds to what you specified here:

    state_open: "open"
    state_opening: "opening"
    state_closed: "closed"
    state_closing: "closing"

Given all of that, there’s no need to define a value_template because what’s being received matches what’s expected.

The purpose of a `value_template is to extract/modify what is received so that it matches what’s expected. In this case, there’s no need to extract sub-strings from the received data nor to modify it.

I suggest you remove value_template. Restart Home Assistant, open the garage door, and see if the correct status is displayed (i.e. cover.garage_door in Developer Tools > States).

3

Again @123 you have solved my problem. Please forgive my ignorance in how some of this works. Note that I have marked your response as a solution.
First you did understand correctly what I wrote. Undefined Homeseer will publish numeric values (as strings) to the topic on the broker. You can force it to publish the $$STATUS: which will publish the text value associated with that numeric value. You can also, to some degree, change those text values. As an example the default for the VSP of 0 is “Close”. I changed it to “close”. I could have changed it to “CLOSE” if I had wished. As you know this doesn’t really change the context of the message. I also could have changed it to “dimple” but then that changes the context and would have been nonsensical.

I have a question. We have four states. Had I kept the definition in my configuration as above, for example “state_open: “open”” and had not changed the payload from “Open” to “open” would I then have needed a value template? If your answer is yes I would need a value template, do I need one for each state? I guess what I am getting at is how do I know or how do I tell the value template which value it is operating on? Is it a “if” , “elif” , “else” syntax or does it know that we only have one “state_topic” and it will take that value and process it as it is instructed?

I am trying to get my head around some of this and to learn. If you could direct me towards any documentation that explains this I would appreciate it. Also thank you for your kind help. I don’t know how but if I can return the favor don’t hesitate to ask.

Chuck

4

According to the documentation for MQTT Cover, here are its default states, all are in lowercase:

    state_open: "open"
    state_opening: "opening"
    state_closed: "closed"
    state_closing: "closing"

In other words, it expects to receive those values in order to correctly report the cover’s state.

Let’s say your garage-door controller is only capable of reporting its states in propercase, like this:

Open
Opening
Closed
Closing

That’s close to what MQTT Cover needs but we still have to adjust it. We could do what you did and change what the garage-door opener reports but not everyone has that kind of control over the opener.

The other way would be to simply change the values MQTT Cover expects to receive, like this:

    state_open: "Open"
    state_opening: "Opening"
    state_closed: "Closed"
    state_closing: "Closing"

Alternately, we leave the default values alone and use value_template to convert the states reported by the garage-door opener to make them match the default values. For this example, it would be very easy because all we need to do is convert all received values into lowercase, using Jinja2’s lower filter, like this:

    value_template: "{{ value | lower }}"

This is a trivial example that, as shown, can be handled without value_template. Where value_template becomes more useful is when the received data is complex and requires more than simply converting it to lowercase.

Let’s say the received data always included the date and time plus the door’s status, something like this:

2020-09-01 08:30:45 Open

We can’t simply set state_open: to match the received value because it contains a date and time (which changes). This is a situation where we have to extract and modify the desired information and that’s where value_template comes into play.

The information we want always begins at the 20th character in the received string. We can use python’s slice feature to extract everything from the 20th character to the end of the string. Then we use the lower filter to convert it to lowercase.

    value_template: "{{ value[20:] | lower }}"

Given the sample data, the result of this template would be open which matches the default value of state_open.

Here’s another example, let’s say the received data is in JSON format, like this:

{"date": "2020-09-01 08:30:45", "status": "Open", "other_stuff": "yes"}

We can use this to get what we need:

    value_template: "{{ value_json.status | lower }}"

I hope that helps to clarify when and how to use value_template for MQTT Cover.

5

@123 Taras thank you for the explanation :smiley:. I am sorry it has taken me so long to respond to your post (life got in the way) :frowning:. Your explanation regarding a template did help. In fact because of your explanation I was able to successfully construct a template for ceiling fan control used to control a Jasco Fan Control Switch. However I do have some questions.

According to the z wave “barrier command class” there is no command for “stop”. However if the barrier does stop somewhere short of fully closed or open it can report this condition in terms of 1 to 99 as a percentage. In fact Homeseer sets up the following Value/Status Pairs:

0/close (control)
0/closed (status)
1 to 99/stopped at xx% (status)
252/closing (status)
253/stopped (status)
254/opening (status)
255/open (control)
255/open (status)

Also note that I am having Homeseer publish the “$$STATUS:” values (alpha strings) as opposed to the “$$VALUE:” values (numeric strings). So I could change to “$$VALUE:” to utilize the position_topic rather than the state_topic I am using now. I would have a command_topic and a position_topic. I would not have a set_position_topic.

In reading the docs for the MQTT Cover integration there is an example of this. In the example they show a value_template of ‘{{ value.x }}’.
Questions regarding this:

  1. The “value” within the braces represents what? I assume the position_topic.
  2. The “x” within the braces represents what?
  3. How does this value_template modify the value? From what to what?
  4. Where or how is the modified value used? I assume the state of the entity.

One last question on this subject. In Lovelace when the system generates a card for this there is an up arrow to click to open the door, there is a square to click to stop the door, and last there is a down arrow to click to close the door. Because there is no stop payload command is there a way to modify the card to eliminate the square stop icon?

Thanks for your help.
Regards
Chuck

6
  1. The “value” within the braces represents what? I assume the position_topic.

The received data. See: Processing incoming data

  1. The “x” within the braces represents what?

It’s assuming the received data is in JSON format and one of the key names is x. For example:

{"name": "John", "age": 43, "x": "whatever"}

What’s curious about that example is normally when the received data is in JSON format, one uses value_json. So to get John’s age we would use value_json.age.

  1. How does this value_template modify the value? From what to what?

The template determines what modifications occur, if any. For example, {{value_json.age}} modifies nothing and simply retrieves the value contained in the age key.

  1. Where or how is the modified value used? I assume the state of the entity.

Yes.

7

@123 Taras , again thank you for your reply. I am getting this slowly but surely. I don’t want to be too critical but to use {{ value.x }} in examples in the documentation when it should read {{ value_json.x }} is confusing to the newby like me.

So if we have only one status_topic or in this discussion a position_topic where we are receiving only one response(value) back from a device then a value_template will read that response (whether it is a single value or it is formatted json key:value pairs) and operate on it.

If we have more than one topic such as the dimmer you and I worked on before where we had two different topics (state:on or off and brightness: some number between 1 and 99) there we would use a state_value_template and/or a brightness_value_template to format the value into something that Home Assistant can use. Their names “state_value” and “brightness_value” tell you which variable your template will work on.

Can you template your payload commands? i.e.

payload_close: "{{ '0' if value = 'close' }}"
payload_open: "{{ '255' if value = 'open' }}"

If I could template the payload commands then I could probably get this to work with the position_topic configuration.

I don’t know whether I would change what I have already got using the state_topic but as I ask questions I learn more.

Regards
Chuck

8

No. You can see that in the documentation where it indicates what the option accepts. It states string as opposed to template.

9

@123 Taras, OK, thanks again for your response. I think I have beat this horse until he is dead :smiley:. Appreciate you putting up with me.
Regards
Chuck