The value under statesmust be attribute_name.value and nothing else. The alternatives under states must include at least 1 key/value but does not appear to serve any purpose. You can omit the states section, but then you can’t specify value and you get a blank to the left of the gear.
Other weird behavior is that once you make a list choice, that choice is shown to the left of the gear before either the capability handler is called or the capability value is changed. Depending on what you’re doing, this can make the state bounce.
Given the current markup, here’s how I would expect things to work:
The list values and state (text to the left of the gear) should be totally independent
When you select a value from the list, the command function should get called with the corresponding key
Presumably because there is not necessarily any similarity between the attribute values and the command arguments and even if there were you might want to present them in a different way e.g. System armed v Arm the system.
Aren’t both being used?
I don’t really have a problem with that, apart from it looking messy, as it is only a display thing. Some commands take time and you need to know what is going on in the meantime. It would be more elegant if you could specify a display only intermediate state as you could in DTHs (*), so to continue the previous example you could have Arming the system.
(*) In a DTH each UI ‘tile’ was defined with the attribute it displayed, and then a list of valid display states. If you actuated a command via the UI it immediately changed the display state to whatever the DTH defined it should be. Then when the attribute actually updated the UI changed to that state.
I populated both sections with keys ‘0’ - ‘9’. The command values are ‘One’, ‘Two’, ‘Three’, etc… The state values are ‘ONE’, ‘TWO’, ‘THREE’, etc… I have never seen the caps versions anytime/anywhere. I have since gutted the states section and populated with a single key:’?’/value:’?’ to satisfy the CLI capabilities:presentation command. It makes absolutely no difference. The list populates based on the command values and sends the command keys. I can set the list state (left of gear) to any string I want which demonstrates that value can be outside either alternatives. Thanks to your earlier reply, I can also filter the list by command keys.
I did consider that ST was trying to do a favor by changing the list state on faith. I’ll have to take a closer look at other display types. I’ve been so paranoid about having handlers for everything that I haven’t paid attention to what might be updating automatically.
You’re referring to the case you mentioned in this post, right?
Let me make some tests with your capability to have a better reference on the behavior you describe.
About the “two” alternatives properties (one in states and the other in commands, I agree with @orangebucket:
The behavior I’ve seen is that if you define different states and commands, all values will appear in the list. However, only the commands are allowed to select, the states appear in gray, for example:
I’ve never seen the state alternatives in the list, but I can think of 2 reasons why:
I had assumed the keys needed to be the same in both alternatives sections
I have a filter applied to the list which would exclude my dummy ‘?’ entry
Why would someone want permanently disabled entries in the list? What’s the use case?
Concerning my other post you referenced, I’m thinking that the device-config for list detailView fails because the second set of alternatives is so intimately intertwined. As I’ve mentioned, the state section has very specific requirements.
Based on the information you provided, I was able to create some grayed-out list entries.
Now I can tease people with non-functional choices. Maybe this would be useful if it could be configured dynamically. Like you gray out the current state. I was hoping to do that with the supportedValues filter, but the filter is only applied when you exit and reenter detailView. It would need to be immediate.
Since both command and state alternatives are hardcoded, I still see no value added by the second alternatives section.
One more mystery. When I create the presentation, I see another state: null one indent inside detailView. What’s that about?
The main purpose isn’t disabling options in the list. A while back, all keys in the “states” and “commands” alternatives had to be the same or it would cause issues in the display.
Now, you can set only one command but send in the backend other states to the capability and provide a more human-readable text using the state’s alternatives.
In the app, this is interpreted and shows the values not included in “commands” as states that are not selectable.
Note: I’m checking with the team if that will be the final behavior expected.
I need to verify the effect on custom capabilities but for stock capabilities, the purpose is to remove the options that are not included in the supportedValues.
About this, I will need to get more info from the internal team, but AFAIK, they are generated automatically.
This is already possible using only the ‘command’ alternatives along with the filter. The advantage is that the disabled status-only alternatives are not even shown in the list. If specified, they will show to the left of the gear. Given the complexity in maintaining custom presentations, I find it easier to just make the state a string and set the text explicitly in code.
I use a list to show miscellaneous commands with combined status for multiple attributes. I display the status using something like:
Ok, just to clarify, you already found a workaround but the previous issue was because you configured alternatives in both, states and commands and used the supportedValues attribute in the presentation which didn’t filter correctly the values. Were the alternatives equal or different on both sides?
Per the forum guidelines, each of my posts is a separate issue.
This post really is just a question. I found that the CLI requires that the second alternatives must be configured if you want to display status (state) to the left of the gear in a list display type. This made me wonder what the second alternatives were even used for since I had never seen them in action.
Now that I’ve disabled the filter and added different keys, I can see the second alternatives displayed in gray. I don’t think this feature adds any useful functionality. I don’t need to use it. I still question why it was ever implemented. You can (better) accomplish the same thing with the filter.
Concerning the filter, my idea was to filter out off as a command when the device is already off. That’s not possible because the list is populated once when the app screen is created. If I were to filter out off and you turn the device on, then the list would still contain on, but the off command would still be missing. You’d have to leave detailView and reenter to see the commands update. I do not consider this a bug. It’s simply a feature limitation.
I need to revisit based on my new understanding, but I’ve still been unable to apply a device-config to a list in order to change the label or alternatives. It’s unclear whether that’s even supported. That discussion begins here. I will simplify my example and start a new post. The workaround is to create additional custom presentations with the changes already hardcoded. Of course, each custom presentation requires its own custom capability.
My ultimate goal is to implement an Edge driver package that supports all the devices in my personal home along with additional automation features. The fan controls will use the pushButton in the dashboard to cycle speed instead of just on/off. Similarly, dimmers will cycle through 3 preset levels. The detailView for a particular device will show other devices in the same room/area. I’ve found the list display type to be the most compact control. I do not want to scroll the detailView. Everything must fit one screen. I like fanSpeed, but in order to use more than 1, I need to create additional components which insert a header taking up precious screen space. Maybe now you can see how all my recent posts fit together.
Each use case can have a different approach, thank you for sharing yours.
I’ll be pending on the new post. However, last time I checked, the labels of a stock capability cannot be modified through the device-config, the text can be overwritten but we cannot see those changes in the app.
I would need to verify using a custom capability and using the patch property. I’ve seen we can remove, add values (I believe “replace” is not very effective for list elements… ). Patch is a tricky property because after you create the device-config using it and the content was accepted, even if you change it, it won’t be considered until you add/remove a capability to force the creation of a new VID.
I suggest you make tests with capabilities that you won’t use in the driver until you get the expected result (in the API and the ST app)
Here’s an example:
Below is a screenshot of 2 stock fanSpeed capabilities with a device-config applied. You can see that the label, range, and even alternatives have been modified. Everything worked as expected. This is what encouraged me to try the same thing with list. According to the presentation, fanSpeed is a list under the hood.