Covers that are flagged with assumed-state internally keep track of their, well, assumed state, which has a high probability to be wrong. I f.e. have a cover that in the background basically is a cover_group but is exposed as only one cover since the grouping is done in KNX. For this cover I do not want to see any estimated state which is why it is marked as assumed state. However, the actions cover-up and cover-down (triggered via automations and manually in frontend) are not always executed/forwarded to KNX. Why? When I try to trigger it manually I first have to tell it to go into the other direction (resetting the state) and then go the direction I want it to move. The state is only assumed and thus should only affect the visuals but never prevent/block any action or service call.
I think you are right, the visualization of covers isn’t representing all eventual states perfectly and actions should be forwarded in every case.
In KNX I would use a scene to trigger a group of covers instead of coerce a stateless (multiple covers that can be controlled individually) to a statefull entity (a single cover entity).
in a KNX scene I can only specify one target state/position, so for up/down I would need two scenes, which is meeeh. Thus one KNX group all desired covers are in and which I can control with physical switches as well.
But apart from my KNX setup, assumed state entities in HA should always forward/perform the actions.
1 Like