Restoring attributes fails

[wgmcg]

1) Give a description of the problem

Restoring captured attributes gives an error:
Could not find a command to set attribute ‘coolingSetpoint’ to value ‘80.0’
+576ms ║║Could not find a command to set attribute ‘heatingSetpoint’ to value ‘68.0’

2) What is the expected behavior?
I would expect the settings to be restored just as I’ve set them by code further up in the piston. Alternately, is there some way, rather than restoring the values, to use them as variables, since I seem to be able to set both setpoints myself via code?

Also, the DH for this thermostat isn’t very sophisticated and I am working on it (and learning how to write a DH right now). It may be entirely possible that a setHeatingSetPoint cmd doesn’t exist in the DH, but then why does it work programatically?

3) What is happening/not happening?
Restore attributes errors.
4) Post a Green Snapshot of the piston

[WCmore]

I do not have a smart thermostat (yet) but I do something similar to a light-bulb that would be easy for you to test in your environment.

This is one I use when I need to find something. It stores the current level into a variable… brightens lights and waits a couple of minutes (not shown here)… then returns to the previous state

Of course, you could force any number you wish into that variable before the final line

[Ryan780]

That’s not going to work the way you want it to. You have to list out the devices that you want to include and use the OR operator for the open and then you’ll want to list the same devices and use the AND operator because you only want to set them normally if all the windows and doors are closed.

Also, because the trigger happens for each window/door, you will only ever be notified for each door. The way you have it constructed, the device variable will only ever include 1 device. That is unless you open two windows at the exact same time. Then they would have both been open for two minutes simultaneously.

But before you set them, you want to store them in a variable for use later. You can’t use Global States. Because that is going to happen a lot later. The global state is now 110 and 55.
So, before you set to 110, insert
Set variable cool = coolingSetpoint and set variable heat = heatingSetpoint.

Just out of curiosity, what kind of Thermostat are you using? If your thermostat has MODES (heat, AC, off) this becomes a lot, LOT, LOT simpler.

[wgmcg]

I was setting variables for the stored setpoints, but I thought I’d get fancy and use the global states.

I understand that the device variable processes one at a time, but I guess what you can’t see in the photo is that in the first condition, it’s Any of {@Windows_Doors} .

My thought was that I want to shut the HVAC off and save the state when the first window opens, the rest don’t matter, which is why I’m setting IsOpen=true. I want to skip saving the thermostat state for every other window that opens. I suppose it might be better to check the IsOpen var as a restriction, rather than a condition.

In the else if case I’m actually doing an ANY in the trigger, but an ALL in the other condition. So if ANY window_door closes and ALL windows_doors are now closed then restore the thermostat.

That logic seems to work. I actually get the restore event when I expect it, it’s just that the restore fails with the error above.

In any event, to your last point, It’s a rheem EcoNet thermostat, and I modified the DH yesterday to support setThermostatMode, so yes, I can just do that now.

[wgmcg]

Here’s the simplified piston. The only interesting thing here is that my thermostat is returning “Off” instead of “off” for its mode so I have to do the string comparison as an expression rather than using the values in the drop down picker. I wish I knew where those were set, is it in the WebCoRE thermostat device type? I had to code the DH to convert lower to upper case for the Rheem API.

The other thing that’s changed is having both ANY and ALL in the else if case. The ALL condition subscribes to events from all the member devices of @Windows_Doors anyway, so that was redundant.

Anyway…

[Ryan780]

You’re still using restore attributes. That won’t work the way you want it to. Save it in a variable. Rather than code the DTH to convert it, you should have modified the states. That’s where it’s getting the lower case from.

[wgmcg]

Well, everything is so much simpler at this point that a variable would work fine too, but its unclear to me why restore attributes won’t work. All of my testing so far shows that it does exactly what I want.

Where are the states defined? The states as defined in my DH are not what’s showing up in the WebCoRE thermostatMode function’s value dropdown, so I had to convert what WebCoRE is sending to something my device’s API understands.

I still don’t understand where WebCoRE’s value list is coming from or how to modify it.

[daba]

Sorry for resurrecting this old topic, but I am also trying to use store and restore with a thermostat’s heatingsetpoint, which is failing.

From the logs it seems like webcore doesn’t know how to restore the heatingsetpoint (it doesn’t seem to know which function/method to use).

I am using a Nest Thermostat and NST Manager. I searched the DTH for any mentions of store/restoring heatingsetpoint, but didn’t find anything. I’m not familiar with SmartThings DTH development and do not know if I should expect to find anything.
It seems like restoring should simply set the value previously stored.

My current workaround uses variables instead, but that just increases the complexity of my pistons.

Can anyone elaborate on

1. why this doesn’t work?
2. if this is expected to work?
3. if it is, any pointers or advice on how to fix it, even if only locally for myself.

[WCmore]

I do not have a Nest, but personally, whenever I capture and restore anything (bulb levels, bulb colors, thermostat, fans etc) I always use variables. It gives me much more control and options, and I have found it much more predictable and reliable compared to using the built-in capture & restore.

Your mileage may vary.