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.
Ha yes right, but so much comment on the code.
// no idea why, but we have to wait, otherwise the next request will fail!
Hu …, the DDF make the request every 24h, can reduce the time for test, if it fail the first time, can work the second one.
// set reporting interval of genOnOff to max to "disable" it
// background: genOnOff reporting does not respect timer or button, that makes the on/off reporting pretty unreliable
// the device is reporting it's state change anyway via tuya DPs, so we just lose the continuous state report
await reporting.onOff(endpoint, {max: 0xFFFF});
Need to do same on the DDF ?
@sinus61 can you share your actual DDF, and the “feature” you are trying to have ? Duration time can be possible with config/duration, but not sure, the legacy code need to never use this field.
I’ve added some changes to the PR from ChrisHae, this is working now for me. Setting the duration time is possible und you get back the time left. I think the PR for z2m added to many stuff I don’t need in the device like weektimers, I can do this better from my home automation.
It don’t have the Tuya magic spell inside, but I have tried with that also. Makes it sense to have it in the DDF?
{
"schema": "devcap1.schema.json",
"manufacturername": "_TZE200_htnnfasr",
"modelid": "TS0601",
"vendor": "LIDL",
"product": "Smart watering timer",
"sleeper": false,
"status": "Gold",
"subdevices": [
{
"type": "$TYPE_ON_OFF_OUTPUT",
"restapi": "/lights",
"uuid": [
"$address.ext",
"0x01"
],
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "state/on",
"refresh.interval": 300,
"read": {
"fn": "tuya"
},
"write": {
"dpid": 1,
"dt": "0x10",
"eval": "Item.val == 1 ? 1 : 0;",
"fn": "tuya"
},
"parse": {
"dpid": 1,
"eval": "Item.val = Attr.val;",
"fn": "tuya"
}
},
{
"name": "state/reachable"
}
]
},
{
"type": "$TYPE_OPEN_CLOSE_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0500"
],
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion",
"refresh.interval": 84000,
"read": {
"at": "0x0001",
"cl": "0x0000",
"ep": 1,
"fn": "zcl"
},
"parse": {
"at": "0x0001",
"cl": "0x0000",
"ep": 1,
"fn": "zcl",
"script": "tuya_swversion.js"
}
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/battery",
"parse": {
"dpid": 11,
"eval": "Item.val = Attr.val * 50;",
"fn": "tuya"
},
"default": 100
},
{
"name": "config/duration",
"write": {
"dpid": 5,
"dt": "0x2b",
"eval": "Attr.val = Item.val;",
"fn": "tuya"
},
"parse": {
"dpid": 5,
"eval": "Item.val = Attr.val;",
"fn": "tuya"
}
},
{
"name": "config/locked",
"write": {
"dpid": 109,
"dt": "0x10",
"eval": "Item.val == 1 ? 1 : 0;",
"fn": "tuya"
},
"parse": {
"dpid": 108,
"eval": "Item.val == 1 ? 0 : 1;",
"fn": "tuya"
},
"default": false
},
{
"name": "config/reachable"
},
{
"name": "state/lastupdated"
},
{
"name": "state/seconds_remaining",
"parse": {
"dpid": 6,
"eval": "Item.val = Attr.val * 60;",
"fn": "tuya"
}
}
]
}
],
"bindings": [
{
"bind": "unicast",
"src.ep": 1,
"dst.ep": 1,
"cl": "0x0006",
"report": [
{
"at": "0x0000",
"dt": "0x10",
"min": 1,
"max": 300
}
]
},
{
"bind": "unicast",
"src.ep": 1,
"dst.ep": 1,
"cl": "0x0006",
"report": [
{
"at": "0x0000",
"dt": "0x10",
"min": 1,
"max": 300
}
]
}
]
}
Good question ^^, you are the better one to answer.
If all is working without, no, can depend of version, some version probably need it (I think it’s for that the code is present on Z2M) but as you can’t test it, better to avoid it, a future user with issues can add itself the code to test.
Quick question, this DDF only specifies read and parse section. How/Why is it sending a magic sequence to the device without a write section? Or am I misunderstanding something completely here?
Hi,
Because there is nothing to « send » to the device. The order in which reading some attributes is done is the « unlock » 