So the behavior is that when you interact with the device it will update the status area right after execution, if the service call didn't fail. It will only update the variables it can, based on the actions metadata definition. So in the case of a dimmer you have two controls on/off and 0-100. These are actually completely different services with different variables that may or may not exist on every device. Depending on which of those controls you use it will update the appropriate status data without doing an explicit refresh. I did this so the user gets immediate feedback if the service call didn't fail. It gives the illusion of speed, but typically this only affects one variable. Everything on vera is done async so i have no idea when the updated values will be there... or for that matter how many variables will be changed. Sometimes it take 1 sec other times 10 secs. But the limitation is the other controls are not tied to each other so they don't update. So the switch doesn't change just because the dimmer does. It's a limitation i'm aware of that i'm evaluating how to enhance. The reason it worked differently in the old app was that it was all hardcoded. I need to figure out a way to correct this using only meta data, which drives how it builds those UIs.... thats how i'm able to easily support lots of plugins without harcoding anything. The easy fix is i make the entire device view refresh each time you do something... however i think that would be weird for the user seeing it open and close like that. That's why you see the device close when you do a refresh. The list and the device item info are not really connected so closing it guarantees you don't see stale data. You will also notice if you have the device open and you use a quick action it doesn't auto update the device area underneath, again same limitation. The short answer is its on my list of things to figure out, but i figured for now it was an acceptable limitation.
