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
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
Hi @markus
It seems on the hourly checkin event, xiaomi devices actually report temperature/humidity (and pressure if it is aqara) in addition to battery. Is it possible to send those events
(in many rooms, the temperature barely changes so it seems it never have a temperature event, but with this change, it can get at least 1 event per hour)
Thanks
Log
2020-08-10 03:49:07.491 pm [info]KNOWN event (Xiaomi/Aqara specific data structure with battery data - 42 - hourly checkin) - description:read attr - raw: 59F80100005201FF42250121770B0421A81305211000062401000300006429CB0B6521C612662B358701000A210000, dni: 59F8, endpoint: 01, cluster: 0000, size: 52, attrId: FF01, encoding: 42, command: 0A, value: 250121770B0421A81305211000062401000300006429CB0B6521C612662B358701000A210000 | parseMap:[raw:59F80100005201FF42250121770B0421A81305211000062401000300006429CB0B6521C612662B358701000A210000, dni:59F8, endpoint:01, cluster:0000, size:52, attrId:FF01, encoding:41, command:0A, value:[raw:[battery:0B77, unknown1:13A8, RSSI_dB:0010, LQI:0000030001, temperature:0BCB, humidity:12C6, pressure:00018735, routerid:0000], battery:2935, unknown1:5032, RSSI_dB:16, LQI:196609, temperature:3019, humidity:4806, pressure:100149, routerid:0], clusterInt:0, attrInt:65281]`
Just poked my head back in to the thread to thank you again for the steady updates and the solid drivers, I've no idea how you find the time to maintain these and be so active and helpful on the forums.
After checking my logs it seems I switched to your drivers in May, all of my devices are currently at 100% uptime - no drop off or instability at all. The only issue was user error when configuring the lux sensor Very, very impressive. Thank you!
3 Likes
Yes, sure, but if there was no change then why would you need extra events? If there is a change it will be reported. Just want to understand the use-case here, it would not be hard to add as an optional, but every optional is another Preference for the user to understand.
Always happy to hear from users of my drivers Mostly I have the time since most things have been automated in my build-process and effective time-management would be the other main reason. Besides that I probably just spend WAY more time than is healthy in front of the computer doing work anyway, so doing these things are like mini-breaks
You must also have a good mesh then My drivers can't magically make the devices stable all on their own, unfortunately...
3 Likes
