Core: MQTT cover component: buttons not working logically

[FrenkK]

Version 0.30.1, Python 3.5.2, running on Windows

I'm using MQTT cover component to control my window blinds and have the following problems:

The first one is about the optimistic mode:

At startup, I have all three buttons available (Open, Stop, Close). If I press e.g. the Close button, the Close button deactivates (greys out) and no longer works until I press the Open button, at which time the Open button deactivates. This is not the right behavior for most covers (window blinds, roller shutters), because I'm not able to close the cover a bit first and then a bit more after a while (for example when the sun goes down a bit). To close it further in this scenario, I have to open it a bit first, in order to enable the Close button, and then close again. This is inconvenient and increases wear.

The second one is about the non-optimistic mode:

The MQTT cover component is designed (according to the documentation) so that I can only send two cover states (open, closed) as feedback from my (homebrew) roller blinds controller. If hass receives a message for an open state, only the Close button is enabled and vice versa. But two states are not enough: Most covers can be open, in intermediate position or closed. The current functionality prevents me from opening the cover half-way and the close it again and vice versa. Having to close the blinds all the way before being able to open them again is inconvenient and it increases wear.

A possible solution:

It seems that both problems are related to the same conceptual issue. Covers don't have two states (open, closed), but three (open, intermediate, closed). In open state, only Close button is needed. In closed state, only Open button is needed. As soon as the cover moves from either open (or closed) state, but does not reach closed (or open) state, it is in intermediate state and all three buttons are needed. I propose that an extra intermediate state is added to the component, during which all three buttons are enabled.
In optimistic mode, all control buttons should always be available.

Additional comment:

From what I can tell by looking at the source code, this is an overarching problem that doesn't only affect MQTT, but probably other covers as well.

[FrenkK]

Another minor issue, specific to MQTT cover: At each MQTT status update a warning is added to the Homeassistant error log, which is not necessary for normal operation and probably an unintended leftover from testing.

[dgomes]

any progress on this issue ?

[FrenkK]

In version 0.35.0 the behavior is still as described.

[dgomes]

I asked because I'm facing a similar issue and was wandering if there was any way around it.

My covers have two actions triggered by a push button (which I control through a relay) which is UP and DOWN for the duration of the push. They automatically stop at both ends (0% and 100%) but I have no sensor to detect at which position the blind is besides timing the pulses.

I might look into the code, but I'm not sure what the proper direction should be taken. Any maintainer reading this :) ? I would gladly produce the code to solve this issue.

[FrenkK]

I read through the code quickly and the problem doesn't seem to be in the MQTT cover component. Most probably it is in the code shared among different cover components, but I did not find it.

[MartinHjelmare]

The existing common way in the cover component to set an intermediate position, is to use the set_cover_position method. This requires an argument position which is an integer 0-100. This method isn't currently implemented for the mqtt cover. Reporting an intermediate position is implemented though.

I think it would be possible to let the device find the end positions on its own, and enable up and down at all times, but the problem is then still how to know the state (open/closed) of the device, if it can't report that. I think state is very fundamental to the current definition of the entity class that is used for all devices in home assistant.

[FrenkK]

As far as the optimistic mode is concerned, I would say that all controls must be available all the time (or at least when an opposing direction is not currently selected, but this is usually already implemented in hardware), anything else is a bug.
As far as reporting is concerned, all controls should work when reported position is not either fully open or closed. Currently it does not work that way, as far as I have tested it.

[MartinHjelmare]

But optimistic mode means that we assume a state after telling the device to open or close. When the device is fully open the open button is disabled and vice versa. I don't see how we can have all buttons available in optimistic mode unless moving to a stateless entity.

[FrenkK]

For either command, we can only assume that the device opened/closed fully if enough time has elapsed (no way to specify this) + nobody stopped the movement. These are two quite important conditions that are in no way checked before disabling a command for a certain direction.
Like I wrote in the first post, the state should have THREE values (open, closed, intermediate) instead of the current two (open, closed). Many covers (especially blinds and shutters) are often used in intermediate state. Both open and closed states should only be assumed after the run time (usually around a minute) is elapsed and only then should any direction be disabled. If movement is stopped at any time, an intermediate state should be assumed and all controls enabled.

[dgomes]

The point is that there exists an intermediate state, and that optimistically speaking it is always in the intermediate state unless some other trigger sets the state open or closed.

In my use case, I send through MQTT the amount of ms I want to press the covers UP or DOWN, and I know that if I ask for more then X amount of time the covers UP the covers will go all the way up, and the same can be said for covers DOWN.

[MartinHjelmare]

Ok, so time should be used to know fully open/closed? We could add a config option that sets the time until state is fully open/closed in optimistic mode. If stop is pressed before time completes, we could set a position of 50%, to represent the arbitrary intermediate position.

Thoughts?

[dgomes]

I like that option a lot since instead of OPEN and CLOSE I was looking at publishing the amount of time.

[dgomes]

More info: in my use case I have 2 relays (one for each direction) can that also be taken into consideration ?

[MartinHjelmare]

@dgomes I would think that number of relays is a device specific implementation detail, ie the device is responsible for knowing which relay to activate when open vs close message is received.

[dgomes]

@MartinHjelmare that is true except my relays are exposed directly using https://github.com/marvinroger/homie

But I understand your point :)

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[dgomes]

There has been no code update to solve this issue

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[balloobbot]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem 👍