Thanks for adding built in drivers for the Aqara devices. Previously I was using Markus' Oh-La Labs drivers and they were great, but apparently create chaos with Hub Mesh. So I switched to the built-in drivers. They have been working great so far, but I am missing a couple items I was wondering if you might be able to add.
1st one is the most important request: ability to reset the state of the Aqara Zigbee Contact Sensor to open or closed by command. I have several rules built around that feature to automatically reset the contact position to closed if the door was intentionally left open to stop notifications.
2nd is more just kinda cause I want it... But could you allow 1 decimal place behind the zero for the humidity readings on the Aqara Zigbee Weather Sensor driver? The previous driver I had allowed up to 2 decimals which I feel is unnecessary, but one decimal place would be super cool. It will make my graphs look a lot less jaggy
While writing a rule to get around this using either global variables or a virtual device is definitely possible and not all that difficult, that would utilize significantly more resources than a simple command to set the position. It also helps when debugging automations as I don't have to be at the physical location of the door to test an automation using that uses the door's sensor.
I totally understand your point - the driver should ideally mimmick the actual sensor during normal operation, 99% of the time. But there are circumstances when the reset option is simply better and easier, and I would like that option to be included if the devs at Hubitat are willing.
I am going to have to disagree on this request as well. No other Hubitat built-in driver provides commands to alter the current state of the sensor to be different from the physical device. Virtual drivers, yes. Physical device drivers, no.
Look guys, I did not really ask for opinions. I was requesting a feature, and not a single person who has responded yet is part of Hubitat's development, so please just keep opinions to yourselves and let Hubitat reply. Quit derailing my topic.
So here's the thing with posting a feature request on a community forum. Anyone can comment on it; and opinions won't necessarily concur with yours. You always have the choice of sending a PM if you only wish for one person to see it.
Posting an opinion about a feature request doesn’t seem like it should have to derail a thread, even if it’s a contrary opinion to the one expressed by the OP.
Getting caught up in whether other community members have the “right” to post in response to a feature request, or the OP has the “right” to dictate who should respond, is much more likely to derail a thread.
Without getting into the debate of opinions as discussed above and going back to the original post, personally, I like the option of being able to set the state of a device. Whether it be a contact or motion sensor.
It aids in testing rules/pistons and also lets say a motion sensor gets stuck active for an hour, one can write a rule/piston to reset it to inactive after a set period of time to get it back to normal.
Just my personal opinion.
Perhaps to you, but you are by no means the only one who posted here. You don't own the topic, even when you start it.
From Hubitat staff: This is pretty much a horrible idea, and one we wouldn't support unless the device itself supports it. The whole point of a driver is to present the real world state of the device, not invent one to aid in 'debugging'. As others observed, if you want to debug an app that uses a sensor, temporarily replace the sensor with one you can directly control the states of.
