[Device Support Request] QS-Zigbee-D02-TRIAC-2C-LN - TS110E _TZ3210_pagajpog

[mbrton]

Is it possible to extend Tuya ts110e.py with support for 2 gang version _TZ3210_pagajpog?

I also tryed Lonsonho version TS110F _TYZB01_v8gtiaed with same results

Without quirk they works only as switch, no dimming functionality.

here is actual signature: DS.txt

[javicalle]

I would suggest this quirk:

DimmerSwitchWithNeutral2Gang

class DimmerSwitchWithNeutral2Gang(TuyaDimmerSwitch):
    """Tuya Dimmer Switch Module With Neutral 2 Gang."""

    signature = {
        MODELS_INFO: [("_TZ3210_pagajpog", "TS110E")],
        ENDPOINTS: {
            # <SimpleDescriptor endpoint=1 profile=260 device_type=257
            # input_clusters=[0, 4, 5, 6, 8, 57345]
            # output_clusters=[10, 25]>
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.DIMMABLE_LIGHT,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    OnOff.cluster_id,
                    LevelControl.cluster_id,
                    TuyaZBExternalSwitchTypeCluster.cluster_id,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            },
            # <SimpleDescriptor endpoint=2 profile=260 device_type=257
            # input_clusters=[0, 4, 5, 6, 8, 57345]
            # output_clusters=[]>
            2: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.DIMMABLE_LIGHT,
                INPUT_CLUSTERS: [
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    OnOff.cluster_id,
                    LevelControl.cluster_id,
                    TuyaZBExternalSwitchTypeCluster.cluster_id,
                ],
                OUTPUT_CLUSTERS: [],
            },
            242: {
                # <SimpleDescriptor endpoint=242 profile=41440 device_type=97
                # input_clusters=[]
                # output_clusters=[33]
                PROFILE_ID: 41440,
                DEVICE_TYPE: 97,
                INPUT_CLUSTERS: [],
                OUTPUT_CLUSTERS: [GreenPowerProxy.cluster_id],
            },
        },
    }
    replacement = {
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.DIMMABLE_LIGHT,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    OnOff.cluster_id,
                    F000LevelControlCluster,
                    TuyaZBExternalSwitchTypeCluster,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            },
            2: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.DIMMABLE_LIGHT,
                INPUT_CLUSTERS: [
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    OnOff.cluster_id,
                    F000LevelControlCluster,
                    TuyaZBExternalSwitchTypeCluster.cluster_id,
                ],
                OUTPUT_CLUSTERS: [],
            },
            242: {
                PROFILE_ID: 41440,
                DEVICE_TYPE: 97,
                INPUT_CLUSTERS: [],
                OUTPUT_CLUSTERS: [GreenPowerProxy.cluster_id],
            },
        },
    }

[mbrton]

Thank you. I addet this code to original file ts110e.py. First channel starts to work very well, but second channel is still not working properly. Any idea how to fix it?

[javicalle]

Have you removed the device from HA and paired it again? If still don't works, enable the debug logs and attach the relevant info here:

• https://www.home-assistant.io/integrations/zha/#debug-logging

[PTwr]

@javicalle I am up to test this bug as well, guess I keep making wrong purchases :)

Without quirk: only On/Off works.

With Quirk: partial dimming Channel 1: On/Off + Dimming Channel 2: On/Off only

HA receives On/Off updates correctly.

Dimming on Channel 1 goes all the way down to fully off, but I don't know if its bug or a feature. (Same lightbulb in _TZE200_dfxkcots TS0601 rotary dimmer never goes as low) Dimming on Channel 2 does nothing.

Setting light level from Off state doesn't even turn on light, but HA incorrectly sees it as On.

Channel 2 in logs is listed as light.tz3210_pagajpog_ts110e_light_2

Logs from clicking around in pairing screen: DimmerSwitchWithNeutral2Gang.logs.txt

Full debug logs from restart to attempts at dimming: home-assistant_2022-12-20T15-04-59.220Z.log (a bit cluttered by few other devices)

[javicalle]

It seems to me that there's a bug in the replacement part of the endpoint 2. Can you replace the LevelControl.cluster_id with F000LevelControlCluster (yes, without the .cluster_id)

