Closed rjantoine closed 2 weeks ago
Now we just need to change version number. 😃 Not sure how to do that though.
It does that Sundays and Wednesdays automatically. I can force it too but the delay helps others test as they can use the have service call and update from "master".
As a note for awareness. The system looks at pr titles for version number and release notes. Feat: triggers a 2.x release. Fix: triggers a 2.5.x release. Chore: docs: and a few others don't cause a release.
Release notes are created based on pr titles.
Calls to lock, unlock, start_climate, stop_climate, start_charge, stop_charge and set_charge_limits now update the state of the vehicle when complete.
TL/DR:
await async_request_refresh()
has been replaced bydon't await, async try to wait until action is done and finally async_refresh()
. The try block should ensure that this feature is completely neutral or additive.This was done by adding a new
async_await_action_and_refresh
function to the coordinator. It addscheck_action_status
that awaits for success or error before callingasync_refresh
. This function is called usingasync_create_task
so that the action can finish without having to wait for a response that can take about 30 to 60 seconds. Since the function now waits for the action to complete before refreshing, the refreshed state now has the updated (post-action) information, updating the UI with the new status. To help avoid any possible bugs in regions that don't have check_action_status properly implemented (HyundaiBlueLinkAPIUSA which doesn't have that function and KiaUvoAPIUSA which doesn't implement the synchronous feature), check_action_status is wrapped in a try block, with a finally block that calls for a refresh, just as it did before.This has been tested with lock, unlock, start_climate and stop_climate in CA and works as expected.