Yes, I saw that, and I have tried pressing three times each time I have tested this, but the result is always the same.
I have tried assigning actions in deCONZ, looking for events in deCONZ, and with REST via homebridge-deconz.
I have a second button that I intend to try to see if maybe I just have a defective device.
Ok, I have tried a second button with the same results.
Do you have the GUI ?
Take a look in deconz/help/debug view , with flag “info”, “info_l2” (“DDF”), and press the button, you need to see something about “buttonmap”.
Nothing about buttonmap. I see lines like:
17:15:46:867 [INFO] - No button handler for: TS004F, broadcast to: 0x0000, endpoint: 0x01, cluster: LEVEL_CONTROL (0x0008), command: MOVE_TO_LEVEL (0x00), payload: 3F0100, zclSeq: 100
followed shortly later with
17:15:47:165 [INFO] - No button handler for: TS004F, broadcast to: 0x0000, endpoint: 0x01, cluster: COLOR_CONTROL (0x0300), command: 0x06, payload: A93F0100, zclSeq: 101
These always come in pairs one LEVEL_CONTROL and one COLOR_CONTROL.
It’s not the mapping used for this device.
"TuyaSmartButton": {
"vendor": "Tuya",
"doc": "Smart Button with two modes (remote mode not mapped)",
"modelids": ["_TZ3000_ja5osu5g"],
"map": [
[1, "0x01", "ONOFF", "0xfd", "0", "S_BUTTON_1", "S_BUTTON_ACTION_SHORT_RELEASED", "Short"],
[1, "0x01", "ONOFF", "0xfd", "1", "S_BUTTON_1", "S_BUTTON_ACTION_DOUBLE_PRESS", "Double"],
[1, "0x01", "ONOFF", "0xfd", "2", "S_BUTTON_1", "S_BUTTON_ACTION_LONG_RELEASED", "Long"]
]
The one previsouly tested use the cluster 0x0006.
You have a device picture here Add DDF + Button Map for _TZ3000_ja5osu5g Tuya Smart Button by Xyaren · Pull Request #6977 · dresden-elektronik/deconz-rest-plugin · GitHub it’s the same one you have ?
If you change the mode, the device still using same cluster ?
This device have 2 mode
The mapping is done for the Scenario mode.
This certainly seems to be the same device.
I have never been able to get it to change mode. 
From the page you linked to above:
Notes
Testing is quite challenging. When playing aroung with bindings, I managed to put the button in some kind of state, that prevented the mode switch by 3x pressing the button.
Even after re-pairing this state remained.
Only after I brute-force played around with the unbinding in the GUI I managed to revert it backt to its initial behaviour.
I wonder if this is my issue. I will try playing around to see if I can somehow trick it into changing modes.
I still haven’t managed to change mode. I see other systems like hubitat report issues around integration, saying things like needing to pair twice.
So I tried pairing again, but that didn’t help either.
I am not sure what to try next
The only information I found if pressing 3 time fastly the button, removing the batterie can reset it, but IDK what is the defaut mode.
There is no information to switch mode on the documentation ?
I have no tried removing the battery and the result is the same.
The only documentation I have says “3 click” to swap the mode.
Looking around at other projects it seems this kind of behaviour is not unknown.
Eg Strange mode switching on Moes Zigbee Smart Button/Scene Switch - Devices - Hubitat
There they talk about forcing the mode to change.
I looked at the attribute that seems to control this, Cluster 0x0006, id 0x8004, but in deconz it appears to be read only.
Ha ? IDK if this attribute can work on this device, and why it is only read.
On the file general.xml (BTW what is your OS ?) you can set it read/write with
<attribute id="0x8004" name="Switch operation mode" type="enum8" default="0" required="m" access="rw">
<value name="Command Mode (Light OnOff/Dimmer commands)" value="0"></value>
<value name="Event Mode (Tuya Scene commands)" value="1"></value>
</attribute>
Need to restart deconz after, and if you have docker, IDK if this file is persistent or editable.
This is a raspberry pi running raspbian.
I found the file and set the attribute to rw. But writing it didn’t help.
In fact, if I set it to “scene mode” the switch becomes unresponsive until I reset it.
I am still at a loss how I can change the mode of this switch.
This device is a sleeper, so we need to awake them in same time we send the request with deconz (generaly with short press on reset button).
But I don’t see why the triple press don’t work if it’s the official method.
This device is a sleeper, so we need to awake them in same time we send the request with deconz (generaly with short press on reset button
Yes, it’s a sleeper, and I worked out that I needed to press the button to get reads and writes to work. As mentioned once I wrote to that attribute (and deconz reported write successfull) the device became unresponsive. Eg there were no more messages in the debug log when I pressed the button. The only way to fix it was to remove the battery.
But I don’t see why the triple press don’t work if it’s the official method.
Looking at other projects it seems the device needs some kind of initialisation otherwise it stays stuck in this mode, and doesn’t respond to triple clicks.
Some success!
I managed to get one of my two buttons into the right mode. The problem is I have no idea what did the trick. I also haven’t been able to repeat it with my second button.
I was trying to do things like manually read attributes as is done for “tuya magic”, plus setting the operational mode. Then the switch became unresponsive again so I reset/repaired it. And then it worked!
On the subject of tuya magic: is this something that the current code/ddf does? eg I see talk of this at Including standard Tuya "magic spell" sequence during joining - #27 by cornim and indeed there is nothing like this in the DDF for my devices, but maybe the magic is implemented elsewhere?
Looking at other projects eg z2m I see that they have used the magic spell for these devices.
Yep, it’s not on all device, and it’s not present on the DDF for _TZ3000_ja5osu5g , you just need to add
{
"name": "config/tuya_unlock"
},
On the DDF for the first device (if you have more than one)
I am not sure what you mean by only needing to do this on the “first device”, but I assume you are saying that the DDF file is shared between all instances of a particular device?
Anyway: It now working. 
So tuya_unlock seems to be required.
Nope ^^, easier, there is some part in the DDF, this code just need to be included in only 1 part. If you use it 2 time for the same device, there is one too much.
BTW, if all is working you can submit a PR to add it officialy ? I can do it if you want, but need the final and tested DDF.
Ok, I have created pull request 7362.
This is the first time I have done this, but I think I got everything right.
Perfect ^^