[Release] Tuya/Lonsonho 1-gang and 2-gang zigbee dimmer module driver

Ah interesting. Will be good to hear how you get on with it. I've not got any sniffer kit and only have a rudimentary understanding of the protocols thus far.

@fc352bf0a6929e9fa80f
Hey I just received the QS-Zigbee-D02-TRIAC-2C-LN today, and wired it up in a test harness on my desk.
It has the right model listed _TYZB01_v8gtiaed but when I installed it, it didn't create a child device for the second switch.

The way I installed it was to add the driver to my list of drivers, plugged in the module and the light started flashing (the physical switch was turned off), when I saw the light flashing I started the pairing mode and the device was added to the network.

I wouldn't think this would make a difference, but I only have 1 light connected to the module instead of 2. I wouldn't have expected the device + driver to be that smart that it would detect that I didn't connect a second light and not create the child devices.

Any help would be appreciate. Not sure what logs you might find useful. I didn't have the log opened up when I paired it anyway

edit:

actually I had more of a play around after enabling debug logging and found this issue:

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:34:21.786 [debug](http://192.168.1.5/device/edit/79)onSwitchLevel: Value=183 level=72

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:34:21.771 [debug](http://192.168.1.5/device/edit/79)onSwitchLevel: value=183

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:34:21.766 [debug](http://192.168.1.5/device/edit/79)Received parsed: [raw:9BAE01000808000020B7, dni:9BAE, endpoint:01, cluster:0008, size:08, attrId:0000, encoding:20, command:0A, value:B7, clusterInt:8, attrInt:0]

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:34:21.761 [info](http://192.168.1.5/device/edit/79)Received raw: read attr - raw: 9BAE01000808000020B7, dni: 9BAE, endpoint: 01, cluster: 0008, size: 08, attrId: 0000, encoding: 20, command: 0A, value: B7

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:34:15.731 [debug](http://192.168.1.5/device/edit/79)true Living Room Lights Living Room Lights 1

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:34:15.726 [debug](http://192.168.1.5/device/edit/79)Received parsed: [raw:9BAE0100060800001001, dni:9BAE, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:10, command:0A, value:01, clusterInt:6, attrInt:0]

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:34:15.722 [info](http://192.168.1.5/device/edit/79)Received raw: read attr - raw: 9BAE0100060800001001, dni: 9BAE, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 01

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:33:48.367 [debug](http://192.168.1.5/device/edit/79)true Living Room Lights Living Room Lights 0

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:33:48.362 [debug](http://192.168.1.5/device/edit/79)Received parsed: [raw:9BAE0100060800001000, dni:9BAE, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:10, command:0A, value:00, clusterInt:6, attrInt:0]

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:33:48.358 [info](http://192.168.1.5/device/edit/79)Received raw: read attr - raw: 9BAE0100060800001000, dni: 9BAE, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 00

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:33:43.660 [debug](http://192.168.1.5/device/edit/79)true Living Room Lights Living Room Lights 1

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:33:43.655 [debug](http://192.168.1.5/device/edit/79)Received parsed: [raw:9BAE0100060800001001, dni:9BAE, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:10, command:0A, value:01, clusterInt:6, attrInt:0]

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:33:43.651 [info](http://192.168.1.5/device/edit/79)Received raw: read attr - raw: 9BAE0100060800001001, dni: 9BAE, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 01

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:33:26.892 [debug](http://192.168.1.5/device/edit/79)true Living Room Lights Living Room Lights 0

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:33:26.884 [debug](http://192.168.1.5/device/edit/79)Received parsed: [raw:9BAE0100060800001000, dni:9BAE, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:10, command:0A, value:00, clusterInt:6, attrInt:0]

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:33:26.880 [info](http://192.168.1.5/device/edit/79)Received raw: read attr - raw: 9BAE0100060800001000, dni: 9BAE, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 00

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:33:11.752 [error](http://192.168.1.5/device/edit/79)com.hubitat.app.exception.UnknownDeviceTypeException: Device type 'Tuya Zigbee dimmer module V2' in namespace 'matthammonddotorg' not found on line 205 (updated)

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:33:11.711 [info](http://192.168.1.5/device/edit/79)Creating child 0 with dni 9BAE-01

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:33:11.700 [debug](http://192.168.1.5/device/edit/79){application=41, manufacturer=_TYZB01_v8gtiaed, model=TS110F}

[dev:79](http://192.168.1.5/logs#dev79)2021-01-23 00:33:11.666 [info](http://192.168.1.5/device/edit/79)updated parent->child

Hmm. Probably a mistake on my part in the driver initialisation code. Try going into the device and clicking "configure" ... That ought to definitely cause try child device to be created.

I agree it ought to not make a difference whether one or both are wired up or not!

Let me know if this works. I'll take a more detailed look at the logs later and let you know if I spot anything else.

Aah. Think I just spotted the bug - thanks to the logs you provided! Try re-importing the driver source code then either going to the device and clicking "configure" or deleting the device and re-pairing with the dimmer.

1 Like

Brilliant, that did it.
I just needed to hit configure and the child devices were created. Thanks very much for the fix.

I looked at the git history and saw that it was indeed a tiny typo :slight_smile:

Good to hear that it works for you!

I've now made this driver available via the hubitat package manager

2 Likes

that's great :slight_smile:
I was actually thinking of doing an pull request to add it to the hubitat package manager for you :slight_smile:

Hey,

I've noticed a potential improvement that could be made to these drivers.

I'm using device watchdog to monitor if any devices drop off the network either because the battery dies, the device is unplugged it for some other reason it falls off the network.

Device watchdog uses the "last activity at" field to decide if the device is working ok or if it's dropped off.

I'm wondering do these devices send updates back to the hub on a regular basis?
If yes would it be possible for the driver to update that timestamp?
At the moment the only time that timestamp gets updated is if the state of the device actually changes.

If I understood correctly you can send a state update from the driver to Hub even if the state hasn't changed and in that case the hub platform will filter out the state so that no automations get retriggered, but the last activity at date will be updated accordingly

Interesting question. Do you definitely mean lastActivityAt, or do you mean lastUpdateTime?

I'm honestly not sure if they do send a regular update. Can I suggest turning on debug mode and checking the logs for a period of time to see if any zigbee messages are logged by the driver? I'm doing the same.

I've noticed that there is a catchall message that my driver seems to receive, but I'm not sure when that occurs or how to interpret it. I think it only happens when there is a state change though. Example:

Received parsed: [raw:catchall: 0104 0008 01 01 0040 00 0812 00 00 0000 0B 01 0400, profileId:0104, clusterId:0008, clusterInt:8, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:0812, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:0B, direction:01, data:[04, 00]]

If it did occur regularly without state changes, then I guess it could be treated as an event worthy of updating the timestamp?

Sorry I didn't see your reply there.
Yeah good idea I'll turn on device logging and monitor it.

Yes I'm sure it's the "last activity at"
That's the field that various community apps like device watchdog use so that you can figure out if a battery device has died or if a powered device was "unplugged"

Last update time seems to be related to wherever device preferences are saved or something like that. Not too sure about this one.

If there isn't a regular update sent from the device, from looking at various drivers it might be possible at initial configuration to configure the device to automatically send the value of a specific cluster at a regular intervals. Similar to how temperature devices can be configured to report their temperature for changes of 0.1 degrees or higher changes it's also possible to set a minimum and maximum time reporting interval

Can you point me at any examples of this that you've come across? (Preferably source on GitHub!)

Firstly - thanks for the driver!

Works with my QS-Zigbee-D02-Triac-2C-LN (although I'm only using a single channel).

When I bought these devices (from Aliexpress) the listing suggested it worked with a standard 'toggle' switch.

I realise now, that it indeed can be controlled by a toggle switch - but not how I'd like it to be! A quick on-off (mimicking a momentary switch) turns the switch on/off. A single 'toggle' does the dimming.

That's fine for me, but not for my other half - who wants to be able to control it like any other light switch (On/Off, with dimming via the app if necessary)!

I guess there is no way around this, and I will never be able to turn it on/off in the 'normal' way with a light switch?

Hi Pavr27, glad the driver works for you!

I don't think the behaviour can be changed - it's hardcoded in the device firmware and behaves that way irrespective of whether it is connected to other smart devices or not.

Probably the simplest solution is to get some momentary switches. The unnecessarily complicated alternative I can think of would be to replace the switch with a ZigBee one, but I think that is more complicated for no discernable benefit :slight_smile:

Forgot to mention: assuming you are UK based, momentary/retractive swtiches are fairly easy to come by. E.g. screwfix: https://www.screwfix.com/c/electrical-lighting/switches-sockets/cat830530#category=cat7320002&switchproducttype=retractive

Thanks for the info re switches. Actually I did a google search for others as I want a two gang one, in brushed metal...there are plenty out there nowadays (I remember a few years ago the only ones available were the white plastic ‘bell’ labelled ones). Let’s hope my partner will ‘tolerate’ momentary switches!

Hi
I have got myself a 2 Gang Zigbee Dimmer module by Moes. I think they are by Tuya. I have installed the driver and initially wired to one lighting. it was working perfectly (thank you) Tired to wire to the second light but I just could create a child device. Any suggestion please?

Hi @ugm2byww - I'm glad you tried the driver and it is at least partially working for you. Please allow me to check: I think you are saying that it is a 2-gang module, but that my driver does not automatically create two child devices (one for each channel) ... is this correct or have I misunderstood? The driver should automatically create the child devices it needs.

The driver looks for specific device fingerprints, and has a built-in table telling it how many channels it needs to provide for that fingerprint. The solution to your problem might be as simple as me adding it to the driver.

Can you provide the fingerprint for your device? ("manufacturer", "model", etc from the 'data' section under "device details".

sorry it has been busy few weeks.
yes you are correct in that I couldn't create two child devices. this the module that I have got

the fingerprint of my device is as of below

  • endpointId: 01
  • application: 42
  • softwareBuild:
  • inClusters: 0000,0004,0005,EF00
  • outClusters: 0019,000A
  • model: TS0601
  • isMultiEP: false
  • manufacturer: _TZE200_e3oitdyu

No problem @ugm2byww and thanks for the fingerprint.

I must admit it is a little confusing - looking at what cluster IDs it supports it implies it doesn't support the standard commands for on/off and dimmer level adjustment. Did you say the driver did appear to work for one of the channels? Both for turning on/off and for dimming? If you can confirm that it does then I'll roll an experimental version for you to try.

Download the Hubitat app