Not sure what they are called exactly or how it work but can commands like these be added to the device variable list?
These are there before I changed it to a device variable and now if I click them it says nothing selected but they are still there if I don’t change them. They also still work even though the command doesn’t exist
I’m not sure I fully understand your question?
You can run commands or subscribe to triggers from a device variable if that’s what you mean… your screenshot looks sound.
You can’t put those commands straight into the variable define section though.
So this piston was created when I just used the standard device and possibly a different DH. I then put the device in a variable and changed the with to that. The piston runs fine but if I edit it and try to change one of the actions the command I originally uses no longer exists. So in this case if I want to increase the on levels I can’t.
So the command must still be possible in the device but it’s just not selectable in the device variable? It’s the same with fireplace and litefade
Ahhh yes, I see what you’re saying now… a know issue.
When you reference a device directly… any custom attributes or commands listed in the device handler are extracted and used to populate the attribute / command dropdown lists. Custom items are marked with that little arrow symbol to the left of the name.
When referencing a device via a variable, that link is broken and the lists are just populated with a default set of standard attributes and commands.
This is actually something I was talking to @ady624 about last week and he is planning to add the enhancement, allong with a ‘swap device’ feature:
“I think I am going to do that. And while at it, why not swap tit-for-tat as well? Ie swap bulb1 and bulb2 in all pistons. Sounds fun and a bit of a challenge from the perspective of timing out. Also, since bins are saved by the UI, not the groovy app, the UI needs to be involved. Ie the UI needs to actually do the swapping and save bins/update pistons.”
Before @ady624 can do that though, we are working through the final checks on an improved UI layout, which must be released first (few weeks away). If further UI updates are made before that, we could run into merge conflicts, so one thing at a time.
For now, do what you’ve been doing, build the piston with the device referenced directly, then switch over to the variable reference, which will then retain the custom command (until you try to change it).
No problem, I just worried and assumed doing it this way may cause issue somewhere down the line.
Sound interesting 
can’t wait to see it 
Brilliant idea, this will essentially remove the need for my device variables in most cases. Since that’s the main reason I’ve used them, just incase that dreaded day comes
@Robin @ady624 - Sorry to revive an old thread but it is exactly the same issue I have been running into on a few pistons. Most recently, I purchased new HomeSeer HS-WD200+ dimmers that have some custom commands which I would like to use but they do not appear unless I reference the devices directly. I have stopped referencing devices directly to make maintenance easier so I am hoping this issue will be addressed soon to avoid ending up with mixed programming standards in my pistons. Any chance it will be addressed soon?
Thanks. That’s what I was wondering. Has the change been made to keep the link to custom attributes?
