Adding support for Tuya ZS3L / TZ3000 / TS0043 / TS0042 / TS0041 to Zigbee Bindings

DanM · October 28, 2022, 4:50am

I got the TS004F model working for all 4 buttons each with short press, double press and long press working with some small edits to the TS0044’s XML file (OH-INF\thing\tuya\ts0044.xml) and by mapping tuya_ts0044,modelId=TS004F in discovery.txt. I just edited the org.openhab.binding.zigbee-3.4.0-SNAPSHOT.jar file using 7-zip for now - will try to get proper changes into GitHub soon.

The edits to ts0044.xml are setting the button1-4 endpoints all to be 1 (rather than 1-4) which I’m not sure is a weird solution or not because this is my first encounter with Zigbee bindings - I suspect maybe the device configuration is a bit odd - I’ll put the node and fingerprint diagnostics below. To me it looks like all the button events are being sent to output clusters defined on endpoints 1-4 depending on which button is pressed which may be the opposite to how it was done with TS0044.

I read some posts about TS004F saying you needed to use a Tuya Zigbee gateway and the Smart Life app to switch it from dimmer mode to scene mode but you can just hold top right and bottom right buttons for about 10 seconds to switch modes. I think (but am not sure) the sequence of getting it into the right mode was:

Stop openHAB (I am using 3.4.0-SNAPSHOT).
Make edits below to discovery.txt and OH-INF\thing\tuya\ts0044.xml on org.openhab.binding.zigbee-3.4.0-SNAPSHOT.jar using 7-zip and put it in the OPENHAB addons folder.
Start openHAB.
Hold bottom left button for about 10 secs to put device in pairing mode.
Start Zigbee pairing.
If it comes up as “Unknown Zigbee…” or similar stop pairing and press buttons if device did not automatically come out of pairing mode when you stopped the scan. Start pairing again and it should come up as something similar to “_TZ3000_xabckq1v…”. Wait a few mins and occasionally press buttons to keep device awake until it comes into ONLINE state and then wait maybe 5 mins to be on the safe side.
Press and hold the top right and bottom right buttons for about 10 seconds to switch to scene mode (dimmer is supposed to be default).
Press the buttons and look for entries similar to the following in OPENHAB/userdata/logs/events.log file:
2022-10-27 22:45:27.121 [INFO ] [openhab.event.ChannelTriggeredEvent ] - zigbee:tuya_ts0044:f8e02ab2a8:5c0272fffe24a55b:button2 triggered SHORT_PRESSED
2022-10-27 22:45:44.964 [INFO ] [openhab.event.ChannelTriggeredEvent ] - zigbee:tuya_ts0044:f8e02ab2a8:5c0272fffe24a55b:button1 triggered DOUBLE_PRESSED
2022-10-27 22:46:26.720 [INFO ] [openhab.event.ChannelTriggeredEvent ] - zigbee:tuya_ts0044:f8e02ab2a8:5c0272fffe24a55b:button3 triggered LONG_PRESSED
If you don’t see them switch the mode by holding the buttons and try again. I removed the device and restarted OpenHAB a few times while experimenting - not sure if that was necessary or not but worth a try if you don’t see anything in the events.log.

Changes OH-INF\thing\tuya\ts0044.xml (just set from 2-4 to 1 in buttons1-4):

		<channel id="button1" typeId="tuya_button">
			<label>Button 1</label>
			<properties>
				<property name="zigbee_endpoint">1</property>
			</properties>
		</channel>

		<channel id="button2" typeId="tuya_button">
			<label>Button 2</label>
			<properties>
				<property name="zigbee_endpoint">1</property>
			</properties>
		</channel>

		<channel id="button3" typeId="tuya_button">
			<label>Button 3</label>
			<properties>
				<property name="zigbee_endpoint">1</property>
			</properties>
		</channel>

		<channel id="button4" typeId="tuya_button">
			<label>Button 4</label>
			<properties>
				<property name="zigbee_endpoint">1</property>
			</properties>
		</channel>

Add this to the end of discovery.txt:

tuya_ts0044,modelId=TS004F

Zigbee nodes output:

openhab> zigbee nodes
Network Addr IEEE Address Logical Type State EP Profile Device Type Manufacturer Model
46141 B43D 60A423FFFE952209 END_DEVICE ONLINE 1 ZIGBEE_HOME_AUTOMATION DIMMER_SWITCH _TZ3000_xabckq1v TS004F
2 ZIGBEE_HOME_AUTOMATION ON_OFF_SWITCH
3 ZIGBEE_HOME_AUTOMATION ON_OFF_SWITCH
4 ZIGBEE_HOME_AUTOMATION ON_OFF_SWITCH

