I think I stumbled on two bugs related to setting variables. One, if I try to set a global variable from device attribute, the dropdown fails when picking a device. Seems like a graphical glitch, but it does cause a broken rule.
Secondly, the list of available attributes when setting local from a thermostat seems to be missing SetCoolingSetpoint:
In all other automations 'coolingSetpoint' does not work, but in this case I am able to retrieve this value to set my virtual dimmer to achieve voice-controlled thermostat.
You can see in the last screenshot, that when I've tried to use a global variable, the only reaction when clicking the "Select device" dialogue box is that it gets a blue shadow. If I choose a local variable from the first list, then this works just fine. My virtual-to-real and real-to-virtual thermostat control works fairly well. Other than the odd behavior of the Zen thermostat in general. It tends to bounce around a lot, and require multiple setpoint pushes to ensure reliability. I did a repeat-actions loop to hit it a few times just to make sure.
Off-topic, but those issues only happen with the built-in driver. I’m using a ported version of the Smartthings Zen driver and it’s rock solid. Only issue is it doesn’t report the mode changes for some reason, but that’s a trade off I’m willing to make.
As soon as I write a question here and get an answer I end up with at least 2 more questions...
@JasonJoel : Is there a way that when I turn of that Virtual switch that it automaticly goes to the set routine... like if I turn of the virtual switch at 02.30, the inner lights should already have turned of and the outdoor light should be at 4%, but if I turn of the Virtual switch at 23.00 1 indoor light should turn of and the outdoor should dim to 30% automaticly and wait for next trigger event... Is this even possible?
You could, but your rules are going to get awfully complicated really fast.
If you used the virtual switch as an additional trigger, and made sure your conditions were time range as one of the conditions in addition to the fixed time (so an OR with the fixed time), you could probably do it.
You can make it as complicated as you have capability to understand, code, and troubleshoot.
You need to be making additional Backups. The backups saved on the Hub are wonderful, but if it dies, you do not get access to them. Techniques have been discussed, search will find them.
Yes, you can buy a new hub and yes you can restore the Backup, assuming you have one. You will get all your rules back, as of the date/time of the backup.
But you will NOT have access to your Zigbee or ZWave devices. Zigbe is probably easy, simply put the new hub in Zigbee include and cause the Zigbee device to re-pair (Factory reset then Pair as if they were new). They will return to the 'slot' (aka device ID) they were before.
ZWave involves: Exclude each device and then Include them. They will have new device IDs and therefore won't return to their 'slots'. You'll have to manually edit each to give them a familiar name, and then individually put them into the Rules/Apps/Drivers. Then you'll have to clean up the Device list to eliminate the 'orphaned' ZWave devices.
The Rules are not the problem. The problem is, the rules have devices in them but the new hub has no devices. When you put the devices back, you have to 'reconnect' the new device to the old device's spot in the rule. Even WebCoRE doesn't solve that.
A new hub has zero devices, restoring the DB just restores the 'knowledge' that a device-once-lived-here. When you re-pair Zigbee, the Device ID (which is hard coded by the manufacturer, and remains the same forever) is able to match the device-once-lived-here. ZWave doesn't do that. No hard coded Device ID. The Device ID is generated as part of the Join process.
