If I select the plug and rightclick it does not have manufacturer name _TZ3000_w0qqde0g (= this plug), but the one for BW-SHP15 (_TZ3000_mraovvmm). Does it fallback to ModelId (TS011F) when Manufacturer name can’t be found? Do they share a ddf?
I will try tomorrow to pair in other modes.
I have found the DDF https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5577
You can edit it with a text editor.
Else, select the cluster 0x0000 “basic”, press the “read” button and drang and drop the model id and the manufacture name, from the cluster panel to the DDF editor panel.
Yes, but somehow this plug was already working in 2.13.2, even without this specific Manufacturer name=_TZ3000_w0qqde0g in a separate ddf. So does it try to fallback to ModelId (TS011F)?
Also in this part: which setting should be changed for a polling plug? The “max” value? Because in the current default config in 2.13.2 it was set to 1-300-1, but it updates every 60s and not 300?
"report": [
{
"at": "0x0505",
"dt": "0x21",
"min": 1,
"max": 500,
"change": "0x00000003"
},The DDF is device specific so It reconize the device using the model id AND the manufacture name.
300 is the maximum, so the device use a lower value. If you know working previous value, better to use them.
But as we are searching too why it have stopped working, can you just try to change the DDF mode to see if it change something (before using a real DDF file), can try for exemple to re-inlude the device on the 3 mode, and check if the power consumption sensor is created.
Great, it works in hybrid mode when I add it again!
I still don’t understand how it works though, because when I choose “Edit DDF” on the _TZ3000_w0qqde0g, it shows the DDF edit screen of a _TZ3000_mraovvmm (BW-SHP15):
Good question ^^.
It s like it open another DDF file (I have this issue too), but it mean the DDF is not used for the device.
What do you have on the editor title ? Just 1cm above your capture (it s the file path)
Ok so it don’t use DDF file. IDK why it work better.
But there is some others issue about “sensors disparition” and the last version, I will say them to test the hybrid mode too.
Note also that the Status needs to be other than “Draft” in order for the DDF file to be used in Hybrid mode.
Just got a FW update in the Tuya app to 1.0.10, which seems to fix the On/Off state memory! Now the plug does not always turn off any more if the main power gets cut off.
ApplicationVersion is 74 in deconz:
Is reporting back :D?
The amazing news is that it even seems to report now instead of polling!
Updates only take a few seconds! 
Disclaimer: short test.
[Update] Not sure what is happening. Weird behavior: in Homey, it correctly displays 4W but a few seconds later it will display no value “-”, then toggle back to 4W etc. It does seem to report changes though!
I think it’s related to the DDF exposing “power”: null in the wrong cluster in the api (also noticed this a few weeks ago with other plugs):
{
“config”: {
“on”: true,
“reachable”: true
},
“ep”: 1,
“etag”: “1f7540da02e29c8446aea75776671ec1”,
“lastannounced”: null,
“lastseen”: “2022-01-12T15:31Z”,
“manufacturername”: “_TZ3000_w0qqde0g”,
“modelid”: “TS011F”,
“name”: “Consumption 244”,
“state”: {
“consumption”: null,
“lastupdated”: “2022-01-12T15:34:00.740”,
"power": null
},
“type”: “ZHAConsumption”,
“uniqueid”: “a4:c1:38:e3:5f:5b:08:68-01-0702”
}
Why are you saying that ?
Have you check direclty the attribute in deconz, I know some device realy send good value/0/good value/0 …
I have checked the DDF, I think it’s possible to make better
Can you show how it look in the DDf editor when you are on “state/power” ? It s possible to select attribute (0x050B for power, and add a “expression”, here it s possible to make a check in same time, something like
Attr.val != 0 ? Item.val = Attr.val : Item.val
if Attr.val != 0 then Item.val = Attr.val else Item.val = Item.val
BTW, ATM you need the tuya application to make update, firmware are not public ?
I think this is the problem for my 3rd party app (Homey):
But at least the default DDF now has the right device manufacturer (problem is that Power is also exposed under ZHAConsumption):
Yes, for the FW update the device needs to be connected to the Tuya Hub + App.
the DDF is in DRAFT atm, is that on purpose?
I did not intend to use the opened custom DDF, I was assuming it would use the built-in version (2.13.4)?
To be honest I have no real clue how DDF works right now. But at least when I select the plug and Edit DDF it chooses the right manufacturer (_TZ3000_w0qqde0g). Before I always saw a different manufacturer in the DDF edit view (of the SHP15: _TZ3000_mraovvmm).
It auto creates them 
Edit:
Ha ok so it s not in the DDF but still in the json ? Even on new inclusion ?
OK, this DDF seems to works for me. It took some fiddling before I got the plug with new FW actually reporting though.
{
"schema": "devcap1.schema.json",
"manufacturername": "_TZ3000_w0qqde0g",
"modelid": "TS011F",
"product": "TS011F",
"sleeper": false,
"status": "Silver",
"path": "/devices/ts011f.json",
"subdevices": [
{
"type": "$TYPE_ON_OFF_PLUGIN_UNIT",
"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/alert",
"description": "The currently active alert effect.",
"default": "none"
},
{
"name": "state/on",
"description": "True when device is on; false when off.",
"refresh.interval": 5
},
{
"name": "state/reachable"
}
]
},
{
"type": "$TYPE_POWER_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0b04"
],
"fingerprint": {
"profile": "0x0104",
"device": "0x010A",
"endpoint": "0x01",
"in": [
"0x0000",
"0x0B04"
]
},
"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": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/current",
"description": "The measured current (in mA).",
"refresh.interval": 300
},
{
"name": "state/lastupdated"
},
{
"name": "state/power",
"description": "The measured power (in W).",
"refresh.interval": 300
},
{
"name": "state/voltage",
"description": "The measured voltage (in V).",
"refresh.interval": 300
}
]
},
{
"type": "$TYPE_CONSUMPTION_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0702"
],
"fingerprint": {
"profile": "0x0104",
"device": "0x010A",
"endpoint": "0x01",
"in": [
"0x0000",
"0x0702"
]
},
"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": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/consumption",
"description": "The measured consumption (in Wh).",
"refresh.interval": 300
},
{
"name": "state/lastupdated"
}
]
}
],
"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,
"cl": "0x0B04",
"report": [
{
"at": "0x050B",
"dt": "0x29",
"min": 3,
"max": 30,
"change": "0x00000001"
},
{
"at": "0x0508",
"dt": "0x21",
"min": 3,
"max": 300,
"change": "0x00000001"
},
{
"at": "0x0505",
"dt": "0x21",
"min": 3,
"max": 300,
"change": "0x00000001"
}
]
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0702",
"report": [
{
"at": "0x0000",
"dt": "0x25",
"min": 60,
"max": 300
}
]
}
]
}
Ha nice, this one is not so bad, you have made it from scratch or use an old one ?
We need to put one for plug here DDF-Library - deCONZ Community easier to find for other users …