I'm nearly done writing my first driver - a virtual contact sensor with switch, but changes to the switch are ignored. Use case: to show the status of something in HomeKit/Home app but prevent an accidental toggle of the switch from actually changing the state of anything.
Anyway, a question: if a contact sensor is open, do you interpret that as a switch that is on or off? The driver has a preference to reverse the interpretation, but what would you consider the default behavior?
Poll:
A) Contact open == Switch on
OR
B) Contact open == Switch off
I consider a contact that is closed to be off, and a contact that is open to be on. The door or window is "active" or "on" when open, as the "default state" is closed, or off.
Similarly, with a motion sensor active is on, and inactive is off, as the default state is inactive.
Other drivers out there that do this, like the Virtual Switch uDTH Lite driver, closes the contact sensor when the switch turns off.
+1 both directions. I wrote a plug driver and gave it the ability to be 'reversed' I called it. Comes in handy! I generally go with 'off = 0 on = 1' so contact closed = off, open = on.
Thank you, everyone, for your replies. I appreciate the various reasons and technical explanations behind your choice. Learned a few things and reminded me of a few other forgotten things along the way.
I re-visited why I decided to write this driver - to show the open/closed status of a contact. Home displays an open contact, and hides a closed one. So I decided that the default will be like a door or window - contact sensor open = switch on. At a glance, I can quickly see what is left open, in the same way I can quickly see which lights have been left on before going to bed - they will be white buttons that stand out.
I had already written in a isReversed preference, so for anyone using it for purposes other than as a hack for Home, it's easy to flip. There is also code to immediately re-evaluate on/off when the preference is saved, in case it was flipped.
Decided to add an additional preference to ignore switch events (default, as per initial driver intent), or to act like a normal virtual switch driver. The switch went from "ignored" to "ignorable".
Then decided to add motion sensor in the same way as contact sensor. Am considering biting off more than I can chew -- making an app that auto creates all of these virtual devices and links them to the real physical devices, eliminating the need to create the virtual device and the rule to mirror the the physical device.
Hats off to you for considering the options, and an optional selection.
It is not unusual at all to employ a contact sensor in a manner or position that ends up where you'd like the opposite state reported from what the device would normally report.
For your driver to not require the user to go through an external translation step to interpret and report the device's status differently than it would be "off the shelf" is helpful.
Am considering biting off more than I can chew -- making an app that auto creates all of these virtual devices and links them to the real physical devices, eliminating the need to create the virtual device and the rule to mirror the the physical device.
