iMicknl / ha-tahoma

Custom component for Home Assistant to interact with smart devices via Somfy TaHoma or other OverKiz based API's.
MIT License
152 stars 30 forks source link

Add support for forcing update after executing command #788

Closed laszlojakab closed 2 years ago

laszlojakab commented 2 years ago

Did you read the instructions?

The request

I have some blinds which has a special command setClosureAndOrientation. With this (using tahoma.execute_command) I can set the closure position and the tilt position in a single command. Setting the cover position with cover.set_cover_position and setting the tilt position with cover.set_cover_tilt_position immediately after that stops the moving cover and only the tile position set. So setClosureAndOrientation is very usefull, no need to wait between the two commands. There is only one problem with this method: the state of cover entity is not updated immediatly after executing the setClosureAndOrientation. Using open cover, close cover, set cover position, etc. immediatly updates cover entity state. It should be good to add posibility to force update cover (tahoma) entity state after executing a custom command (maybe an optional parameter for execute_commandservice).

Which gateway / hub do you use?

Connexoon

Device model (optional)

No response

Device type (optional)

No response

Additional information

No response

iMicknl commented 2 years ago

Can you turn on debug logging and execute setClosureAndOrientation?

By the way, we didn't port this functionality to the core integration. Would this be a blocker for you to migrate?

laszlojakab commented 2 years ago

Hi @iMicknl, logging turned on, log attached: home-assistant.log

If there will be a non core tahoma integration which has this functionality I would use that. It is very annoying that you have to wait for the cover to move into position before you can set the tilt position. Also very hard (need a lot of extra code to do it right) to write scripts/automations for that. As I mentioned you have to use delay between setting cover and tilt position. If you use short delays then the moving of tilt stops the moving of cover and the cover won't be in expected position. If you using long delays than you have to wait a lot for setting position. For example I have a blind which opens/closes in 61 seconds so I have to use 61 seconds delay in my automation to be sure it is moving to the expected position. If the cover is in correct position only the tilt should be rotated and don't need to wait for 61 seconds. It is a very bad user experience that you press a button on the dashboard which executes a script to set the cover and tilt position and nothing happens for 61 seconds. I know I could calculate the difference between the current position and the expected position and then calculate the delay time based on that but why should I do that if there is a setClosureAndOrientation command?

To be honest I don't know why there isn't a set_cover_and_tilt_position for base cover entity itself in the core to implement this functionality.

iMicknl commented 2 years ago

To be honest I don't know why there isn't a set_cover_and_tilt_position for base cover entity itself in the core to implement this functionality.

This would indeed be a blocker for us to implement this... However, this is a good example why the execute_command service is important.

I didn't have time to review your log yet, but I wonder why there are no real-time updates after your execute that specific command...

laszlojakab commented 2 years ago

The set_cover_and_tilt_position could be optional (maybe with an addtional SUPPORTED_FEATURES flag) in that case won't be a blocker for you :) Is there a plan to move execute_command service to core?

github-actions[bot] commented 2 years ago

'There hasn't been any activity on this issue recently. Is this issue still present? Please make sure to update to the latest Home Assistant version and version of this integration to see if that solves the issue. Let us know if that works for you by adding a comment 👍. This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.'