Closed ads1230 closed 2 years ago
Hey! Just updated my Conbee II fw and its showing different clusters
Please try the DDF approach:
Please try the DDF approach:
- take the file from this repo: https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/xiaomi/xiaomi_mccgq14lm_openclose_sensor.json
- Change the modelID in line 4 to lumi.magnet.ac01
- Change the product ID in line 6 to MCCGQ13LM
- Save the file as xiaomi_mccgq13lm_openclose_sensor.json locally
- Find the file referenced in the first bullet on your system and copy the just created file for your device to the exact same folder
- Restart deconz, reset the device and re-pair
- If it works, please share the file for integration
Thanks. Added the DDF (and updated to latest docker version). Appears as an open/close sensor now but the state does not change when opened/closed. Also seems to now appear as a "smart plug" which powers off when the sensor is closed (and on when open). Tried resetting multiple times but has the same effect.
Oh man... A typical Xiaomi again...
Can you please check if the IAS Zone clusters Alarm 1 box changes upon open/close? Eventually, it helps to restart deconz once more (some folks reported the LM14 then started to work).
Oh man... A typical Xiaomi again...
Can you please check if the IAS Zone clusters Alarm 1 box changes upon open/close? Eventually, it helps to restart deconz once more (some folks reported the LM14 then started to work).
No luck even after reboot, only value which changes is the onoff state from false (closed) to true
Hm, next option to try would be in the lluni specific cluter (0xfcc0) to set attribute 0x0009 from (presumably) 0 to 2. As to my experience, this sets devices into some sort of "more zigbee comliant" mode, but it doesn't necessarily work for all devices (e.g. the LM14). Eventually, you need to re-read the simple descriptors are having done so (right click on the node).
Hm, next option to try would be in the lluni specific cluter (0xfcc0) to set attribute 0x0009 from (presumably) 0 to 2. As to my experience, this sets devices into some sort of "more zigbee comliant" mode, but it doesn't necessarily work for all devices (e.g. the LM14). Eventually, you need to re-read the simple descriptors are having done so (right click on the node).
Changing the value to 2 removed the onoff, Lumi specific and groups clusters. the IAS Zone Status changes from 0x0020 to 0x0021 when open, but not automatically (has to be read). The device reports correctly to phoscon / HA now, but requires a manual read.
Ok, looks like it's getting warmer and just the IAS Zone cluster binding is missing. Please follow https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/DDF-cheat-sheet#bindings-panel , but only step 1 (so spare the attribute report configuration).
Not much going on after dragging the cluster to the binding panel. Rebooted, repaired etc.
Hm, do you run Conbee/Raspbee II firmware version 0x26720700?
Eventually, it would help if you'd write instead of 2 here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5703#issuecomment-1025014334 otherwise I wouldn't really know how to get it to work properly.
Hm, do you run Conbee/Raspbee II firmware version 0x26720700?
Hey, yes my Conbee II stick is on 0x26720700 I've tried numerous resets/re-pairing but no luck.
Eventually, it would help if you'd write instead of 2 here #5703 (comment) otherwise I wouldn't really know how to get it to work properly.
Hmm is there a different value to 2 that could work? When opening / closing the sensor the only value which seems to change from false to true is the onoff attribute of the onoff cluster. Would it be possible to use this for open close?
Argh, doesn't really help to mention to do something without telling what... Known valid values for attribute 0x0009 are:
It's interesting that quite some folks mentioned lately that also the E1 open/close sensor shows a similar behavior, which is remarkable since I had it in hands for intergration and it simply worked out of the box with the DDF. Apparently, there's more to explore/investigate.
Argh, doesn't really help to mention to do something without telling what... Known valid values for attribute 0x0009 are:
- 1: Let's call that compatibility mode
- 2: Let's call it (more) zigbee mode
- 3: Apparently some very Xiaomi specific behavior, if you can call it like that at all
It's interesting that quite some folks mentioned lately that also the E1 open/close sensor shows a similar behavior, which is remarkable since I had it in hands for intergration and it simply worked out of the box with the DDF. Apparently, there's more to explore/investigate.
Ahh makes sense, thanks. 1 didn't do much, the IAS zone didn't change with open close. 3 had similar behaviour to 2 - the IAS zone changed but not automatically - only on read. It seems we're at a dead end, unless you'd be willing to let me post you a device?
Ok. Well, then please set it back to 2.
Looks like we are getting somewhere on the E1... Check out https://forum.phoscon.de/t/can-not-add-aqara-window-and-door-sensor-to-phoscon/1423/27?u=swoop
Can you please follow Smanar's advice a little down below?
Ok. Well, then please set it back to 2.
Looks like we are getting somewhere on the E1... Check out https://forum.phoscon.de/t/can-not-add-aqara-window-and-door-sensor-to-phoscon/1423/27?u=swoop
Can you please follow Smanar's advice a little down below?
Thanks.
Finding similar results to wosch, but with a payload.
Open
21:34:40:699 [IAS ZONE] - Address 0x54EF44100018AA90, Payload 0000003000010000311500020000192100100000f00000000000000000, Command 0x01
21:34:40:700 [IAS ZONE] - 0x54EF44100018AA90 No IAS sensor found for endpoint: 0x01
21:34:41:692 [IAS ZONE] - Address 0x54EF44100018AA90, Payload 11000020ff, Command 0x01
21:34:41:694 [IAS ZONE] - 0x54EF44100018AA90 No IAS sensor found for endpoint: 0x01
Closed
21:35:31:559 [IAS ZONE] - Address 0x54EF44100018AA90, Payload 0000003000010000311500020000192000100000f00000000000000000, Command 0x01
21:35:31:561 [IAS ZONE] - 0x54EF44100018AA90 No IAS sensor found for endpoint: 0x01
21:35:32:557 [IAS ZONE] - Address 0x54EF44100018AA90, Payload 11000020ff, Command 0x01
21:35:32:559 [IAS ZONE] - 0x54EF44100018AA90 No IAS sensor found for endpoint: 0x01
HAve you run a new sensor search while opening and closing the device? If not, please do so. Curious to learn if this already does the trick.
HAve you run a new sensor search while opening and closing the device? If not, please do so. Curious to learn if this already does the trick.
No luck when trying with sensor search on.
Got it and that's really odd. I'd assume you have a sensor automatically created? Should look like this: https://forum.phoscon.de/t/can-not-add-aqara-window-and-door-sensor-to-phoscon/1423/22?u=swoop (1st screenshot).
EDIT: Could you give this a try? https://forum.phoscon.de/t/can-not-add-aqara-window-and-door-sensor-to-phoscon/1423/34?u=swoop
Got it and that's really odd. I'd assume you have a sensor automatically created? Should look like this: https://forum.phoscon.de/t/can-not-add-aqara-window-and-door-sensor-to-phoscon/1423/22?u=swoop (1st screenshot).
EDIT: Could you give this a try? https://forum.phoscon.de/t/can-not-add-aqara-window-and-door-sensor-to-phoscon/1423/34?u=swoop
DING DING WINNER!
So attribute 0x0009 = 2 Added
{
"name": "config/enrolled",
"public": false,
"description": "State of IAS enrollment process.",
"default": 1
},
The attribute doesn't change automatically but the Zone Status updates.
Only things left are:
From the API Information
{
"config": {
"battery": 1,
"on": true,
"pending": [],
"reachable": true
},
"ep": 1,
"etag": "4da34608deb2d2ee4d8398b4acfc933f",
"lastannounced": "2022-02-13T08:44:48Z",
"lastseen": "2022-02-13T08:48Z",
"manufacturername": "LUMI",
"modelid": "lumi.magnet.ac01",
"name": "OpenClose 96",
"state": {
"lastupdated": "2022-02-13T08:48:41.111",
"lowbattery": false,
"open": false
},
"swversion": "2019",
"type": "ZHAOpenClose",
"uniqueid": "54:ef:44:10:00:18:aa:90-01-0500"
}
Nice.
So with the battery, you could also try to make a binding (the E1 just ignores it and sends without it) on 0x0020 attribute (should be voltage). I'd recommend to set something like min 60, max 60, change 1 for testing, so this should result in battery reports coming in every minute.
I guess the light should be deletable via API, gotta check if it requires any special parameters...
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.
As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.
I would like for this sensor to be supported. Can I do something to help?
I would like for this sensor to be supported. Can I do something to help?
You can use the DDF shared here, or perhaps @ads1230 can share his and we can get a PR.
Device
Screenshots
Basic
Identify
IAS Zone
Power Configuration
OTAU
Node info