Help with "capture attributes"

[MABeatty1978]

I was just helping out a Redditor creating a piston. He was using “capture attributes” to save the state of a light before changing it then “restore attributes” afterwards. He was having some odd behavior with it. I’ve never used the capture/restore functions, have always used variables to save states and restore them and as such, that is what I suggested. But this capture attributes seems to be a pretty convienient function if it does what it sounds like its supposed to do.

Here is a link to his piston, https://imgur.com/a/dLu7x he was reporting that
" It will flash red/green and then revert to a random color. If it does work properly, it seems to cycle through a random color, then cycle to the previous state."

Any ideas what’s happening? Why it isn’t working?

[eibyer]

I think this might the same one?

Flash a light green when the front door is locked, then return the light to it's previous state

1) Give a description of the problem It will flash red/green and then revert to a random color. If it does work properly, it seems to cycle through a random color, then cycle to the previous state. 2) What is the expected behavior? If front door is unlocked, flash the front door Hue light green, then return to original level/color/state. If front door is locked, flash the front door Hue light red, then return to original level/color/state. 3) What is happening/not happening? It will flash …

As was suggested by the other poster, I’d try to some of the attributes first instead of all the available ones, then restoring only the ones selected.

Also, when I played with capture/restore before… I put a second or two after the capture, then execute tasks, then a few seconds wait, and then restore. I have not actually tried to play with his sample piston.

[lflorack]

Also, when I played with capture/restore before… I put a second or two after the capture, then execute tasks, then a few seconds wait, and then restore. I have not actually tried to play with his sample piston.

I can definitely confirm that waits of one to two seconds or more are needed both after the capture and before the restore commands. If sufficient wait time is not allowed at these two points, WebCoRE may not properly capture or restore the device attributes. More devices or more attributes will increase the wait times needed for successful captures and restores. Also, depending on the then current speed of the infrastructure (SmartThings, Internet, etc.), even more time may be required periodically. I can normally get by with 1-2 second waits when only using two or three devices while using just the switch and level attributes, but not always.

[ipaterson]

It sounds worthwhile to investigate whether webCoRE could instead capture and restore synchronously to avoid requiring a wait. That’s too much variability to account for in every piston that uses those actions…