Is it doable to automate the execution of standard tuya “magic spell” ( like Z2M ) during join of new device when attribute 0xfffe is present in Basic Cluster ?
I.e. read following attributes from Basic Cluster is this order :
Attribute: Manufacturer Name (0x0004)
Attribute: ZCL Version (0x0000)
Attribute: Application Version (0x0001)
Attribute: Model Identifier (0x0005)
Attribute: Power Source (0x0007)
Attribute: Unknown (0xfffe)
He yep, again ^^, you have a tuya device that need it ?
I don’t think its possible without editing c++ code. It’s something easy to code if you have a device that use it to test, but there is so much PR in waiting list, I don’t think this one will be prioritary.
But if you have time to loose, we can try some things on code ?
Hi,
I was quite sure about the need of modifying some code, that’s why I asked to add this feature that other platform has already added or in phase of adding it (like Z2M) 
I’ve already spend a lot of time trying to get this device to work properly, before I understandd that I won’t be able to have it working before a while, then it will return to sender tomorrow.
Sadly because it seems that all this kind off recent version of powerstrips based on the same Tuya _TZ3000_xxxxxx will encounter the same issue.
Hope to find another one that is fully compliant without this kind of stupid “magic”, or I’ll buy some individual power plug that are small enough to be all plugged on a dumb powerstrip
Last time I spent some time modifying code … I’m still waiting for integration … As you said, too much PR in waiting list to be so patient … Let my place to other player this time 
-)
Are you able to make a PR for this in c++?
I need someone with the device to test, but yes I don’t see problem to code it.
There is already some “magic sequence” for other device, no so hard to add a new one.
But as it’s not possible using DDF It mean need to make a device check in c++ using a whitelist for exemple, realy not “DDF friendly”, so for the PR validation …
Sorry to kidnap this thread, but I just spent over two hours trying to send the magic spell using UI. Unfortunately without success, see my comment on github here.
According to z2m sources, there is now over 80 devices using the tuya magic packet. Those devices are not working properly or not exposing their features in deconz, because deconz does not support this magic spell… So if its possible, I kindly ask to get this prioritized and it gets implemented in deconz source. 
Thanks!
80 devices is nothing, there is a new tuya clone every days.
Making devices that use exotic stuff (and a lot have hardware issue) working with deconz is not a priority for me. There is better devices that have issues too.
Even though I can only agree with the fact that Tuya « compilants » products are flooding the market with devices, most of which are not of good quality and which I try to avoid as much as possible, you have to admit that your answer is contradictory.
If there are so many of them every day, it means that 80 will be overtaken very quickly !
The it will become a pressure and priority in all Zigbee world …
if the Deconz Rest-Api based solutions are not able to support them (despite their flaws) people will go to other solutions and all the people who are doing an admirable job, like you do, will just spend their time answering that Deconz doesn’t support it. Waste of time for everyone.
I would be happy to help but I have no skills in C++
If this kind of whitelist could be an text editor list (sort of json or XML syntax) seems to be a good idea.
That way people could test their device without compiling. And the list could be completed as quickly as Tuya device are flooding the market.
May be that list could be grouped by devices that need a type of sequence because, as I understand, some devices need only some attributes to be read in a specific order, some need one specific attr to by written at the end with a specific value.
That’s just a suggestion.
Just another example that this feature will open new opportunities if could be managed by each people in a editable list #6631
But the problem is I don’t see a “clean” method to do that.
As the priority is clean the code to remove all “hack” there is inside, I can’t add a code that will work only for some device that don’t respect zigbee rules.
If it will be possible using DDF no problem, but here …
I fully agree, I also thought about DDF but useless in that case, and thru GUI it’s to slow.
Is it doable to just send some zigbee reads sequence just after pairing if cluster 0xfffe is present ?
Not without adding hack in c++ code.
Ok, so I was totally wrong, it’s possible using DDF (THX to @nebarh01) for users that have a device that need to be unlocked, pls add this code on the DDF on ednpoint 0x01
{
"name": "config/configured",
"refresh.interval": 86400,
"read": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": [
"0x0004",
"0x0000",
"0x0001",
"0x0005",
"0x0007",
"0xfffe"
]
},
"parse": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": "0xfffe",
"eval": "Item.val = (Attr.val != 0)"
},
"public": false,
"default": false
}
In test ATM, or the working one (but not optimised)
{
"name": "config/interfacemode",
"refresh.interval": 86400,
"read": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": [
"0x0004",
"0x0000",
"0x0001",
"0x0005",
"0x0007",
"0xfffe"
]
},
"parse": {
"fn": "zcl",
"ep": 1,
"cl": "0x0000",
"at": "0xfffe",
"eval": "Item.val = Attr.val"
},
"public": false,
"default": 0
}
Edit: Deleted for the reason
@bibabutzi would have been nice to not hijack this generic topic with a specific device support request. Device that is BTW already covered by it’s own github issue #5493.
Thanks
For the TS0044 4gangs I have separated one with the Tuya cluster and added this, but it makes no difference. Looks like for this type of device we don’t need it.
Played also a little with the _TZE200_htnnfasr Lidl water valve, but it helps also not much more to get more values or set something.
Ha yes this issue _TZE200_htnnfasr
But IDK if this device is working ATM, too much to read about this device.
But from z2m code
{
fingerprint: [{modelID: 'TS0601', manufacturerName: '_TZE200_htnnfasr'}],
model: 'PSBZS A1',
vendor: 'Lidl',
description: 'Parkside smart watering timer',
fromZigbee: [fz.ignore_basic_report],
toZigbee: [tz.on_off, tz.lidl_watering_timer],
onEvent: tuya.onEventSetTime,
configure: async (device, coordinatorEndpoint, logger) => {},
exposes: [e.switch(), exposes.numeric('timer', ea.SET).withValueMin(1).withValueMax(10000)
.withUnit('min').withDescription('Auto off after specific time.')],
},
There is no tuya unlock request, and nothing for return in “fromZigbee”
But this pr may add something more in z2m
Don’t know if this is all really needed, setting the duration time would be enough for me.
It seems there are line 1066 of PR referenced by @sinus61