Hi @veeceeoh and thanks for you great work on the drivers.
Just an observation.
I notice that the date/time stamps are not being displayed in 'English' for the want of a better word.
Yes, originally I removed the "human readable" date/time stamps when I ported the ST device handlers to Hubitat device drivers because there was no mobile app for Hubitat. I left the Unix/Epoch-based date/time stamps for people using WebCoRE on their Hubitat, though. That string of numbers is simply the number of milliseconds since Epoch time (00:00:00 Thursday January 1 1970) for when that event took place.
Since then, the Dashboard feature was added, and people who love to see exactly when something has happened on every device starting asking for a custom date/time attribute to be put back in the driver.
However, other people, who hate having their events list cluttered or feel that it may be slowing down things, have asked for a way to disable the custom date/time attribute events altogether.
So, I am going through each of the drivers and adding these features. The one from your screenshot for the Motion Sensor has not yet been updated. I hope to get to it soon.
Thank you for your patience.
This was discussed earlier (around post #293). On the sendEvent( lines you can replace "value: now()" with "value: new Date().toLocaleString()" to get readable dates.
1 Like
I had to change this line:
if (!oldFirmware & valueHex != null & encoding > 0x18 & encoding < 0x3e) {
to this:
if (!oldFirmware && valueHex != null && encoding > 0x18 && encoding < 0x3e) {
Groovy uses a double ampersand '&&' for the 'AND' operation.
I have not seen any errors with that change. Is there any reason this will be a problem? (I am NOT a Groovy expert).
Thanks. Great work!
[UPDATE] This change is NOT necessary! I used the original code by @veeceeoh and it works great. The error I saw must have been caused by some fat-fingering of my own.
Why did you have to change that line? Was something not working?
Not from what I have read. Although & is a bitwise operator, when evaluating boolean expressions, both & and && act as logical AND operations as they do in Java:
Using && is a little more efficient because if any expression is false then evaluation of all the expressions stops there, and false is returned. In this case, the code is only executed once when a message is passed from the hub's parser, so efficiency isn't really a big concern.
What I am concerned about is that something isn't working despite all of my testing. Are you seeing errors?
As I said, I am not a groovy expert. I had used a pre-release version from your github that had '&' and I did get an error on that line. I honestly did not run the released version before I made the change to '&&'. I will run it as you had it when i get home and report back.
Ahhh, I think that would explain it. I made a copy-paste error that propagated into an earlier update of the code on GitHub which was subsequently fixed, all before I made the announcement last night.
I guess I didn't anticipate people watching over the GitHub repository for any updates.... 
Looks like I jumped the gun on my stalking. 
I changed the code back to single ampersands"&" and I do not see any errors. Your code looks great. I'll update my post above to make sure no one thinks that change is necessary.
Thank you!
1 Like
Thanks. Sorry to hassle you. Wasn't sure if it was something that was overlooked.
Do you have a PayPal donation link? I need to buy you a beer. 
1 Like
Seems to have broken the Model WXKG03LM (1 button) - 2018 Revision (lumi.remote.b186acn01)
Regards Pete
dev:7522019-02-14 06:11:34.076 pm errorgroovy.lang.MissingMethodException: No signature of method: static java.lang.Integer.parseInt() is applicable for argument types: (java.lang.String, java.lang.String, java.lang.Integer) values: [01, 01, 16] Possible solutions: parseInt(java.lang.String, int), parseInt(java.lang.String) on line 117 (parse)
dev:7522019-02-14 06:11:34.042 pm debugSingle Light Button by Bedroom 2: Message payload: 0001
dev:7522019-02-14 06:11:34.040 pm [debug]
(http://192.168.1.133/device/edit/752)Single Light Button by Bedroom 2: Parsing message: read attr - raw: 1B2A0100120A5500210100, dni: 1B2A, endpoint: 01, cluster: 0012, size: 0A, attrId: 0055, encoding: 21, command: 0A, value: 0100
dev:7522019-02-14 06:11:34.027 pm debugSingle Light Button by Bedroom 2: Data type of payload is little-endian; reversing byte order
To be honest, I have been reticent in accepting donations after seeing again and again how people decide they are entitled to service and support by donating to "hobbyist developers" (see the Echo Speaks thread over on the SmartThings Community for some great examples of how nasty people can get.)
However, personally, I only ever send donations to developers to show appreciation and support. So if that's the reason behind sending a small donation, then I would be happy to accept it. Please just know that my accepting a donation does not constitute any kind of contract or agreement for services or support now or in the future. I will promptly return a donation to anyone who asserts as much.
With that in mind, here's a PayPal link: 
Either way, thank you for your patience and support.
3 Likes
It most certainly is. You are putting a lot of work into this in your spare time. I'm not sure my other half would be happy with me spending my spare time developing stuff and also troubleshooting when people have issues.
Enjoy your beer or whatever your tipple may be. 
2 Likes
Nope unfortunately stil broken, and also breaks my double button, so the double button gives:-
2019-02-14 07:47:24.275 pm errorgroovy.lang.MissingMethodException: No signature of method: dev15501736381781508166688.$() is applicable for argument types: (dev15501736381781508166688$_parse16Message_closure7) values: [dev15501736381781508166688$_parse16Message_closure7@4b74c952] Possible solutions: is(java.lang.Object), run(), run(), any(), use([Ljava.lang.Object;), any(groovy.lang.Closure) on line 147 (parse)
And the single button:-
2019-02-14 07:51:25.571 pm errorgroovy.lang.MissingMethodException: No signature of method: dev15501736381781508166688.$() is applicable for argument types: (dev15501736381781508166688$_parse18Message_closure8) values: [dev15501736381781508166688$_parse18Message_closure8@3db8d398] Possible solutions: is(java.lang.Object), run(), run(), any(), use([Ljava.lang.Object;), any(groovy.lang.Closure) on line 161 (parse)
dev:7522019-02-14 07:51:25.545 pm debugSingle Light Button by Bedroom 2: Message payload: 0001
dev:7522019-02-14 07:51:25.542 pm debugSingle Light Button by Bedroom 2: Parsing message: read attr - raw: 1B2A0100120A5500210100, dni: 1B2A, endpoint: 01, cluster: 0012, size: 0A, attrId: 0055, encoding: 21, command: 0A, value: 0100
dev:7522019-02-14 07:51:25.538 pm debugSingle Light Button by Bedroom 2: Data type of payload is little-endian; reversing byte order
The double button is model lumi.sensor_86sw2Un
The single button is model lumi.remote.b186acn01
Regards Pete
I am very sorry about that. I will need to look at the code after work when I can do some proper testing with my own 2016 revision two-button lumi.sensor_86sw2Un.
If you're using those buttons on a regular basis, here's a link to the previously working v0.6b to use until I can figure out the issue: Aqara Wireless Smart Light Switch device driver v0.6b (OLD VERSION)
Many thanks, @bobbles!
And thank you to everyone else who sent donations. It is very much appreciated and encouraging!
@veeceeoh I have a couple of Aqara Door Sensors, in the model field this is what they show:
endpointId: 01
application:
model: lumi.sensor_magnet.aq2�B!�(!�!$ !��d
manufacturer:
Is this normal? They work fine just seemed like odd naming
Keith, not a problem, been in this industry too long not to keep backups 
very appreciative of all the time you spend helping us numpties out. Happy to test the code when you update it. Regards Pete
1 Like
Yes, it seems to be normal. I've seen that with my Aqara Door/Window Contact sensors and my Aqara Leak sensor.
As mentioned in my above linked post, I believe what happens is: during the pairing process the value telling the hub the length the model text string is missed somehow, so extra "garbage" characters are picked up as part of the model name.
In any of my drivers that check on the ZigBee model name to do certain things, I make sure it only confirms the model begins with the relevant characters, so for example:
if (zigbeeModel.startsWith("lumi.sensor_magnet.aq2")) ...
1 Like
Hello,
I installed a cube and I think is not working properly, not sure what is the problem, I can't get it detect anything, just shaking as button 1, here is the logs, first was a slide, then a face change:
I noticed when I paired the Cube it did not pick up the driver, paired as a device, so I proceeded to pair a second Cube and the same, paired as a device, so I got the fingerprint just in case. Any help will be greatly appreciated.
Edit: Restoring firmware 2.0.4 and selecting the disable for the compatibility fix I got working the face flip, slide, tab and shake, rotate is not working, I'm using the 36 button option. I have a hub exclusively for Xiaomi and Tradfri so I can help doing firmware upgrades and downgrades or changing/swapping drivers for testing and help the development of the drivers.
Manufacturer: Unknown Manufacturer
Product Name: Device
Model Number: lumi.sensor_cube.aqgl01
deviceTypeId: 109
more...
manufacturer:null
address64bit: deleted, sorry
address16bit: deleted, sorry
model:lumi.sensor_cube.aqgl01
basicAttributesInitialized:true
application:null
endpoints.01.manufacturer:null
endpoints.01.idAsInt:1
endpoints.01.inClusters:0000,0003,0019,0012
endpoints.01.endpointId:01
endpoints.01.profileId:0104
endpoints.01.application:null
endpoints.01.outClusters:0000,0004,0003,0005,0019,0012
endpoints.01.initialized:true
endpoints.01.model:lumi.sensor_cube.aqgl01
endpoints.01.stage:4
endpoints.02.manufacturer:null
endpoints.02.idAsInt:2
endpoints.02.inClusters:0003,0012
endpoints.02.endpointId:02
endpoints.02.profileId:0104
endpoints.02.application:null
endpoints.02.outClusters:0004,0003,0005,0012
endpoints.02.initialized:true
endpoints.02.model:null
endpoints.02.stage:4
endpoints.03.manufacturer:null
endpoints.03.idAsInt:3
endpoints.03.inClusters:0003,000C
endpoints.03.endpointId:03
endpoints.03.profileId:0104
endpoints.03.application:null
endpoints.03.outClusters:0004,0003,0005,000C
endpoints.03.initialized:true
endpoints.03.model:null
endpoints.03.stage:4
Right rotation
Left rotation
To be honest, I did not test the compatibility fix with the Cube beta driver because after successfully testing just about every other driver, in "theory" it should have just worked with the one for the Cube as well. Apparently, it's not.
I'm sorry to say that the Cube driver has received the least amount of attention, so I think now is a good time to look at getting it working correctly. However...
I haven't mentioned this before, but right at the same time I found out about the change with raw ZigBee message data in Hubitat update 2.0.5, I also learned changes the next SmartThings firmware update will result in broken functionality for a number of Xiaomi / Aqara button devices, as well as open up functionality that was previously unavailable.
So I have a really big pile of code changes and updates to work through.
Thanks for the offer! I think the log output you've already shared here is quite helpful, but I will let you know if it would help to see log output from the driver running in FW 2.0.4. I have a Cube and plan to focus on making sure the driver works in FW 2.0.5 for future compatibility.
1 Like
