So I have a bunch of WADWAZ contact switches and it has always annoyed me that I could not use the external sensor on them readily with the generic driver. So... I am now providing the first public iteration of a driver I have written for it.
Major features (at present) are:
State variables for both the internal and external contact switch
Provides tamper notification and tamper can be reset
Can select in preferences how the Hubitat contact capability will be triggered by one of multiple methods:
Internal Contact - Will only provide events for the internal switch but will update the external switch attribute
External Contact - Will only provide events for the external switch but will update the internal switch attribute
Either Open / Both Closed - Will provide an open event if EITHER switch is open but will only trigger closed event if BOTH are closed
Either Closed / Both Open - Will provide a closed event if EITHER switch is closed but will only trigger open event if BOTH are open
@adamkempenich: I have them reporting in state variables separately, but did not see anything in Hubitat's capabilities listing that indicated you can send an event for anything more than "contact" with "open" or "closed". If there is another way for that I definitely need to look into it, going to check now. Thanks!
Ah... I see now, you have them acting as child devices so it is treating each switch as a separate child. Something for me to look into... although I have not dealt with any child devices yet (or even looked at the whole child/parent thing). Although it does not feel like I have already been here 3 months...
Another difference I see is that the WADWAZ reports both internal and external in the Alarm report as Type 0x07(s) as well as reporting the internal in the Basic report as well. But all that could be worked around easy enough I think. Maybe something for future revisions if people want it.
Hey, me again. I've got a dozen or so of these sensors and two of them have external switches connected. The external switches worked fine in SmartThings but I've tried every HE driver I can find and none show the state of the external switch. I'm trying your driver because it seems to be the most recent but I cannot see the state of the external switch even though it shows as a state. I've tried toggling to switch but it does not reflect the changes. Is there something specific to HE that I might be missing here? Thanks.
If they reported on ST... they should report in Hubitat. My biggest problem was newer models do not enable the external port and my attempts at sending the parameter to enable it (at least what I found online that SAID it should enable it) did not work. Of course, I have not really done much with it since.
So that being said, I want to get this working for you. Looking at the driver... Yeesh... I have not even updated it to some of my newer "standards". If you do not mind, I should have a new version posted soon. It probably will not solve the problem but should enable more logging (if the current one lacks it) to be able to see if the Hubitat actually SEES anything more from the WADWAZ. Then we can go from there.
If you can upgrade to the newest version I am going to write up in a second, then set the logging to Trace and send me copies of what shows up when you open/close both the internal and external contacts, I can make the changes needed. Trying to get one of my old ones working as well.
Changed to new SEMVER standard of versioning control.
Changed to my newer style of checking for new driver versions.
Changed to my newer style of logging and updated/added some logging in the driver.
Found 2 new alarm types being reported and now handling those properly for the internal sensor.
Updated the fingerprint based on what my device just responded with when paired this morning. Maybe that will make it so this driver gets detected rather than "Generic Z-Wave Contact".
Known Issue(s):
Going to restart my work on creating a command to enable the external contact if it is disabled (like many come out of manufacturing).
I must have an issue with the other sensor because with this one it appears your driver works. I can choose which switch will update the contact attribute but it does not appear that the InternalContact and ExternalContact attributes are updated or usable in webCoRE.
Ok, that is a start at least. I think WebCore wants them to be "Events" but I am not posting the ExternalContact/InternalContact values directly, just relying on them making the overall "contact" based on what the preference is.
I will make this edit, as I am revising the driver right now. Should have a new version posted soon.
I have a dozen of these and will give your driver a test on a few of them. For me, the HE generic driver is generating message storms and will randomly slow down my mesh. I found another driver ported from Smartthings that stopped the message storms (and slow downs) but I'm not sure battery is being reported. I'm not seeing battery events in the event logs where I did see them with the generic driver. I am seeing "check-ins" every 4 hours so maybe they are included with the check-in.
As for battery reporting in general, I've been using a majority of these sensors since 2015 and they still say 100%. I'm not sure battery reporting is accurate anyway.
Internal/ExternalContact is now reported as an event so that they can be used directly without just relying on the contact event.
Now attempts to allow enabling/disabling the external contact when you save your preferences. NOT SURE IF THIS WORKS. It does appear to send the parameter (do not forget you need to wake up your device to receive the command, usually by tapping the tamper button or sometimes opening/closing the internal contact). BUT... on my sample device it does not report any external contact activity even though the correct parameter appears to be set. Going to see if I have a bad reed switch somehow...
Removed the refresh and configure commands as they were not doing much of use anyways.
For the battery, I have always had trouble with that on mine. Trying to figure out if a battery is good, bad, or somewhere in between has never really appeared to work. They always seem to be 100% or not responding and no activity... I wonder if these report it more as a "Good" type of battery status, like a lot of simple sensors do.
I have a few of these but they are mostly firmly attached and tough for me to play with much (especially in winter, opening windows will get me in trouble). I have 1 that is meant for testing, but it is being a pain (as I mentioned in the update I just posted). Way back when I was last working on it, the older versions all seemed to have the external contact enabled by default. Newer ones have it disabled... annoying.
I'm sure I've had to replace some batteries but with so many battery operated devices and having moved all of them from the house in Michigan to the one in Florida, I really can't remember. I was on ST until April this year so there is that conversion too.
Anyway. I'm using this app to monitor my battery devices and if one falls off, I'll know within a couple days. These devices report on a regular basis so I'll know within 24 hours if one has failed so battery is not a big deal.
My WADWAZ are pretty easy to get to so if I get some time, I'll hook up a couple wires to one and see how the external contact is working. Being in the sunshine state, though it's cool and rainy right now, I can open windows and doors without dropping the WAF.
Florida does have that benefit although I could not survive the heat and humidity.
I put a couple wires to the external contact of my test one... and there was zero activity there at all. Wonder if some are just bad. Going to have to get one of my others swapped over to my development Hubitat to play more.
I have some stuff set up for monitoring battery devices like this. I just wish they all actually reported some actual value besides "good" or "low" in some cases. %, voltage, expected days remaining, expected "whatever they do" remaining... Something a bit more granular.
I am OK with whatever to be honest for the battery. If a device provides voltage, I make my driver say that but then I convert it to the % battery that the Hubitat capability needs. In the long run as long as a user knows that a battery needs replacing before it stops functioning AND can have faith they are not replacing it when it still has lots of life, that is the minimum. If they can get some idea about I need X time/presses/snapshots (whatever) that is even better.
I wrote a piston that converts CR123A battery percentage to voltage. Obviously, you can't use it with the GoControl sensors but it works great for most battery powered devices that use CR123A batteries. It's really convenient to open webCoRE and see the battery voltage right there in the piston state.
I have no idea about webCore or Pistons to be honest. I have not gotten a request to "reverse" the method from % to voltage on any of my drivers but it is a good thought for anyone that needs it in the future.
It could work with basically any battery. Just might want to put a "rated voltage" variable or such that people could set. That is similar to how I convert voltage to % for the couple times I have done it, well, not given them the option, but built in the that target voltage as applicable for the sensor at hand.
Yeah, I don't know how much webCoRE is used with HE since Rule Machine exists but it was pretty popular with SmartThings users. The rumor that SmartThings is going to do away with it is one of the main reasons I switched to Hubitat.
I'd love to learn how to write drivers some day. Mainly because the Wi-Fi temperature probe that I use for smoking has an API and it would be nice to incorporate some of that info into some of my automations. I managed to figure out how to poll the API for device attributes but then I lost interest and got distracted with other projects. I might give it another shot after the holidays.
It has not been bad. I had ZERO knowledge of Groovy and only limited recent experience writing stuff for Particle Photons (arduino-esque code). Not saying I am really any good, but I now have a fair number of drivers most of them API related.
That said, if you want me to take a look at a driver for that temperature probe's API, just let me know. I much prefer ones that are local to a network and not using a company cloud server or such but I have made a lot of those also.
Should have a new version posted soon.