Zigbee fingerprint output:

Logging that gave me some clues (this was from after edit discovery.txt but before editing ts0044.xml):

Top Left

Short Press:
2022-10-27 21:00:02.871 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction complete: ZigBeeTransaction [ieeeAddress=60A423FFFE952209 queueTime=104, state=COMPLETE, sendCnt=1, command=DefaultResponse [On/Off: 0000/0 → B43D/1, cluster=0006, TID=6F, commandIdentifier=253, statusCode=SUCCESS]]
Double Press:
2022-10-27 21:00:44.982 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction complete: ZigBeeTransaction [ieeeAddress=60A423FFFE952209 queueTime=103, state=COMPLETE, sendCnt=1, command=DefaultResponse [On/Off: 0000/0 → B43D/1, cluster=0006, TID=70, commandIdentifier=253, statusCode=SUCCESS]]
Long Press:
2022-10-27 21:01:48.321 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction complete: ZigBeeTransaction [ieeeAddress=60A423FFFE952209 queueTime=106, state=COMPLETE, sendCnt=1, command=DefaultResponse [On/Off: 0000/0 → B43D/1, cluster=0006, TID=71, commandIdentifier=253, statusCode=SUCCESS]]

Top Right

Short Press:
2022-10-27 20:40:54.044 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - Incoming message from node B43D did not translate to command
2022-10-27 20:40:54.149 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction complete: ZigBeeTransaction [ieeeAddress=60A423FFFE952209 queueTime=106, state=COMPLETE, sendCnt=1, command=DefaultResponse [On/Off: 0000/0 → B43D/2, cluster=0006, TID=5E, commandIdentifier=253, statusCode=FAILURE]]
Double Press:
2022-10-27 20:43:58.514 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction complete: ZigBeeTransaction [ieeeAddress=60A423FFFE952209 queueTime=106, state=COMPLETE, sendCnt=1, command=DefaultResponse [On/Off: 0000/0 → B43D/2, cluster=0006, TID=64, commandIdentifier=253, statusCode=FAILURE]]
Long Press
2022-10-27 20:45:03.054 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction complete: ZigBeeTransaction [ieeeAddress=60A423FFFE952209 queueTime=107, state=COMPLETE, sendCnt=1, command=DefaultResponse [On/Off: 0000/0 → B43D/2, cluster=0006, TID=65, commandIdentifier=253, statusCode=FAILURE]]

Bottom Left

Short Press:
2022-10-27 20:48:37.326 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction complete: ZigBeeTransaction [ieeeAddress=60A423FFFE952209 queueTime=102, state=COMPLETE, sendCnt=1, command=DefaultResponse [On/Off: 0000/0 → B43D/3, cluster=0006, TID=66, commandIdentifier=253, statusCode=FAILURE]]
Double Press:
2022-10-27 20:49:40.959 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction complete: ZigBeeTransaction [ieeeAddress=60A423FFFE952209 queueTime=105, state=COMPLETE, sendCnt=1, command=DefaultResponse [On/Off: 0000/0 → B43D/3, cluster=0006, TID=68, commandIdentifier=253, statusCode=FAILURE]]
Long Press:
2022-10-27 20:51:44.129 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction complete: ZigBeeTransaction [ieeeAddress=60A423FFFE952209 queueTime=105, state=COMPLETE, sendCnt=1, command=DefaultResponse [On/Off: 0000/0 → B43D/3, cluster=0006, TID=6A, commandIdentifier=253, statusCode=FAILURE]]

Bottom Right

Short Press:
2022-10-27 20:53:15.510 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction complete: ZigBeeTransaction [ieeeAddress=60A423FFFE952209 queueTime=106, state=COMPLETE, sendCnt=1, command=DefaultResponse [On/Off: 0000/0 → B43D/4, cluster=0006, TID=6B, commandIdentifier=253, statusCode=FAILURE]]
Double Press:
2022-10-27 20:55:47.142 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction complete: ZigBeeTransaction [ieeeAddress=60A423FFFE952209 queueTime=108, state=COMPLETE, sendCnt=1, command=DefaultResponse [On/Off: 0000/0 → B43D/4, cluster=0006, TID=6D, commandIdentifier=253, statusCode=FAILURE]]
Long Press:
2022-10-27 20:57:18.965 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction complete: ZigBeeTransaction [ieeeAddress=60A423FFFE952209 queueTime=107, state=COMPLETE, sendCnt=1, command=DefaultResponse [On/Off: 0000/0 → B43D/4, cluster=0006, TID=6E, commandIdentifier=253, statusCode=FAILURE]]

