I've run across threads discussing reversing the interpretation of a contact sensor but I don't think I've seen an explicit request to add that as an option in the built-in drivers. I believe there are some Custom Drivers that allow this.
I can't be the only one that's ever ended up with a magnet/sensor mounting configuration (or remote wiring of a secondary contact) that reports OPEN (as it should per the electronics) when in actuality the physical door/window/hatch/pressure-sw is CLOSED due to the way the contact is being used.
To date I handle the logic within the rule...but yeah, it's confusing when someone looks at the Device's page. I can live with this if it really is a "one off" use case....but I can't believe other's haven't ended up wishing they could flip the interpretation of the state.
Having gone down the Mirroring path suggested ...I gotta say I'm still wishing I could of just changed the state interpretation of Open to Closed, and Closed to Open right in the Driver.
It's would offer less complexity & confusion when you start using this flipped state everywhere.
So I hope it's doable and on your long term To Do List.
Yeah, even using the Mirror App I'm going through correcting some mistaken misinterpretations with a new rule I had just set up yesterday that isn't behaving as it should this evening.
I'm refreshing this topic in case I'm not the only one wishing this capability was right there on a built-in standard driver's settings page.
I guess we could build a list of which drivers this was most often a desire on...mine is pretty specifically CONTACTs but I'm sure there are others where it's not just OPEN vs CLOSED reporting that somebody needs to flip based on their use case.
I hear yah, but...it's really not specific to this: Visonic MCT-370 SMA
as it is a Use Case that is opposite to normal use which is common for a lot of situations people find themselves in. The case can be as simple as having limited locations for placement of a sensor that you need to reach the battery in, vs the magnet.
Yes, all of this can be reversed in RM whereby you say "if it says OPEN it's really CLOSED" and act or communicate accordingly. But I think the thread above confirms that folks have a need to swap the interpretation right in the driver.
I know above Mike suggested using the "Mirror Instance". I'm just back here testing if his "For now" meant maybe he's in for making this an Easy Button Feature of his generic drivers that would benefit from this.
A long aside explaining a broader mindset about core use of "Custom Stuff":
This contact device works perfect with the built-in generic Zigbee driver.
And I'll be honest, with a desire to keep up with the upgrades to the HE platform I have an in-built resistance to having Custom/Community solutions be apart of every stinking part of how I accomplish things.
Not that there isn't stuff contributed that is down right stellar, because there is indeed
....It's more that little nagging voice in the back of my head that's going: "but what if that guy/gal moves on and nobody picks this up",,,,and after some upgrade in the future breaks something and you don't remember what all non-built-ins to look at as the cause. I really disdain having to go back and lift-the-hood and dig into stuff after I've got it working. I'm resisting calling this my hobby despite what others think seeing this up on my laptop constantly
This one little feature in the generic driver would make things cleaner/easier....it's not the kind of thing where I'm prone to go "oh, I'll use that Custom xyz" that guy/gal wrote to address". That's kinda why I've not gone down the Mirror Instance path as it's just another layering I gotta remember is involved later on. I guess I'd rather keep noting the translation of: O=C and C=O where ever I need it.
I DO buy into Custom stuff for bigger things that are just too nice (and widely used/supported) to not use along with the rest of the Community.
Can you just find a community driver that works for your contact sensor, download it, then open it and do a Save As with a revised name, then switch the open and closed. Then you can assign that driver to the contact sensor where you want to swich open/closed and it does not impact any other devices.
@PunchCardPgmr - I also have a Zigbee contact sensor on my mailbox, and it also ends up with reversed logic. It would be a nice feature to have a user preference to reverse the default open/closed logic.
That would be ideal, however I have looked and have never found a nice, clean Generic Zigbee Contact Sensor community driver. If you find one, let me know please!
Yeah I was good with having kludged the reverse logic until the other day in my particular Use Case i had one of the two doors dependent on each other fail (well actually the power to the actuator failed). One door is Open when the contact is open, the other with a different contact is reversed.
Revisiting the Rules that manage this dance I was cussing how complicated I had made understanding what was going on simply because I had to interpret the Open really being Closed, and the Closed really being Opened.
Thanks. I did take a look at @kkossev's contact sensor driver. It is actually quite a complex driver, compared to what I am used to. I'd prefer a much smaller, lighter-weight piece of code as a starting point.
I did find an old ST Groovy contact sensor driver that I might use as a starting point for a custom driver. Now I just need to find some time!
