I am using 2.5.10
I guess that means OH2 won’t be able to support that switch, which sends a custom command.
I’ll play around with the switches some more, but if your last statement is correct, there is no way to make them work natively in OpenHab…
It would be good if you could use the current codebase so that exception traces line up with the code.
Yes, unless the binding is modified to support it, then it will not be able to support the switch.
It is of course possible to make it work, but you would need to modify the binding. All I said is that we would not modify the ZigBee libraries - this is using a non-standard command, which is therefore (by definition) not part of the ZigBee library.
My understanding was, that “modifying the binding” == “write an XML that does what you want”, and “modifying the Zigbee libraries” == “modify com.zsmartsystems.zigbee”…
Maybe I got a little confused here, could you please clarify what (code) you mean by “modfiy the binding”?
@chris, hope your move is going well.
Here’s the good news:
I was able to add support for the manufacturer-specific command and have it trigger the OH button state whenever I press the physical button.
See patch attached:
0001-Add-support-for-Tuya.patch.txt (6.9 KB)
The downsides:
-
I am adding support for that command to any OnOff switch, whether they support it or not.
I can potentially identify the Tuya switches in the code and only add that command to qualified switches, but I am still introducing manufacturer-specific code to the generic OnOff switch. Not sure what you think about that and what the alternatives are. -
It does not distinguish between long/short/doublepressing the button.
I can probably emit an event for each of the “press types”, but there is only one button to toggle.
What I have now is good enough for my purposes, but I want to contribute back to the project and add support for these switches to OH2, so everyone can use them.
I’ll play with the code some more, see how much more “beautiful” I can make it, but I would appreciate your feedback. Specifically, how to add manufacturer-specific commands to the Zigbee bindings, in case you had thought about that earlier.
Maybe we can create a Tuya-specific ZigBeeConverterSwitchOnoff…?
Thanks,
Daniel
I’m currently working on getting the 4-gang switch to work. Many many thanks for the research and patches so far. It really helped a lot. From what I understand creating support for this is a two pronged approach for one there is a thing definition and secondly the converter which @schalli created, which would translate the raw zigbee commands and the other quirks of that device into something usable.
While I understand the reluctance to create device specific drivers for what should strictly follow zigbee standards, would it be possible to add maybe a quirks conversion layer?
Hi @Sunshine,
here’s my latest version:
0001-Add-Tuya-button-support.patch.txt (18.9 KB)
This one is emitting button events instead of toggling on/off and it’s not interfering with the generic onoff switch.
You need to add a custom XML and a mapping in discovery.txt for your 4-gang switch.
I think that’s the ‘conversion layer’ you were referring to.
Let me know if that works.
I haven’t added the battery clusters yet, but that should be a minor issue…
Hello Daniel,
just had a glimpse on your patch file and saw that you named the buttons “Left”,“Center” and “Right”.
As there are multiple versions of those switches (you know I own the 4-button version) it might be better to e.g. give them numbers and name them “Button1”…
Regards
Thomas
No worries about the power configuration cluster. That’s - I hope - easy to sort out, if its advertising as mains powered does still allow for reading voltage or level.
I do however noticed an oddity. While the log shows that only the first endpoint offers the power config cluster, openHAB (PaperUI) shows the power config on the first 3 endpoints and only the 4th endpoint is being On/Off only. I still need to debug that, but this is something I’d like to rectify too, if possible or someone else hasn’t done so before.
I also agree with @Oggerschummer that we should name the buttons with their number. There are several different versions of that switch around so placement might be a bit confusing.
Regards,
Sunshine
That might simply be an incomplete discovery. As far as I’ve seen, EVERY button is reporting battery levels.
(Or just another quirk of the Tuya buttons.)
In any case, I’d suggest we only keep voltage info on the FIRST button.
Each device has its own vendor and model name, e.g. _TZ3000_<8 random chars> / TS0043 (for the 3 button version).
You’ll have to add a custom XML and a line in discovery.txt for each of your device type as I outlined above.
In that XML, you can name the buttons appropriately, e.g. “UpperLeft”, “UpperRight”, etc for the 4 button version…
Hello Schalli,
May I ask against which version you created the second patch? I tried to apply it to plain master and it failed in several places to compile afterwards, most notably ZigBeeBaseChannelConverter.getChannel(ThingUID, ZigBeeEndpoint).
Or maybe I’m just missing something.
Cheers,
Sunshine
Yep, I just gathered it from the old imports. I updated it to V3 for myself now and added the definition form the 4-button switch.
Sorry about the wrong patch. I had accidentally put the thing definitions in the wrong directory. I’ve removed it for now and will post the corrected version again when it is working.
best regards,
Sunshine
Merry Christmas / Fröhliche Weihnachten!
Here’s a patch (for v2.5.10) that adds support for all Tuya switches (1, 2, 3, and 4 buttons), including power configuration (battery voltage / level / alarm):
0001-Add-Tuya-button-support.patch.txt (26.4 KB)
I think this is close to the final version, but it requires some more testing.
I’ve had some issues pairing the switches, but once they were paired, they have been working well so far 
Sometimes, it takes a couple of seconds until the event is reaching the coordinator, especially when the switch is not in direct reach of the coordinator and the packet has to travel a few hops.
Not sure why, other devices don’t seem to have that delay…
Anyway, @Oggerschummer, @Sunshine, please test and send feedback.
@chris, if you have time, please take a look and give feedback on the implementation / code.
Thanks,
Daniel
Merry Christmas indeed and thank you very much for that nice surprise gift.
I’ve just applied your patch to my 3.0.0 branch, ported it and testing the build now.
Merry Christmas,
Sunshine
Tested on 3.0.0 and it’s working well enough there too.
@chris @schalli @Oggerschummer what kind of unit tests do we want to add for this thing? I assume since this seems to be the first quirky device being added, we may want to set a standard for testing, so I assume we would like to see, that it is set up correctly, binds the necessary clusters and attributes and configures reporting as expected? And maybe having additional tests for checking that upon reception of an attribute report the correct call is triggered?
0002-Add_Tuya_button_support_-_xmas_patch_by_Daniel_Schaller.patch.txt (27.5 KB)
Merry Christmas,
Sunshine
Hello Daniel,
I tested the binding this morning with the following results:
- Switch with all four buttons discovered without problems
- All four button event channel discovered
- Battery channels shown only once - perfect
- Still reports as mains powered (caused by wrong information the device delivers)
- Events trigger correct (Pressed, double press, long press)
The buttons on the 4 button device report counterclockwise beginning with the lower left button. Device manual names our “Button 1” as “Button 2”, so this might irritate the user(This button is used for starting the discovery mode). In my opinion not tragic, just inconvenient.
What I saw is that the events startet firing only after I deactivated and reactivate the device after it was discovered. But I was not able to reproduce it.
For those who like to use those switches but are note familiar with using events:
Below is the code of the rule I used for testing my switch. It may be helpful as s starting point for dealing with the events and linking to items. No error handling, feel free to improve it.
Regards
Thomas
rule "TuyaTesting"
when Channel 'zigbee:tuya_ts0044:0600206B:bc33acfffe28b9e2:button1' triggered
or Channel 'zigbee:tuya_ts0044:0600206B:bc33acfffe28b9e2:button2' triggered
or Channel 'zigbee:tuya_ts0044:0600206B:bc33acfffe28b9e2:button3' triggered
or Channel 'zigbee:tuya_ts0044:0600206B:bc33acfffe28b9e2:button4' triggered
then
var chan = receivedEvent.getChannel()
var but = chan.toString.split(":").last()
var evt = receivedEvent.getEvent().toString()
switch (evt){
case "SHORT_PRESSED": {
logInfo("TuyaSwitchTest", but + " triggered:" + evt )
}
case "DOUBLE_PRESSED": {
logInfo("TuyaSwitchTest", but + " triggered:" + evt )
}
case "LONG_PRESSED": {
logInfo("TuyaSwitchTest", but + " triggered:" + evt )
}
default: {
logInfo("TuyaSwitchTest", but + " triggered unknown event:" + evt )
}
}
end
```After testing the switches for a little longer, I noticed that the switches randomly disconnect and start blinking.
They keep blinking until I either re-pair them, or (in case I don’t notice) until the battery is drained.
Has anyone of you observed this, too?
No, mine are running fine.
I think I found the reason for the strange “blinking until the battery is drained”.
Seems my switches need relatively high voltage / good batteries, and as soon as the voltage of the batteries drops too much, the switches don’t have enough power to function properly.
Then they go in a vicious on/off cycle that eliminates the rest of the battery in no time.