I’m having trouble visualizing how that would work. I’m more of a visual learner so I would need to be able to play with it to know for sure.
But if I’m the only one looking for something like this, it’s not necessary to create something special for me.
The contact sensor solution works and is where I figured this was going; I was just curious if someone had a solution that would work better.
Right now the door is reading open/closed from a ring contact sensor using Alexa and then obviously what I’m trying to accomplish with locked/unlocked using the Yale lock.
The ability to get both ends of that into one virtual device most certainly is intriguing.
And for those who don’t know, Amazon added the ability about a year ago to trigger Alexa routines from a lock as well as a sensor, so you don’t need the lock to present as a Sensor in order to trigger an Alexa routine. 
This allows you to have a door lock with a built-in contact sensor so it can indeed be closed and unlocked or open and locked as well as the expected states when used as a routine trigger.
You may not want to use it as a lock for a routine target, though, because then it will require a pin code to unlock. 
Hi! I am doing a simple dumb integration with my Twinkly christmas tree lights through Node-red and I was wondering if there is any interest in adding a virtual RGBW light to this project. I’ve been using a virtual dimmer so far but it shows as a switch and I’d like to have a light icon + the ability to control the color. I couldn’t find a repo for this project but I am willing to spend some time in an MR for this functionality if that is what it takes 
Sounds simple enough; I’ll add this plus the earlier request for a virtual door device and have a driver update in a couple days.
The next update also needs to include a fix for something that a recent SmartThings update broke: any Edge driver with an integer preferences setting without a max value defined in the device profile will no longer let you modify the settings value. Max values are supposed to be optional….
This driver and the multi-device version of the Web Requestor have made it possible for me to eliminate all my custom DTHs bar the one used for the Sonoff Button, and a patch to the Ikea button driver has recently been requested for that. So thanks for that.
Something I could do with is a virtual device with the battery capability, ideally in tandem with the powerSource capability.
The use case is to allow phone and tablets to communicate their battery status and whether they on on charge. I don’t understand why the mobile apps aren’t already doing this. Why only be a Presence Sensor when there are other things they could also be?
How do you envision setting those capability attributes in the virtual device? I haven’t experimented with those, but they look like output attributes only; no commands. So we’d have to come up with some mechanism to set the values. I would think only from an automation and not the app?
Indeed they are, however so are contactSensor, motionSensor, waterSensor, presenceSensor, temperatureMeasurememt and airQualityIndicator, to name just a few.
That doesn’t seem unreasonable, at least not for my use case. Indeed for my use case even an automation presentation is largely irrelevant.
As battery uses a percentage there is always the option to abuse switchLevel to avoid a custom capability.
@DJFliX Follow-up on your request for a color light virtual device. I found one unexpected thing I wanted to make sure would still work for your use-case: I found that with the standard colorControl capability, that you cannot, from an IF part of an automation, query the current color (hue & saturation). However you can, from a THEN part of an automation, set the color (hue & saturation). Is this going to be alright for what you need? I know you said you needed the ability to control the color, but wanted to make sure you weren’t planning to try and trigger anything based on the color…
@TAustin That would be perfect! I can’t think of a use case for using it in the ‘if’ part to be honest.
Updated Driver has been pushed out:
This update includes 3 new virtual devices as follows:
Door
@sdaltons, @milandjurovic71
This device includes both a contact and a lock, with switches to control each independently. A device Setting option can be used to force synchronization between the contact & lock:
Default setting is NOT to synchronize.
A second Settings option allows the selection of either lock or contact for the dashboard icon.
Light
@DJFliX
Includes stock capabilities for switch, color, color temperature, and dimmer.
Battery
@orangebucket
Includes stock capabilities for battery and power source, as well as controls to set each.
Driver Upgrading Notes
The driver will be automatically updated to your hub as usual. All existing virtual devices will continue to operate as-is under the updated driver.
Possible issues you may experience:
I don’t see the new device types listed in the create list
If you’ve waited patiently for the update to your hub, but the battery, door, & light devices are not available to select from the create-device button, then you may need to force a re-creation of your creator device. Do this by deleting the creator device (not your virtual devices!), and then get it re-created with an Add device / Scan nearby. The new device will be named ‘vEdge Creator V2.3’, and you should now see the new virtual device types to create.
The driver update seems to have broken things; my virtual devices have stopped responding
Occasionally there are Edge problems installing updated drivers that may result in a hang of the driver and its devices. If you think this may have happened to you, then rebooting the hub will usually fix it.
@TAustin You, sir, are an absolute legend! Thank you very much for adding the Light device. It seems to work exactly as I had expected so the only thing to do now is fix my functions in Node-red.
Thanks for that. I may have been a bit quick off the mark as I’ve had to delete and reinstall the driver on both my hubs to prevent a generic network error thing when trying to create a new device. The driver information shown for the creator device was the same before and after reinstall.
Working great thanks. Gives me something to monitor my mobile device battery and charging state with.
Thank you for this!
I’m having trouble getting it setup, but it might just be that I’m misunderstanding.
I have the device created in ST and alexa sees it. I was going to do the routines for the contact first.
So for the routine…
When ring front door contact sensor is closed
…
As soon as I choose this new door device for the action step, it recognizes it as a lock and states “alexa will lock door device” with no option to choose any other action.
If I’m missing something obvious, go easy on me!
By mobile you mean phone? Could I use this to activate my morning routines when unpluging my phone? Now I use IFTTT to run that automation. 
You are right, Alexa is only seeing it as a lock and not a contact, even when you change it to a contact in SmartThings. Alexa seems to stick to the type of whatever the device was when it was initially created (which is lock). I may have to change the default type when created to a contact. Let me experiment and I’ll figure out a fix. My apologies. I know you wanted to have a lock icon on the SmartThings device even though Alexa may see it as a contact.
UPDATE: This may be bad news; it appears that as long as there is a lock capability defined within the device, then Alexa will treat it as a lock - even if I define the device as a contact type in the profile. I’ll continue to look at this; don’t know if anyone else may have a suggestion…
I’m honestly over the icon thing. If you could make one device that could: read if the door is open/closed, read if the lock is locked/unlocked, and lock the door, I would be very impressed.
And if it doesn’t work out, that’s no problem. I have a virtual contact sensor pulling the open/closed status and a separate virtual lock that can lock the door, but always shows as “locked” no matter what since alexa won’t “unlock” it. I can easily switch that last one to a contact sensor, which will cover everything I need, other than labeling the status as “locked/unlocked” rather than “open/closed.”
I actually am using sharptools for a lot of this and it may be possible to override the labels on that end (I haven’t played around with this).
All that is to say, I can get where I want to be using two devices, and I’m totally fine with that. But if you are enjoying the challenge, I’d love to see what you end up coming up with!
I’m contemplating changing the stock lock capability over to a custom capability that would have all the look and feel (commands/attributes/icon) of a lock, but it would be implemented as a custom capability in order to prevent Alexa from treating the device as a lock. That way you should be able to use the companion switch to control it from Alexa (on/off=locked/unlocked). The only potential downside is that within SmartThings, since it isn’t an ‘official’ lock, there may be some differences in the way it is treated. And you still may need an automation to synchronize the virtual lock state with your physical device.
What do you think of this approach?
Certainly intriguing. If you think it’ll work, I’m all for it.
Pass code might not be needed anymore