Closed Otnow closed 2 years ago
Try with adding to devices.js
{
zigbeeModel: ['lumi.motion.agl02'],
model: 'RTCGQ12LM',
vendor: 'Xiaomi',
description: 'Aqara human body movement and illuminance sensor',
meta: {battery: {voltageToPercentage: '3V_2100'}},
fromZigbee: [fz.xiaomi_battery, fz.occupancy_with_timeout, fz.RTCGQ11LM_illuminance, fz.RTCGQ11LM_interval],
toZigbee: [],
exposes: [e.battery(), e.occupancy(), e.illuminance_lux().withProperty('illuminance'),
e.illuminance().withUnit('lx').withDescription('Measured illuminance in lux')],
},
Try with adding to devices.js
After pairing, no sensor events appear.
Sensor exposes in Web-interface:
_battery - N/A % occupancy - N/A illuminancelux - N/A lx illuminance - N/A lx linkquality - 47 lqi
If you remove all entries from fromZigbee, restart z2m... do any messages show up for missing converters?
If you remove all entries from fromZigbee, restart z2m... do any messages show up for missing converters?
Moreover, after listening to the zigbee-traffic, I see that the sensor does not respond to movement (there are no corresponding events - "Report Attributes") after pairing with the zigbee-stick.
@Otnow I think you have to sniff the traffic with the original gateway as we need to figure out how to configure the detection period. So start sniffing, pair it with the gateway, change detection period. https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html
@Otnow I think you have to sniff the traffic with the original gateway as we need to figure out how to configure the detection period. So start sniffing, pair it with the gateway, change detection period. https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html
I already made such a dump in advance and placed it in the initial post in the Additional info section under the spoiler Dump zigbee-packets with ZBOSS Sniffer and Wireshark )
@Otnow sorry for being blind. I've created an initial pr, it only allows setting the detection period: https://github.com/Koenkk/zigbee-herdsman-converters/pull/2079/files
Seems that something non standard is used for occupancy. Can you provide the packet numbers of occupancy: true and false (please provide multiple)
Seems that something non standard is used for occupancy. Can you provide the packet numbers of occupancy: true and false (please provide multiple)
When motion is detected, only 1 event is generated: dump entries № 214, 220, 226, 232, 238, 244, 251, 257, 263 (events were generated every 2 seconds, because detection period = 2s). There are no events at the end of the detection period.
By analogy with the Aqara T1 temperature, humidity and pressure sensor (WSDCGQ12LM), this code:
{
zigbeeModel: ['lumi.motion.agl02'],
model: 'RTCGQ12LM',
vendor: 'Xiaomi',
description: 'Aqara T1 human body movement and illuminance sensor',
fromZigbee: [],
toZigbee: [],
meta: {},
configure: async (device, coordinatorEndpoint, logger) => {
const endpoint = device.getEndpoint(1);
const binds = ['msOccupancySensing'];
await reporting.bind(endpoint, coordinatorEndpoint, binds);
},
exposes: [],
},
allows you to generate a motion detection event in the log:
Can you check updates of https://github.com/Koenkk/zigbee-herdsman-converters/pull/2079/files?
Following should work now: occupancy, illuminance and battery (please check carefully in the logs if configure is succesfull, you can force it via https://www.zigbee2mqtt.io/information/mqtt_topics_and_message_structure.html#zigbee2mqttbridgerequestdeviceconfigure)
Can you check updates of https://github.com/Koenkk/zigbee-herdsman-converters/pull/2079/files?
The test showed that motion events appear, but the set detection period is not observed, although the parameter is set normally. Also, illuminance and battery power are not displayed.
Made some more updates to https://github.com/Koenkk/zigbee-herdsman-converters/pull/2079/files, battery and illuminance should work after this
, but the set detection period is not observed, although the parameter is set normally.
I don't understand what you mean with this, can you explain it further?
Made some more updates to https://github.com/Koenkk/zigbee-herdsman-converters/pull/2079/files, battery and illuminance should work after this
The battery power is now displayed, but the illuminance is still not:
- Zigbee2MQTT:error 2021-01-15 20:58:32: Failed to configure '0x04cf8cdf3c7fd37e', attempt 1 (Error: ConfigureReporting 0x04cf8cdf3c7fd37e/1 msIlluminanceMeasurement([{"attribute":"measuredValue","minimumReportInterval":15,"maximumReportInterval":3600,"reportableChange":500}], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null}) failed (Timeout - 9879 - 1 - 14 - 1024 - 7 after 10000ms)
at Timeout._onTimeout (/zigbee2mqtt-1.17.0/node_modules/zigbee-herdsman/dist/utils/waitress.js:46:35)
at listOnTimeout (internal/timers.js:549:17)
at processTimers (internal/timers.js:492:7))
I don't understand what you mean with this, can you explain it further?
I set the detection period = 5s:
- Zigbee2MQTT:debug 2021-01-15 20:59:05: Received MQTT message on 'zigbee2mqtt/0x04cf8cdf3c7fd37e/set' with data '{"detection_period":5}'
- Zigbee2MQTT:debug 2021-01-15 20:59:05: Publishing 'set' 'detection_period' to '0x04cf8cdf3c7fd37e'
But the generated events of the beginning and the end of the movement show the delay significantly more than 5s, in fact - 106s:
- Zigbee2MQTT:debug 2021-01-15 21:02:22: Received Zigbee message from '0x04cf8cdf3c7fd37e', type 'attributeReport', cluster 'msOccupancySensing', data '{"occupancy":1}' from endpoint 1 with groupID 0
- Zigbee2MQTT:info 2021-01-15 21:02:22: MQTT publish: topic 'zigbee2mqtt/0x04cf8cdf3c7fd37e', payload '{"battery":100,"detection_period":5,"linkquality":136,"occupancy":true,"voltage":3100}'
- Zigbee2MQTT:debug 2021-01-15 21:04:08: Received Zigbee message from '0x04cf8cdf3c7fd37e', type 'attributeReport', cluster 'msOccupancySensing', data '{"occupancy":0}' from endpoint 1 with groupID 0
- Zigbee2MQTT:info 2021-01-15 21:04:08: MQTT publish: topic 'zigbee2mqtt/0x04cf8cdf3c7fd37e', payload '{"battery":100,"detection_period":5,"linkquality":136,"occupancy":false,"voltage":3100}'
@Otnow can you provide a sniff with the Xiaomi gateway from pairing till a illuminance report is send?
@Otnow can you provide a sniff with the Xiaomi gateway from pairing till a illuminance report is send?
RTCGQ12LM_2.pcapng.gz - encrypted pcapng-dump (Network Key for decryption entries: 21724f48ad8ebbc4f96ae7000506d3fc) RTCGQ12LM_2.zip - decrypted plain text dump
Recorded events in the dump:
Can you update to the latest zigbee2mqtt dev branch first (https://www.zigbee2mqtt.io/how_tos/how-to-switch-to-dev-branch.html), apply latest changes from https://github.com/Koenkk/zigbee-herdsman-converters/pull/2079 and check if illuminance is reported now?
Can you also provide a sniff when pairing it with Zigbee2MQTT?
Can you update to the latest zigbee2mqtt dev branch first (https://www.zigbee2mqtt.io/how_tos/how-to-switch-to-dev-branch.html), apply latest changes from Koenkk/zigbee-herdsman-converters#2079 and check if illuminance is reported now? Can you also provide a sniff when pairing it with Zigbee2MQTT?
After pairing the sensor with a zigbee-stick, no motion events are generated in zigbee-traffic. Accordingly, they are not in the Zigbee2MQTT log either, as are the illuminance values. The battery power value is not detected again. It was only possible to set the value of the detection period.
RTCGQ12LM_3.pcapng.gz - encrypted pcapng-dump (Network Key for decryption entries: 01030507090b0d0f00020406080a0c0d) RTCGQ12LM_3.zip - decrypted plain text dump
Recorded events in the dump:
Environment:
Updated https://github.com/Koenkk/zigbee-herdsman-converters/pull/2079/files again, can you check what works and provide a sniff?
Updated https://github.com/Koenkk/zigbee-herdsman-converters/pull/2079/files again, can you check what works and provide a sniff?
As before after pairing the sensor with a zigbee-stick, no motion events are generated in zigbee-traffic. Accordingly, they are not in the Zigbee2MQTT log either, as are the illuminance values. But the battery power value is detected again.
RTCGQ12LM_4.pcapng.gz - encrypted pcapng-dump (Network Key for decryption entries: 01030507090b0d0f00020406080a0c0d) RTCGQ12LM_4.zip - decrypted plain text dump
Recorded events in the dump:
Environment:
Don't understand why no occupancy is reported. Can you try again with: https://github.com/Koenkk/zigbee-herdsman-converters/pull/2079/commits/79c3986231d25f4a636921e4842f9ed091170c79 with this you reported that occupancy worked.
Don't understand why no occupancy is reported. Can you try again with: Koenkk/zigbee-herdsman-converters@79c3986 with this you reported that occupancy worked.
After pairing the sensor with a zigbee-stick, no motion events are generated in zigbee-traffic. Accordingly, they are not in the Zigbee2MQTT log either, as are the illuminance values. The battery power value is not detected again. It was only possible to set the value of the detection period.
RTCGQ12LM_5.pcapng.gz - encrypted pcapng-dump (Network Key for decryption entries: 01030507090b0d0f00020406080a0c0d) RTCGQ12LM_5.zip - decrypted plain text dump
Recorded events in the dump:
Environment:
In this configuration:
{
zigbeeModel: ['lumi.motion.agl02'],
model: 'RTCGQ12LM',
vendor: 'Xiaomi',
description: 'Aqara T1 human body movement and illuminance sensor',
fromZigbee: [fz.occupancy, fz.battery],
toZigbee: [tz.RTCGQ12LM_detection_period],
exposes: [e.occupancy(), e.battery(),
exposes.numeric('detection_period', exposes.access.STATE_SET).withValueMin(2).withValueMax(199).withUnit('s')
.withDescription('Time in seconds till occupancy goes to false')],
meta: {configureKey: 1, battery: {voltageToPercentage: '3V_2100'}},
configure: async (device, coordinatorEndpoint, logger) => {
const endpoint = device.getEndpoint(1);
await reporting.bind(endpoint, coordinatorEndpoint, ['genPowerCfg', 'msOccupancySensing']);
await reporting.occupancy(endpoint);
await reporting.batteryVoltage(endpoint);
},
},
battery power is displayed and motion events are generated (no illuminance), but the set detection period is not taken into account (actually 116s instead of the given 2s).
RTCGQ12LM_6.pcapng.gz - encrypted pcapng-dump (Network Key for decryption entries: 01030507090b0d0f00020406080a0c0d) RTCGQ12LM_6.zip - decrypted plain text dump
Recorded events in the dump:
Environment:
I tried by analogy with:
occupancy: async (endpoint, overrides) => {
const p = payload('occupancy', 0, repInterval.HOUR, 0, overrides);
await endpoint.configureReporting('msOccupancySensing', p);
},
set up reporting in the reporting.js for 0x0112 attribute from aqaraOpple cluster:
RTCGQ12LM_occupancy: async (endpoint, overrides) => {
const p = payload('illuminance', 0, repInterval.HOUR, 0, overrides);
await endpoint.configureReporting('aqaraOpple', p);
},
with devices.js:
{
zigbeeModel: ['lumi.motion.agl02'],
model: 'RTCGQ12LM',
vendor: 'Xiaomi',
description: 'Aqara T1 human body movement and illuminance sensor',
fromZigbee: [fz.xiaomi_opple_illuminance, fz.battery],
toZigbee: [tz.RTCGQ12LM_detection_period],
exposes: [e.illuminance(), e.battery(),
exposes.numeric('detection_period', exposes.access.STATE_SET).withValueMin(2).withValueMax(199).withUnit('s')
.withDescription('Time in seconds till occupancy goes to false')],
meta: {configureKey: 1, battery: {voltageToPercentage: '3V_2100'}},
configure: async (device, coordinatorEndpoint, logger) => {
const endpoint = device.getEndpoint(1);
await reporting.bind(endpoint, coordinatorEndpoint, ['genPowerCfg', 'aqaraOpple']);
await reporting.RTCGQ12LM_occupancy(endpoint);
await reporting.batteryVoltage(endpoint);
},
},
but sensor responds that attribute 0x0112 is not supported for reporting:
Accordingly, there are no motion events.
Environment:
By analogy with the Philips Hue motion sensor (SML001), this code:
{
zigbeeModel: ['lumi.motion.agl02'],
model: 'RTCGQ12LM',
vendor: 'Xiaomi',
description: 'Aqara T1 human body movement and illuminance sensor',
fromZigbee: [fz.occupancy, fz.battery],
toZigbee: [tz.occupancy_timeout],
exposes: [e.occupancy(), e.battery(),
exposes.numeric('occupancy_timeout', exposes.access.ALL).withValueMin(0).withValueMax(65535).withUnit('s')
.withDescription('Time in seconds till occupancy goes to false')],
meta: {configureKey: 1, battery: {voltageToPercentage: '3V_2100'}},
configure: async (device, coordinatorEndpoint, logger) => {
const endpoint = device.getEndpoint(1);
await reporting.bind(endpoint, coordinatorEndpoint, ['genPowerCfg', 'msOccupancySensing']);
await reporting.occupancy(endpoint);
await reporting.batteryVoltage(endpoint);
},
},
allows you to set the detection period (any, not just 2-199s) and generate a motion detection event based on it:
In previous configuration attempts, the static delay between start and end of detection in 116s was due to the default attribute pirOToUDelay = 120s.
It remains to understand where to get the value of illuminance.
Really like the config from https://github.com/Koenkk/zigbee2mqtt/issues/5706#issuecomment-763271991 , if I understand correctly everything works except the illuminance?
Do you see illuminance reports when adding msIlluminanceMeasurement
to reporting.bind
? Make sure to reconfigure the device via https://www.zigbee2mqtt.io/information/mqtt_topics_and_message_structure.html#zigbee2mqttbridgerequestdeviceconfigure after changing the configure() (otherwise it won't be applied)
Really like the config from #5706 (comment) , if I understand correctly everything works except the illuminance?
Yes.
Do you see illuminance reports when adding
msIlluminanceMeasurement
toreporting.bind
? Make sure to reconfigure the device via https://www.zigbee2mqtt.io/information/mqtt_topics_and_message_structure.html#zigbee2mqttbridgerequestdeviceconfigure after changing the configure() (otherwise it won't be applied)
Added msIlluminanceMeasurement
to reporting.bind
, but the illuminance parameter is still not visible:
RTCGQ12LM_7.pcapng.gz - encrypted pcapng-dump (Network Key for decryption entries: 01030507090b0d0f00020406080a0c0d) RTCGQ12LM_7.zip - decrypted plain text dump
Recorded events in the dump:
Moreover, if you add to the configuration:
await reporting.illuminance(endpoint);
then the sensor responds that the cluster Illuminance Measurement (0x0400) is unsupported:
Environment:
What if we bind the aqaraOpple
cluster? Updated: https://github.com/Koenkk/zigbee-herdsman-converters/pull/2079/files
What if we bind the
aqaraOpple
cluster? Updated: https://github.com/Koenkk/zigbee-herdsman-converters/pull/2079/files
Added aqaraOpple
to reporting.bind
, but the illuminance parameter is still not visible:
RTCGQ12LM_8.pcapng.gz - encrypted pcapng-dump (Network Key for decryption entries: 01030507090b0d0f00020406080a0c0d) RTCGQ12LM_8.zip - decrypted plain text dump
Recorded events in the dump:
Environment:
TBH I'm currently out of ideas how to get the illuminance working. I think the magic is in the write of 0x00FF (https://github.com/Koenkk/zigbee2mqtt/issues/5706#issuecomment-761622061) but looking at your various Xiaomi gateway sniff the values is different every time (so don't know how to reconstruct it). I will merge the current MR so at least occupancy is supported for now.
Where did you buy this sensor? Interested in buying one myself.
I think the magic is in the write of 0x00FF (#5706 (comment)) but looking at your various Xiaomi gateway sniff the values is different every time (so don't know how to reconstruct it).
Yes, I think so too. You have correctly noticed that each time the gateway writes the 0x00FF attribute with a different value. I tried to write the 0x00FF attribute with the value from the dump, but the illuminance did not appear, because there seems to be some special algorithm for its generation. I also wanted to check for a possible vendor lock by MAC address, but for some reason the value of the configuration parameter ext_pan_id: [84, 239, 68, 16, 0, 2, 212, 160]
is not applied:
- info 2021-01-22 05:35:30: Starting Zigbee2MQTT version 1.17.0-dev (commit #2ef2c54)
- info 2021-01-22 05:35:30: Starting zigbee-herdsman (0.13.57)
- debug 2021-01-22 05:35:30: Using zigbee-herdsman with settings: '{"adapter":{"concurrent":null,"delay":null},"backupPath":"/opt/zigbee2mqtt/data/coordinator_backup.json","databaseBackupPath":"/opt/zigbee2mqtt/data/database.db.backup","databasePath":"/opt/zigbee2mqtt/data/database.db","network":{"channelList":[25],"extendedPanID":[84,239,68,16,0,2,212,160],"networkKey":"HIDDEN","panID":22441},"serialPort":{"path":"/dev/ttyACM0"}}'
- info 2021-01-22 05:35:34: zigbee-herdsman started
- info 2021-01-22 05:35:34: Coordinator firmware version: '{"meta":{"maintrel":2,"majorrel":2,"minorrel":7,"product":2,"revision":20190425,"transportrev":2},"type":"zStack30x"}'
- debug 2021-01-22 05:35:34: Zigbee network parameters: {"channel":25,"extendedPanID":"0x00124b0014d9f126","panID":22441}
What can be wrong?
I will merge the current MR so at least occupancy is supported for now.
Ok, let it be as a temporary solution for now. Thank you.
Where did you buy this sensor? Interested in buying one myself.
I bought this sensor on Aliexpress from this seller (my purchase history), but judging by the comments under my review of the sensor on Reddit, it quickly ran out and now this seller is sending the old version (not T1). I think after some time this sensor should again appear on sale on Aliexpress and it is better to ask the seller in advance for the name of the model before buying, so as not to be mistaken.
About the ext_pan_id, can you provide the herdsman debug log when starting with this?
To enable herdsman debug logging, see https://www.zigbee2mqtt.io/information/debug.html#zigbee-herdsman-debug-logging
About the ext_pan_id, can you provide the herdsman debug log when starting with this?
To enable herdsman debug logging, see https://www.zigbee2mqtt.io/information/debug.html#zigbee-herdsman-debug-logging
Ah, this is a bug in the Zstack 3.0.x firmware (probably will not be fixed since this firmware is not maintained anymore by TI).
Here you see Zigbee2MQTT checks the extended pan id, which matches yours:
zigbee-herdsman:adapter:zStack:znp:SRSP <-- SYS - osalNvRead - {"status":0,"len":8,"value":{"type":"Buffer","data":[84,239,68,16,0,2,212,160]}} +38ms
zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] +4ms
zigbee-herdsman:adapter:zStack:startZnp Item 'extendedPanID' is valid +39ms
However when z2m reads the extended pan id with another request it returns the ieeeAddr
instead of the extended pan id.
zigbee-herdsman:adapter:zStack:znp:SRSP <-- ZDO - extNwkInfo - {"shortaddr":0,"devstate":9,"panid":22441,"parentaddr":0,"extendedpanid":"0x00124b0014d9f126","parentextaddr":"0x0000000000000000","channel":25} +748ms
This probably is not the issue why the illuminance doesn't work (since other stuff works fine)
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
Experimentally, it was possible to find out that the value of the attribute 0x00FF, which the gateway transmits to the sensor during pairing, changes approximately once every 5 minutes:
21:20:33 - 30:53:24:44:22:15:63:24:12:55:14:34:29:22:84:10
21:21:20 - 30:53:24:44:22:15:63:24:12:55:14:34:29:22:84:10
21:22:18 - 30:53:24:44:22:15:63:24:12:55:14:34:29:22:84:10
21:23:17 - 30:53:24:44:22:15:63:24:12:55:14:34:29:22:84:10
21:24:16 - 30:53:24:44:22:15:63:24:12:55:14:34:29:22:84:10
21:25:16 - 30:53:24:44:22:15:63:24:12:55:14:34:29:22:84:10
21:26:16 - 95:47:57:88:77:34:10:69:61:74:79:54:40:78:18:18
21:27:17 - 95:47:57:88:77:34:10:69:61:74:79:54:40:78:18:18
21:28:15 - 95:47:57:88:77:34:10:69:61:74:79:54:40:78:18:18
21:29:17 - 95:47:57:88:77:34:10:69:61:74:79:54:40:78:18:18
21:30:16 - 95:47:57:88:77:34:10:69:61:74:79:54:40:78:18:18
21:31:16 - 13:41:03:54:26:81:18:82:21:26:24:94:14:78:81:83
21:32:15 - 13:41:03:54:26:81:18:82:21:26:24:94:14:78:81:83
21:33:48 - 13:41:03:54:26:81:18:82:21:26:24:94:14:78:81:83
21:34:19 - 13:41:03:54:26:81:18:82:21:26:24:94:14:78:81:83
21:35:15 - 13:41:03:54:26:81:18:82:21:26:24:94:14:78:81:83
21:36:24 - 18:23:20:31:56:54:56:74:94:08:16:32:42:00:96:53
21:37:17 - 18:23:20:31:56:54:56:74:94:08:16:32:42:00:96:53
21:38:15 - 18:23:20:31:56:54:56:74:94:08:16:32:42:00:96:53
21:39:52 - 18:23:20:31:56:54:56:74:94:08:16:32:42:00:96:53
21:40:21 - 18:23:20:31:56:54:56:74:94:08:16:32:42:00:96:53
21:41:17 - 18:23:20:31:56:54:56:74:94:08:16:32:42:00:96:53
21:42:16 - 97:89:23:89:20:68:35:37:87:57:99:95:19:14:44:15
21:43:15 - 97:89:23:89:20:68:35:37:87:57:99:95:19:14:44:15
RTCGQ12LM_9.zip - decrypted plain text dump
Using the intercepted value of the 0x00FF attribute for 5 minutes, I repeated its transmission to the sensor in the test environment, but the sensor did not start transmitting the illuminance value.
Environment:
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
I recently purchased some of the RTCGQ12LM sensors myself.
I'm curious - does anybody have any ideas as to why illuminance not work?
Would it help if I supplied a physical sample of this sensor to the developers?
Or is there something I can dump from the sensors I have here?
I recently purchased some of the RTCGQ12LM sensors myself.
I'm curious - does anybody have any ideas as to why illuminance not work?
Would it help if I supplied a physical sample of this sensor to the developers?
Or is there something I can dump from the sensors I have here?
Unfortunately, Aqara does not strictly adhere to the standard of the zigbee protocol, so the algorithm for activating the transmission of illuminance data by the sensor is not yet clear.
Hopefully, over time, someone will figure out this algorithm.
Got it - do any of the devs need a sample of the server to progress this?
@Koenkk while working on supporting the E1 devices in ZHA I noticed something interesting. When we do the same thing that you did in the firmware to support the E1 devices (respond w/ Xiamoi's MFG code when pairing) this device acts differently. I haven't had a ton of time to dig into this much yet but I am getting reports now from cluster 0xfcc0 which isn't in the device signature.
@Koenkk while working on supporting the E1 devices in ZHA I noticed something interesting. When we do the same thing that you did in the firmware to support the E1 devices (respond w/ Xiamoi's MFG code when pairing) this device acts differently. I haven't had a ton of time to dig into this much yet but I am getting reports now from cluster 0xfcc0 which isn't in the device signature.
Yes, thanks, I am planning to test the operation of this motion sensor with a modified coordinator firmware (respond w/ Xiamoi's MFG code when pairing) by analogy with the e1 sensors and with a high probability I hope to get the illuminance data.
@Koenkk while working on supporting the E1 devices in ZHA I noticed something interesting. When we do the same thing that you did in the firmware to support the E1 devices (respond w/ Xiamoi's MFG code when pairing) this device acts differently. I haven't had a ton of time to dig into this much yet but I am getting reports now from cluster 0xfcc0 which isn't in the device signature.
Yes, thanks, I am planning to test the operation of this motion sensor with a modified coordinator firmware (respond w/ Xiamoi's MFG code when pairing) by analogy with the e1 sensors and with a high probability I hope to get the illuminance data.
From a quick test… the default occupancy sensing cluster functionality now appears broken. I see traffic on the mfg cluster. There are 2 reports that I have noticed so far. One looks like the typical Xiaomi byte string and the other looks like it’s the occupancy event. I’m not at the logs atm so I can’t provide specifics
@dmulcahey interesting! (and somehow disappointing that Xiaomi doesn't follow the spec, I guess they just don't want their device to work with other gateways)
@Otnow could you provide the z2m debug log when running with the new fw and triggering occupancy on the sensor?
See https://www.zigbee2mqtt.io/guide/usage/debug.html on how to enable debug logging.
This isn't from Z2M but it is what the sensor sends when occupancy is triggered:
Endpoint 1, Cluster Id: 0xfcc0
ZCL request 0x000a: [[Attribute(attrid=274, value=<TypeValue type=uint32_t, value=65540>)]]
The value of this attribute isn't consistent.
if you press the button on the device 1x you also get the Xiaomi bytes report:
Endpoint 1, Cluster Id: 0xfcc0
ZCL request 0x000a: [[Attribute(attrid=247, value=<TypeValue type=LVBytes, value=b'\x01!?\x0c\x03(\x19\x04!\xa8C\x05!\x18\x00\x06$\x03\x00\x00\x00\x00\x08!#\x01\n!\x00\x00\x0c \x01d\x10\x00e!\x00\x00f \x03g \x01h!\xa8\x00'>)]]
It also looks like occupancy no longer clears itself
@dmulcahey interesting! (and somehow disappointing that Xiaomi doesn't follow the spec, I guess they just don't want their device to work with other gateways)
@Otnow could you provide the z2m debug log when running with the new fw and triggering occupancy on the sensor?
Yes, unfortunately Aqara is trying to prevent its sensors from being used in alternative systems.
This motion sensor, when paired with a coordinator on a modified firmware, completely ceases to use standard clusters (msOccupancySensing no longer gives occupancy data and is occupied all the time) and uses only its own (aqaraOpple - 0xFCC0).
Now, in fact, there is only a motion start event containing illuminance data - cluster 0xFCC0: attribute 0x0112 (type: 0x23), manufacturerCode: 0x115f - starting point: 65536 = 0 Lux:
Received Zigbee message from '0x04cf8cdf3c7fd37e', type 'attributeReport', cluster 'aqaraOpple', data '{"illuminance":65540}' from endpoint 1 with groupID 0
The occupancy timeout is now contained in parameter - cluster 0xFCC0: attribute 0x0102 (type: 0x20), manufacturerCode: 0x115f - default: 60 sec:
Received Zigbee message from '0x04cf8cdf3c7fd37e', type 'readResponse', cluster 'aqaraOpple', data '{"258":60}' from endpoint 1 with groupID 0
Environment:
@Otnow could you try with this external converter:
const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const extend = require('zigbee-herdsman-converters/lib/extend');
const {calibrateAndPrecisionRoundOptions} = require('zigbee-herdsman-converters/lib/utils');
const e = exposes.presets;
const ea = exposes.access;
const fzLocal = {
occupancy_illuminance: {
cluster: 'aqaraOpple',
type: ['attributeReport', 'readResponse'],
options: [exposes.options.precision('illuminance'), exposes.options.calibration('illuminance', 'percentual'),
exposes.options.occupancy_timeout()],
convert: (model, msg, publish, options, meta) => {
if (msg.data.hasOwnProperty('illuminance')) {
// The occupancy sensor only sends a message when motion detected.
// Therefore we need to publish the no_motion detected by ourselves.
const timeout = options && options.hasOwnProperty('occupancy_timeout') ? options.occupancy_timeout : 90;
// Stop existing timers because motion is detected and set a new one.
globalStore.getValue(msg.endpoint, 'timers', []).forEach((t) => clearTimeout(t));
globalStore.putValue(msg.endpoint, 'timers', []);
if (timeout !== 0) {
const timer = setTimeout(() => {
publish({occupancy: false});
}, timeout * 1000);
globalStore.getValue(msg.endpoint, 'timers').push(timer);
}
const illuminance = msg.data['illuminance'] - 65536;
return {occupancy: true, illuminance: calibrateAndPrecisionRoundOptions(illuminance, options, 'illuminance')}
}
},
}
}
const definition = {
zigbeeModel: ['lumi.motion.agl02'],
model: 'RTCGQ12LM',
vendor: 'Xiaomi',
description: 'Aqara T1 human body movement and illuminance sensor',
fromZigbee: [fzLocal.occupancy_illuminance, fz.aqara_opple_report],
toZigbee: [],
exposes: [e.illuminance().withUnit('lx').withDescription('Measured illuminance in lux'), e.occupancy(), e.battery(), e.battery_voltage()],
};
module.exports = definition;
See https://www.zigbee2mqtt.io/advanced/support-new-devices/01_support_new_devices.html#instructions how to use it
Questions:
occupancy: true
would be set when none is detectedThe occupancy timeout is now contained in parameter - cluster 0xFCC0: attribute 0x0102 (type: 0x20), manufacturerCode: 0x115f - default: 60 sec:
- I don't understand why the sensor does this when it doesn't send an occupancy false event itself.
The occupancy timeout is now contained in parameter - cluster 0xFCC0: attribute 0x0102 (type: 0x20), manufacturerCode: 0x115f - default: 60 sec:
- I don't understand why the sensor does this when it doesn't send an occupancy false event itself.
Maybe it's writeable that way software can use this to reset it? similar to on w/ timed off from the OnOff cluster? I don't understand why the entire device needs to function completely differently...
Given what we are seeing I am starting to go through the rest of the Aqara Zigbee 3.0 devices that I have managed to acquire... The Aqara TVOC device now has the Opple cluster as well when pairing w/ this change. Unlike the T1 motion sensor the device continues to function as it did before the change. So much for any form of consistency. The Opple cluster is reporting the Xiaomi data but I have no clue what any of it is for.
It may make sense to go through all Aqara Zigbee 3.0 devices to ensure they function still before widely recommending this firmware change to support the E1 devices.
Maybe it's writeable that way software can use this to reset it? similar to on w/ timed off from the OnOff cluster? I don't understand why the entire device needs to function completely differently...
That would only make sense if the occupancy sensor also can produce an occupancy: false event (like e.g. the Hue occupancy sensors)
It may make sense to go through all Aqara Zigbee 3.0 devices to ensure they function still before widely recommending this firmware change to support the E1 devices.
True, @z-x-f you have added support for many new Xiaomi devices, do you see any differences with the new fw?
True, @z-x-f you have added support for many new Xiaomi devices, do you see any differences with the new fw?
You need to remove them and re-pair them to test just FYI.
@Koenkk My smart outlet, smart plug and smart wall switch are no different with the new fw (after removing, restart z2m, and then re-pair).
Information about the device + link
Aqara motion sensor T1 (RTCGQ12LM; lumi.motion.agl02)
It has 1 parameter for customization:
data/database.db entry of the device
{"id":46,"type":"EndDevice","ieeeAddr":"0x04cf8cdf3c7fd37e","nwkAddr":56004,"manufId":4447,"manufName":"LUMI","powerSource":"Battery","modelId":"lumi.motion.agl02","epList":[1],"endpoints":{"1":{"profId":260,"epId":1,"devId":263,"inClusterList":[0,1030,3,1],"outClusterList":[3,25],"clusters":{"genBasic":{"attributes":{"modelId":"lumi.motion.agl02","manufacturerName":"LUMI","powerSource":3,"zclVersion":3,"appVersion":29,"stackVersion":2,"hwVersion":1,"dateCode":"20200327","swBuildId":"2019\u0000www."}}},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":29,"stackVersion":2,"hwVersion":1,"dateCode":"20200327","swBuildId":"2019\u0000www.","zclVersion":3,"interviewCompleted":true,"meta":{},"lastSeen":1610396769681}
Additional info
Zigbee2mqtt pairing log
- Zigbee2MQTT:debug 2021-01-11 23:25:46: Received MQTT message on 'zigbee2mqtt/bridge/config/permit_join' with data 'true' - Zigbee2MQTT:info 2021-01-11 23:25:46: Zigbee: allowing new devices to join. - Zigbee2MQTT:info 2021-01-11 23:25:47: MQTT publish: topic 'zigbee2mqtt/bridge/config', payload '{"commit":"1.17.0","coordinator":{"meta":{"maintrel":0,"majorrel":38,"minorrel":104,"product":0,"revision":"0x26680700","transportrev":0},"type":"ConBee2/RaspBee2"},"log_level":"debug","network":{"channel":11,"extendedPanID":"0xdddddddddddddddd","panID":6754},"permit_join":true,"version":"1.17.0"}' - Zigbee2MQTT:info 2021-01-11 23:25:57: Device '0x04cf8cdf3c7fd37e' joined - Zigbee2MQTT:info 2021-01-11 23:25:57: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x04cf8cdf3c7fd37e","ieee_address":"0x04cf8cdf3c7fd37e"},"type":"device_joined"}' - Zigbee2MQTT:info 2021-01-11 23:25:57: Starting interview of '0x04cf8cdf3c7fd37e' - Zigbee2MQTT:info 2021-01-11 23:25:57: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x04cf8cdf3c7fd37e","ieee_address":"0x04cf8cdf3c7fd37e","status":"started"},"type":"device_interview"}' - Zigbee2MQTT:info 2021-01-11 23:25:57: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":{"friendly_name":"0x04cf8cdf3c7fd37e"},"type":"device_connected"}' - Zigbee2MQTT:info 2021-01-11 23:25:57: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"interview_started","meta":{"friendly_name":"0x04cf8cdf3c7fd37e"},"type":"pairing"}' - Zigbee2MQTT:debug 2021-01-11 23:26:01: Received Zigbee message from '0x04cf8cdf3c7fd37e', type 'readResponse', cluster 'genBasic', data '{"modelId":"lumi.motion.agl02"}' from endpoint 1 with groupID null - Zigbee2MQTT:debug 2021-01-11 23:26:01: Skipping message, definition is undefined and still interviewing - Zigbee2MQTT:debug 2021-01-11 23:26:02: Received Zigbee message from '0x04cf8cdf3c7fd37e', type 'readResponse', cluster 'genBasic', data '{"manufacturerName":"LUMI"}' from endpoint 1 with groupID null - Zigbee2MQTT:debug 2021-01-11 23:26:02: Skipping message, definition is undefined and still interviewing - Zigbee2MQTT:debug 2021-01-11 23:26:03: Received Zigbee message from '0x04cf8cdf3c7fd37e', type 'readResponse', cluster 'genBasic', data '{"powerSource":3}' from endpoint 1 with groupID null - Zigbee2MQTT:debug 2021-01-11 23:26:03: Skipping message, definition is undefined and still interviewing - Zigbee2MQTT:debug 2021-01-11 23:26:04: Received Zigbee message from '0x04cf8cdf3c7fd37e', type 'readResponse', cluster 'genBasic', data '{"zclVersion":3}' from endpoint 1 with groupID null - Zigbee2MQTT:debug 2021-01-11 23:26:04: Skipping message, definition is undefined and still interviewing - Zigbee2MQTT:debug 2021-01-11 23:26:05: Received Zigbee message from '0x04cf8cdf3c7fd37e', type 'readResponse', cluster 'genBasic', data '{"appVersion":29}' from endpoint 1 with groupID null - Zigbee2MQTT:debug 2021-01-11 23:26:05: Skipping message, definition is undefined and still interviewing - Zigbee2MQTT:debug 2021-01-11 23:26:06: Received Zigbee message from '0x04cf8cdf3c7fd37e', type 'readResponse', cluster 'genBasic', data '{"stackVersion":2}' from endpoint 1 with groupID null - Zigbee2MQTT:debug 2021-01-11 23:26:06: Skipping message, definition is undefined and still interviewing - Zigbee2MQTT:debug 2021-01-11 23:26:07: Received Zigbee message from '0x04cf8cdf3c7fd37e', type 'readResponse', cluster 'genBasic', data '{"hwVersion":1}' from endpoint 1 with groupID null - Zigbee2MQTT:debug 2021-01-11 23:26:07: Skipping message, definition is undefined and still interviewing - Zigbee2MQTT:debug 2021-01-11 23:26:08: Received Zigbee message from '0x04cf8cdf3c7fd37e', type 'readResponse', cluster 'genBasic', data '{"dateCode":"20200327"}' from endpoint 1 with groupID null - Zigbee2MQTT:debug 2021-01-11 23:26:08: Skipping message, definition is undefined and still interviewing - Zigbee2MQTT:debug 2021-01-11 23:26:09: Received Zigbee message from '0x04cf8cdf3c7fd37e', type 'readResponse', cluster 'genBasic', data '{"swBuildId":"2019\u0000www."}' from endpoint 1 with groupID null - Zigbee2MQTT:debug 2021-01-11 23:26:09: Skipping message, definition is undefined and still interviewing - Zigbee2MQTT:info 2021-01-11 23:26:09: Successfully interviewed '0x04cf8cdf3c7fd37e', device has successfully been paired - Zigbee2MQTT:warn 2021-01-11 23:26:09: Device '0x04cf8cdf3c7fd37e' with Zigbee model 'lumi.motion.agl02' and manufacturer name 'LUMI' is NOT supported, please follow https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html - Zigbee2MQTT:info 2021-01-11 23:26:09: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"definition":null,"friendly_name":"0x04cf8cdf3c7fd37e","ieee_address":"0x04cf8cdf3c7fd37e","status":"successful","supported":false},"type":"device_interview"}' - Zigbee2MQTT:info 2021-01-11 23:26:09: MQTT publish: topic 'zigbee2mqtt/bridge/devices', payload '**[{"date_code":"20200327","definition":null,"endpoints":{"1":{"bindings":[],"clusters":{"input":["genBasic","msOccupancySensing","genIdentify","genPowerCfg"],"output":["genIdentify","genOta"]},"configured_reportings":[]}},"friendly_name":"0x04cf8cdf3c7fd37e","ieee_address":"0x04cf8cdf3c7fd37e","interview_completed":true,"interviewing":false,"model_id":"lumi.motion.agl02","network_address":56004,"power_source":"Battery","software_build_id":"2019\u0000www.","supported":false,"type":"EndDevice"}]**' - Zigbee2MQTT:info 2021-01-11 23:26:09: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"interview_successful","meta":{"friendly_name":"0x04cf8cdf3c7fd37e","supported":false},"type":"pairing"}'Dump zigbee-packets with ZBOSS Sniffer and Wireshark
The dump was made according to [this instruction](https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html): - [RTCGQ12LM.pcapng.gz](https://github.com/Koenkk/zigbee2mqtt/files/5798137/RTCGQ12LM.pcapng.gz) - encrypted pcapng-dump (_Network Key for decryption entries: 21724f48ad8ebbc4f96ae7000506d3fc_) - [RTCGQ12LM.txt.zip](https://github.com/Koenkk/zigbee2mqtt/files/5798141/RTCGQ12LM.txt.zip) - decrypted plain text dump **Recorded events in the dump:** - sensor pairing - changing sensor settings - _Detection period = 199s_ - dump entry №121 - _Detection period = 2s_ - dump entry №183 - motion detections **Environment:** - Sensor firmware version: _0.0.0_0029_ - Aqara Hub M1S (ZHWG15LM) firmware version: _3.1.0_0005.0517_ - Aqara Home app version: _2.2.4_