Happened again this morning … this time with a single “on” command from Alexa. As you can see in the history, the switch turned on, then off (as expected), then without any additional (programmed) “push” reverted to on and stayed there until I was able to reset it about 15 minutes later. .
Thanks again for the data. Is there any chance that this erroneous change was caused by an automation?
If you create another device without any automations, can you reproduce it ?
That particular device is used in only one Alexa routine, and turning it on triggers a single ST routine. As I have multiple Alexa devices, I checked and confirmed that no other Alexa devices issued a command to that virtual device at that time. I also checked for activity by any other device using your driver around that time and found none.
Boy, I really miss being able to see the source of events.
I have a test button created using your driver that is not connected to any automations. I’ve only seen that one turn on in one of two circumstances, the first being the multiple-press sequence on the device page that I described earlier. (I have a CLI driver:logcat of this if you haven’t been able to reproduce this yet).
The second happened quite by accident and with rather hysterical results. This morning, in an effort to put a temporary band-aid on this, I created a rule that would send an ‘off’ command to all of my virtual buttons if any of them were found to stuck open for more than one minute. (Okay, I was in a hurry and a bit lazy, and I figured the shotgun approach would be quicker to write.) When I tested the rule, however, sending the ‘off’ command to all those devices resulted in every single one of them turning ‘on’ and getting stuck ‘on.’ Even worse, every routine linked to those buttons ran at once. It was quite the unintentional show of electronic fireworks.
I’m baffled. Until the event in my previous post, I was convinced this was the result of multiple commands somehow hitting the device or driver at once. But I can’t find anything like that for the latest event. And while this problem is rare—to my knowledge @Jake_Mohl is the only other person reported the issue—when it happens it’s a problem. I’m not sure where to go from here.
That must have been a wild scene! 
Thanks for all the input; I’m going to look at the possibility of multiple timers causing this, but it’s just a guess at this point. We’ll figure it out one way or another; I don’t want this to be unreliable.
Do you have a hub?
Are you logged into the correct Samsung account which contains your hub?
Ok, understand…
I dont have a samsung hub, just a MOES Hub… thats the issue.
Thanks for the great work on this driver.
I don’t know if it’s possible but i could really use a virtual contact that could be set to automatically turn on in a periodic fashion. For example every 15 minutes. It would be nice if it contained a level setting to specify the interval that could be written to programmatically along with a way to stop and start it. This would really help my ability to create a random light on/off show when the house is empty.
If anyone has an idea of another way to create this type of periodic signal, that would be appreciated also.
I still love the driver even if you can’t do this. It has saved a ton of work converting from WebCore. Thank you!
I would do that with a SharpTools rule, putting whatever you want to occur within a loop that would repeat on whatever interval you specify.
@David_Swope @Mariano_Colmenarejo has a Virtual Appliance driver that you can create random lighting automations with that may be of interest.
Here’s a link to my post with an example of the rule. (The routine does work, I had something else that was disabling it)
Some good solutions already mentioned, but if those don’t meet your needs, let me know. I have a counter utility driver that could potentially be expanded to provide the features you’re looking for.
You can do that with a routine. If device has been off for x minutes then turn device on (then turn device off in x minutes). You can use preconditions to only do this during certain modes or at specific times. I use it to cycle a heater only when the temperature is below a threshold and when in night mode.
Thanks for all the suggestions. I’ll try them out as soon as i get some time.
Hi @TAustin, we live in a wildfire-prone area and in season the air can get ugly fast, and regularly see AQI numbers in the hundreds—and sometimes in excess of 500. I’m trying to improve my monitoring and climate control to adapt to the changing environment and am looking for a virtual AQI device that will work with the higher AQI ranges used in the United States. Any suggestions? Thanks.
I could create what’s called a “custom capability” that would could have a an index with whatever ceiling you want. The question is, how are you setting the virtual device? The current one uses a dimmer control to set the CAQI value, which works out because they both have a range of 0-100. If we have a custom CAQI device, I assume you’ll need some way to set it. Rather than use a dimmer control, I could, for example, just provide a numeric input field. But don’t know if you’d be able to use that in your automation routines. Let me know what you think.
Via the API. And the majority of my automations within SmartThings are rule, not routine-based, which generally gives me more latitude.
Maybe I missed something, but I downloaded the vEdge creator and created a new virtual contact device on my iPhone….that was easy and worked great. However, when I access Smartthings thru my iPad I can see both the newly created virtual device, as well as the vEdge Creator V2.7 icon, but when I click on the vEdge Creator V2.7 icon it shows “connected” but won’t allow me to create another device.
What am I doing wrong on the iPad?
Thanks
I don’t think you are doing anything wrong. This sounds like an app issue. But I’ll try it myself on an iPad when I can.
Were you able to solve your issue on the iPad? I tried it myself, and it works OK for me. Sometimes you just have to exit and reload the app, or give it a lot of time to update before you try anything.
