Nested quirks signature triggering

[MattWestb]

Some tuya devices like the TS004X family devices is very Zigbee but need little patching for working OK in ZHA like disabling the time cluster for not turning itself off in 2 minutes and its working great the all devices is behaving the same and using MODEL: "TS0041" as signature for all types.

Then its tuya devices it very likely coming "custom versions" that is little different and needs being selected with MODELS_INFO and manufacturer and model strrings.

Is it possible in the quirk first adding devices with MODELS_INFO for getting devices that need extra settings and after that one MODEL in the end for the "normal" devices that need only "general family" patching and ZHA is loading "model info" with the right quirk part and the rest is getting "model" part ??

I dont knowing how the selection mechanism is working but if its possible doing like in my example its wold being great for some devices quirks.

Mvh MW

[MattWestb]

Also if its possible i think its one policy question how to implanting quirks so its being good done and not 15 different ways doing the same thing.

I think all tuya ts0601 deices shall being moved to one folder for not being mixes with "normal" Zigbee device that not needing all DP things in the init that is in the tuya main folder.
(Its for the moment better then Z2M that have "moes" devices as one own file and some is in the "tuya" file that is making one big mess for looking for supported devices)

[MattWestb]

All ts0601 devices quirk is renamed and is starting with ts0601_ and function (with exceptions) and all other ("tuya Zigbee" not DP devices) is starting with tsxxxx and function if its more functions in the device family.
All switches and remotes is using MODELS_INFO so not need adding all new device that is dropping in.
Only sensor is still using ts02xx_function then its many different fixes in the family.
tuya power state and and default power multiple is moved to the tuya init so more device can reusing the code.

ts0601.py is need being spited but i dont do that then i dont have the device for testing is its working after splitting the file.

[MattWestb]

Have starting adding functions i tuya INI with TuyaZB in front of the function in the INI for making then easier to see that is zigbee devices and not DP device function like:
from zhaquirks.tuya import TuyaZBMeteringCluster, TuyaZBOnOffRestorePowerCluster

2 unknown tuya cluster 0xE000 and 0xE001 that is out of range ((0xFC00, 0xFFFF) is the range for manufacture cluster) and need being defined for not getting problems then making quirks.
The 0xE002 is being used for configuring Temperature and Humidity Alarms.
One 0xEEFF have being seen but is no known function on it.

[MattWestb]

We have testing with TS004F and if first adding MODELS_INFO for "special devices" and the last class is MODEL: the model info is first cached and loaded and not the model and if the device is not having one matching model info its using the model if the EP / cluster config is OK.
Tested with the classical 4 button dimmer switch and the new knob and both is triggering there class and if changing the model id its using the model = OK.