schalli · October 28, 2022, 5:07am

Hi @DanM , welcome to the community!
Thanks for your analysis, I personally don’t have a 4-button switch, so I can’t experiment with it.

Looking at your traces, I can see the buttons report individual endpoints.
What you are seeing in your trace is the response (hence the word DefaultResponse in the log) sent from the Zigbee coordinator at 0000/0 to the endpoint B43D/x to let the device know that the command failed.
Endpoint /x is the endpoint that has sent the command to begin with.

Top Left has endpoint 1:
2022-10-27 21:00:02.871 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction complete: ZigBeeTransaction [ieeeAddress=60A423FFFE952209 queueTime=104, state=COMPLETE, sendCnt=1, command=DefaultResponse [On/Off: 0000/0 → B43D/1, cluster=0006, TID=6F, commandIdentifier=253, statusCode=SUCCESS]]

Top Right has endpoint 2:
2022-10-27 20:40:54.149 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction complete: ZigBeeTransaction [ieeeAddress=60A423FFFE952209 queueTime=106, state=COMPLETE, sendCnt=1, command=DefaultResponse [On/Off: 0000/0 → B43D/2, cluster=0006, TID=5E, commandIdentifier=253, statusCode=FAILURE]]

and so on…

I’m curious how it worked out for you mapping all buttons to endpoint 1 in the XML.

DanM · October 28, 2022, 6:34am

Well darn. In retrospect it did seem a bit too good to be true and while testing I had not taken into account that pressing button 1 would be sending all 4 commands that I would later find in the logs.

I believe button 1 is functioning correctly by dropping in the ts0044 config, but I was not able to determine how to construct the remaining 3 channels by looking at the nodes and fingerprint which may have led to some wishful thinking - any pointers you could provide would be great.

schalli · October 28, 2022, 2:47pm

Judging from the log you sent, each button does have its own endpoint from 1 to 4 and uses the same command id as my buttons (253).
Makes me think the default config should have just worked.

Did you check the file /var/log/openhab/events.log for button-pressed events, or how did you determine that button 1 kind of works?

Can you remove the button, stop OpenHab, upload your modified jar, start OpenHab, and then add the button again and give it another try?
IIRC, OpenHab does not re-initialize the device/channel when the jar is modified while the device has already been added.
That can lead to half-initialized/non-working buttons.

Thanks,
Daniel

DanM · October 28, 2022, 3:54pm

Thanks for your prompt help - greatly appreciated.

Did you check the file /var/log/openhab/events.log for button-pressed events, or how did you determine that button 1 kind of works?
With the unmodified XML file I could see the 3 types of event in the events.log for button 1 but not for buttons 2-4, and there were cluster-related errors initializing the channels which I will capture. After turning on Zigbee logging per the binding doc I could see lots of log entries in openhab.log related to commandIdentifier=253 and EPs 2-4 from which I pulled the log entries posted previously - I will capture a full sample.

Can you remove the button, stop OpenHab, upload your modified jar, start OpenHab, and then add the button again and give it another try?
Will give this a go later today. Thanks again for your help.

schalli · December 7, 2022, 6:06pm

Hey @chris , as mentioned in the PR, I am sending you a log snipped from my test setup.
The tuya button is the only device connected to my Zigbee stick ATM, so all comms should be only between the coordinator and the device:

asking for time cluster.txt (124.2 KB)

As you can see in the log, the Tuya device is asking for cluster 000A (time) every ~11 minutes, but the coordinator doesn’t know how to handle that.
Since Time is a standard cluster, and seems to be implemented in the Zigbee lib (ZclTimeCluster), I figured it should be possible to enable that cluster somehow.
However, I’m stuck on the details, how to add support for it.
IIUC, the coordinator needs to support this cluster, not the device, because the coordinator is supposedly the one providing this cluster to callers…?

I’m hoping that fixing the missing time cluster will stop the device from waking up every 11 minutes and stop draining the battery.

Thanks,
Daniel

chris · December 7, 2022, 7:35pm

Hey Dan,

There’s a bit going on here… Time is one issue, but the device is also constantly requesting the NodeDescriptor and I can’t remember off the top of my head if the NCP responds to that or not.

Anyway, one thing at a time (no pun intended), and regarding time - let’s deal with that first…

Yes, the Time cluster is supported in the library, but that’s just basic support. This doesn’t really do anything - it’s just the cluster definition. I’m happy to look at adding more support for this - it shouldn’t take me very long to do (hopefully). I’ll try and take a look at this over the next few days as I’ll be sitting on a plane for 36 hours