Not sure if I understand the dimming behavior. Can you elaborate it? Logs from the behavior will be also helpful.

[PTwr]

Replacing LevelControl.cluster_id with F000LevelControlCluster makes dimming work.

Dimming behavior: Dimming is deeper than in https://github.com/home-assistant/core/issues/83832 I have deep dimming LED bulbs. With TS110 (this) they go all the way down to zero. With TS0601 (rotary dimmer from other issue) minimum brightness is on "night light" level. But thats the dimmer behavior on its own, both without pairing or via Tuya gateway. So probably feature, not a bug.

I don't have time today to do full testing, , I'll try to get clean logs tomorrow.

[javicalle]

So there are 3 issues:

• add the ts110e 2 gang device
• the dimming range of the device 0-65535 vs ZHA range 0-255
• the minimum dim -> turn off the device

Isn't it?

Point 1 should be fixed now.

Point 2 could be addressed in the attribute value conversion:

• https://github.com/zigpy/zha-device-handlers/blob/c2b2893d027fdcd3a225996fdf382d2ac72ff799/zhaquirks/tuya/ts110e.py#L85
• https://github.com/zigpy/zha-device-handlers/blob/c2b2893d027fdcd3a225996fdf382d2ac72ff799/zhaquirks/tuya/ts110e.py#L115

But not sure if it is a common behavior for all the TS110e devices or just this one. @MattWestb, any advice here?

The point 3 could be a side effect of point 2. I suggest to address first the point 2 and them check again.

[MattWestb]

Welcome down in the ZCL rabbit hole from tuya MCU heights @javicalle !!

Some from ZCL R8:

The ground is in 3.10 Level Plus the derived for level for lights.

For Light level:

Name Range Default M/O CurrentLevel 1 to FE 0xff M

7565 3.19.2.2.1 CurrentLevel Attribute for Lighting 7566 A value of 0 SHALL not be used. 7567 A value of 1 SHALL indicate the minimum level that can be attained on a device. 7568 A value of 0xfe SHALL indicate the maximum level that can be attained on a device. 7569 A non-value of 0xff SHALL represent an undefined value. 7570 All other values are application specific gradations from the minimum to the maximum level.

7556 3.19.2.1 Dependencies 7557 Please see examples of state changes with regards to the On/Off server cluster in section 3.19.4. (the logic if turning on or off then getting level commands)

5058 3.8.2.1.1 Effect on Receipt of Level Control Cluster Command (and the same for On/Off cluster)

Plus the min and max level shall not being smaller / larger then the device set min and max level.

So if the device have max level set to 200 (in hardware or sett by command) it shall being the max the device is using in all cases and the same for the min level.

You need locking on the 3.19.2.1 (level) and 3.8.2.1.1 (On/Off) in ZCL R8 for see the logic between level and On/Off.

Sorry for not answering with one yes or no but is not so easy and making braking things is very bad for other devices.

[javicalle]

Ummm, not sure if I want to look inside that hole... 🙈

But the issue here is that the F000LevelControlCluster uses a custom command to dim, so no standar to look at for help 😓

Until now, the dim conversion in F000LevelControlCluster has been 0-1000 vs 0-256 Now a new device states that the conversion would be 0-65535 vs 0-255. But I haven't found any similar behavior around. That's the reason to invoke to you and your knowledge

At the other side, @PTwr, are you sure that the dimmer uses all the 0-65535 range? I mean, device may need a '16bit' value for accomodating a 0-1000 range, but that doesn't means that would use all the 16 bit range. Do you have evidences for that?

[MattWestb]

@javicalle I think the most important is only using 0-254 then 255 is unknown and 0 is reserved. The min and max i think is best implanting on manufacture attributes and if its possible also "converting" it to ZCL is its possible.

Also the default is ZHA is not shoeing the level then the light is off but is knowing the level. Also sending step or move is tricky then the light i off so better stick to the "ZHA standard" then its possible.

As you is knowing tuya is changing there standard "on the fly" so i think you need one conversion for the 0-1000 (1K) and one for the 0-65535 (64K).

And one good point if tuya is using all the 64K or only some part for and the rest as function bits like start from zero, may or last used.

If you have little to do and being bored CSA-ITO have making man heavy papers and now Matter spec is online but is shall using most of the ZCL R8 if i have understanding it right.

