zguy2008
commented
1 year ago Using the Window Covering cluster, I can control motor start and stop as well as direction.
Closed zguy2008 closed 1 year ago
zguy2008
commented
1 year ago Using the Window Covering cluster, I can control motor start and stop as well as direction.
Smanar
commented
1 year ago Hello, as it work with covering cluster, I hope it don't use the lumi cluster ... Can try this DDF
{
"schema":"devcap1.schema.json",
"manufacturername":"LUMI",
"modelid":"lumi.curtain.agl001",
"status":"Gold",
"sleeper":false,
"subdevices":[
{
"type":"$TYPE_WINDOW_COVERING_DEVICE",
"restapi":"/lights",
"uuid":[
"$address.ext",
"0x01"
],
"items":[
{
"name":"attr/manufacturername"
},
{
"name":"attr/modelid"
},
{
"name":"attr/name"
},
{
"name":"attr/swversion"
},
{
"name":"attr/type"
},
{
"name":"attr/uniqueid"
},
{
"name":"attr/lastannounced"
},
{
"name":"attr/lastseen"
},
{
"name":"config/checkin",
"default":480
},
{
"name":"state/lift",
"parse":{
"cl":"0x0102",
"at":"0x0008",
"eval":"Item.val = Attr.val"
},
"read":{
"cl":"0x0102",
"at":"0x0008"
},
"refresh.interval":700
},
{
"name":"state/open",
"parse":{
"cl":"0x0102",
"at":"0x0008",
"eval":"Item.val = Attr.val < 100"
}
},
{
"name":"state/reachable"
}
]
},
{
"type":"$TYPE_BATTERY_SENSOR",
"restapi":"/sensors",
"uuid":[
"$address.ext",
"0x01",
"0x0001"
],
"items":[
{
"name":"attr/manufacturername"
},
{
"name":"attr/modelid"
},
{
"name":"attr/name"
},
{
"name":"attr/swversion"
},
{
"name":"attr/type"
},
{
"name":"attr/uniqueid"
},
{
"name":"attr/lastseen"
},
{
"name":"config/on"
},
{
"name":"config/reachable"
},
{
"name":"state/battery",
"parse":{
"cl":"0x0001",
"at":"0x0021",
"eval":"Item.val = Attr.val"
},
"read":{
"cl":"0x0001",
"at":"0x0021"
},
"refresh.interval":1800
},
{
"name":"state/lastupdated"
}
]
}
],
"bindings":[
{
"bind":"unicast",
"src.ep":1,
"cl":"0x0001",
"report":[
{
"at":"0x0021",
"dt":"0x20",
"min":300,
"max":600,
"change":"0x01"
}
]
},
{
"bind":"unicast",
"src.ep":1,
"cl":"0x0020"
},
{
"bind":"unicast",
"src.ep":1,
"cl":"0x0102",
"report":[
{
"at":"0x0008",
"dt":"0x20",
"min":1,
"max":600,
"change":"0x01"
}
]
}
]
}Very good.
I now see the motor and the battery in the REST-API
The motor also shows in Phoscon in the lights section as expected. However, neither are picked up by the Jowihue plugin I use. I'll see with him if there is something to do on his side.
Question. In the JSON above I see "name":"state/lift" and "name":"state/open". Lift and open are synonymous so shouldn't there be an lower/close pair as well? This device being for curtains/draperies, the expectation would be open/close or left//right horizontal movement.
This window covering device also features a occupation/motion sensor (type: ZHAPresence) and a light level/lux sensor (type: ZHALightLevel) that need to be exposed to the REST-API. I see some motion related attributes in the Lumi specific cluster.
Lastly, the device also has start/end positions settings that defines the travel distance between the open/closed state.
Smanar
commented
1 year ago However, neither are picked up by the Jowihue plugin
It was not working, or it don't appear ? I don't use state/bri and and state/on, as thoses fields are deprecated, so it can explan the covering is not working.
Question. In the JSON above I see "name":"state/lift" and "name":"state/open". Lift and open are synonymous so shouldn't there be an lower/close pair as well? This device being for curtains/draperies, the expectation would be open/close or left//right horizontal movement.
There is too state/tilt if needed. But it's rare device need it, to be sure you can test using the GUI. If you look in the GUI (in the covering cluster) state/open are for the 2 first buttons, lift percentage for the state/lift and the other for tilt. If the tilt command is working I can add it in the DDF.
For the missing sensor, can add to test (I m not sure for the used cluster)
{
"type": "$TYPE_TEMPERATURE_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0402"
],
"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",
"awake": true,
"parse": {
"fn": "xiaomi:special",
"at": "0xff01",
"idx": "0x01",
"script": "xiaomi_battery.js"
}
},
{
"name": "config/offset",
"default": 0
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/temperature",
"parse": {
"at": "0xff07",
"ep": 1,
"eval": "Item.val = Attr.val",
"fn": "xiaomi:special",
"idx": "0x03"
},
"read": {
"fn": "none"
}
},
{
"name": "state/lastupdated"
}
]
}However, neither are picked up by the Jowihue plugin
It was not working, or it don't appear ? I don't use state/bri and and state/on, as thoses fields are deprecated, so it can explan the covering is not working.
They are not seen at all. When doing a device scan in the plugin it doesn't add the curtain driver. I'm a bit surprised as the plugin relies on deCONZ REST-API.
Question. In the JSON above I see "name":"state/lift" and "name":"state/open". Lift and open are synonymous so shouldn't there be an lower/close pair as well? This device being for curtains/draperies, the expectation would be open/close or left//right horizontal movement.
There is too state/tilt if needed. But it's rare device need it, to be sure you can test using the GUI. If you look in the GUI (in the covering cluster) state/open are for the 2 first buttons, lift percentage for the state/lift and the other for tilt. If the tilt command is working I can add it in the DDF.
This being a curtain driver, the tilt is irrelevant. This would work only with vertical or horizontal blinds.
In the window covering cluster, controls that works are:
All others return an error or 'Not supported'.
The open / close determine which direction the motor goes. There is an option to reverse the action of those controls for curtains opening the other way.
I tried to insert your DDF in the previous one.
"at":"0x0008", "dt":"0x20", "min":1, "max":600, "change":"0x01" } ] } ] --- inserted here --- }
That didn't work. I lost the motor in the REST-API. Only the battery would show.
Did I do this right?
zguy2008
commented
1 year ago OOPS! That code block didn't work... here is the insert:
Smanar
commented
1 year ago They are not seen at all. When doing a device scan in the plugin it doesn't add the curtain driver. I'm a bit surprised as the plugin relies on deCONZ REST-API.
Ok so effectively it's strange, the type is good, I don't see why the device is not reconized, but If the plugin dev needed I can re-add state/on and state/bri.
This being a curtain driver, the tilt is irrelevant. This would work only with vertical or horizontal blinds.
Not my choose, but the dev that make the firmware ^^
All others return an error or 'Not supported'.
Even "go to lift percentage" ? it s the request used by the code to set the level position ?
The open / close determine which direction the motor goes. There is an option to reverse the action of those controls for curtains opening the other way.
Yes, with the GUI you can find it in the covering cluster, with the API I think it work only for tuya. some devices have an hardware procedure for that (with local command)
{
"schema": "devcap1.schema.json",
"manufacturername": "LUMI",
"modelid": "lumi.curtain.agl001",
"status": "Gold",
"sleeper": false,
"subdevices": [
{
"type": "$TYPE_WINDOW_COVERING_DEVICE",
"restapi": "/lights",
"uuid": [
"$address.ext",
"0x01"
],
"items": [
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "config/checkin",
"default": 480
},
{
"name": "state/lift",
"parse": {
"cl": "0x0102",
"at": "0x0008",
"eval": "Item.val = Attr.val"
},
"read": {
"cl": "0x0102",
"at": "0x0008"
},
"refresh.interval": 700
},
{
"name": "state/open",
"parse": {
"cl": "0x0102",
"at": "0x0008",
"eval": "Item.val = Attr.val < 100"
}
},
{
"name": "state/reachable"
}
]
},
{
"type": "$TYPE_BATTERY_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0001"
],
"items": [
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "attr/lastseen"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/battery",
"parse": {
"cl": "0x0001",
"at": "0x0021",
"eval": "Item.val = Attr.val"
},
"read": {
"cl": "0x0001",
"at": "0x0021"
},
"refresh.interval": 1800
},
{
"name": "state/lastupdated"
}
]
},
{
"type": "$TYPE_TEMPERATURE_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0402"
],
"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",
"awake": true,
"parse": {
"fn": "xiaomi:special",
"at": "0xff01",
"idx": "0x01",
"script": "xiaomi_battery.js"
}
},
{
"name": "config/offset",
"default": 0
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/temperature",
"parse": {
"at": "0xff07",
"ep": 1,
"eval": "Item.val = Attr.val",
"fn": "xiaomi:special",
"idx": "0x03"
},
"read": {
"fn": "none"
}
},
{
"name": "state/lastupdated"
}
]
}
],
"bindings": [
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0001",
"report": [
{
"at": "0x0021",
"dt": "0x20",
"min": 300,
"max": 600,
"change": "0x01"
}
]
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0020"
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0102",
"report": [
{
"at": "0x0008",
"dt": "0x20",
"min": 1,
"max": 600,
"change": "0x01"
}
]
}
]
}Some progress. But we're not quite there yet.
Before using that last DDF, I updated the JowiHue Homeseer Plugin. It now sees the device.
After updating the DDF with the last you sent I get 2 more sub battery devices:
I'm a bit baffled by those 2. The values are meaningless. Or at least, I can't make sense of them.
Operating the controls above, I can see in the log the requests being sent out. I can not see what is actually sent though. And unfortunately, the device does not respond.
I retested all the Window Covering cluster controls. Here is the detail:
So at this point,
We have to figure out why the commands sent to deCONZ do not activate the device. I'll try and get some debugging log from the plugin to troubleshoot this.
There are a bunch of missing controls:
All of the above controls are available in the proprietary Aqara app. My understanding is this app only works with their proprietary Zigbee bridge. However if these functionalities are available, they must be controllable via the clusters and should be able to be exposed to the REST-API.
Luminance and motion would be nice to have. The other 3 controls though are must have I think.
I'd like to express my thanks to you and your team work to make all these devices working and making people's live easier. I much appreciate.
Smanar
commented
1 year ago 0.29°C would be the battery temperature? Room temp is about 22, so, not sure...
Have checked again, and I m almost sure it's the good id, I need *100, but the value need to be the good one, it's the device temperature perhaps, it can decrease if you don't use it ?
luminance/lux sensor
Its the same thing than for the temperature sensor, but with the ID = 11 It seem the battery value use the ID 101 (need to / 2) I see nothing about presence sensor for this device.
I m not sure for then but it s possible to see Xiaomi manufacture return in log when enabling flag "info"
All of the above controls are available in the proprietary Aqara app. My understanding is this app only works with their proprietary Zigbee bridge. However if these functionalities are available, they must be controllable via the clusters and should be able to be exposed to the REST-API.
Exactly it's that making the temperature sensor in test.
must be stopped with the stop control
You haven't skipped a calibration step ?
0%, battery charge level possibly? Not likely.
Yep the ZHABattery use classic cluster, and this device use Xiaomi cluster, I m using it with the ID 0x01 for other sensor, they have a bad values too ? If yes try with the idx = 101 instead of 0x01
zguy2008
commented
1 year ago Hi Smanar,
Sorry for delay, was away a couple of days.
To be honest, I don't understand all you're telling me.
0.29°C would be the battery temperature? Room temp is about 22, so, not sure...
Have checked again, and I m almost sure it's the good id, I need *100, but the value need to be the good one, it's the device temperature perhaps, it can decrease if you don't use it ?
It still shows 0.29°C . Device is cool to hand touch, room temp 23°C. Multiply by 100 would give 29°C. If this is indeed a temperature, it's not the room temperature. The battery temperature may be? Still, I think the value is high.
luminance/lux sensor
Its the same thing than for the temperature sensor, but with the ID = 11 It seem the battery value use the ID 101 (need to / 2) I see nothing about presence sensor for this device.
I m not sure for then but it s possible to see Xiaomi manufacture return in log when enabling flag "info"
Where do I enable this info flag? In the clusters? Which one?
You're right about presence sensor. They mention it but it actually is another device external to the curtain driver.
0%, battery charge level possibly? Not likely.
Yep the ZHABattery use classic cluster, and this device use Xiaomi cluster, I m using it with the ID 0x01 for other sensor, they have a bad values too ? If yes try with the idx = 101 instead of 0x01
I've checked the JSON but I'm not sure where to do that change. Please tell me which section.
must be stopped with the stop control
You haven't skipped a calibration step ?
Device is not yet attached to curtain. There is a manual way to do it. But I was hoping to have the controls exposed to set them remotely.
I will post the output of the REST-API so you have an updated version.
zguy2008
commented
1 year ago Here is the REST-API output
In lights:
"12": {
"etag": "090759055009cb23cb8bd0907089e717",
"hascolor": false,
"lastannounced": "2022-11-02T20:43:21Z",
"lastseen": "2022-11-02T22:39Z",
"manufacturername": "LUMI",
"modelid": "lumi.curtain.agl001",
"name": "Rideau chambre sud",
"state": {
"lift": 0,
"open": true,
"reachable": true
},
"swversion": "0.0.0_0024",
"type": "Window covering device",
"uniqueid": "54:ef:44:10:00:51:0d:79-01"
}In sensors:
"65": {
"config": {
"on": true,
"reachable": true
},
"etag": "b635a1e8b1aa59e1c091733198fb1ad3",
"lastannounced": "2022-11-02T20:43:21Z",
"lastseen": "2022-11-02T22:39Z",
"manufacturername": "LUMI",
"modelid": "lumi.curtain.agl001",
"name": "Rideau chambre sud Batterie",
**_"state": {
"battery": null, Probably why it shows as 0
"lastupdated": "none"_**
},
"swversion": "0.0.0_0024",
"type": "ZHABattery",
"uniqueid": "54:ef:44:10:00:51:0d:79-01-0001"
},
"66": {
"config": {
"battery": 0,
"offset": 0,
"on": true,
"reachable": true
},
"etag": "f61f6ca1aaf4dca1e35fb9ec1ea227a4",
"lastannounced": "2022-11-02T20:43:21Z",
"lastseen": "2022-11-02T22:39Z",
"manufacturername": "LUMI",
"modelid": "lumi.curtain.agl001",
"name": "Temperature 66 Temperature",
"state": {
"lastupdated": "2022-11-02T22:37:05.377",
"temperature": 29
},
"swversion": "0.0.0_0024",
"type": "ZHATemperature",
"uniqueid": "54:ef:44:10:00:51:0d:79-01-0402"
}
}New DDF to test :
{
"schema": "devcap1.schema.json",
"manufacturername": "LUMI",
"modelid": "lumi.curtain.agl001",
"status": "Gold",
"sleeper": false,
"subdevices": [{
"type": "$TYPE_WINDOW_COVERING_DEVICE",
"restapi": "/lights",
"uuid": [
"$address.ext",
"0x01"
],
"items": [{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "config/checkin",
"default": 480
},
{
"name": "state/lift",
"parse": {
"cl": "0x0102",
"at": "0x0008",
"eval": "Item.val = Attr.val"
},
"read": {
"cl": "0x0102",
"at": "0x0008"
},
"refresh.interval": 700
},
{
"name": "state/open",
"parse": {
"cl": "0x0102",
"at": "0x0008",
"eval": "Item.val = Attr.val < 100"
}
},
{
"name": "state/reachable"
}
]
},
{
"type": "$TYPE_BATTERY_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0001"
],
"items": [{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "attr/lastseen"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/battery",
"parse": {
"cl": "0x0001",
"at": "0x0021",
"ep": 1,
"fn": "zcl",
"eval": "Item.val = Attr.val"
},
"read": {
"cl": "0x0001",
"at": "0x0021",
"ep": 1,
"fn": "zcl"
},
"refresh.interval": 1800
},
{
"name": "state/lastupdated"
}
]
},
{
"type": "$TYPE_LIGHT_LEVEL_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x1",
"0x0400"
],
"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",
"awake": true,
"parse": {
"at": "0x040B",
"cl": "0xFCC0",
"ep": 1,
"eval": "Item.val = Attr.val"
}
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/lastupdated"
},
{
"name": "state/lightlevel",
"parse": {
"at": "0xff07",
"ep": 1,
"eval": "Item.val = Attr.val",
"fn": "xiaomi:special",
"idx": "0x0B"
},
"read": {
"fn": "none"
}
}
]
},
{
"type": "$TYPE_TEMPERATURE_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0402"
],
"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",
"awake": true,
"parse": {
"fn": "xiaomi:special",
"at": "0xff01",
"idx": "0x65",
"eval": "Item.val = Attr.val"
}
},
{
"name": "config/offset",
"default": 0
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/temperature",
"parse": {
"at": "0xff07",
"ep": 1,
"eval": "Item.val = Attr.val",
"fn": "xiaomi:special",
"idx": "0x64"
},
"read": {
"fn": "none"
}
},
{
"name": "state/lastupdated"
}
]
}
],
"bindings": [{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0001",
"report": [{
"at": "0x0021",
"dt": "0x20",
"min": 300,
"max": 600,
"change": "0x01"
}]
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0020"
},
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0102",
"report": [{
"at": "0x0008",
"dt": "0x20",
"min": 1,
"max": 600,
"change": "0x01"
}]
}
]
}
have added a TYPE_LIGHT_LEVEL_SENSOR
Light sensor now visible. Value doesn't seem to react to light changes.
Trying a new ID for the ZHATemperature
Value now at 0.02°C instead of 0.29°C.
Using a new method to try having the battery, visible on the TYPE_LIGHT_LEVEL_SENSOR, trying to read the attribute 0x040B
Battery status still at 0%.
REST-API output
for lights:
"12": {
"etag": "e61973af1403eeb3279b944ee6355c14",
"hascolor": false,
"lastannounced": null,
"lastseen": "2022-11-04T00:15Z",
"manufacturername": "LUMI",
"modelid": "lumi.curtain.agl001",
"name": "Rideau chambre sud",
"state": {
"lift": 0,
"open": true,
"reachable": true
},
"swversion": "0.0.0_0024",
"type": "Window covering device",
"uniqueid": "54:ef:44:10:00:51:0d:79-01"
}for sensors:
"65": {
"config": {
"on": true,
"reachable": true
},
"etag": "16facb6eb6aae1c908ce20cb6957b5da",
"lastannounced": null,
"lastseen": "2022-11-04T00:15Z",
"manufacturername": "LUMI",
"modelid": "lumi.curtain.agl001",
"name": "Rideau chambre sud Batterie",
"state": {
"battery": null,
"lastupdated": "none"
},
"swversion": "0.0.0_0024",
"type": "ZHABattery",
"uniqueid": "54:ef:44:10:00:51:0d:79-01-0001"
},
"66": {
"config": {
"battery": 0,
"offset": 0,
"on": true,
"reachable": true
},
"etag": "974486d6fdb3d7b28d2363e3384c68e2",
"lastannounced": null,
"lastseen": "2022-11-04T00:15Z",
"manufacturername": "LUMI",
"modelid": "lumi.curtain.agl001",
"name": "Battery Temperature 65",
"state": {
"lastupdated": "2022-11-04T00:12:48.705",
"temperature": 2
},
"swversion": "0.0.0_0024",
"type": "ZHATemperature",
"uniqueid": "54:ef:44:10:00:51:0d:79-01-0402"
},
"67": {
"config": {
"battery": 0,
"on": true,
"reachable": true
},
"etag": "974486d6fdb3d7b28d2363e3384c68e2",
"lastannounced": null,
"lastseen": "2022-11-04T00:15Z",
"manufacturername": "LUMI",
"modelid": "lumi.curtain.agl001",
"name": "LightLevel 67",
"state": {
"lastupdated": "none",
"lightlevel": 0
},
"swversion": "0.0.0_0024",
"type": "ZHALightLevel",
"uniqueid": "54:ef:44:10:00:51:0d:79-01-0400"
}
}Ok So I give up, not possible to guest manufacture id used.
Use this DDF, all sensor are removed
{
"schema":"devcap1.schema.json",
"manufacturername":"LUMI",
"modelid":"lumi.curtain.agl001",
"status":"Gold",
"sleeper":false,
"subdevices":[
{
"type":"$TYPE_WINDOW_COVERING_DEVICE",
"restapi":"/lights",
"uuid":[
"$address.ext",
"0x01"
],
"items":[
{
"name":"attr/manufacturername"
},
{
"name":"attr/modelid"
},
{
"name":"attr/name"
},
{
"name":"attr/swversion"
},
{
"name":"attr/type"
},
{
"name":"attr/uniqueid"
},
{
"name":"attr/lastannounced"
},
{
"name":"attr/lastseen"
},
{
"name":"config/checkin",
"default":480
},
{
"name":"state/lift",
"parse":{
"cl":"0x0102",
"at":"0x0008",
"eval":"Item.val = Attr.val"
},
"read":{
"cl":"0x0102",
"at":"0x0008"
},
"refresh.interval":700
},
{
"name":"state/open",
"parse":{
"cl":"0x0102",
"at":"0x0008",
"eval":"Item.val = Attr.val < 100"
}
},
{
"name":"state/reachable"
}
]
},
{
"type":"$TYPE_BATTERY_SENSOR",
"restapi":"/sensors",
"uuid":[
"$address.ext",
"0x01",
"0x0001"
],
"items":[
{
"name":"attr/manufacturername"
},
{
"name":"attr/modelid"
},
{
"name":"attr/name"
},
{
"name":"attr/swversion"
},
{
"name":"attr/type"
},
{
"name":"attr/uniqueid"
},
{
"name":"attr/lastseen"
},
{
"name":"config/on"
},
{
"name":"config/reachable"
},
{
"name":"state/battery",
"parse":{
"cl":"0x0001",
"at":"0x0021",
"ep":1,
"fn":"zcl",
"eval":"Item.val = Attr.val"
},
"read":{
"cl":"0x0001",
"at":"0x0021",
"ep":1,
"fn":"zcl"
},
"refresh.interval":1800
},
{
"name":"state/lastupdated"
}
]
}
],
"bindings":[
{
"bind":"unicast",
"src.ep":1,
"cl":"0x0001",
"report":[
{
"at":"0x0021",
"dt":"0x20",
"min":300,
"max":600,
"change":"0x01"
}
]
},
{
"bind":"unicast",
"src.ep":1,
"cl":"0x0102",
"report":[
{
"at":"0x0008",
"dt":"0x20",
"min":1,
"max":600,
"change":"0x01"
}
]
}
]
}Enable logs in deconz/help/debug view with flag "info", you will see all Xiaomi report from the device.
Will be easier to reconize the usefull one.
zguy2008
commented
1 year ago OK.
There does not seem to be a way to save that debug info to a file from deCONz.
I saw I could use command line parameter --dbg-info=1 or 2 > debug.txt to get a log file.
Is that the only way or saving to file can be done from the GUI?
And how long should I run this so you get what you need? or do I need to do something with the device to have its output?
Smanar
commented
1 year ago There does not seem to be a way to save that debug info to a file from deCONz. I saw I could use command line parameter --dbg-info=1 or 2 > debug.txt to get a log file. Is that the only way or saving to file can be done from the GUI?
You are not using an SD card ? Storing log in a file can be destructive.
IDK how fast Xiaomi make is notification, but how many devices have you ? the log make a kind of table easy to reconize in the flow, it s somethink like
:11:35:216 01 battery 3035 (0x0BDB)
23:11:35:216 03 temperature 26 °C
23:11:35:216 04 unknown 5032 (0x13A8)
23:11:35:216 05 RSSI dB (?) 17 (0x0011)
23:11:35:216 06 LQI (?) 4294967296 (0x0100000000)
23:11:35:216 0a unknown 0 (0x0000)
23:11:35:216 64 on/off 0In my mind was possible just with looking in the output debug windows, but I can be wrong.
You can trigger notification using the device, but not sure It will send the usefull one ...
zguy2008
commented
1 year ago The debug window scrolls at a pace fast enough to make it difficult to take screen shots.
I tried starting deCONZ from a command line with /usr/bin/deCONZ --dbg-info=1 > /tmp/deconzdebug1.txt
That generated the following log:
Hope you find what you need in it.
I'm using a RaspBee II hat on a Pi 4 with a 32g SD card. The network has 28 nodes, including one of the Aqara.
Smanar
commented
1 year ago We can see the report, but not values
13:10:37:041 ZCL attribute report 0x54EF441000510D79 for cluster: 0xFCC0, ep: 0x01, frame control: 0x1C, mfcode: 0x115F
I have take a look again on z2m code
Battery is 0x65, but not working for us Voltage is 0x040B ??? another battery ?
Can try to re-add the luminosity
{
"type":"$TYPE_LIGHT_LEVEL_SENSOR",
"restapi":"/sensors",
"uuid":[
"$address.ext",
"0x1",
"0x0400"
],
"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",
"awake":true,
"parse":{
"at": "0x00f7",
"ep": 1,
"eval": "Item.val = Attr.val",
"fn": "xiaomi:special",
"idx": "0x040b"
}
},
{
"name":"config/on"
},
{
"name":"config/reachable"
},
{
"name":"state/lastupdated"
},
{
"name":"state/lightlevel",
"parse":{
"at":"0x00f7",
"ep":1,
"eval":"Item.val = 100* Attr.val",
"fn":"xiaomi:special",
"idx":"0x0B"
},
"read":{
"fn":"none"
}
}
]
},With luck it will expose the good battery level. But BTW I don't see anything about temperature or light level https://www.zigbee2mqtt.io/devices/ZNCLBL01LM.html#xiaomi-znclbl01lm
I can be wrong for the attribute too, I m using 0xff07 but not sure it's the good one. (edit It seem it 's 00F7, so was using a bad one)
zguy2008
commented
1 year ago Hi Smanar,
I edited the 3rd DDF you sent (still using this one) to reflect the above changes to TYPE_LIGHT_LEVEL_SENSOR. I'm not seeing any changes. Values reported are still the same.
WOW! The information in this link https://www.zigbee2mqtt.io/devices/ZNCLBL01LM.html#xiaomi-znclbl01lm Is exactly what we need. If there is a way to leverage this, we should. Is this possible?
You're right it doesn't mention light level. Yet that is documented on the manufacturer page: https://www.aqara.com/en/product/curtain-driver-e1-rod-version.
But many of the needed attributes / functionalities are there: cover (state, position), battery, voltage, device_temperature, action, motor_state, running, hooks_state, target_position, power_source, charging, linkquality
Smanar
commented
1 year ago But you are sure your device have it ? Strange the z2m team haven't added them, you can see the sensor somewhere (a hole for exemple)
If there is a way to leverage this, we should. Is this possible?
Sure, but I don't understand what I m doing wrong.
Will make a new try for the "voltage", from that I m understand it's the battery level. And give up light and temperature sensor.
{
"schema":"devcap1.schema.json",
"manufacturername":"LUMI",
"modelid":"lumi.curtain.agl001",
"status":"Gold",
"sleeper":false,
"subdevices":[
{
"type":"$TYPE_WINDOW_COVERING_DEVICE",
"restapi":"/lights",
"uuid":[
"$address.ext",
"0x01"
],
"items":[
{
"name":"attr/manufacturername"
},
{
"name":"attr/modelid"
},
{
"name":"attr/name"
},
{
"name":"attr/swversion"
},
{
"name":"attr/type"
},
{
"name":"attr/uniqueid"
},
{
"name":"attr/lastannounced"
},
{
"name":"attr/lastseen"
},
{
"name":"config/checkin",
"default":480
},
{
"name":"state/lift",
"parse":{
"cl":"0x0102",
"at":"0x0008",
"eval":"Item.val = Attr.val"
},
"read":{
"cl":"0x0102",
"at":"0x0008"
},
"refresh.interval":700
},
{
"name":"state/open",
"parse":{
"cl":"0x0102",
"at":"0x0008",
"eval":"Item.val = Attr.val < 100"
}
},
{
"name":"state/reachable"
}
]
},
{
"type": "$TYPE_BATTERY_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0001"
],
"items": [{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion"
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "attr/lastseen"
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/battery",
"parse": {
"cl": "0xfcc0",
"at": "0x040b",
"ep": 1,
"fn": "zcl",
"mf": "0x115f",
"eval": "Item.val = Attr.val"
},
"read": {
"cl": "0xfcc0",
"at": "0x040b",
"ep": 1,
"mf": "0x115f",
"fn": "zcl"
},
"refresh.interval": 1800
},
{
"name": "state/lastupdated"
}
]
}
],
"bindings":[
{
"bind":"unicast",
"src.ep":1,
"cl":"0x0102",
"report":[
{
"at":"0x0008",
"dt":"0x20",
"min":1,
"max":600,
"change":"0x01"
}
]
}
]
}I have used all information I can read, the cluster, the attribute, the manufacture number, they are not making bind/report.
If i don't work you can try to add the attribute 0x040b in the general.xml file to be able to see/read it in the GUI
<attribute id="0x0409" name="Charging" type="u8" mfcode="0x115f" access="r" required="o">
<description>Battery charging state: 1: charging, 2: not charging.</description>
</attribute>
<attribute id="0x040b" name="voltage" type="u8" mfcode="0x115f" access="r" required="o">
<description>Battery voltage.</description>
</attribute>
</attribute-set>If you read it in the GUI, it need to force it in the API (if the DDF not working)
zguy2008
commented
1 year ago I'm not seeing any improvement with that last DDF.
I have received information from the plugin developer.
Below is a debug log from plugin. It clearly shows commands being sent and success results received from the REST-API. Yet, the device does not react when these are sent.
So I'm pretty sure the problem is in the DDF (even for those controls, on top of the others not working) because I can control the device with the cluster controls.
I wish I knew more about this.
` Close:
20:38:09.4311114 -- (JowiHueUtils.SetDeviceByUserRequest) Debug: SetDeviceByUserRequest:Start ref=2033 Action:0 controltype:5 Controlstring:
20:38:09.4331478 -- (JowiHueUtils.SetDeviceByUserRequest) Debug: Handling blinds actions for Rideau chambre sud Open/Close
20:38:09.4331478 -- (BridgeApi.SetLights) Set lights starting
20:38:09.4331478 -- (BridgeApi.SetState) SetState called by BridgeApi.SetLights for id=12
20:38:09.4331478 -- (BridgeApi.SetState) setstate Blind stateset {"lift":0} splitbri:False
20:38:09.4331478 -- (BridgeCommander.EnQueue) Queuing new command: type Light current queue size is 1 on ZguyPhoscon
20:38:09.4412277 -- (BridgeApi.SetState) Blind command: url:http://192.168.1.71:80/api/1AEBD4A074/lights/12/state stateset lift:0 stop:
20:38:09.4412277 -- (JowiHueUtils.SetDeviceByUserRequest) Debug: :End
20:38:09.4412277 -- (BridgeCommander.RunCommand) BridgeCommandTick: HandleCommandQueue took 0. Next wait: 100
20:38:09.4432451 -- (BridgeApi.SendJsonCommand) SendJsonCommand: Sending command PUT 8:38:09 PM
20:38:09.4432451 -- (BridgeApi.SendJsonCommand) SendJsonCommand: http://192.168.1.71:80/api/1AEBD4A074/lights/12/state: {"lift":0}
20:38:09.7944771 -- (BridgeApi.SendRequest) sendrequest total took 350
20:38:09.7965304 -- (BridgeApi.CheckJsonResult) [{"success":{"/lights/12/state/lift":0}}]
20:38:09.7965304 -- (BridgeApi.SendJsonCommand) 0
Open:
20:38:16.3785250 -- (JowiHueUtils.SetDeviceByUserRequest) Debug: SetDeviceByUserRequest:Start ref=2033 Action:255 controltype:5 Controlstring:
20:38:16.3785250 -- (JowiHueUtils.SetDeviceByUserRequest) Debug: Handling blinds actions for Rideau chambre sud Open/Close
20:38:16.3785250 -- (BridgeApi.SetLights) Set lights starting
20:38:16.3785250 -- (BridgeApi.SetState) SetState called by BridgeApi.SetLights for id=12
20:38:16.3785250 -- (BridgeApi.SetState) setstate Blind stateset {"lift":100} splitbri:False
20:38:16.3785250 -- (BridgeCommander.EnQueue) Queuing new command: type Light current queue size is 1 on ZguyPhoscon
20:38:16.3785250 -- (BridgeApi.SetState) Blind command: url:http://192.168.1.71:80/api/1AEBD4A074/lights/12/state stateset lift:100 stop:
20:38:16.3785250 -- (BridgeApi.SendJsonCommand) SendJsonCommand: Sending command PUT 8:38:16 PM
20:38:16.3785250 -- (BridgeCommander.RunCommand) BridgeCommandTick: HandleCommandQueue took 0. Next wait: 100
20:38:16.3785250 -- (BridgeApi.SendJsonCommand) SendJsonCommand: http://192.168.1.71:80/api/1AEBD4A074/lights/12/state: {"lift":100}
20:38:16.3785250 -- (JowiHueUtils.SetDeviceByUserRequest) Debug: :End
20:38:17.3020404 -- (BridgeApi.SendRequest) sendrequest total took 924
20:38:17.3020404 -- (BridgeApi.CheckJsonResult) [{"success":{"/lights/12/state/lift":100}}]
Stop:
20:38:23.4848766 -- (JowiHueUtils.SetDeviceByUserRequest) Debug: SetDeviceByUserRequest:Start ref=2033 Action:261 controltype:5 Controlstring:
20:38:23.4848766 -- (JowiHueUtils.SetDeviceByUserRequest) Debug: Handling blinds actions for Rideau chambre sud Open/Close
20:38:23.4848766 -- (BridgeApi.SetLights) Set lights starting
20:38:23.4848766 -- (BridgeApi.SetState) SetState called by BridgeApi.SetLights for id=12
20:38:23.4848766 -- (BridgeApi.SetState) setstate Blind stateset {"stop":true} splitbri:False
20:38:23.4848766 -- (BridgeCommander.EnQueue) Queuing new command: type Light current queue size is 1 on ZguyPhoscon
20:38:23.4848766 -- (BridgeApi.SetState) Blind command: url:http://192.168.1.71:80/api/1AEBD4A074/lights/12/state stateset lift: stop: True
20:38:23.4848766 -- (BridgeApi.SendJsonCommand) SendJsonCommand: Sending command PUT 8:38:23 PM
20:38:23.4848766 -- (BridgeCommander.RunCommand) BridgeCommandTick: HandleCommandQueue took 0. Next wait: 50
20:38:23.4848766 -- (BridgeApi.SendJsonCommand) SendJsonCommand: http://192.168.1.71:80/api/1AEBD4A074/lights/12/state: {"stop":true}
20:38:23.4848766 -- (JowiHueUtils.SetDeviceByUserRequest) Debug: :End
20:38:23.4929502 -- (BridgeApi.SendRequest) sendrequest total took 1
20:38:23.4929502 -- (BridgeApi.CheckJsonResult) [{"success":{"/lights/12/state/stop":true}}]
Limited open/close 37%:
20:38:26.8254602 -- (JowiHueUtils.SetDeviceByUserRequest) Debug: SetDeviceByUserRequest:Start ref=2033 Action:37 controltype:7 Controlstring:
20:38:26.8254602 -- (JowiHueUtils.SetDeviceByUserRequest) Debug: Handling blinds actions for Rideau chambre sud Open/Close
20:38:26.8254602 -- (BridgeApi.SetLights) Set lights starting
20:38:26.8300035 -- (BridgeApi.SetState) SetState called by BridgeApi.SetLights for id=12
20:38:26.8300035 -- (BridgeApi.SetState) setstate Blind stateset {"lift":37} splitbri:False
20:38:26.8300035 -- (BridgeCommander.EnQueue) Queuing new command: type Light current queue size is 1 on ZguyPhoscon
20:38:26.8300035 -- (BridgeApi.SetState) Blind command: url:http://192.168.1.71:80/api/1AEBD4A074/lights/12/state stateset lift:37 stop:
20:38:26.8300035 -- (BridgeApi.SendJsonCommand) SendJsonCommand: Sending command PUT 8:38:26 PM
20:38:26.8300035 -- (JowiHueUtils.SetDeviceByUserRequest) Debug: :End
20:38:26.8300035 -- (BridgeApi.SendJsonCommand) SendJsonCommand: http://192.168.1.71:80/api/1AEBD4A074/lights/12/state: {"lift":37}
20:38:26.8300035 -- (BridgeCommander.RunCommand) BridgeCommandTick: HandleCommandQueue took 0. Next wait: 100
20:38:26.8725045 -- (BridgeApi.SendRequest) sendrequest total took 45
20:38:26.8725045 -- (BridgeApi.CheckJsonResult) [{"success":{"/lights/12/state/lift":37}}]`
Smanar
commented
1 year ago So I'm pretty sure the problem is in the DDF
But the DDF have an impact on return, not on action.
because I can control the device with the cluster controls.
Right, and the "lift" request use the "go to lift percentage" command, that is working with the GUI.
All seem fine for me in his log. On log with the flag "ZCL" you will be able to see the request
18:40:52:438 ZCL cmd-req nwk: 0x40FF, profile: 0x0104, cluster: 0x0006 cmd: 0x00
You need to see cluster 0x0102 cmd 0x05, you can compare them with the GUI and with the plugin.
zguy2008
commented
1 year ago So I'm pretty sure the problem is in the DDF
But the DDF have an impact on return, not on action.
OK, if you say so. I'm pretty good with technology and computers in general. But I'm no expert with JSON and have no knowledge on how deCONZ works internally.
But so far, what I'm seeing is that everything deCONZ expose to the external world does not function.
because I can control the device with the cluster controls.
Right, and the "lift" request use the "go to lift percentage" command, that is working with the GUI.
Indeed. But what works in deCONZ GUI does not work when commands are sent to deCONZ.
All seem fine for me in his log.
Right. Command is sent to deCONZ, deCONZ returns success. Seems all good. But the command is not executed by the device. So something, somewhere within the RaspBee is not working. Is it the DDF? deCONZ? The REST-API? Something else? I don't know. This is where you come in, you're the RaspBee expert.
On log with the flag "ZCL" you will be able to see the request
18:40:52:438 ZCL cmd-req nwk: 0x40FF, profile: 0x0104, cluster: 0x0006 cmd: 0x00You need to see cluster 0x0102 cmd 0x05, you can compare them with the GUI and with the plugin.
I'm not sure what you mean with the ZCL flag or the rest of this.
Smanar
commented
1 year ago When you make a API request, deconz make a zige request, make a response with "success", even if the zigbee request fail. Deconz update the API with device return. It mean even if the zigbee request fail, you will have a success return.
{
"name":"state/lift",
"parse":{
"cl":"0x0102",
"at":"0x0008",
"eval":"Item.val = Attr.val"
},
"read":{
"cl":"0x0102",
"at":"0x0008"
},
"refresh.interval":700
},So when using the DDF, deconz by-pass the legacy code, only when you "read" or "parse" the value, not when you "write" it.
You can remove all this part and use just
{
"name":"state/lift"
},It will by-pass all the DDF core.
Using the API, you are using the request "lift" = X, are you able to test with the "open" ? It's possible just with curl, using
curl -H 'Content-Type: application/json' -X PUT -d '{"open": true}' http://192.168.1.71:80/api/1AEBD4A074/lights/12/state
To see logs, in the GUI, go to help / debug view, and check "ZCL" (you can perhaps see usefull information with "info" and "info_l2")
zguy2008
commented
1 year ago When you make a API request, deconz make a zige request, make a response with "success", even if the zigbee request fail. Deconz update the API with device return. It mean even if the zigbee request fail, you will have a success return. So when using the DDF, deconz by-pass the legacy code, only when you "read" or "parse" the value, not when you "write" it.
Not exactly good. I did not know that.
You can remove all this part and use just
{ "name":"state/lift" },It will by-pass all the DDF core.
And then we would get the proper status, success or failure?
Using the API, you are using the request "lift" = X, are you able to test with the "open" ? It's possible just with curl, using
curl -H 'Content-Type: application/json' -X PUT -d '{"open": true}' http://192.168.1.71:80/api/1AEBD4A074/lights/12/state
I tried that. It did not give any feedback. No errors or success. The device was not activated either.
To see logs, in the GUI, go to help / debug view, and check "ZCL" (you can perhaps see usefull information with "info" and "info_l2")
I started deCONZ with this command line:
/usr/bin/deCONZ --dbg-info=2 --dbg-zcl=1 > /tmp/debug.txt
Here is the result: debug2022-11-14.txt
I hope you can make sense of what is in that log. Filtering and understanding what is going in there is beyond what I can do right now.
You know we've been at this for 3 weeks now with no results. Basic functions like open/close/stop don't work. I try to give you as much info you request as I can but I have limits with these technologies, I'm not familiar with them. How about having someone else help and take a look at it to get a new insight, another point of view, to help us get this device working? May be he would find something new.
Smanar
commented
1 year ago And then we would get the proper status, success or failure?
Sucess mean the API request is fine, the zigbee state is updated with device zigbee return.
I tried that. It did not give any feedback. No errors or success. The device was not activated either.
No return message ?
I have check your log, and there is absolutely nothing about your device and the cluster 0x0102
Edit: Ok I have found the problem I think, there is a hack in the code used for old device, and not possible to by pass it for new model ...
quint16 cluster = WINDOW_COVERING_CLUSTER_ID;
// if (taskRef.lightNode->modelId().startsWith(QLatin1String("lumi.curtain"))) // FIXME - for testing only.
if (taskRef.lightNode->modelId().startsWith(QLatin1String("lumi.curtain.")))
{
cluster = ANALOG_OUTPUT_CLUSTER_ID;
supportsLiftInc = taskRef.lightNode->modelId().startsWith(QLatin1String("lumi.curtain.acn002"));
}I m asking if there is an easy way to by-pass it without editing the c++ code. BTW what is your OS ? (to know if you can compile the code, if we need to edit the c++ code)
zguy2008
commented
1 year ago And then we would get the proper status, success or failure?
Sucess mean the API request is fine, the zigbee state is updated with device zigbee return.
Does the REST-API end up getting the Zigbee status?
I tried that. It did not give any feedback. No errors or success. The device was not activated either.
No return message ?
Nothing. Pasted the command, hit enter and got back the command line prompt.
I have check your log, and there is absolutely nothing about your device and the cluster 0x0102
Edit: Ok I have found the problem I think, there is a hack in the code used for old device, and not possible to by pass it for new model ...
quint16 cluster = WINDOW_COVERING_CLUSTER_ID; // if (taskRef.lightNode->modelId().startsWith(QLatin1String("lumi.curtain"))) // FIXME - for testing only. if (taskRef.lightNode->modelId().startsWith(QLatin1String("lumi.curtain."))) { cluster = ANALOG_OUTPUT_CLUSTER_ID; supportsLiftInc = taskRef.lightNode->modelId().startsWith(QLatin1String("lumi.curtain.acn002")); }I m asking if there is an easy way to by-pass it without editing the c++ code. BTW what is your OS ? (to know if you can compile the code, if we need to edit the c++ code)
Ouf!
uname -a returns Linux phoscon 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021 armv7l GNU/Linux
But that is the production system. I wouldn't recompile anything on it and risk breaking something.
I have a spare PI and RaspBee I could use to test. But I'm going to need some time to setup that and connect it to my test system.
Let me know if this will be needed.
Smanar
commented
1 year ago Does the REST-API end up getting the Zigbee status?
Ofc, it s the normal working mode, device always send return when the action is done, else you will stay at previous state (like you ATM)
But that is the production system. I wouldn't recompile anything on it and risk breaking something.
I have a spare PI and RaspBee I could use to test. But I'm going to need some time to setup that and connect it to my test system.
Let me know if this will be needed.It's perfect, I m asking the direction to take, to be sure the PR will be merged. We have 2 solutions :
The problem is some PR are in waiting list since so long time, so I think the fast patch is the more unwanted PR, but the less dangerous for actual code, so probably fastly valided.
Smanar
commented
1 year ago Ok so good news from manup, he is away for some days but we will have for the next beta more option in the DDF stuff, so we probably can use the DDF for send request and bypass this hack.
zguy2008
commented
1 year ago Good. Keep me informed.
zguy2008
commented
1 year ago Ok so good news from manup, he is away for some days but we will have for the next beta more option in the DDF stuff, so we probably can use the DDF for send request and bypass this hack.
Hi Smanar,
Any good news?
Smanar
commented
1 year ago Lol, not yet, no return, perhaps a hostage taking ^^
zguy2008
commented
1 year ago Lol, not yet, no return, perhaps a hostage taking ^^
Do you want me to send a commando?
zguy2008
commented
1 year ago Any update @Smanar ?
Smanar
commented
1 year ago No more information :(
I m asking a roadmap, the next step need to be PR merge, but there is some critic issues on last deconz version that are prioritary.
2 days ago we have https://github.com/dresden-elektronik/deconz-rest-plugin/releases/tag/v2.19.3 The return are not so bad, but there is still an unknow latency issue, so idk what will be the decision, another stable (so no PR merge), or a new beta.
zguy2008
commented
1 year ago So Smanar, over a month now. What is happening?
Smanar
commented
1 year ago No official roadmap, sorry. But unofficially, I can say you manup and some devs are on the critics issues with version 2.19.X, it's the priority. Will be realy soon if recent tests are good. After that I think it will be a PR merge sessions for small PR, to decrease the number, then bigger one. No informations about the future DDF core.
zguy2008
commented
1 year ago I see. While I wait, is there any other way than the REST API that I could use to at least make open/close the device?
Smanar
commented
1 year ago No, apart recompile the code, there is no way to use another cluster than the 0x0102 to send a covering request.
github-actions[bot]
commented
1 year ago As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
zguy2008
commented
1 year ago Keeping issue active.
@Smanar, it's been almost 3 months issue is open. Please send good news.
VeeTeeDev
commented
1 year ago Hi guys,
any news ? It doesn't even get recognised when I try to pair it. Is there enough info available for the developers? I can provide more logs if needed.
Smanar
commented
1 year ago No need logs the problem is known. But need a better DDF support, or someone able to compile the code to test a code change.
VeeTeeDev
commented
1 year ago All,
Is there somewhere a 'latest' version of the DDF available? I can see it pasting around here and then changing stuff... (one I can temporally use to connect my devices and start using them ;-) )
Smanar
commented
1 year ago Nope, the problem is from c++ code, DDF can't have impact on it. There is 2 solutions possibles and both need to be tested with compiling the code.
I can give you the procedure if you have a real OS.
Else need to wait for the DDF core support it, but there is so much thing in todo list.
VeeTeeDev
commented
1 year ago I replied on discord :-) I can give it a go if my system in able to run it.
zguy2008
commented
1 year ago Nope, the problem is from c++ code, DDF can't have impact on it. There is 2 solutions possibles and both need to be tested with compiling the code.
I can give you the procedure if you have a real OS.
Else need to wait for the DDF core support it, but there is so much thing in todo list.
So, how is that DDF core support coming?
github-actions[bot]
commented
1 year ago As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
zguy2008
commented
1 year ago @Smanar We're almost 4 months down the road. Can we get some feedback please?
Smanar
commented
1 year ago Nothing offical for a better DDF core. Have found one user to compile code and test modification but unfortunately he was on HA and we haven't succed with playing with OS.
Device
Xiaomi Aqara curtain driver E1, model # CM-M01
Screenshots
Basic
Power Configuration Cluster
Identify
Other clusters that are not mentioned above