deconz-rest-plugin
deconz-rest-plugin copied to clipboard
dresden-elektronik
DDF add support for some tuya device
Add DDF for Spruce Soil Sensor,nothing special (apart it use the attribute 0x0000 for battery level) see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6222
- Manufacturer: PLAID SYSTEMS
- Model identifier: PS-SPRZMS-SLP3
Add a new clone for a tuya water sensor https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6266
- Manufacturer: _TZ3000_ww9i3e0y
- Model identifier: TS207
Add a new clone for a tuya door sensor https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6333
- Manufacturer: _TZ3000_rgchmad8
- Model identifier: TS0203
Add a DDF for a wired tuya device 3 gangs, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6267
- Manufacturer: _TZ3000_qewo8dlz
- Model identifier: TS0013
Add a DDF for a tuya plug https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6272
- "manufacturername": "_TZ3000_okaz9tjs",
- "modelid": "TS011F", I m using a special folder, because this device work less easily than other tuya model
Add a DDF for Mercator SSWM-DIMZ wired switch, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6051
- "manufacturername": "_TZE200_9cxuhakf",
- "modelid": "TS0601",
Add a DDF for Immax NEO Smart kontroler, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6325
- Manufacturer: _TZ3000_llfaquvp
- Model identifier: TS0012
@Smanar Hi. Its quite time. I asked to support tuya TRV device _TZE200_hue3yfsn. I discover some json config for that device, but it does not work. Where to store ddf file and how to name it for deconz working. Thanx ! json config: { "schema": "devcap1.schema.json", "manufacturername": "_TZE200_hue3yfsn", "modelid": "TS0601", "vendor": "Tuya", "product": "TRV", "sleeper": false, "status": "Gold", "path": "/devices/_TZE200_hue3yfsn.json", "subdevices": [ { "type": "$TYPE_THERMOSTAT", "restapi": "/sensors", "uuid": [ "$address.ext", "0x01", "0x0201" ], "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/battery" }, { "name": "config/heatsetpoint", "parse": {"fn": "tuya", "dpid": 2, "eval": "Item.val = Attr.val * 10;"}, "write": {"fn": "tuya", "dpid": 2, "dt": "0x2b", "eval": "Item.val / 10;"}, "read": {"fn": "none"} }, { "name": "config/locked", "parse": {"fn": "tuya", "dpid": 7, "eval": "Item.val = Attr.val;"}, "write": {"fn": "tuya", "dpid": 7, "dt": "0x10", "eval": "Item.val;"}, "read": {"fn": "none"} }, { "name": "config/on" }, { "name": "config/reachable" }, { "name": "config/preset", "parse": {"fn": "tuya", "dpid": 4, "script": "tuya_trv_preset.js"}, "write": {"fn": "tuya", "dpid": 4, "dt": "0x30", "eval": "const modes = ["holiday","auto","manual","comfort","eco","boost","complex"]; v = modes.indexOf(Attr.val); if (v >= 0) { Item.val = modes.indexOf(Attr.val); }"}, "read": {"fn": "none"} }, { "name": "state/lastupdated" }, { "name": "state/temperature", "parse": {"fn": "tuya", "dpid": 3, "eval": "Item.val = Attr.val * 10;"}, "read": {"fn": "none"} }, { "name": "state/valve" }, { "name": "state/windowopen" } ] } ] }
Hello, Tuya TRV can't work yet, they need this PR was merged first https://github.com/dresden-elektronik/deconz-rest-plugin/pull/6054
@Smanar Tricky PR ;) to be honest it's better to split such things up into one PR per DDF in future. That makes it easier to review, and has less chances of conflicts with other PRs and also provides a meaningful changelog.
We should aim to get rid of the word "some" in all PR headlines as it tells the reader nothing.
Compare:
"DDF add support for some tuya device" vs. "DDF for Tuya motion sensor (M-3000)"
Anyway since there is already a lot of work done here, I'm fine with merging for v2.20.0-beta if there are no other concerns?
@manup
Tricky PR ;) to be honest it's better to split such things up into one PR per DDF in future. That makes it easier to review, and has less chances of conflicts with other PRs and also provides a meaningful changelog.
I m agree, but it's not 100% my fault. When I have started this PR .... All switches are using the line in button_map.json and same DDF for 1,2,3,4 gangs, so to prevent conflict better to use the same one. Lot of device are just clone, like temperature sensor, so using the same DDF Some update are just a 1 line code, so I m using a generic PR. Lot of new devices are using old files still in waiting PR, so using the same PR for them.
And ect, and ect, I did not think to complete it for 6 months, I m sorry but was not my initial project.
Anyway since there is already a lot of work done here, I'm fine with merging for v2.20.0-beta if there are no other concerns?
No problem, have just checked all manufactures name, no duplicate. It's a 100% DDF so not critic, and solve some boring issues like battery drain.
~~The worst thing that can happen with it is more cosmetic, like missing swbuild in json.~~ (Updated)
@manup
Tricky PR ;) to be honest it's better to split such things up into one PR per DDF in future. That makes it easier to review, and has less chances of conflicts with other PRs and also provides a meaningful changelog.
I m agree, but it's not 100% my fault. When I have started this PR .... All switches are using the line in button_map.json and same DDF for 1,2,3,4 gangs, so to prevent conflict better to use the same one. Lot of device are just clone, like temperature sensor, so using the same DDF Some update are just a 1 line code, so I m using a generic PR. Lot of new devices are using old files still in waiting PR, so using the same PR for them.
And ect, and ect, I did not think to complete it for 6 months, I m sorry but was not my initial project.
Anyway since there is already a lot of work done here, I'm fine with merging for v2.20.0-beta if there are no other concerns?
No problem, have just checked all manufactures name, no duplicate. It's a 100% DDF so not critic, and solve some boring issues like battery drain.
~The worst thing that can happen with it is more cosmetic, like missing swbuild in json.~ (Updated)
All good thanks, PR will be part of v2.20.0-beta :)