[PTwr]

At the other side, @PTwr, are you sure that the dimmer uses all the 0-65535 range? I mean, device may need a '16bit' value for accomodating a 0-1000 range, but that doesn't means that would use all the 16 bit range. Do you have evidences for that?

I have not made any extensive testing, 65535 was just first large number I thought of when testing TS0601. It was just to make sure it will always be max, 2^32-1 would be my next attempt if it would still be dim at 100% :) However when I recalculated range 8bit->16bit (for that setlevel command) it matched dimmer behavior for lowest and highest, and range felt accurate. Its rather easy to confirm as my TS0601 has physical knob that works even when unpaired.

I can do more manual tests with my 16bit hack once I get back to my smartcrib, but does it still matter if quirk you shared fixes that?

For TS110 we need 2gang SWITCH+DIMMER added, as in current HA release its detected as 2gang SWITCH only. It also appears to have no concept of minimum brightness, but as I mentioned before I don't know how dimmers in HA are supposed to work at 0% as I only have TS110 and TS0601 currently.

For everything else... I have no idea. Gotta do more googling before I can answer (or understand question) as my HA adventure started last week.

But it appears to me that primary blocker to fixes are devices with same ID might work differently (eg. 8bit vs 16bit)? If so, can we just add some config flags editable from UI? I don't think there's other way to overcome such conflict if devices are a mess.

[javicalle]

but does it still matter if quirk you shared fixes that?

Well, the proposed quirk will only dim your device between 1-1000 (aprox). If your device values can go up to 64K there is a lot to dim left. I believe that this was also an issue, but probably I misunderstood the fatcs.

Please, keep the issue conversation about the _TZ3210_pagajpog device. Mixing data from several devices makes me difficult to recall the issue facts when I come back.

So, is then any issues left with that device?

[AlpineWhite]

but does it still matter if quirk you shared fixes that?

Well, the proposed quirk will only dim your device between 1-1000 (aprox). If your device values can go up to 64K there is a lot to dim left. I believe that this was also an issue, but probably I misunderstood the fatcs.

Please, keep the issue conversation about the _TZ3210_pagajpog device. Mixing data from several devices makes me difficult to recall the issue facts when I come back.

So, is then any issues left with that device?

I picked one of these up (and the single gang + neutral) and ran it with the custom quirk on the single gang, just put both in ts110e.py.

Seems to work fine using code in this comment appended to ts1103.py in the main branch, and loaded using custom_quirks. I do believe it does get full brightness from the 1000 setting for manufacturer_max_brightness as-written and I can dim both channels in UI and in automations.

Can probably close #1422 using the quirk addition above.

EDIT: Looks like #1422 was already merged, but the merge did not address anything on this device. I only achieved full functionality after adding the snippet commented here to my custom ts110e.py quirk (copied from main repo)

[AlpineWhite]

AH, one other little issue.

So fade on off action works. When set to none, the lights go out immediately. However, on_off_transition_time, and on_transition_time are both set to none, and any attempt to change the value will fail to change, and the device maintains a 1-2s ramp-up on the 'ON' action.

Action: Read value for on_transition_time in cluster 1 Write 0 to on_transition_time in cluster 1 Read value for the same (comes back as 'None')

I see this in the logs:

