Remove the lock on apply_action #93
Conversation
Add two functions to select first existing command or state from a list. Implement in cover.py
Related Github issues: #91
Related Github issues: #92
As an async apply_action doesn't prevent the lock, I propose to add an execution queue to tahoma_device entities, and only perform the update once the queue is empty. Having `update` instead of `schedule_update` line 97 doesn't prevent the lock... Related Github issues: #92
Also clear the exec_queue if it's not executing anymore. Related Github issues: #92
…te." This reverts commit 45a3024
vlebourl
added
bug
|
If accepted, I think this would deserve a beta release. |
| @@ -60,6 +60,12 @@ def device_class(self): | |||
|
|
|||
| def update(self): | |||
| """Update the state.""" | |||
| exec_queue = self.controller.get_current_executions() | |||
There was a problem hiding this comment.
This code is the same in all implementations? Should we move it to the tahoma_device and call this function from here?
There was a problem hiding this comment.
It could take this form:
def should_wait(self):
"""Wait for actions to finish (this would be in tahoma_device"""
exec_queue = self.controller.get_current_executions()
self._exec_queue = [e for e in self._exec_queue if e in exec_queue]
return True if self._exec_queue else False
def update(self):
"""Update the state."""
if self.should_wait():
self.schedule_update_ha_state(True)
return
# continue update
|
I test with the 1.5-alpha2. My covers reacts with several seconds delay to the click in the HA frontend. |
|
How reactive is it when interacting through the TaHoma web dashboard? |
|
It's very reactive at my place... Not sure why it would add any delay. |
|
There is no delay through the TaHoma Dashobard. I can change the position, wait a little bit and click on stop and the cover reacts immediately. Through HA it starts in general directly but not always. When there is a delay then you see the delay also on the TaHoma dashboard. One interesting point: The stop button is not working while moving. When I click the button on TaHoma dashboard it stops immediately. (Please wait some seconds after you start the movement and then try to click on stop - for me it is not working) |
|
"When there is a delay then you see the delay also on the TaHoma dashboard." I don't know about the stop button, but I suspect it's not related to the delay, so I propose to keep it away from this issue and open one of its own. |
|
The delay is completely new to me. Before I had to use the current version (because of the login issue) there were no such delays. It appears the first timt 30 minutes ago after the HA update to 0.112 and the component update to 1.5-alpha2 |
|
The delay might be related to the login issue. You probably still get logged out a lot, then the api re-logs you in automatically causing the delay. We would need to figure out why you get logged out, but I have no idea how to do that... |
|
Overhere it is far beter then in the last versions. Before the stop button wasn't reacting, and now it is. will test again in few hours. |
Ok, that could be the reason for the delay. It would be great to get this fixed - but I also have no idea, how to find the reason
Interesting ... for me all versions including 1.3 were much better than the current version and the stop button was working for me without problems. The problems for me start with version 1.4 (which I skipped until the login issue) |
|
Can you open a new issue with details on your cover regarding the stop button? I'll try to put more log messages to find why you get kicked out of the api. |
|
I tested it again and I would say that the reason is the login issue. I clicked on the move-down-button and it had a delay of around 2 seconds. The same happens when I clicked on the stop-button some seconds later. So I would say it relates not only to the stop-button. |
|
can you edit the file Restart HA a try again with debug log setup for the component (see here) |
|
By the way, conversation should be moved to #86 |
#90
#92