[Deprecated] Xiaomi / Aqara / Opple Drivers with Presence!

Hi @markus,
Thanks for writing all those drivers.

I'm have an Aqara double wall switch no neutral, and I'm having the same issue as one of the other users above which cannot see the ON/OFF buttons.

Using the latest beta driver:
(Already pressed "Initialize" a couple of times and went out and came back to the page)

I also saw above that you then suggested another driver which I also tried but still no ON/OFF buttons:
https://raw.githubusercontent.com/markus-li/Hubitat/development/drivers/expanded/zigbee-aqara-wall-switch-expanded.groovy

Always happy to hear that they are liked :slight_smile:

Refresh the page, you should have 2 child devices at the bottom. The parent device does not have on/off.

oh ok now I see the 2 virtual child devices at the bottom - i could swear there were not there previously.
Should I use the latest beta v0.8.2.0803b or the standard driver v0.8.2.0730b ?

:slight_smile:

Doesn't really matter, there is an experimental feature in the latest Beta, but it is not enabled by default.

ok thanks. Just checked the logs and saw this for you:
Aqara Double wall switch no neutral

2020-08-03 11:20:26.478 [warn]Known model: lumi.ctrl_neutral2 - PLEASE REPORT THIS LOG TO THE DEV - description:read attr - raw: A6D40100005A01FF42296410006510006E20006F20000121E40C03282205210F00082112260A2182BE9923000000009B210000, dni: A6D4, endpoint: 01, cluster: 0000, size: 5A, attrId: FF01, encoding: 42, command: 0A, value: 296410006510006E20006F20000121E40C03282205210F00082112260A2182BE9923000000009B210000 | parseMap:[raw:A6D40100005A01FF42296410006510006E20006F20000121E40C03282205210F00082112260A2182BE9923000000009B210000, dni:A6D4, endpoint:01, cluster:0000, size:5A, attrId:FF01, encoding:41, command:0A, value:[raw:[openClose:00, switch2:00, unknown10:00, unknown11:00, battery:0CE4, deviceTemperature:22, RSSI_dB:000F, unknown3:2612, routerid:BE82, gestureCounter3:00000000, unknown9:0000], openClose:false, switch2:false, unknown10:0, unknown11:0, battery:3300, deviceTemperature:34, RSSI_dB:15, unknown3:9746, routerid:48770, gestureCounter3:0, unknown9:0], clusterInt:0, attrInt:65281]

1 Like

Thanks for the xiaomi drivers.

I added absolute humidity in my driver, but I use HPM to update my drivers automatically.
So it gets overridden once you release a new version.
I'm wondering if you could add the absolute humidity in your driver?

this attribute is useful because, in summer, the basement is humid ( humidity ~70% ), while outside is like 45%, but if you open the window in basement, the humidity will get even higher in basement since basement is very cool compare to the outside.
So my automation will need to compare the absolute humidity between basement and outside to see if we can open the windows or not.

Thanks.
//AbsoluteHumidity private calcAbsHumidity() { def deviceTemp if (getTemperatureScale() != "C") { deviceTemp = fahrenheitToCelsius(device.currentValue('temperature')) } else { deviceTemp = device.currentValue('temperature') } def deviceHumidity = device.currentValue('humidity') def numerator = (6.112 * Math.exp((17.67 * deviceTemp) / (deviceTemp + 243.5)) * deviceHumidity * 2.1674) def denominator = deviceTemp + 273.15 def absHumidity = (numerator / denominator).round(1) log.info "${device.displayName}: Parse returned: Absolute Humidity ${absHumidity},Temperature ${deviceTemp}, Humidity ${deviceHumidity}" sendEvent( name: "absoluteHumidity", value: absHumidity, descriptionText: "Absolute Humidity Is ${absHumidity} g/m³" ) }

3 Likes

Thanks :slight_smile:

It's in the Beta release for the Xiaomi, Aqara and Sonoff T&H sensors. Just enable "Report Absolute Humidity" in Preferences.

