Fix Zigbee Dual Curtain Switch _TZ3000_j1xl73iw (TS130F)#6016
Fix Zigbee Dual Curtain Switch _TZ3000_j1xl73iw (TS130F)#6016manup merged 2 commits intodresden-elektronik:masterfrom Xyaren:master
Conversation
It's WIP, need someone to test it #5710 (comment) With this PR you can add to the DDF Work only for covering that don't use the tuya cluster (but the covering cluster) |
|
I'm not sure if that is covering (ha!) this device but I'll happily test it once available. |
|
The code is available, you have the procedure to test it on the link. It have worked on my side for a covering module (but in stand alone mode, without real covering) |
|
[REDACTED] |
|
@Smanar {
"schema": "devcap1.schema.json",
"manufacturername": "_TZ3000_j1xl73iw",
"modelid": "TS130F",
"product": "TS130F",
"sleeper": false,
"status": "Gold",
"path": "/devices/ts130f.json",
"subdevices": [
{
"type": "$TYPE_WINDOW_COVERING_DEVICE",
"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/lift",
"refresh.interval": 300,
"parse": {
"at": "0x0008",
"cl": "0x0102",
"ep": 0,
"eval": "Item.val = (100 - Attr.val);",
"fn": "zcl",
"reverse": true
},
"default": 0
},
{
"name": "state/open",
"parse": {
"at": "0x0008",
"cl": "0x0102",
"eval": "Item.val = Attr.val == 100",
"fn": "zcl"
}
},
{
"name": "state/reachable"
}
]
},
{
"type": "$TYPE_WINDOW_COVERING_DEVICE",
"restapi": "/lights",
"uuid": [
"$address.ext",
"0x02"
],
"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/lift",
"refresh.interval": 300,
"parse": {
"at": "0x0008",
"cl": "0x0102",
"ep": 0,
"eval": "Item.val = (100 - Attr.val);",
"fn": "zcl",
"reverse": true
},
"default": 0
},
{
"name": "state/open",
"parse": {
"at": "0x0008",
"cl": "0x0102",
"eval": "Item.val = Attr.val == 100",
"fn": "zcl"
}
},
{
"name": "state/reachable"
}
]
}
],
"bindings": [
{
"bind": "unicast",
"src.ep": 2,
"cl": "0x0102",
"report": [
{
"at": "0x0008",
"dt": "0x20",
"min": 0,
"max": 0
}
]
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0102",
"report": [
{
"at": "0x0008",
"dt": "0x20",
"min": 0,
"max": 0
}
]
}
]
}So the following works:
Percentage and State are show correctly once the shutter comes to a stop at the requested position. What does not work now:
When calling the API I get the following error: So this is no a feasable solution right now. |
No, but I don't have full device to test code, it's for that I need you. Have updated the code, you can update it just with The "stop" request is working now (I think I can listen a "clic" when making the request), but I don't understand why you create 2 light entry on your json ? |
I'll have to remove that. |
|
No I mean "light entries", it s covering, but you have 2 and same in binding part, I don't think your device have 2 cluster ? |
|
Oh, yeah it does have two clusters. https://www.aliexpress.com/item/1005003612165338.html |
|
Ha yeah, so forget that I m saying. All seem fine in your DDF. |
|
Stop command is doing something now yes. Almost feels like something is always fighting my inputs. This did not happen with code change from this PR. |
|
BTW, thx for your test. I will stop to pollute your issue ^^ |
|
Hi, should this PR be included in the next beta or is it work in progress? |
|
Sorry, my fault, have polluted his PR, discution have nothing to see with his PR. |
|
I'm fine with this PR beeing merged. I have been testing it for the last weeks and it performs as expected. |
|
Device additions are only allowed with DDF's as far as i knew. @manup since when are we adding c++ based device additions again? |
|
Only in very rare cases like this one since the PR simple and doesn't hurdle the transition to DDF once possible. |
Thanks ! |
Followup to #3757
I know that PRs regarding devices are not merged if they are not in DDF format, but don't stop reading here.
The logic of reversing the percentage like it is implemented is currently not possible with the DDF specification.
If that changes I am happy to add and test a DDF for the device.