-
Notifications
You must be signed in to change notification settings - Fork 675
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
[BUG] TS0601 changing brightness turns off device #1694
Comments
Thanks for the info at #1554 |
I recently changed from Deconz + Conbee II to ZHA + Conbee II. I have no experience with ZHA before HA 2022.8. I also didn’t find other people with this problem until now. I have 3 different Tuya Dimmers (all from brand Moes), and all have the same behavior with turning off the actual light (not the status of the light) when brightness is changed (slider in UI or change in HomeKit for instance). types: I hope there is a solution for this behavior. If I can help with some logs, I need some guidance what to do. |
Confirming the issue as well with my dimmer (TZE200_3p5ydos3) |
I have a similar issue with dimmer TS0601 by _TZE200_dfxkcots and one month before it was OK. I can't say that updates cause this problem. But now then i try to change brightness, lamp is always turn off. On entity brightness number is changed, lamp brightness stay the same. When I change brightness with dimmer knob, it changed and brightness number on entity changed. I remove and reinstall the device with no effect. |
Can someone with this issue turn on full debug logs and attach an unedited/unfiltered log of the interaction? |
|
Where are the logs from the radio lib? |
@TheJulianJES |
Sry for not pasting all the logs, just briefly checking, if I'm not compromising any secrets... I'm not familiar with the full debug logs |
@dmulcahey if you need anything else, feel free to contact me even via my email, or just write here, I'll do my best to help with this :) |
@dmulcahey rest of the logs 4 the timewindow, since somehow I didn't paste it all |
Hello everyone. I recently updated from HA 2022.04 to .08 and had the same issue with my dimmers when setting the level. I could fix it by reverting one change from pull request #1489. |
Is this the section you mean? I'm not sure how to change it as this issue is driving me crazy and no-one is fixing it...
|
Yes, that's the section. After posting my reply, I realized that HA actually expects the on_off command to be sent and behaves weirdly if not. It assumes the light turns on and off based on the level, and does not send explicit on_off commands when using scenes, for example. So I ended up leaving the code in and changing a single line:
to:
Basically, this fully implements the move_to_level_with_on_off assuming the device's min_level is 0. From my understanding, for a correct implementation, the min_level would need to be fetched from the device, but this is probably good enough for most use cases and fixes the current issue. |
Ummm, I believe that this is a misunderstanding of the command ARGS meaning.
I will check it later at home, but I believe that the proposed code can do the job. |
And here is the PR #1748 It will restore the 'normal' behavior, but... |
In case someone wants to test the new version before next release, you can enable the local quirks and copy the file from here: |
just a tiny bug remains - might be unrelated to this one and moved to a separate one - then the dimmer is turned off and I move the knob, the GUI shows, that the light turned on, but the physical light stays off |
Just to be sure, when you says "I move the knob" are you refering to the knob of the physical device (and not from the GUI) right? Can you attach the HA logs from 'moving the knob' from the physical device? |
I'm pretty sure @lotr is describing the same behavior that I described as "HA behaves weirdly" (which, admittedly, is not very descriptive...). HA expects the move_to_level_with_on_off to be correctly implemented, so when the light is off and you increase the level using the slider in HA, HA automatically reports the light as on, since it has sent the move_to_level_with_on_off command. With the new code change, the light does not turn on, so there is a discrepancy between the actual state and what HA reports. |
@javicalle I mean the GUI knob, I'll attach the logs later today :) |
How do I do that? Do I just add that file to the /config/zha_quirks folder and ensure this is in HA configuration.yaml?
that doesn't seem to work... |
@shanelord01 what I've done, I've checked the pull request which contained only a single file, so I changed the file in the python venv lib folder |
How do I access that? |
@shanelord01 depends on your installation - you have to find the exact file in the HA installation folder, try to grep it for example :) |
So I guess I'm screwed as I'm using Home Assistant OS... :( |
@javicalle Here's the log. The physical device was off, the device in the GUI was off. I've moved the GUI knob from the most left position (min position) to some value. The physical device did not turn on, but the GUI was showing the device as it was turned on.
|
Ummmm, I believe that would be a little more complex... You will need to copy also the And adapt (in the ts0601_dimmer.py file) all the from zhaquirks.tuya import NoManufacturerCluster, TuyaDimmerSwitch
from custom_zha_quirks import (
TuyaInWallLevelControl,
TuyaLevelControlManufCluster,
TuyaOnOff,
TuyaOnOffNM,
) |
The fixed command probably will be included in the next HA release. |
I confirm my dimmers work correctly after upgrading to HA Core 2022.10.4 |
Describe the bug
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clear and concise description of what you expected to happen.
This used to work, I honestly don't know what version. I'm 100% sure this is broken in all 2022.8.x versions.
Device signature
Diagnostic information
Additional logs
Additional context
Related issues:
Possible causes:
NoManufacturerCluster
classes #1572NO_MANUFACTURER_ID
dimmers #1489NO_MANUFACTURER_ID
dimmers #1489 (comment)The text was updated successfully, but these errors were encountered: