detect_non_ha_changes incorrectly detecting changes from rgb_color to color_temp #449
Assignees
Comments
|
Can you post your config? what's your interval set to and your transition? do you have |
Yes, without that it won't detect manual control changes that I actually want (via physical switches / other apps). Not sure how to get the config in YAML format, but here are screenshots The only thing I changed since filing this issue, was enabling |
|
Try setting your |
|
Thanks for the quick response, now i'm having trouble reproducing (it seems When it happens again, I will attempt the transition fix. |
|
Update: Still happening, attempting the transition fix. Seems like for most people, that fixed the issue of lights turning BACK on unintentionally after being turned off (which I have also experienced), but the manual control flag is more of the issue i've been trying to debug. Perhaps the interval is related to both, will report back here with findings once I give it some time. |
1 similar comment
|
Update: Still happening, attempting the transition fix. Seems like for most people, that fixed the issue of lights turning BACK on unintentionally after being turned off (which I have also experienced), but the manual control flag is more of the issue i've been trying to debug. Perhaps the interval is related to both, will report back here with findings once I give it some time. |
|
Okay this morning the same thing happened, lights came on via my normal good morning automation (after being off all night), but got tagged with manual control. New Config: Logs: |
|
|
|
I'd rename your issue to something like:
You're welcome to try my Pull Request to see if it fixes your issue.. Shameless plug to my own PR as I need testers. Just add |
nathang21
changed the title
It does yes, here is is. For what it's worth, i've previously tried adding delays, and adjusting the order of actions but haven't noticed any improvements. It doesn't seem like disabling sleep mode before/after turning on the lights made much of a difference, but i've tried so many different things at this point I might be conflating variables. automation.yamlalias: Good morning automation
description: ""
trigger:
- type: motion
platform: device
device_id: 75f3d34c516e472f8865e361c3e64b47
entity_id: binary_sensor.keypad_occupancy_sensor_2
domain: binary_sensor
for:
hours: 0
minutes: 0
seconds: 3
- type: motion
platform: device
device_id: 846e89dac7f620b1cf0f5424f7171883
entity_id: binary_sensor.living_room_motion_sensor_2
domain: binary_sensor
for:
hours: 0
minutes: 0
seconds: 3
- type: motion
platform: device
device_id: 6a2621fefb96255214ee13495ee7d44c
entity_id: binary_sensor.office_occupancy_sensor_2
domain: binary_sensor
for:
hours: 0
minutes: 0
seconds: 3
condition:
- condition: and
conditions:
- condition: device
device_id: f5dc6eec3d92ebd49b5777d1a63c9766
domain: alarm_control_panel
entity_id: alarm_control_panel.abode_alarm_2
type: is_armed_home
- condition: time
weekday:
- mon
- tue
- wed
- thu
- fri
- sat
- sun
after: "05:00:00"
before: "11:30:00"
action:
- service: light.turn_on
data: {}
target:
entity_id: light.living_room_lights
continue_on_error: true
- service: light.turn_on
data: {}
target:
entity_id: light.kitchen_lightstrips
continue_on_error: true
- device_id: f5dc6eec3d92ebd49b5777d1a63c9766
domain: alarm_control_panel
entity_id: alarm_control_panel.abode_alarm_2
type: disarm
code: "2369"
continue_on_error: true
- service: media_player.media_pause
target:
device_id: 7ac1d8ba91ef1c3bbb772171feb735fa
entity_id: media_player.googlenestpointead9_3
data: {}
continue_on_error: true
- service: media_player.volume_set
target:
device_id: 7ac1d8ba91ef1c3bbb772171feb735fa
entity_id: media_player.googlenestpointead9_3
data:
volume_level: 0.5
continue_on_error: true
- service: climate.set_temperature
data:
target_temp_low: 65
target_temp_high: 75
hvac_mode: heat_cool
target:
device_id: 4dd6c5a84f9d751f6af17b64315500a7
entity_id: climate.hallway
continue_on_error: true
- service: input_boolean.turn_off
data: {}
target:
entity_id: input_boolean.alarm_on_off
continue_on_error: true
- service: switch.turn_off
data: {}
target:
entity_id:
- switch.adaptive_lighting_sleep_mode_living_room
- switch.adaptive_lighting_sleep_mode_kitchen
- switch.adaptive_lighting_sleep_mode_master_bedroom
continue_on_error: true
- service: script.disable_adaptive_lighting_manual_control
data: {}
enabled: true
mode: singlescript.yamlalias: Disable Adaptive Lighting Manual Control
sequence:
- service: adaptive_lighting.set_manual_control
data:
entity_id:
- switch.adaptive_lighting_living_room
- switch.adaptive_lighting_kitchen
- switch.adaptive_lighting_master_bedroom
- switch.adaptive_lighting_office
- switch.adaptive_lighting_nursery
manual_control: false
mode: single
Done.
This looks great, when I get some time later this weekend I will hopefully give this a shot. Thanks for all the help. |
|
No problem at all! |
|
Sorry to ask for more but I also need to see your script.disable_adaptive_lighting_manual_control |
|
Oops sorry about that, just edited my comment above to include that. |
|
Found the problem(I think) Just have your script turn the main adaptive switch off and on again for now, I'll see what I can do for a more perm fix. Turning the main switch off and on resets manual control and should start the adaptive process fresh |
|
That's a good idea, thats effectively what i've been doing as a workaround everytime I notice it's not adapting properly. I also just installed your PR, probably going to use all 3 new config options, looks to be exactly what I need. I will leave feedback there if you prefer. |
|
Fantastic! Yes if you use that PR please leave any future issues you have specifically concerning manual control there as to not confuse the devs. |
|
@th3w1zard1 So little update, still having the same issue "lights not adapting when expected" however after using your PR, i'm noticing manual control is not set at all, but the lights still fail to adapt, I also see some new errors in the logs (see screenshot). At first it did seem like the interval changes you suggested above helped so maybe I should have waited before also testing the PR. Would love your thoughts here on how best to proceed.
|
|
Oof a 'task exception was never received' is really bad. I'm confused why I haven't seen it on my side. I put out a substantial update to the PR in the past 24 hours that I'm hoping will fix the 'task exception was never received' error.. but as much as I'd like testers I'm not going to ask you to forgo ensured stability. But if you're still willing to test please grab the latest build! Otherwise, if you're a bit tired of dealing with the bugs and would like to regain stability, I'd revert back to the main build, as I really think just turning on and off the switch will bypass that 'rgb_color to color_temp' check. I really think that will fix your original issue. |
|
Apologies, regarding the new options I had the following (otherwise same config except I added Thankfully it's pretty easy to revert back to the official release via HACS, so I did that last night, but I am happy to continue helping out with your PR, but I may be a bit slow to respond with work, and a baby on the way any day now! I'll grab the latest build and report back with more logs if/when I can reproduce. EDIT: Just re-installed the latest PR, and restarted - so far no errors in logs.
With this in mind on the main build, do you still recommend setting the interval lower than all the transition times as well? Just want to make sure i'm not conflating issues/solutions here, and will try to keep the variable changes to a minimum. |
Congratulations!!
Setting interval lower than the transition time is necessary if you want a manual change event to fire while using
interval and transition time relation will not matter for
Please use this as you like, change as much as you want! it's the best way to find new issues. |
|
Using the latest official version of this addon (test PR has been closed/merged it seems), i'm still getting manual control tagged on my kitchen lightstrip(s) almost always despite never changing anything outside of HA. Please let me know if I can provide more detail or help test in anyway @th3w1zard1. Config: Logs (trimmed to last ~12 hours: |
@nathang21 The pr #450 we've been testing has been closed in favor of #486. Would you mind seeing if #486 fixes your issue? |
|
Done, same issue, manual control applied right away after HA restart. Logs: |
|
These are really good logs, I'm glad I added the extra debugging. Looking at this now. |
|
So it looks like the service data we're sending the light is getting converted into rgb_color after the light.turn_on, then when we check for a manual change it's detecting color_temp existed in the service data, but not in the state. I'm just going to remove that bit of code as it doesn't seem to catch any real manual events anyway. I can't imagine someone swapping to rgb_color then using the exact same values that adaptive lighting sent in it's last service data under tl;dr I fixed the problem, please try the new build! |
|
Okay I've been running this all day, few things I noticed.
|
|
Hey - I should be able to roll out another fix for this in the next few minutes! |
th3w1zard1
added a commit
to th3w1zard1/adaptive-lighting
that referenced
this issue
Mar 31, 2023
- `significant_change` now checks `last_state_change[light][0]` instead of `last_service_data[light]` to fix basnijholt#449 - Readded 'switched from RGB mode to color_temp or visa versa' in both `switch.py` and `test_switch.py` Fixed `KeyError: 'light'` during forced call of `_update_manual_control_and_maybe_adapt()`
I need to test the build quickly to ensure it'll work correctly before I waste your time. |
|
I lost power due to a storm but I'll push these fixes once it's restored 😁 |
|
@nathang21 Pushed the changes, double checked a few things from your logs, everything should probably be fixed this time. |
th3w1zard1
added
need/author-input
status/done+waiting-for-review
and removed
status/in-progress
labels
|
@nathang21 Hey wanted to point out you can set |
th3w1zard1
added a commit
that referenced
this issue
Apr 3, 2023
* 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]>
basnijholt
added a commit
that referenced
this issue
Apr 3, 2023
* 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]>
basnijholt
added a commit
that referenced
this issue
Apr 3, 2023
* 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 Should I upgrade to the official v 1.9.1 or stay on the PR #486 from a few days ago (whichever commit this is [1]), since it looks like that will be split up into multiple PR's? Things are working much much better now, not 100% sure it's perfect yet, but will keep monitoring. [1] adaptive-lighting-rewrite_detect_non_ha_changes_slowattempt (2).zip |
basnijholt
added a commit
that referenced
this issue
Apr 4, 2023
* Add auto_reset_manual_control with async timer * cherry-pick wait for transition stuff * Update switch.py * not renamed in this branch yet. * Update switch.py * update tests * Update switch.py * merge related fix * cleanup * Revert "cleanup" This reverts commit 3aa2f32. * Update switch.py * Update switch.py * Update switch.py * Small refactor * Move test to old position for better diffs * Revert "Small refactor" This reverts commit b986b3f. * Update README.md * fix the test last_state_change isn't updated quick enough. * #510 changes (#516) * 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> * No need to wrap the reset * Remove unused attrs * Shorter log message * revert unrelated tests change * remove unused function * Use patch * Bump to 1.10.0 --------- Co-authored-by: Bas Nijholt <[email protected]> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Bas Nijholt <[email protected]>
|
@nathang21 Unfortunately this fix couldn't make it into 1.10.0 but you can grab #514 as I wrote that pr to fix your issue here specifically. #514 is a clone of 1.10.0 with the only change being the fix for this issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version information:
version 1.4.1
Description:
I have 2 govee lightstrips in the Kitchen controlled by Adaptive Lighting, both are members of an HA group called "Kitchen Lightstrips" which is what I set AL to control.
AL works correctly and adjusts the color/brightness but doing so causes them to get flagged as manual control, when no manual control actions were done. I'm not sure how to avoid this, but this problem isn't happening with my other lights/rooms in the house with seperate AL configurations.
See below for logs, these 2 the lines appear odd to me, but i'm not sure how to avoid this.
Logs
The text was updated successfully, but these errors were encountered: