@ni.schottfam@ipaterson
I have noticed that when Defining a Device Variable and adding Devices to it and then referencing them later in the piston, I am unable to get a list of all the Commands Available to the devices.
Example: I have Door Bells and I add them to a piston, I see a option like "custom clearImage" and it works, but if I add them to a Variable DoorBells and then reference that, the command "custom clearImage" is missing,
I have the same issue with status options.
Using the same doorbells and adding them to a piston i can do a compare on smartDetectType, but if I use the device variable they compare list is missing several of the options.
Are you able to make it so that when we have devices in a Device Variable is maintains a list of all the Status Options and Commands they can do. It would make creating and maintaining pistons must better IMO. I use both Local and Global Device Variables. (So if I have to replace one device or upgrade it, I don't have to find all the locations in the code and manually change them, I can do it in one or 2 spots.
Since these device variables are essentially constant (you can’t change them while the piston is running) this seems like it should be possible. A device variable may include unknowable devices like $currentEventDevice but in that case you probably just get the current behavior.
@nh.schottfam what would happen now in Groovy if a device variable has two different devices and you try to execute a command that only one supports? Or if a condition targets an attribute that only one device supports? Deciding whether this should be an intersection or a union of commands and attributes.
What about only showing the variables that are shared across all the devices in a device variable.
So if a device variable has 2 contact sensors and they both have contact, Battery and temp. It shows all 3 option
However if you have 2 contact sensors and they both have contact and battery and only one has temp. Then the only options it would show are Contact and battery. So temp is not shown since its not available on both devices.
This should help eliminate the issue of errors. And show a cleaner selection.
As this is already an issue. As you can see from my screen shots above. The device by itself and the options to select from vs the device variable with only the one device selected. The list is completely different.
How do you all feel about a divider between the shared attributes and the current "everything else"? It actually already shows the shared attributes first but without some divider it's not obvious.
This is going to need a lot more work, just looking for feedback. I need to find a way to make those dividers non-selectable or ideally to include optgroup headings describing each group of options. Also currently the resolution of device variables is not recursive, so a variable referencing another variable is not handled properly and you're guaranteed to get just the global attributes.
It would also be possible to show the shared attributes, any additional unique or custom attributes, and finally the global stuff. In this case one of the circulation fans includes power monitoring but most are switch only. I suspect that if this even works it would only be desirable with an optgroup label to identify that hey, these might not work for some of the devices in the variable.
it is a physical device (so you should know what it is or the list is)
it is a variable
with some value assigned
with no value assigned
So for the variable with some value assigned, I like your idea above, and you can still show all the built-in and custom attributes that are known in the IDE
With no value assigned, there will be no shared section, but it still should have the list of built-in and custom attributes that are known in the IDE.
The runtime code should handle if you ask a device for something it does not support (it will produce an error, but should continue running). If there are any issues we find there I can fix them.
If I'm understanding this issue, there's a possible workaround... They way I do it is build the piston with the device explicitly called out in the conditions or actions. Then I can create the device variable with the desired devices and add it to the piston with the explicit device before unchecking the explicit device. Then save.
Make the piston:
Make the device variable you want to replace the thing with unique capabilities:
Add the device variable to the piston before unchecking the explicit device:
This is a very simple example using a common device type but it should keep the capability for unique devices. I tested this on my Rachio sprinkler and Ecobee. This also allows you to swap a device in the variable with one that does not have that same capability, so it could break your piston. For example, I can swap that device in the variable for any device, so if I change it to a bulb, the contact will never change because it does not have that capability.
I added the new implementation of attributes to https://staging.webcore.co for review. It resolves variables recursively, so if you have a device variable that includes device variables everything should work properly. Inclusion of any non-initialized or system device variable like $currentEventDevice will cause everything but $status to appear in the "subset" group.
This was also applied to selection of multiple physical devices (i.e. no variables). The case is not as strong but there is a plausible benefit there. For example, if after creating a piston you switch the device handler for one of the devices it may have different attributes. The piston editor would have shown a blank value for the previously selected attribute since it no longer applies to all devices, and that makes it pretty tough to fix. Now you should see it in the subset group and be able to fix it. Granted, if an attribute was selected and now none of the devices have it you'll probably still see a blank value .
Finally, I think the following comment may not have applied to the production dashboard.webcore.co, sorry for any confusion there.
I'm done waiting for SmartThings to kill off the platform... once a similar thing is implemented for commands and tested I'll get dashboard.webcore.co up-to-date with all of the good stuff on staging and just hope it's backwards compatible if anyone is still clinging to WC on ST.
I started to add this concept to commands today, seems like it should work fine there, too. The command UI already has support for distinguishing commands that are shared by all the devices, only some of the devices, or global (it just didn't work with variables). It's a little odd since "available to only some" is at the bottom, I might move that around to match the attribute list and update the attribute list wording to match.
.
