Here's the log with the updated driver installed:
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.
Updated Version(s):
Change(s):
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.
Others disagree with me but I would LOVE to see voltage instead of percent.
We are taking the grandkids to look at lights tonight but maybe tomorrow I can hook up the external contacts. My switches are all circa 2015 or so.
I bought a lot of the GoControl kits when they were getting blown out the door for cheap. These things are big but they have been great devices.
No worries, whenever it is convenient.
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.
If you really want to take a look you're more than welcome to. I can message you the API info. If you get something working I would gladly send you a donation
I finally had a chance to pull the sensor off of my screen door and bench test it with your driver this morning. The driver works as expected with the external contact. You can use either the internal or external contact independently, or you can use both contacts in tandem. Nice work. I did nothing special to "turn on" the external contact and have never used it on this device before. This could be one of my older sensors from 2015.
Not sure if battery reporting is working as I don't have a spent battery to test with.
I'm going to change all 15 of my old zwave goControl sensors to your driver and see how it works. The HE generic driver was causing a lot of message storms and the occasional zwave slowdowns. The ported ST driver in currently using stopped the storms and slowdowns so I'll be curious to see how you're driver performs on all the sensors. If it works, I'll post an update after the holidays. If it doesn't, I'll be updating much sooner.
UPDATE:
I didn't catch it until I started changing all of my sensors but I just realized your driver does not have a configure button to press after changing to it. I updated preferences immediately after selecting the driver so I don't think it's an issue but most drivers I've used on HE have a configure button to send updated parameters to the device. I don't create drivers and only write VERY SIMPLE groovy apps so maybe the button isn't needed. I don't know.
Thanks! Always good to hear that something works properly. When I first got my internal & external contacts working I thought it might be nice to let people decide how the "contact" that Hubitat sees gets reported. Being able to base it on either (or both) has worked out. I put one of these on my network rack-case, with the internal on the front door and a series of switches on the 3 side panels that can be removed going to the external contact. Now it shows if anything is open but will not show it as closed until everything is buttoned up again.
I actually removed the configure capability (well, commented it out) because it was only calling "updated" anyways, which happens when you Save Preferences. I thought there was not much point in having a command that added no value.
My older WADWAZ work just fine for the external contact. It seems to be weird with newer ones. If you do not mind my asking, can you provide the model number from the back of the device (if it is visible). Just want to see if there are different models that implemented it differently.
That's what I did because there wasn't a configure button and I wasn't using the external contact. From what I've seen, most people are "programmed" to press that configure button and it is the first thing that they are told to do when asking for help with a driver. Just a suggestion, you might want to consider putting it back for continuity with other drivers.
I will think on it. Most of my other drivers do not have it either but they are mostly dealing with "virtual" devices or if I can find a reason to put it back. I hate having commands or such that GNDN (Goes Nowhere Does Nothing) or really lack any relevance.
Updated Version:
Change(s):
Not sure if you're still working on anything for this, but I've been using the GoControl Contact Sensor driver from michaelahess. I can't post a link, but it's very easy to find with a quick google search. It has all the features, but it gives me a MissingMethodException with each update. I'm going to try your driver. I just thought I would share in case it is helpful for you...
Download the Hubitat app
