Hmm, in which case I'll have to do more digging once I get chance. It's entirely possible there's enough detail out there already to fix the issue, I'm just drowning in "Real Life Responsibilities" at the moment. 
2 Likes
Real life comes first. For most of us, this is just a fun hobby.
2 Likes
These do look interesting if they are able to report back state change. That said, one could probably do some sort of rule that would programmatically keep up with state, yes or no?
Comparing this Tuya version to the Sonoff ZBMINI-L of which I have several, they are the same size except 8mm thinner which is helpful. They also claim no need for the capacitor I had to add for one of my use cases,
Better make sure to order the TMZ02L and not the TMZ02 which requires neutral.
Can you tell @birdslikewires if this version is what you referenced as being digital so it will not be so loud when turned on and off as the Sonoff ZBMINI-L is?
I have two of these installed for testing and they definitely have a relay. There is a solid click noise about a half second after switching on or off using a paddle switch.
1 Like
Wait, what...you mean HA isn't Real Life?!
Can't believe it, my wife was right...
2 Likes
My wife is usually right... but don't tell her that 
2 Likes
Tuya Zugbee mini switch TMZ02L (_TZ3000_txpirhfq) was added into Muxa's "Zemismart ZigBee Wall Switch Multi-Gang" driver - please try the development branch (the second link in this post) :
I've downloaded the driver and should be able to test tomorrow. I'd removed the switches and it will be easier to reinstall when it's light out.
1 Like
@kkossev The Zemismart development branch driver works! Re-installed switch, detected as Tuya Switch Module TS0011 ; changed to Device and cleared everything ; changed to Zemismart driver. Didn't work yet so I re-detected zigbee device and did these steps again and now it's working. Not 100% reliable yet but it hasn't had much time for the zigbee mesh to optimize.
Thank you!
Further report... the driver is working reliably as of now. However, on a dashboard tile the status shows only as "Sending" after switching on or off. On the device page, the status shows instantly. I'm using the switch tile but have also tried the outlet tile.
BTW, I don't see the fingerprint for the _TZ3000_txpirhfq in the code but it does include "Ver. 0.2.7 2022-06-05 kkossev" so it must be the correct driver.
1 Like
I am glad to hear we are making progress!
This is a single channel switch and it seems like the driver does not handle 1-gang switches (or light switch modules) in the best way. Looking at the code I see it may get confused because TS0011 has no children ... Probably this driver has never been used with a sing gang switches until now. So let me look at this over the week.
And yes, _TZ3000_txpirhfq fingerprint is not in the driver code, will add it in the next update.
Do you have a wall switch connected to control the module locally? What type is it - a momentary switch or ...?
P.S. I removed the 'solution' mark, as there is still some more work to be done before the driver is fully functional.
Just got an idea - try switching to the HE inbuilt 'Generic Zigbee Switch' driver. Once the 'Tuya Black Magic' spell was cast toward a weird Tuya device (during the initial pairing), it is often magically transformed into a standard ZHA 1.2 device! 
Yes, it's a standard paddle (toggle, not momentary) switch. It works fine and I'm not bothered with the switch not being in the same position when the lights are on.
I've tried and although the device still works, the dashboard still has same problem showing "Sending" after a command. I've tried changing the driver to Device, and then to Generic Zigbee Switch in case that made a difference.
The other thing I notice is that the logs do not show anything while the driver is set to Generic. If I switch the driver back to Zemismart, then the logs start working again.
The new development branch version 0.2.7 2022/06/06 9:42 should be working now with the TS0011 single switch ( no child device will be created).
Please update the driver before testing again. Observe the device web page '"Current States"
switch value - should alternate between on and off when switched both from the device page, from a dashboard, and locally from the paddle.
I installed the latest version and it shows * driverVersion : 0.2.7 2022/06/06 9:42 AM on the device page but there's no difference on the dashboard. Still hangs at Sending. Also switching physically via the paddle is not reflected on the dashboard.
BTW, there's a small typo on the new fingerprint line deviceJoinName (Zugbee). Also on my device it shows * outClusters: 0019,000A and the fingerprint only has 0019. Since I don't know what the 000A attribute(cluster?) is for I don't know if that matters.
Thank you for the feedback, I have fixed the typo, and the outClusters are now corrected in the dev branch (timestamp 2022/06/06 9:47 AM ). '000A' is Zigbee time cluster, but omitting it in the fingerprint does not have any effects in my opinion.
It seems like you have some strange one-direction only communication.. The Zemismart switch accepts the commands, but the reporting back to HE hub is lost somewhere.. If you check http://192.168.0.66/hub/zigbee/getChildAndRouteInfo (replace the IP address with your local IP), do you see the switch in the 'Route Table Entry' communicating to HE via another repeating device?
When you have the chance, you may try switching off the HE hub for a couple of minutes and then powering it back again - this worked in @ADDs case.
Do you see any debug logs? What I am looking for is logs that contain "Parsed: [raw: ......." like this:
Debug Logs
dev:24792022-06-07 07:32:14.535 debugTS0011 _TZ3000_txpirhfq Parent switch on
dev:24792022-06-07 07:32:14.531 debugTS0011 _TZ3000_txpirhfq Parsed: [raw:739D0100060800001001, dni:739D, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:10, command:0A, value:01, clusterInt:6, attrInt:0]
dev:24792022-06-07 07:31:53.149 debugTS0011 _TZ3000_txpirhfq Parent switch off
dev:24792022-06-07 07:31:53.140 debugTS0011 _TZ3000_txpirhfq Parsed: [raw:739D0100060800001000, dni:739D, endpoint:01, cluster:0006, size:08, attrId:0000, encoding:10, command:0A, value:00, clusterInt:6, attrInt:0]
I've often displayed the getChildAndRouteInfo page and this switch is not showing, but many other devices also don't show. I guess there's a limit of 16 devices in the Route Table? (one is showing as unused but that also happens frequently). I've done the power off hub for 20 minutes routine after installing new zigbee devices that don't work reliably many times in the past and will do it again later today. It's never seemed to fix anything. I have noticed that all the devices in this list connect to 1 of 2 zigbee outlets that are about 2 feet from my hub and nothing is connected directly but maybe that doesn't show on this list. I guess I need to learn more about the inner workings of zigbee reporting.
Here's a log of turning the switch on and off:
dev:7272022-06-07 11:26:38.799 am infoKitchen Island Lights Turning all child switches on
dev:7272022-06-07 11:26:14.585 am debugKitchen Island Lights UNPROCESSED EP: null cluster: null attrId: null
dev:7272022-06-07 11:26:14.582 am debugKitchen Island Lights Parsed: [raw:catchall: 0104 0006 01 01 0040 00 03D2 00 00 0000 0B 01 0000, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:03D2, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:0B, direction:01, data:[00, 00]]
dev:7272022-06-07 11:26:14.330 am infoKitchen Island Lights Turning all child switches off
dev:7272022-06-07 11:26:05.743 am debugKitchen Island Lights UNPROCESSED EP: null cluster: null attrId: null
dev:7272022-06-07 11:26:05.740 am debugKitchen Island Lights Parsed: [raw:catchall: 0104 0006 01 01 0040 00 03D2 00 00 0000 0B 01 0100, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:03D2, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:0B, direction:01, data:[01, 00]]
dev:7272022-06-07 11:26:05.391 am infoKitchen Island Lights Turning all child switches on
The logs look just fine. The message from the switch when turned off/on are received, processed, and events are generated. All looks normal (ignore the unprocessed debug line, I will suppress it in the final version).
The problem should be in your dashboard. When a device is removed and re-added later, the IDs of the device may change. From Hubitat Dashboard add again the Tuya switch to the list of the devices that are available for the particular dashboard, then go to the dashboard,and delete the old switch and add it again.
Just to be safe, I again deleted and re-added the device from the dashboard app, then from the dashboard itself, but no improvement. I didn't really think this would help since the tile has been able to control the switch which wouldn't have been the case if the ID was wrong. It just doesn't display the state of the switch correctly. Still shows "Sending..." after clicking the tile to turn the switch on or off until I click the dashboard check mark to reload it.
In any case, I'd rather have this dashboard problem than not have the switch working. I can now use the switch in rules and can control it with Google Assistant so thanks again for all your work.
1 Like
I just bought 4 of Tuya ZigBee 3.0 Smart Light Switch 16A Smart Home Automation
and I'm confused if I will be able to use in a 2-way config. I have a 2 way switch at top and bottom of stairs wired as such
the wiring for the smart switch shows
and I found a different wiring shown here (for Sonoff so may not apply)
Knowing that I'm limited to the left box has the hot/neutral coming in and the right box has the wires going to the light and there is 3 wires between the 2 boxes.... I can't figure out WHERE to put the smart device within those wiring contraints ...is it even possible?
