Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correctly wait for transitions #510

Merged
merged 32 commits into from
Apr 4, 2023
Merged

Correctly wait for transitions #510

merged 32 commits into from
Apr 4, 2023

Conversation

th3w1zard1
Copy link
Collaborator

@th3w1zard1 th3w1zard1 commented Apr 3, 2023

This PR changes two things:

  • Wait for transitions before adapting a light
  • Remove all of the unnecessary code that assumes a transition could still be happening (e.g. cnt_significant_changes)

I've named all the PRs with number headings representing the ascending order they should merge in.

Hope this simplifies the changes a bit as I totally agree that having everything in one PR was a bit too much upkeep.

@th3w1zard1 th3w1zard1 force-pushed the wait_for_transitions branch from 59f358b to 52275bf Compare April 3, 2023 03:57
@th3w1zard1 th3w1zard1 changed the title Wait for transitions (Main) Wait for transitions Apr 3, 2023
@th3w1zard1 th3w1zard1 requested a review from basnijholt April 3, 2023 04:54
@th3w1zard1 th3w1zard1 changed the title (Main) Wait for transitions (1.) (Main) Wait for transitions Apr 3, 2023
@th3w1zard1 th3w1zard1 changed the title (1.) (Main) Wait for transitions < 1 > (Main) Wait for transitions Apr 3, 2023
@basnijholt
Copy link
Owner

I seemed to have broken something accidentally so I reverted my change. I will continue in #516.

th3w1zard1 and others added 4 commits April 3, 2023 03:29
last_state_change isn't updated quick enough.
* Change (WIP)

* Update test_switch.py

* Refactor

* Revert "Revert "Small refactor""

This reverts commit 3731c99.

* Update README.md

* Fix the test

* Bump to 1.9.0 (#518)

* Basic community fixes PR (#460)

* Fixes #423

#423

* Do not adapt lights turned on with custom payloads.

* Update switch.py

* Issue fixes

#423, #378, #403, #449

* quickly test #274

* Revert feature requests, this branch only has fixes.

Reverted FR 274

* pre-commit fix

* Create automerge.yaml

* test

* Delete automerge.yaml

My bad.

* Fix #460 and #408

* see @basnijholt 's comment in #450.

* @basnijholt requested changes.

---------

Co-authored-by: Bas Nijholt <[email protected]>

* Undo accidental changes introduced in #509, but adds the changes from #460 (#521)

* Release 1.9.1 (#522)

* Bump to 1.9.1

* Add CODEOWNERS

---------

Co-authored-by: Benjamin Auquite <[email protected]>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
@th3w1zard1
Copy link
Collaborator Author

Once this is implemented, I highly recommend changing the default config values.

e.g. interval: 5 transition: 60 as updating attributes isn't nearly as cpu-intensive as calling light.turn_on. A reminder that we're also checking if the service data differs from the last adapt in 1.9.1

@th3w1zard1
Copy link
Collaborator Author

th3w1zard1 commented Apr 3, 2023

Awesome!

I believe I didn't explain the purpose of cnt_significant_changes properly. The idea is that sometimes the light changes not because of a light.turn_on event, but because the light has been changed e.g., on a dimmer in the wall, or via Google Home.

Therefore we are seeing whether a light has changed.

I think your fix is orthogonal to the cnt_significant_changes code being broken.

We need your fix regardless, but I think we shouldn't remove the cnt_significant_changes functionality (given we still want that fixed).

I don't quite see the purpose of this? Once a transition finishes, we're updating the light's state via update_entity to see if it correctly matches the last service data. What more needs to be done? If a light is updated outside of home assistant, update_entity should still refresh its state in HASS.

Also the current implementation in this PR passes the test_significant_change test where we test non ha changes.

@th3w1zard1
Copy link
Collaborator Author

th3w1zard1 commented Apr 3, 2023

@basnijholt I moved this here for accessibility:

The ONLY possible cases where detect_non_ha_changes can fail in this pr (ordered most to least problematic):

  1. Light never got the light.turn_on command we sent with the last service data somehow. Haven't seen this happen in the two weeks I've been using the new significant_change code. Perhaps this could be tested in our tests?
  2. Light went offline during the transition of the last adapt, code will currently fire the manual control event for any bulbs that go offline. This was an already outstanding issue in the old code. (see Initial Adjustment Delay after light comes online (from unavailable) #307)
  3. Light is improperly configured by the user and doesn't report any state changes to hass even after an update_entity() call (e.g. zigbee bulb where reporting is configured to off)
  4. (fixed in Fix RGB Color Temp Swaps #514) Light's entity state was correctly adapted to last_service_data but the light converted the color data (e.g. color_temp_kelvin used in our service data but was converted by the light to rgb_color)

Please add to this list if you think of any outstanding issues!

@th3w1zard1
Copy link
Collaborator Author

@basnijholt What is the is_async argument used for in _fire_manual_control_event? I notice it's only False for significant_change

@th3w1zard1 th3w1zard1 changed the title < 1 > (Main) Wait for transitions [ 1 ] (Main) Wait for transitions Apr 3, 2023
tests/test_switch.py Outdated Show resolved Hide resolved
@basnijholt basnijholt changed the title [ 1 ] (Main) Wait for transitions Correctly wait for transitions Apr 3, 2023
@basnijholt
Copy link
Owner

This is really great!

Glad you got to the bottom of this 3-year-old bug 😄

I changed the manifest.json version to 1.10.0, such that I can tag a new version right away.

@th3w1zard1
Copy link
Collaborator Author

th3w1zard1 commented Apr 4, 2023

This is really great!

Glad you got to the bottom of this 3-year-old bug 😄

I changed the manifest.json version to 1.10.0, such that I can tag a new version right away.

Can we include #513 and #512 in the release? Having alt_detect_method may be nice for users still experiencing problems with detect_non_ha_changes

@basnijholt basnijholt merged commit c7f44e4 into main Apr 4, 2023
@basnijholt basnijholt deleted the wait_for_transitions branch April 4, 2023 00:04
@basnijholt
Copy link
Owner

I prefer to take it one at the time because those PRs are another 500+ lines of code changes.

I also don't have time today to review those anymore :-(

@th3w1zard1
Copy link
Collaborator Author

I prefer to take it one at the time because those PRs are another 500+ lines of code changes.

I also don't have time today to review those anymore :-(

Good idea! Thank you SO much!!

@basnijholt
Copy link
Owner

@all-contributors please add @th3w1zard1 for bugs

@allcontributors
Copy link
Contributor

@basnijholt

I've put up a pull request to add @th3w1zard1! 🎉

@basnijholt
Copy link
Owner

@all-contributors please add @th3w1zard1 for maintenance

@allcontributors
Copy link
Contributor

@basnijholt

I've put up a pull request to add @th3w1zard1! 🎉

@th3w1zard1 th3w1zard1 restored the wait_for_transitions branch April 6, 2023 03:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants