first of all I want to thank all of you for making this awesome project possible! Actually I am quite new to HA, so I am just scratching the surface of what it can do. I strongly hope to contribute someday valuably .
Actually I am setting up a system to control my window blinds/covers.
CLIENT SIDE:
Each blind has an ESP8266, running an MQTT client software with the popular “PubSubClient” MQTT library.
The clients are subscribed to the topic “home/window/cover/xxx”, there xxx is the particular room.
The state is reported on topic “home/window/cover/tilt-state/xxx”.
SERVER SIDE:
well, Home Assistant ( ), running on an ODROID C2, configuration for some MQTT covers, using “tilt” parameters, because I wanted to be able to set the covers to defined positions with this fancy slider.
What is working:
rolling covers all way up/down by clicking the arrow buttons in UI (HA sends payload “0” for up and “100” for down)
setting covers to desired position between 0 and 100 with the slider in UI (HA sends payload corresponding to slider value)
client send back its actual position, which is represented by the slider
client gives feedback on serial interface, if ANY message with valid topic is received
What is NOT working:
stopping the covers by clicking the UI square button
It looks to me, as if just no MQTT message is send, because the client doesn’t give any feedback. So even in case of a “strange” or unknown payload, the client should report, that “something” has been received.
I don’t know a lot about this programming style, but looking at the code on github, it seems to me, as if up/down commands and stop commands are handled differently (something seems to be missing for stop commands).
Maybe this is a bug and worth a report on github?!
The stop command is working for me. Can you post the relevant part of your configuration.yaml? Do you know what command your ESP8266 would expect to stop the cover, and is some kind of stop functionality implemented on the ESP? You may need to explicitly include the config parameter “payload_stop” if your ESPs are expecting a command other than “STOP” (the default).
Actually I have two covers configured. At first, I only worked without tilt commands, which worked pretty fine (up, down, stop). This is still the case for cover “Esszimmer”. But there was no fancy slider for positioning.
Then I started using tilt to have the fancy positioning slider. This is the case for “Wohnzimmer”. As I sayed, my ESP-code should react on ANY MQTT message with valid topic, regardless of the payload. But for the tilt-cover (“Wohnzimmer”), no message arrives by clicking the stop button.
As you can see, I already have the payload_stop parameter for both cover variants (with and without tilt). The ESP code is identical for both variants, only the topics differ.
I think I am confused about what you are expecting - I don’t think there’s a “stop” command associated with tilt because the slider sets the tilt position (you are choosing how tilted you want the blind to be, so no need to stop). You’ve commented out the command topic, so of course no STOP payload is going to be sent to your ESP8266, as HASS doesn’t know what topic to send to… the tilt command shouldn’t be moving your blind up and down, that’s what’s position is for.
command_topic is for OPEN/CLOSE/STOP commands.
status_topic is for open/closed payloads back from the cover to report what state the cover is in (closed = fully closed, any other position = open).
tilt_command_topic is for HASS to send a numeric value to the ESP8266 to tell the cover how tilted to make the slats (and tilt_status_topic for the cover to report its tilt state back to HASS).
To get what you want, you’ll need to specify both a command_topic and tilt_command_topic. I’d need to experiment with this to see what the front end does, but I would expect that the main entity card would show up/down arrows and a stop icon, and clicking on the entity would bring up another card with a slider for setting tilt.
See the example on the MQTT cover page for “Full configuration with tilt”, both command_topic and tilt_command_topic are specified:
OMG, I think I got it all wrong !
I thought it would work like this:
“Use command_topic for only up/down/stop” or “Use tilt_command_topic for precise positioning (and stopping).” I never wanted to stop the cover by the slider .
Now you tell me, that I need both things in my config file, which brings up two problems.
my client can only subscribe to one topic (either home-assistant/cover/tilt OR home-assistant/cover/set) -> see edit
when I have both things in my config file (uncommenting the lines above), there will by six control elements when “entering” the cover object in the UI: four arrows and two stops:
Have a look here:
Only tilt parameters (the three lines above commented out), stop is not working:
And to be honest, this does not make much sense to me.
Cheers and thanks!
EDIT:
ok, I just see, that I might subscribe to multiple topics, so this won’t be a problem. But the “problem” with the redundant buttons persists
Now I think I understand. I think it’s just a mismatch between the user interface elements (which present a set of standard controls that any platform can use, ie arrows, sliders, toggles) and the duplication of efforts in the mqtt cover code between command_topic and tilt_command_topic, which try to achieve the same thing in different ways.
So I think I may agree with you after all, but I’m not sure how best to fix it. One way would be to create another set of UI elements for entities or functions that have an open/close or up/down function but no true stop capability (like a garage door or the tilt function of a window blind). In this case the user would only see up-down and no stop icon.
Another way is to change the mqtt cover code so that when only using tilt_command_topic a stop command is nevertheless sent by pressing the stop icon. But then the device would need to be able to process a stop command on that topic, which would be characters instead of integers as the device is probably expecting.
Or, the third option is to just live with the redundant stop icon .
Maybe it is a good idea to raise this as a issue on GitHub and we can have a discussion with the developers there.
Again, thanks for your replay .
In the meantime, I was not lazy and tried a lot of things. I think I also missunderstood a few things, which you helped me to make a little bit clearer.
I think we have several “mismatches” here, because some functionalities from “normal” commands and tilt commands are the same, but behave differently, others seem different, but behave in the same way:
There is no slider for the cover position, even when “set_position_topic” is defined
So why not inserting a slider for the position, that calls the “set_cover_position” service, as the slider for tilt calls the “set_cover_tilt_position**” service? Min and max values could be defined in a similar way as values for the tilt functionality.
The “Stop” button for the tilt functionality does not work, as long as “command_topic” is not defined
Why not defining a new payload for this service? The command-stop-button calls the “stop_cover” service, while the tilt-stop-button calls the “stop_cover_tilt” service. So why not defining a new payload for that? You are right, that this would be a character value, but this is also the case at the moment anyway, because the “payload_stop” will be send on the “command_topic”, although it is the “stop_cover_tilt” service. I see no (new) problem here.
Do you agree here or do I have missed something why I don’t get a slider for positioning?
In fact, there IS a slider to set and reflect the position of the cover, without using “tilt”!
The reason why I was so confused was, that this slider does not show up, as long as HA has not received a state-topic from the client !
This is the difference to the “tilt”-stuff, because when using “tilt”, the slider shows up from the beginning on.
So if the client sends his state (cover position) only on a change event (makes sense), the position slider in HA might never show up until the end of days. When I send a new position command by clicking the up/down button, the client changes it’s state/position according to the command, and when the client then sends this new state, the slider will magically show up and reflect the position sent by the client immediately!
I think this is worth an issue raise on github. Indeed it is not critical, but also not beautiful .
.
), running on an ODROID C2, configuration for some MQTT covers, using “tilt” parameters, because I wanted to be able to set the covers to defined positions with this fancy slider.
!
!