Interesting Galaxy Watch affect now that I’m using the SmartThings Virtual Switches. I have a Walking Mode virtual switch, and when I went for a walk today and toggled my Walking Mode virtual switch On and Off via the SmartThings Tile on my Galaxy Watch as usual, I noticed that it toggled the virtual switch On/Off much faster than my previous virtual switch did using this driver. Cool!
I am going to say yes. The API reference and the developer documentation aren’t at all forthcoming about them but that isn’t untypical. They are supported by a Labs tool, and more importantly the Core SDK, the CLI and the Advanced Web App.
@orangebucket Roger that
I am searching for a virtual switch which will support three states (ArmAway, ArmStay & Disarmed). This is desirable since rules using the security mode are executed in the cloud. Installed vEdge Creator but can’t find a tri-state security mode switch.
Mariano Colmenarejo developed a virtual security switch that might meet your needs.
Go to the 1st post for the driver installation link.
Utilizing what I know is available, I would use a virtual Dimmer to hold a state variable value between 0 and 100. 1= ArmAway, 2=ArmStay, 3=Disarmed…or similar. I’d likely designate Disarmed as Off/0.
Paul_Oliver, Aplicaciones Virtuales Mc worked for me. Created a virtual security object and it does everything I need. Thanks!
Glad it worked.
Great, now I have an Alexa routine to work/activate my IR blaster . . with these triggers I can now assign to a remote switch in Smartthings . . and all because Samsung removed the scenes link from Tuya app . . thank you
Just FYI, I’d been away for a long time, but I’m still around. Not sure if you’re referring to reported issues or requests for new capabilities. I haven’t tried to catch up on all the posts here, but - and this is for everyone - if there are problems that need to be fixed, please let me know.
I’ve been experiencing an odd issue with the virtual thermostat device (or any type that involves temps) where I can’t set temperatures b/c it internally converts F values to C & then tries to parse them as F values.
Eg if I try to set a temperature value to 55°F, it will instead set it to 12.8°F (and then produce an out of range error)
I am have the same problem with Mariano’s child thermostats. If you change the temperature units under settings to Celsius and it should solve the problem.
It seems like ST is automatically making the conversation so there is no need to manually set it to °F.
I’ll take a look at it. Last I knew, SmartThings didn’t give developers any way to discover the temperature units in use by the app, which is why there is a Setting option for that. But something else must be getting fouled up as well, so I’ll try to reproduce your issue.
I’ve looked at this issue and I think I’ve discovered the root cause. It seems a change has taken place for the thermostatHeatingSetpoint and thermostatCoolingSetpoint capabilities, where they only return degrees Celsius now. The catch is that this behavior apparently depends on the hub & firmware version. I’ve looked at the latest SmartThing Matter drivers vs. the Zigbee drivers, and for Matter (more recent) they check an undocumented version number and adjust logic based on that. For Zigbee drivers, they make an assumption that if the setpoint value is 40 or below, it is assumed to be Celsius; and if greater than 40, it is assumed to be Fahrenheit.
Either way it’s a hell of an undocumented mess. I’ve made the change to the virtual thermostat code (per the Zigbee driver hack method) and it seems to be working normally again, but I fear that others on different levels of firmware may or may not see the same. It needs to be verified by users in both Celsius & Fahrenheit-based countries, and with varying levels of hub versions and firmware levels.
I’m going to push out a driver update in a day or two. It’s possible it may cause problems for some, and solve it for others, so further changes might be needed. I’ll post here when the driver update has been pushed.
This may be associated with the ongoing “degradation” of the SmartThings cloud but my two Virtual Presence sensors are suddenly out of whack. They both currently show as “On” but “Not Present”.
Attempting to switch them off gives the ever popular “network or server error had occurred”
These have been in use for at least a year without issues.
Update
These have sorted themselves out. Not sure why but the settings are in sync.
DRIVER UPDATE NOTICE: Virtual Devices V2.95
Virtual devices that use the thermostatHeatingSetpoint or thermostatCoolingSetpoint capabilities (thermostat, A/C, Fridge) have been updated to correct an issue documented here.
Please report any further problems here!
The driver will be automatically installed to your hub if you are subscribed to my Shared Projects channel.
Given that this virtual thermostat isn’t a child device of an actual thermometer device how do you get the thermostat temperature to mirror that of an actual thermometer reading?
I’m currently using the MC child virtual thermostat, just wondering if I ended up replacing some of my temp sensors with matter over thread ones how I’d get the virtual thermostat in @TAustin s virtual devices driver to mirror a real world temperature?