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 ^^