-
Notifications
You must be signed in to change notification settings - Fork 679
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] Custom quirks not working in HA 2023.03 #2250
Comments
Error type:
Solution:
from zhaquirks.tuya.mcu import (
DPToAttributeMapping,
TuyaAttributesCluster,
TuyaMCUCluster,
TuyaDPType, # <-- REMOVE
)
dp_to_attribute: Dict[int, DPToAttributeMapping] = {
1: DPToAttributeMapping(
MotionSensorCluster.ep_attribute,
"zone_status",
dp_type=TuyaDPType.BOOL, # <-- REMOVE FROM ALL DPs
converter=lambda x: IasZone.ZoneStatus.Alarm_1 if not x else 0,
),
.../... |
Error type:It seems that there are no logs related but some entities stop working after update. It may be affected if the quirks made use of the dp_to_attribute: Dict[int, DPToAttributeMapping] = {
104: DPToAttributeMapping(
TuyaIlluminanceMeasurement.ep_attribute,
"measured_value",
dp_type=TuyaDPType.VALUE,
converter=lambda x: math.log10(x) * 10000 + 1 if x > 0 else 0, # <-- like this one
),
} Solution:An explicit conversion to the data type must be implemented in order for the code to perform the proper conversion. For the previous case, the correction would be the conversion to dp_to_attribute: Dict[int, DPToAttributeMapping] = {
104: DPToAttributeMapping(
TuyaIlluminanceMeasurement.ep_attribute,
"measured_value",
# dp_type=TuyaDPType.VALUE,
converter=lambda x: int(math.log10(x) * 10000 + 1) if x > 0 else int(0),
),
} Ref: #1928 (comment) |
Reserved |
1 similar comment
Reserved |
The reason for implanting custom quirk is for easy testing quirk for devs and users. The most impotent is knowing and informing users then making braking changes also for custom quirk for getting it working well also then the device is not officiously supported then the quirk is not PRed. Braking thins is always not welcome but is always happening and its importing fixing them like the large reworking of ZCL R7 that was braking very mush bit it wars very needed and we is getting good things from it all the time after its was done and i think its the same with the tuya MCU updates (and converting most tuya devices toEnchantedDevice that also is very needed and can braking some devices). Understanding and learning then things is not going well it is the definition of one intelligent animal and here is most very intelligent :-)) |
Yeah, I'd consider custom quirks as a temporary workaround. With the amount of users that use custom quirks, it's not ideal that ZHA currently completely breaks, but those quirks are not (and can't be) officially supported unless they're merged into zha-quirks. Thanks javicalle for the guide on fixing those quirks though!
I understand what you mean, but I'm not sure that would really make a difference. |
The ZHA is loading custom quirks i think it shall throwing one warning for every quirk that is loaded from the custom directory so the user is not forgetting that is one test function and not one permanent solution that is making on PR for betting it main ZHA. As sad custom quirks is user supported and only warning if knowing some is braking is needed then making changes but in the first row is Zigpy / zha for getting the system working well and its one must doing large complex changes that can being only 95% tested before merger them. By the was great thanks for the work on tuya MCU command part that was very needed as the implanting of quirk device classes for matching functions in ZHA !!! |
In setting > system > Repairs looks being one good place putting custom quirks warnings then the user can muting it to next manor update and its being re triggered like having portainer installed in one container and have suprevised HA installed or skipping updates of HA and addons. |
Hmm, I don't think a PR with those changes would be accepted. Custom quirks are considered to be similar to custom integrations. See: home-assistant/home-assistant.io#23884 (comment) |
Wish full thinking from my side ;-) So ZHA throwing warning in the log is the only realistic option. |
Yeah, warnings won't help as much as they should. I deprecated There isn't really much that can be done other than merging the custom quirks into the main repo, or letting things break (either explicitly or silently). I also agree with @TheJulianJES regarding custom quirks integrating with the frontend: they're 100% meant for development and quick testing, not for general use. I vote for merging #2242 to at least prevent blocking startup and upgrading the warnings to errors. |
Is there an easy was to see if a custom quirk was PRed? I think if quirk was added to connect a device that previously had no quirk at all - it should even be quite easy for Hass to perform a check and inform user, saying something "Hey, you're using a custom quirk for device X but we now support it officially" or something like that. If a custom quirk was used to fix a bug for a device that already has a quirk - well, probably not much to do here, but maybe there's some elegant solution to this as well. |
Im not sure if this is the right place or what i need tosupply but none of my zha quirks are working as of yesterday, this is my 2 gang switch: and my three gang switch: what is happening with my switchs is that when activate one button is activated via home assistant all the buttons activate on that switch. |
Your 3 gang is a local quirk. Have you tried the fix from this post? The 2 gang don't have a local quirk, so if there is a problem you should open a new issue with all the required info, in example, what is not working. |
Recently in HA v2023.03, the ZHA integration has stopped working due to issues with some user-installed custom quirks.
The issue is caused by some changes made to Tuya's MCU device implementations. These changes (necessary and brilliantly implemented) could have been deployed in a different way to avoid the impact on integration and the noise generated.
This could be fixed with PR #2242, but it only mitigates the effect of possible changes.
It should be said that the use of custom quirks implies (or should imply) some technical knowledge about what is being done and about the analysis of the incidents that can be generated. On many occasions the problem has been detected and corrected by the users, but not all users are the same.
My intention is to collect here the problem that occurred, the possible solutions and lessons learned.
The first thing is to identify the origin (or origins) of the problem.
I have detected mainly 2:
dp_type
from theDPToAttributeMapping
classtuya.Data
) #2017 that implements the autodetection of the Tuya data type from the value typeNothing to reproach the changes. I gave them my approval myself.
But it is clear that we underestimate the impact of change. Although all the code implemented in the library was modified according to the new implementation, the custom quirks hosted in the user installations have not, and these have affected the integration.
In order to mitigate this type of problem, it would have been convenient to grant a deprecation time to the implemented changes. It will not always be achievable, but at least we should considerate it.
Let it be clear that this issue is only addressed to myself and that he only seeks to collect my comments on it.
The text was updated successfully, but these errors were encountered: