Hi All,
Got Aqara Switch T1 " lumi.switch.n0agl1 " it is working as switch on / off with generic drivers in Hubitat
The issue is that Aqara Switch T1 have power meter function as well and i can not get this function to work without proper drivers .
Maybe someone have drivers for Aqara Switch T1 ?
or willing to create / modify from other systems I can test 
Many thanks
Like Home Assistant have driver , have not checked on Smarthing but possible working there as well
Reviving old topic! I have similar switch: lumi.switch.l1aeu1
Tried using driver: Zigbee - Aqara Wall Switch (w/ healthStatus) by: kkossev
Latest logs:
dev:932024-06-15 13:57:33.594errorgroovy.lang.MissingMethodException: No signature of method: user_driver_oh_lalabs_com_Zigbee___Aqara_Wall_Switch__w__healthStatus__640.on() is applicable for argument types: () values:
Possible solutions: run(), run(), any(), is(java.lang.Object), any(groovy.lang.Closure), run(java.io.File, [Ljava.lang.String;) on line 1693 (method toggle)
dev:932024-06-15 13:57:30.467infoNo VALID lastCheckin event available! This should be resolved by itself within 1 or 2 hours and is perfectly NORMAL as long as the same device don't get this multiple times per day...
dev:932024-06-15 13:57:30.443infoRecovery feature ENABLED
dev:932024-06-15 13:57:30.410infogetDriverVersion() = 2.0.6 2024/05/11 7:05 PM
dev:932024-06-15 13:57:28.846errororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_oh_lalabs_com_Zigbee___Aqara_Wall_Switch__w__healthStatus__640.push() is applicable for argument types: (java.math.BigDecimal) values: [1]
Possible solutions: use([Ljava.lang.Object;), run(), ping(), run(), dump(), parse(java.lang.String) (method push)
dev:932024-06-15 13:55:58.129errorgroovy.lang.MissingMethodException: No signature of method: user_driver_oh_lalabs_com_Zigbee___Aqara_Wall_Switch__w__healthStatus__640.on() is applicable for argument types: () values:
Possible solutions: run(), run(), any(), is(java.lang.Object), any(groovy.lang.Closure), run(java.io.File, [Ljava.lang.String;) on line 1693 (method toggle)
Does anybody has any luck with this switch?
Please post the Device Details - Data section that is found at the bottom of the device web page.
When you paired this switch for a first time, was this driver selected automatically!
(I edited this twice, the other thread was also for another type of switch, let’s continue here)
Here you go:
I have similar switch, with dual rocker. Using You're driver. Most likely it was detected automatically because of that.
Other one which works flawlessly:
Single rocker is new one. Hoped if dual rocker works fine, should single one also.
Every device is different, the driver is made this way that every particular model should be explicitly defined within the driver code.
Missing the device definition is the reason for the errors in your logs.
I will need also the detailed device fingerprint - can you please switch temporarily to the HE inbuilt driver named 'Device' , click on the 'Get Info' button and select/copy/paste as a text the fingerprint that will be shown in the live logs?
Only info i can get that way:
dev:942024-06-15 16:53:00.226debuggetting info for unknown Zigbee device...
As far i can see, it stays that way.
Edit:
dev:462024-06-15 16:56:30.022infoNo VALID lastCheckin event available! This should be resolved by itself within 1 or 2 hours and is perfectly NORMAL as long as the same device don't get this multiple times per day...
Sorry, last one seems info from another device.
dev:46 is lumi.switch.l2aeu1 dual rocker version
That's not good... I see also a problem with the Aqara switch that somehow is working OK (the umi.switch.l2aeu1) - it is registered in the HE system with probably wrong endpointId...
Do you still have the old (the original) version of the Markus's driver?
Go to Drivers Code, type 'Aqara Wall Switch' in the filter field and check whether you have more than one driver which names starts with 'Aqara Wall Switch' :
If you have the old driver, delete it. To be able to delete a driver, it should not be used by any device at this time.
Then, you delete the new switch (use the 'REMOVE DEVICE' red button at the bottom of the device page) and pair it again to the hub.
During the pairing, after the device is found, there will be a 'Device Info' hyperlink. Click on this link before you enter the custom device name/label, as the link will disappear later.
Make a screenshot (or better select/copy/paste as a text) ALL the information that will appear in the popup window.
OK, this means that some of the old fingerprints in this driver is causing HE to mistakenly match the wrong endpointId 2 .... I will try to find and fix it later.
Now I will need all the detailed information for all endpoints during the pairing process as a new device.
Will try that. For some reason after new pairing it still gets Aqara driver as default.
Tried few times.
If i change driver after pairing, same information. Getting info...
Selecting the Aqara driver is OK !
Look at this example for the info that I need.
This will hopefully change after the next driver update. You can't get the fingerprint now with the 'Get Info' button - the only possibility is this inital screen during the paring, as in the example.
Example page is unavailable. Will try to pair again and view live log.
I need this :
The link was to a post in the Beta forum..
The information needed is not available in the logs - it is available only once :
Thanks! Will look into it.
From live logs during pairing:
ev:982024-06-15 17:23:47.784infoPower Cluster 0006 catchall - description:catchall: 0000 0006 00 00 0040 00 FCE4 00 00 0000 00 00 D6FDFF040101190000 | parseMap:[raw:catchall: 0000 0006 00 00 0040 00 FCE4 00 00 0000 00 00 D6FDFF040101190000, profileId:0000, clusterId:0006, clusterInt:6, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:FCE4, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[D6, FD, FF, 04, 01, 01, 19, 00, 00]]
dev:462024-06-15 17:23:46.772warnUnhandled Event PLEASE REPORT TO DEV - description:catchall: 0000 0005 00 00 0040 00 B86F 00 00 0000 00 00 FA0000 | msgMap:[raw:catchall: 0000 0005 00 00 0040 00 B86F 00 00 0000 00 00 FA0000, profileId:0000, clusterId:0005, clusterInt:5, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:B86F, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[FA, 00, 00]]
dev:982024-06-15 17:23:44.606warnUnknown model (lumi.switch.l1aeu1) - PLEASE REPORT THIS LOG TO THE DEV - description:read attr - raw: FCE40100002E050042126C756D692E7377697463682E6C3161657531, dni: FCE4, endpoint: 01, cluster: 0000, size: 2E, attrId: 0005, encoding: 42, command: 01, value: 126C756D692E7377697463682E6C3161657531 | parseMap:[raw:FCE40100002E050042126C756D692E7377697463682E6C3161657531, dni:FCE4, endpoint:01, cluster:0000, size:2E, attrId:0005, encoding:42, command:01, value:lumi.switch.l1aeu1, clusterInt:0, attrInt:5]
sys:12024-06-15 17:23:44.412infoZigbee Discovery Stopped
dev:982024-06-15 17:23:44.342warnUnknown model (lumi.switch.l1aeu1) - PLEASE REPORT THIS LOG TO THE DEV - description:read attr - raw: FCE401000012040042044C554D49, dni: FCE4, endpoint: 01, cluster: 0000, size: 12, attrId: 0004, encoding: 42, command: 01, value: 044C554D49 | parseMap:[raw:FCE401000012040042044C554D49, dni:FCE4, endpoint:01, cluster:0000, size:12, attrId:0004, encoding:42, command:01, value:LUMI, clusterInt:0, attrInt:4]
sys:12024-06-15 17:23:44.075infoCreated Zigbee Device Zigbee - Aqara Wall Switch (w/ healthStatus)
I edited my previous post with a sample screenshot.
See also this example.
| Manufacturer: | LUMI |
|---|---|
| Endpoint 01 application: | 0B |
| Endpoint 01 endpointId: | 01 |
| Endpoint 01 idAsInt: | 1 |
| Endpoint 01 inClusters: | 0000,0002,0003,0004,0005,0006,0009 |
| Endpoint 01 initialized: | true |
| Endpoint 01 manufacturer: | LUMI |
| Endpoint 01 model: | lumi.switch.l1aeu1 |
| Endpoint 01 outClusters: | 000A,0019 |
| Endpoint 01 profileId: | 0104 |
| Endpoint 01 stage: | 4 |
Thanks!
I will add this device, but also the OP other model to the driver and will ping you when ready.
Thank you so much! Will keep eye on here, also will let know how it goes after you post modified driver!
Please first update the driver :
ver. 2.0.8 2024-06-15
I will ask you to remove the device again and pair it as a new one. This driver should be selected automatically again, but change temporarily to the 'Device' driver and let me know whether the 'Get Info' button works this time.
Getting info still working its magic. Other info ei got from logs:
dev:1042024-06-15 18:32:41.190debuggetting info for unknown Zigbee device...
dev:1042024-06-15 18:31:54.019infoNo VALID lastCheckin event available! This should be resolved by itself within 1 or 2 hours and is perfectly NORMAL as long as the same device don't get this multiple times per day...
dev:1042024-06-15 18:31:49.615infoPower Cluster 0006 catchall - description:catchall: 0104 0006 01 01 0040 00 C3BA 00 00 0000 07 01 00 | parseMap:[raw:catchall: 0104 0006 01 01 0040 00 C3BA 00 00 0000 07 01 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:C3BA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00]]
dev:1042024-06-15 18:31:48.647infoOn/Off Button press - description:read attr - raw: C3BA0100060A00001000, dni: C3BA, endpoint: 01, cluster: 0006, size: 0A, attrId: 0000, encoding: 10, command: 01, value: 00 | parseMap:[raw:C3BA0100060A00001000, dni:C3BA, endpoint:01, cluster:0006, size:0A, attrId:0000, encoding:10, command:01, value:00, clusterInt:6, attrInt:0, valueParsed:false]
dev:1042024-06-15 18:31:47.758infosetAsConnected(button=1)
dev:1042024-06-15 18:31:47.708infoMaking device with type 1 virtual switch and id 104-1
dev:1042024-06-15 18:31:47.698infosetAsConnected(button=2)
dev:1042024-06-15 18:31:47.628infoMaking device with type 1 virtual switch and id 104-2
dev:1042024-06-15 18:31:47.590infoNo VALID lastCheckin event available! This should be resolved by itself within 1 or 2 hours and is perfectly NORMAL as long as the same device don't get this multiple times per day...
dev:1042024-06-15 18:31:47.512infoRecovery feature ENABLED
dev:1042024-06-15 18:31:47.451infogetDriverVersion() = 2.0.8 2024/06/15 6:04 PM
Download the Hubitat app