2023-02-12 07:41:40.462 DEBUG (MainThread) [homeassistant.components.zha.api] Requested attributes for: cluster_id: 8, cluster_type: 'in', endpoint_id: 2, response: [{'id': 0, 'name': 'current_level'}, {'id': 1, 'name': 'remaining_time'}, {'id': 2, 'name': 'min_level'}, {'id': 3, 'name': 'max_level'}, {'id': 4, 'name': 'current_frequency'}, {'id': 5, 'name': 'min_frequency'}, {'id': 6, 'name': 'max_frequency'}, {'id': 15, 'name': 'options'}, {'id': 16, 'name': 'on_off_transition_time'}, {'id': 17, 'name': 'on_level'}, {'id': 18, 'name': 'on_transition_time'}, {'id': 19, 'name': 'off_transition_time'}, {'id': 20, 'name': 'default_move_rate'}, {'id': 16384, 'name': 'start_up_current_level'}, {'id': 65533, 'name': 'cluster_revision'}, {'id': 65534, 'name': 'attr_reporting_status'}, {'id': 61440, 'name': 'manufacturer_current_level'}, {'id': 64514, 'name': 'bulb_type'}, {'id': 64515, 'name': 'manufacturer_min_level'}, {'id': 64516, 'name': 'manufacturer_max_level'}] 2023-02-12 07:41:45.252 DEBUG (MainThread) [zigpy.zcl] [0xB321:2:0x0008] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True, *is_reply=False), tsn=38, command_id=<GeneralCommand.Read_Attributes: 0>, *direction=<Direction.Server_to_Client: 0>, *is_reply=False) 2023-02-12 07:41:45.253 DEBUG (MainThread) [zigpy.zcl] [0xB321:2:0x0008] Sending request: Read_Attributes(attribute_ids=[18]) 2023-02-12 07:41:45.254 DEBUG (MainThread) [bellows.zigbee.application] Sending packet ZigbeePacket(src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), src_ep=2, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0xB321), dst_ep=2, source_route=None, extended_timeout=False, tsn=38, profile_id=260, cluster_id=8, data=Serialized[b'\x00&\x00\x12\x00'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=None, rssi=None) 2023-02-12 07:41:45.255 DEBUG (MainThread) [bellows.ezsp.protocol] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xb321, EmberApsFrame(profileId=260, clusterId=8, sourceEndpoint=2, destinationEndpoint=2, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=38), 39, b'\x00&\x00\x12\x00') 2023-02-12 07:41:45.267 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame received sendUnicast: [<EmberStatus.SUCCESS: 0>, 86] 2023-02-12 07:41:45.276 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame received messageSentHandler: [<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 45857, EmberApsFrame(profileId=260, clusterId=8, sourceEndpoint=2, destinationEndpoint=2, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=86), 39, <EmberStatus.SUCCESS: 0>, b''] 2023-02-12 07:41:45.276 DEBUG (MainThread) [bellows.zigbee.application] Received messageSentHandler frame with [<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 45857, EmberApsFrame(profileId=260, clusterId=8, sourceEndpoint=2, destinationEndpoint=2, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=86), 39, <EmberStatus.SUCCESS: 0>, b''] 2023-02-12 07:41:45.287 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame received incomingMessageHandler: [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=8, sourceEndpoint=2, destinationEndpoint=2, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=93), 255, -70, 0xb321, 255, 255, b'\x18&\x01\x12\x00\x86'] 2023-02-12 07:41:45.287 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=8, sourceEndpoint=2, destinationEndpoint=2, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=93), 255, -70, 0xb321, 255, 255, b'\x18&\x01\x12\x00\x86'] 2023-02-12 07:41:45.288 DEBUG (MainThread) [zigpy.application] Received a packet: ZigbeePacket(src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0xB321), src_ep=2, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), dst_ep=2, source_route=None, extended_timeout=False, tsn=93, profile_id=260, cluster_id=8, data=Serialized[b'\x18&\x01\x12\x00\x86'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=255, rssi=-70) 2023-02-12 07:41:45.288 DEBUG (MainThread) [zigpy.zcl] [0xB321:2:0x0008] Received ZCL frame: b'\x18&\x01\x12\x00\x86' 2023-02-12 07:41:45.289 DEBUG (MainThread) [zigpy.zcl] [0xB321:2:0x0008] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True, *is_reply=True), tsn=38, command_id=1, *direction=<Direction.Client_to_Server: 1>, *is_reply=True) 2023-02-12 07:41:45.290 DEBUG (MainThread) [zigpy.zcl] [0xB321:2:0x0008] Decoded ZCL frame: F000LevelControlCluster:Read_Attributes_rsp(status_records=[ReadAttributeRecord(attrid=0x0012, status=<Status.UNSUPPORTED_ATTRIBUTE: 134>)]) 2023-02-12 07:41:45.294 DEBUG (MainThread) [homeassistant.components.zha.api] Read attribute for: cluster_id: [8] cluster_type: [in] endpoint_id: [2] attribute: [18] manufacturer: [None] response: [None] failure: [{18: <Status.UNSUPPORTED_ATTRIBUTE: 134>}],

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.