Hi @markus,
First off, great drivers. I'm trying to understand the RTCGQ11LM. I have noticed some behavior and would like to know if it is expected. It is the Rest Motion Timer. I have set the reset value to 30 seconds. As expected the sensor reports no motion in thirty seconds. What I have noticed is the device will not report motion again until another 30 seconds have past. In other words, once motion is triggered, the earliest another motion can occur is about 1 minute regardless of the timer value. Is this the way the RTCGQ11LM works?

It is, that is why the default is 61 seconds. There is a hardware hack that brings it down to 5 seconds, it could destroy your sensor if done wrong, but has worked well for me with the few devices I've done it on. I did not solder, I used a piece of copper tape. You can also use a copper pen and many other ways. There's a thread in the forum about this hack if you're interested.

1 Like

That got my eye right away and thought that is a curious default number. The lights came on (pun intended) as to why today while I was testing. Now that I know what I'm working with, I can work with it. Thanks for the mod instructions, I may try it in the future.

What's the battery life like after implementing that hack?

I've done this on a couple motion sensors about 7-8 months ago. Battery life hasn't really shifted. So I suspect there isn't much of an effect on battery life.

I want to read @markus' response, but I'm going to guess that the material used to connect the two points might make a difference. I've read about decreases in battery life when the two points were connected using graphite pencil marks. Graphite is much less conductive than copper.

I didn't have copper tape, and didn't trust my soldering skills, so I used conductive ink - like the pen linked to below:

https://www.amazon.com/Circuit-Scribe-Non-Toxic-Conductive-Silver/dp/B00OZATJ3A/

2 Likes

Just like @aaiyar I haven't seen any noticeable change in battery life on the few sensors I've made this change on in January. I'm sure it should shorten it by a little bit, but probably not by much, it depends on how often the sensor is activated.

2 Likes

Just reporting in these logs!

dev:122020-08-05 02:33:42.694 infoSending temperature event (Temperature: 25.0 °C)
dev:122020-08-05 02:33:42.690 warnKnown model: lumi.ctrl_neutral1 - PLEASE REPORT THIS LOG TO THE DEV - description:read attr - raw: 102F0100005A01FF42296410006510006E20006F20FF0121E40C0328190521A900082116260A2174679923000000009B210000, dni: 102F, endpoint: 01, cluster: 0000, size: 5A, attrId: FF01, encoding: 42, command: 0A, value: 296410006510006E20006F20FF0121E40C0328190521A900082116260A2174679923000000009B210000 | parseMap:[raw:102F0100005A01FF42296410006510006E20006F20FF0121E40C0328190521A900082116260A2174679923000000009B210000, dni:102F, endpoint:01, cluster:0000, size:5A, attrId:FF01, encoding:41, command:0A, value:[raw:[openClose:00, switch2:00, unknown10:00, unknown11:FF, battery:0CE4, deviceTemperature:19, RSSI_dB:00A9, unknown3:2616, routerid:6774, gestureCounter3:00000000, unknown9:0000], openClose:false, switch2:false, unknown10:0, unknown11:255, battery:3300, deviceTemperature:25, RSSI_dB:169, unknown3:9750, routerid:26484, gestureCounter3:0, unknown9:0], clusterInt:0, attrInt:65281]
dev:102020-08-05 02:33:18.542 infoSending temperature event (Temperature: 26.0 °C)
dev:102020-08-05 02:33:18.534 warnKnown model: lumi.ctrl_neutral1 - PLEASE REPORT THIS LOG TO THE DEV - description:read attr - raw: C7E20100005A01FF42296410006510006E20006F20FF0121E40C03281A0521F70E082116260A2174679923000000009B210000, dni: C7E2, endpoint: 01, cluster: 0000, size: 5A, attrId: FF01, encoding: 42, command: 0A, value: 296410006510006E20006F20FF0121E40C03281A0521F70E082116260A2174679923000000009B210000 | parseMap:[raw:C7E20100005A01FF42296410006510006E20006F20FF0121E40C03281A0521F70E082116260A2174679923000000009B210000, dni:C7E2, endpoint:01, cluster:0000, size:5A, attrId:FF01, encoding:41, command:0A, value:[raw:[openClose:00, switch2:00, unknown10:00, unknown11:FF, battery:0CE4, deviceTemperature:1A, RSSI_dB:0EF7, unknown3:2616, routerid:6774, gestureCounter3:00000000, unknown9:0000], openClose:false, switch2:false, unknown10:0, unknown11:255, battery:3300, deviceTemperature:26, RSSI_dB:3831, unknown3:9750, routerid:26484, gestureCounter3:0, unknown9:0], clusterInt:0, attrInt:65281]
dev:142020-08-05 02:30:33.084 infoSending temperature event (Temperature: 25.0 °C)
dev:142020-08-05 02:30:33.080 warnKnown model: lumi.ctrl_neutral1 - PLEASE REPORT THIS LOG TO THE DEV - description:read attr - raw: B7520100005A01FF42296410006510006E20006F20FF0121E40C03281905218500082116260A2174679923000000009B210000, dni: B752, endpoint: 01, cluster: 0000, size: 5A, attrId: FF01, encoding: 42, command: 0A, value: 296410006510006E20006F20FF0121E40C03281905218500082116260A2174679923000000009B210000 | parseMap:[raw:B7520100005A01FF42296410006510006E20006F20FF0121E40C03281905218500082116260A2174679923000000009B210000, dni:B752, endpoint:01, cluster:0000, size:5A, attrId:FF01, encoding:41, command:0A, value:[raw:[openClose:00, switch2:00, unknown10:00, unknown11:FF, battery:0CE4, deviceTemperature:19, RSSI_dB:0085, unknown3:2616, routerid:6774, gestureCounter3:00000000, unknown9:0000], openClose:false, switch2:false, unknown10:0, unknown11:255, battery:3300, deviceTemperature:25, RSSI_dB:133, unknown3:9750, routerid:26484, gestureCounter3:0, unknown9:0], clusterInt:0, attrInt:65281]
1 Like

