@markus I will look into using a virtual temp sensor. Good idea!
The below 50 is just for resetting the offset once it has first reached 70. Doesn’t matter if it’s 60, 50 or 40 really.
@markus I will look into using a virtual temp sensor. Good idea!
The below 50 is just for resetting the offset once it has first reached 70. Doesn’t matter if it’s 60, 50 or 40 really.
Temp and Humidity driver seems to be working good so far. I like the new options and layout in the device page.
Any plans to do other devices like the vibration sensor or magic cube?
@markus
You are a legend!!!!!
Thank you so much for releasing these drivers as I had sent a request via PM to veeceeoh and have not had a reply. I really do like your drivers as most of my devices are Sonoff's running tasmota and using your drivers.
What I wanted to ask was your Xiaomi/Aqara Motion Sensor and the Xiaomi/Aqara/Opple Button/Switch/Remote only has the checking time in the epoch format, would it be possible to have a "readable date" rather.
EDIT: Scrap that, I had to trigger them once and it all seems to be showing the checking time perfectly, once again, thanks for releasing these.
I'm very happy to see this was something many people wanted Thank you all for the kind words!
They're all three partially done, can't decide on how I want them to work yet. My Magic Cube driver will probably not be compatible with currently released Apps expecting the button order to be as the current driver, however. Not sure if that will cause problems?
As you later noticed, that is taken care of when the next event comes in What you saw was the epoch from the old driver. You can still get epoch in mine, but it is not on by default.
I wonder if you have an older model/firmware and they send events differently, what I see there with the btn: 0, btnModified: 0, endpoint: 1 is the held event (which is ignored), but without a release. Can you get me a screenshot of the Data section of the device?
They won't reset to 0, if the same button is pressed it registers as a new event, but it never goes back to 0.
EDIT: @Carl I just saw that the number of buttons is set to 5, that would indicate that what you have is the WXKG01LM model from Xiaomi, not WXKG11LM from Aqara? If that is the case, your device does not send messages the same way as mine. With the data section screenshot I can be more certain to how it really is.
Probably - but as long as your release notes include that information, it gives users all they need to fix their automations accordingly. So, any problems will be temporary .....
I'm looking forward to trying these out!
Any chance of getting a driver for the vibration sensor as well?
He said above they were partially done?
Great Thank you. the presence is genius. We USED TO have a last checkin date, but it got pulled from the firmware, apparently wasn't accurate.
I can't believe my xiaomi motion sensor is going on 16 months with original battery, in the kitchen !
but as long as your release notes include that information
I'll try to do it one better and add a setting to run it with the original order, as long as it doesn't clutter up the settings to much... I'll see what I can come up with.
We USED TO have a last checkin date, but it got pulled from the firmware, apparently wasn't accurate.
I wouldn't call this accurate either, bit it is enough to keep track of if the device is still alive or not
I can't believe my xiaomi motion sensor is going on 16 months with original battery, in the kitchen !
That is a very long time, do remember that when battery levels start to report a decline, it can go quickly for the voltage to fall.
Thanks - missed that!
Now post release, I do want to ask, the RSSI and LQI values are extracted by these drivers, but they as well as the parent device ID are not displayed. Would these be of interest? I chose to not show them because the values as they are sent make little sense.
Are these values "reliable", if so then yes maybe having the link quality would help, but if they are randomly changing for no reason then I think just having the present option is enough.
I agree with @greglsh, if reliable these would be good to know.
Also I assume if the device was to become 'unresponsive' would it hold the last known values? If so, this may show up something that caused the device to drop.
Also I must add, great job on these drivers.
Do you have a donation page?
Yes, I agree as well, If reliable then they can be a great help in troubleshooting!
Are these values "reliable", if so then yes maybe having the link quality would help, but if they are randomly changing for no reason then I think just having the present option is enough.
if reliable these would be good to know.
If reliable then they can be a great help in troubleshooting!
That's the thing, they don't really correspond to what I see with my Xbee. I'll look at it some more, maybe the values need some converting.
Also I must add, great job on these drivers.
Thanks
Do you have a donation page?
I do not, not yet anyway. Haven't really given it much though.
Here it actually states WXKG11LM and Aqara.
Ok, then it is clear, I will sort it out. This is plenty clear information.
a bit messed up though:
Yes, some Aqara devices include extra, non-standard, information after the actual model name. My driver cleans that, but can get the cleaning wrong sometimes it looks like. It should have been cleaned to "lumi.sensor_switch.aq2" and not "lumi.sensor_switch". Once I have updated the driver a quick click on the reset button will set the model name correctly.
So something interesting. I have six Tradfri USB Signal Repeaters on my Xiaomi/Aqara Hubitat. And I routinely check them using getRouteTable(). For the last ~8 months, 4 of these had lots of entries in the route table, while the other two had basically empty route tables. This was consistent with the possibility that once Aqara devices pick a zigbee router, they stick to that router.
Today, the route table for all six have lots of entries. Do your drivers "encourage" Aqara devices to not stick to a single zigbee router? If true, this would make them much more stable - because it lets them use different routes to communicate with the coordinator.
So something interesting.
Yes, isn't it interesting Fun you noticed
Do your drivers "encourage" Aqara devices to not stick to a single zigbee router? If true, this would make them much more stable - because it lets them use different routes to communicate with the coordinator.
Yes, indirectly, my driver sends commands back to all devices when they check in, plus some other commands for some devices that have those commands sent to them by the Aqara hub. It is part of what makes things "snappier" and to keep them online.
Yes, indirectly, my driver sends commands back to all devices when they check in, plus some other commands for some devices that have those commands sent to them by the Aqara hub. It is part of what makes things "snappier" and to keep them online.
Once again, my hats off to you. Very nice job!
Excellent. Thank you. I've just switched my temp/humidity driver. It's been stable, but does have a tendency to fall off the network when the battery approaches 50%. I'll offer results in as we eventually get back to that level. It's at 85% right now.
I have the 6 button Opple on my Aqara hub, so I'll give that another shot on HE today. My first 3am pairing experience with that was an eyeopener when I triggered my alarm setup at the time.
but does have a tendency to fall off the network when the battery approaches 50%.
At 50% chances are you have reached the point where voltage will drop very fast. Not sure if it is worth the effort, but maybe it would be worth adding a filter to take into account the actual voltage curve for the battery type. Another day maybe. At least now you will know within 3 hours of this happening.
My first 3am pairing experience with that was an eyeopener when I triggered my alarm setup at the time.
Stay away from button 1 and 2 (those with the LED) during paring and you should be fine. Once the log reports that the pairing and configuration is done, then they are safe again
This is something I'd like have to be un-read for a while, because now I want ALL my Xiaomi/Aqara devices to use your drivers!
They're coming, I want to get them right and not have to make "breaking" changes after release. Basically the only devices I don't own myself of Aqaras Zigbee devices are the blinds, the B1 curtain (but that one I have driver for anyway) and the old wall switch models (I've bought the new D1 model, couldn't get the older models) . I'll probably sort them all out in the end.
Your WXKG11LM model is the one from 2015, I don't have one of those, so I had missed something regarding that one. It will be added soon.
This... and your excellent work with Tasmota devices have really made a great contribution to the Hubitat platform.
Happy to hear that Always nice to hear when people have a use for the code I've written.
Actually it might even lure over some of the most faithful users of Home Assistant that praise the local device control, but still are missing the convenience of using hub with a solid backbone like "our precious"!
Let's see, maybe that brings over some more devs that can create some more fun stuff.
Not to mention the tremendous work by @thomas.c.howard and the HubiGraphs, that I actually never ever thought would be possible.
Yes, that is a nice creation, the first real use we have for the event history!