Great job! 
Yes, as mentioned in this post, the team is working on a fix. Iâll let you know in case I receive feedback about that. 
1 Like
The 3 custom capabilities that I have created work fine in automations in the Action Part (then), but in the Condition part (if), it doesnât work.
Once the condition is selected, it shows as unknown condition.
With this error, it does not allow saving the automation.
Double check the capabilities presentations, in particular the âconditionsâ sections. The âlistâ object should include a line of the form:
"value": "attributeId.value"
Without that line it wouldnât know what attribute value it is supposed to use.
The similar structure in the âactionsâ section doesnât have that line, it has "command": "commandName" entry instead. Could you have missed that difference?
1 Like
It seems that I have that error in the capability presentation:
"automation": {
"conditions": [
{
"label": "Progressive ON",
"displayType": "list",
"list": {
"command": "setProgOn",
"alternatives": [
{
"key": "yes",
"value": "yes"
},
{
"key": "no",
"value": "no"
}
]
}
}
],
"actions": [
{
"label": "Progressive ON",
"displayType": "list",
"list": {
"command": "setProgOn",
"alternatives": [
{
"key": "yes",
"value": "yes"
},
{
"key": "no",
"value": "no"
}
]
}
}
]
It would be to replace in conditions the command line by attributeID.value
I will try it
Thank you
Just noticed I left the quote marks off. I am too used to writing YAML now. Just for clarity, here is an example I have with a âlistâ condition.
"conditions": [
{
"label": "STHM Status",
"displayType": "list",
"list": {
"alternatives": [
{
"key": "armedAway",
"value": "Armed (Away)",
"type": "active"
},
{
"key": "armedStay",
"value": "Armed (Stay)",
"type": "active"
},
{
"key": "disarmed",
"value": "Disarmed",
"type": "active"
}
],
"value": "sthmStatus.value"
}
}
],
2 Likes
The example helps!
The documentation that is there is so bad
Thank you
1 Like
What do you consider should be improved in the documentation?
Thereâs an example of each display type for the different presentation sections, for example, this is the one for the list in âactionsâ:
Tip:
The âconditionâ section of the automation is used to compare a capability value, so itâs easy to differentiate the configuration from the âactionâ section because the last one uses the property âcommandâ.
Being precise in giving qualifiers in a language that is not yours is not always easy!
I understand that the documentation in times of transition is not easy to be 100% updated.
Many times it is not that something is missing, it is that it is not easy to find it and when you find it, as in preferences, it is valid for groovy, it is not 100% valid for Edge Drive.
Also how and where to look can help.
If you go to the Edge drive manual, you cannot use the search, it gives page not found error to everything you are looking for.
If it werenât for your help, it would be a lot more difficult, not only for me, from what I see daily in the forum!
If so many people find it difficult to make the custom capabilities, their presentation and the final view presentation of the device, it is that something is not so clear in the procedures.
In my case the lack of knowledge also counts.
Thanks for your help
I modified the presentations of the 3 custom capabilities and got it to work after I was about to quit.
I created a new configuration presentation of the device to get a new âvidâ, but it gave me exactly the same.
I verified in the API, that the presentations were updated with the âvalueâ instead of the âcommadâ.
I thought, well he will have modified the data of the custom capabilities with the same vid.
When testing it kept giving an âunknown conditionâ error
In the end it occurred to me to modify in the .json to create the device presentation the color temperature value from 2700 to 2699.9 in the details view and it already gave me a new âvidâ.
Tried, everything worked.
It doesnât seem normal to do this for update something data in the custom capabilities.
Is there another way to do it?
Thanks
There are still a few more issues with the custom capabilities driver.
As I mentioned before it installs fine and kind of works however if I go to the SmartThings Android UI and repeat adding and removing a device which is controlled by this driver in about 40% cases after adding it, instead of displaying the custom capability value on the dashboard and on the detailed view it just displays the word âConnectedâ and never displays the custom capability value. However if I remove it and add it again there is a big chance that it will display the expected capability value. What can be wrong? Why might it happen?
If I go to the detailed view of the SmartThings Android UI and try to change the value of the custom capability it displays an error âA network or server error occurred. Try again later.â It is unlikely a network error. It ALWAYS displays this error. Why might this happen? Once again my driver code is very close to the custom-capability sample with a few modifications and a custom capability using a list of values. It is sort of a hybrid between the hello-world sample and custom-capability sample.
The curious things is that the virtual device controlled by this driver works fine in the rules. I can change the value of the device as a result of a rule execution and I can trigger other rules by the change of the value of this custom capability but I cannot change it via UI. However if the value is changed by a rule it is displayed correctly in the UI. I donât really see major difference from the hello-world driver example which works entirely fine and I can change the value, turn it on and off from the UI. In the case with my driver there no logs at all when I try to change the value from the UI. I would expect to see at least something like what I see with the hello-world âTRACE Hello World Received event with handler capabilityâ but there is nothing at all in the case with my driver as if the requests donât reach the hub at all.
UPDATE: I just figured out the cause of the first problem. It turned out that I had 2 slightly different versions of the driver installed and even though packageKey of them was different, so that I had two distinct drivers in the system, the name of the profile and the name property in the profile was the same and that name was used when a virtual device object was created. Apparently when I added a device via the UI, it arbitrarily started one or the other driver first, it created a device and at the moment the system started the other driver the device was already created and it did nothing or maybe it recreated the device. In any case it would lead to 50% chance of instantiated device of one or another driver. The other problem still persists.
Ok, Iâd like to give a further look at your configuration. Can you please share your driver source code (not the packaged version) in a zip file to build@smartthings.com?
This happens when you include the same capabilities, to force creating a new VID, you need to add/remove capabilities.
However, you should see the changes if you follow the instructions I shared above.
Update: After more tests, I noticed there are some elements of the presentation that are updated almost immediately but others seem to get stuck in the previous version. (Android)
In iOS, the update is not so active so Iâll also mention this.
When you experience this again, you can open a new post to discuss the specific configuration where the issue was present.
1 Like
Donât worry, I sent you an email. Please check your inbox and reply to me there. Thanks!
Considerations to share about what I have observed when using custom capabilities:
-
When you create custom capabilities and their presentations you do not need to create a Device Configuration Presentation (Vid) to add it to the profile metadata.
-
You only need a device configuration presentation (vid) if you are going to modify the presentation of a standard capacity, for example the color temperature capability default ranges.
-
If you modify a presentation of a Custom Capability and you want see new presentation on your device, you have to do the following:
-
uninstall driver â unpublish driver â delete driver and do new package â publish â install.
This is a problem when you want to publish a new version of a driver that is in use, since it creates a new driver ID and does not consider it a new version, it considers it a new driver.
- If you have changed something in the presentation of a custom capability that is used in a profile that has a device Vid in the metadata, you do not need to create a new vid, you just have to follow the steps described in the section 3 and you can use the same vid.