Something I've just noticed - when controlling virtual switch 1 of an Aqara QBKG03LM wired switch (two buttons) via a dashboard, operating button 1 (left physical paddle) on the dashboard causes button 2 to report the same on/off state without any relay change occurring on the switch itself.

Operating button 2 on the dashboard (right physical paddle) doesn't do the same thing - button 1 remains reporting the correct state.

Sounds like my driver isn't parsing packets the right way, would need to have the full debug logs from when operating the left paddle from the Dashboard or device page. Then also the debug logs form operating the right paddle.

Here you go!

dev:72020-08-05 09:26:58.764 infoTurning OFF relay 2 (endpoint: 3)
dev:72020-08-05 09:26:58.760 infoOn/Off Button press - description:read attr - raw: 7E07030006160000100000F02330000007, dni: 7E07, endpoint: 03, cluster: 0006, size: 16, attrId: 0000, encoding: 10, command: 0A, value: 0000F02330000007 | parseMap:[raw:7E07030006160000100000F02330000007, dni:7E07, endpoint:03, cluster:0006, size:16, attrId:0000, encoding:10, command:0A, value:00, clusterInt:6, attrInt:0, additionalAttrs:[[value:07000030, encoding:23, attrId:F000, consumedBytes:7, attrInt:61440]], valueParsed:false]
dev:72020-08-05 09:26:58.693 errorjava.lang.NullPointerException: Cannot invoke method parse() on null object on line 643 (parse)
dev:72020-08-05 09:26:58.674 infoPower Cluster 0006 catchall - description:catchall: 0104 0006 03 01 0040 00 7E07 00 00 0000 0B 01 0000 | parseMap:[raw:catchall: 0104 0006 03 01 0040 00 7E07 00 00 0000 0B 01 0000, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:03, destinationEndpoint:01, options:0040, messageType:00, dni:7E07, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:0B, direction:01, data:[00, 00]]
dev:72020-08-05 09:26:58.434 debugsendZigbeeCommands(cmd=[he cmd 0x7E07 0x03 0x0006 0x00 {}, delay 200])
dev:72020-08-05 09:26:58.428 debugcomponentOff() from 7-2
dev:72020-08-05 09:26:55.005 infoTurning ON relay 2 (endpoint: 3)
dev:72020-08-05 09:26:55.001 infoOn/Off Button press - description:read attr - raw: 7E07030006160000100100F0232F000007, dni: 7E07, endpoint: 03, cluster: 0006, size: 16, attrId: 0000, encoding: 10, command: 0A, value: 0100F0232F000007 | parseMap:[raw:7E07030006160000100100F0232F000007, dni:7E07, endpoint:03, cluster:0006, size:16, attrId:0000, encoding:10, command:0A, value:01, clusterInt:6, attrInt:0, additionalAttrs:[[value:0700002F, encoding:23, attrId:F000, consumedBytes:7, attrInt:61440]], valueParsed:true]
dev:72020-08-05 09:26:54.950 errorjava.lang.NullPointerException: Cannot invoke method parse() on null object on line 641 (parse)
dev:72020-08-05 09:26:54.931 infoPower Cluster 0006 catchall - description:catchall: 0104 0006 03 01 0040 00 7E07 00 00 0000 0B 01 0100 | parseMap:[raw:catchall: 0104 0006 03 01 0040 00 7E07 00 00 0000 0B 01 0100, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:03, destinationEndpoint:01, options:0040, messageType:00, dni:7E07, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:0B, direction:01, data:[01, 00]]
dev:72020-08-05 09:26:54.625 debugsendZigbeeCommands(cmd=[he cmd 0x7E07 0x03 0x0006 0x01 {}, delay 200])
dev:72020-08-05 09:26:54.618 debugcomponentOn() from 7-2
dev:72020-08-05 09:26:50.328 infoTurning OFF relay 1 (endpoint: 2)
dev:72020-08-05 09:26:50.324 infoOn/Off Button press - description:read attr - raw: 7E07020006160000100000F0232E000007, dni: 7E07, endpoint: 02, cluster: 0006, size: 16, attrId: 0000, encoding: 10, command: 0A, value: 0000F0232E000007 | parseMap:[raw:7E07020006160000100000F0232E000007, dni:7E07, endpoint:02, cluster:0006, size:16, attrId:0000, encoding:10, command:0A, value:00, clusterInt:6, attrInt:0, additionalAttrs:[[value:0700002E, encoding:23, attrId:F000, consumedBytes:7, attrInt:61440]], valueParsed:false]
dev:72020-08-05 09:26:50.222 infoPower Cluster 0006 catchall - description:catchall: 0104 0006 02 01 0040 00 7E07 00 00 0000 0B 01 0000 | parseMap:[raw:catchall: 0104 0006 02 01 0040 00 7E07 00 00 0000 0B 01 0000, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:02, destinationEndpoint:01, options:0040, messageType:00, dni:7E07, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:0B, direction:01, data:[00, 00]]
dev:72020-08-05 09:26:49.834 debugsendZigbeeCommands(cmd=[he cmd 0x7E07 0x02 0x0006 0x00 {}, delay 200])
dev:72020-08-05 09:26:49.826 debugcomponentOff() from 7-1
dev:72020-08-05 09:26:45.546 infoTurning ON relay 1 (endpoint: 2)
dev:72020-08-05 09:26:45.537 infoOn/Off Button press - description:read attr - raw: 7E07020006160000100100F0232D000007, dni: 7E07, endpoint: 02, cluster: 0006, size: 16, attrId: 0000, encoding: 10, command: 0A, value: 0100F0232D000007 | parseMap:[raw:7E07020006160000100100F0232D000007, dni:7E07, endpoint:02, cluster:0006, size:16, attrId:0000, encoding:10, command:0A, value:01, clusterInt:6, attrInt:0, additionalAttrs:[[value:0700002D, encoding:23, attrId:F000, consumedBytes:7, attrInt:61440]], valueParsed:true]
dev:72020-08-05 09:26:45.413 infoPower Cluster 0006 catchall - description:catchall: 0104 0006 02 01 0040 00 7E07 00 00 0000 0B 01 0100 | parseMap:[raw:catchall: 0104 0006 02 01 0040 00 7E07 00 00 0000 0B 01 0100, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:02, destinationEndpoint:01, options:0040, messageType:00, dni:7E07, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:0B, direction:01, data:[01, 00]]
dev:72020-08-05 09:26:45.127 debugsendZigbeeCommands(cmd=[he cmd 0x7E07 0x02 0x0006 0x01 {}, delay 200])
dev:72020-08-05 09:26:45.119 debugcomponentOn() from 7-1
dev:72020-08-05 09:26:31.921 debugdirty model = lumi.ctrl_neutral2, clean model=lumi.ctrl_neutral2
dev:72020-08-05 09:26:31.917 debugModel Name Received - description:read attr - raw: 7E070100002E050042126C756D692E6374726C5F6E65757472616C32, dni: 7E07, endpoint: 01, cluster: 0000, size: 2E, attrId: 0005, encoding: 42, command: 01, value: 126C756D692E6374726C5F6E65757472616C32 | parseMap:[raw:7E070100002E050042126C756D692E6374726C5F6E65757472616C32, dni:7E07, endpoint:01, cluster:0000, size:2E, attrId:0005, encoding:42, command:01, value:lumi.ctrl_neutral2, clusterInt:0, attrInt:5]
dev:72020-08-05 09:26:29.259 debugsendZigbeeCommands(cmd=[he raw 0x7E07 1 0x01 0x0000 {10 00 00 05 00}, delay 2000])
dev:72020-08-05 09:26:29.255 debugrefresh cmd: [he raw 0x7E07 1 0x01 0x0000 {10 00 00 05 00}, delay 2000]
dev:72020-08-05 09:26:29.249 debugsendZigbeeCommands(cmd=[he raw 0x7E07 1 0x01 0x0000 {10 00 00 04 00}, delay 2000])
dev:72020-08-05 09:26:29.244 infoping()
dev:72020-08-05 09:26:29.194 infoDo nothing - The device already exists
dev:72020-08-05 09:26:29.181 infoMaking device with type 1 virtual switch and id 7-1
dev:72020-08-05 09:26:29.178 infoDo nothing - The device already exists
dev:72020-08-05 09:26:29.159 infoMaking device with type 1 virtual switch and id 7-2
dev:72020-08-05 09:26:29.146 debugdirty model = lumi.ctrl_neutral2, clean model=lumi.ctrl_neutral2
dev:72020-08-05 09:26:29.121 debugsendZigbeeCommands(cmd=[he raw 0x7E07 1 0x01 0x0000 {10 00 00 04 00}, delay 2000])
dev:72020-08-05 09:26:29.112 debugrecoveryMode: Slow
dev:72020-08-05 09:26:29.057 infoRecovery feature ENABLED
dev:72020-08-05 09:26:29.053 debugstartCheckEventInterval()
dev:72020-08-05 09:26:28.959 infogetDriverVersion() = v0.8.2.0803b
dev:72020-08-05 09:26:28.954 debugrefresh() model='lumi.ctrl_neutral2'
dev:72020-08-05 09:26:28.949 infoupdated()

As instructed, here are some logs from a DJT11LM. As far as I know, those 3 events occurred and none since.

Does seem to relate to some of the the lastCheckin events.

thanks for adding the abs humidity.
just one more question, abs humidity is a function of both temperature and humidity,
but you only added it when humidity change.
when temperature changes, it should update as well.
also, typically we receive both humidity and temperate at almost the same time, but the order is not always the same, ideally, we should just wait for 2 seconds, after both humidity and temperature are both updated, and calculate abs humidity.
thanks.

Waiting is not a great thing to do in this type of platform, but I have updated to send absolute humidity changes on both temp and humidity changes. The change is in the Beta version now.

1 Like