I currently have 0.0.0-pre.7 and it reports 0.0.0-pre.6 so seems consistently inconsistent.
Hi, @Panos
Regarding the error response while creating your device-config, it is being triggered because the label
attribute is only supported by the capabilityβs presentation API. Also, the component
attribute is required to create the device-config as it is the reference of state
and component plugin
(a more complex reference of the use of components would be multi-button devices).
Also, to make an effective state
presentation, the unit must be passed without curly brances and place it as well at the stateβs label (e.g. βlabelβ: β{{attribute.value}} {{attribute.unit}}β). At the API documentation, values that do not use curly brace are generally expressed as (^[[a-z]*([A-Z][a-z]*)*){1,36}(\.unit)+
.
Is is just me or is this getting overwhelming. I can create a simple capability with just 1 attribute. I can create a presentation for it successfully. I placed it in the DTH and generated a config. I updated the config to remove the extra dashboard stuff. I can even get a config to generate and give me a vid.
However, I can get nothing to display in the dashboard or the detailed view for this capability All I want is a simple state showing the value in the dashboard and in the detailed view. Does anyone have any examples of such?
Iβm about to throw in the towel.
Hi, @mellit7
Thank you for sharing!
To have a better reference of why you havenβt been able to deploy the state
display type, it would be great if you could share with us your current capabilityβs presentation.
Update
With a few changes on this example, hereβs another one that you can implement to deploy the state
display type.
- Capabilityβs definition (supports a unit for testing porpuses):
{
...
"name": "State Example",
"attributes": {
"attr": {
"schema": {
"type": "object",
"properties": {
"value": {
"type": "string"
},
"unit": {
"type": "string",
"enum": [
"unit"
],
"default": "unit"
}
},
"additionalProperties": false,
"required": [
"value"
]
},
"setter": "setAttr",
"enumCommands": []
}
},
"commands": {
"setAttr": {
"name": "setAttr",
"arguments": [
{
"name": "value",
"optional": false,
"schema": {
"type": "string"
}
}
]
}
}
}
- Capabilityβs presentation:
{
"dashboard": {
"states": [{
"label": "{{attr.value}} {{attr.unit}}"
}]
},
"detailView": [{
"label": "Attribute value:",
"displayType": "state",
"state": {
"label": "{{attr.value}} {{attr.unit}}",
"unit": "attr.unit",
"alternatives": []
}
}]
}
- DTH code (the only changes that need to be applied on your side is the capabilityId and vid):
/**
* Test DTH for custom capabilities.
*/
metadata {
definition (name: "stateExample", vid: "", mnmn: "SmartThingsCommunity", author: "SmartThingsCommunity") {
capability "namespace.stateExample"
}
simulator {}
tiles {}
}
def parse(String description) {
log.trace "parse($description)"
}
def installed() {
initialize()
}
def updated() {
initialize()
}
def setAttr(String arg){
log.trace "setAttr( ${arg} )"
sendEvent(name: "attr", value: arg)
}
private initialize() {
sendEvent(name: "attr", value: "initial value")
sendEvent(name: "healthStatus", value: "online")
}
To trigger commands successfully, create the device at the IDE using this DTH, then deploy the simulator installing it to the device created instead of the default device.
If this results useful to you, let me know by marking this response as a solution.
@erickv Thanks - these examples are very useful. I was able to get the list example up and running and am trying to apply it to a real device now.
Would it be possible for you to post the status of which display types currently have known issues so we know what to avoid? I think weβre all struggling with the question of whether something not showing is an error we made, a delay due to caching, or an issue beyond our control. Itβs helpful that you posted the key/value issue for lists and that youβre aware of an issue with steppers.
In getting your list example to work (and the other custom capabilities that Iβve gotten to display), it seemed like I needed to add the Health Check capability to the DTH for it to render. That also could have just been coincidence thoughβ¦ In your example DTHs you havenβt included it, so is it necessary?
I havenβt been able to get more than one display type to show up in the detail view for a single custom capability. For example, trying to show both a state and a push button for the same capability. I canβt say Iβve tried enough to rule out errors on my side or caching though. At one point you posted that multi-attribute capabilities arenβt supported at this point, but are we able to do multiple display types for a capability?
My test case includes the use of βAlternativesβ to display either βBinary Activeβ or βBinary Inactiveβ in the dashboard state, depending on whether the state of βbinaryβ is βactiveβ or βinactiveβ. It displays βBinary Activeβ so I must have got something right. Unfortunately it displays it regardless of the actual state.
Over in the Detail View, the same attribute is being used with a toggle switch. The format of the label and the Alternatives is essentially the same as the dashboard. That one ignores the Alternatives but manages to display inactive or active as appropriate. Between the two I have all the components of the functionality, but neither works.
I reported on how I tried Erickβs example this morning. I actually got a command to run. I could see it in the Live Logging. I then deliberately added a parameter to the command source and saw it fail in the Live Logging as I would expect. Unfortunately I donβt want to use a type with a single setter command, I want to use separate commands for setting each state. If I do that in the dashboard pressing the button either crashes the app back to its own screen or does nothing. If I do it on the Details View I get the slightly delayed error that you always get when a command is run but doesnβt result in the expected state change. It hasnβt run a command. There is nothing in the Live Logging. If the command was called there would be something in the live logging, even if it just said there was no such command.
Iβm pretty confident Iβve got it right according to the documentation and by comparison with assorted standard capability presentations. Also I exhausted all the βwrongβ permutations about two months ago. Iβve not just spent man hours on this, Iβve spent man days on it.
I also tried a different test this week. I couldnβt a dashboard state at all with that one.
I have a large pile of towels β¦
Thanks for the quick responses. Hereβs where I am. I currently donβt have units or alternatives. Wonder if thatβs part of the problem.
Hereβs the capability created from line prompts. Thereβs no setter, this is information generated through another command that just needs a place to be stored and displayed.
{
βidβ: βwanderwater41919.playerCountβ,
βversionβ: 1,
βstatusβ: βproposedβ,
βnameβ: βPlayer Countβ,
βattributesβ: {
βplayerCountβ: {
βschemaβ: {
βtypeβ: βobjectβ,
βpropertiesβ: {
βvalueβ: {
βtypeβ: βintegerβ
}
},
βadditionalPropertiesβ: false,
βrequiredβ: [
βvalueβ
]
},
βenumCommandsβ:
}
},
βcommandsβ: {}
}
Hereβs my presentation
{
βdashboardβ: {
βstatesβ: [
{
βlabelβ: β{{playerCount.value}}β
}
],
βactionsβ: ,
βbasicPlusβ:
},
βdetailViewβ: [
{
βlabelβ: βNumber of Playersβ,
βdisplayTypeβ: βstateβ,
βstateβ: {
βlabelβ: β{{playerCount.value}}β
}
}
],
βidβ: βwanderwater41919.playerCountβ,
βversionβ: 1
}
Sorry this looks horrible, donβt know what I did to lose the indents
Try using code indents instead of quotes. Itβs easy, start one line with three ` characters. The paste your code in the next line and then again the last line should have three ` characters.
So like this
```
lotsa code
lotsa code
```
and it will render as
lotsa code
lotsa code
So, Iβm stuck again. Here is where I am at.
I have the following capability defined:
Capability: dictionaryfabric11101.adjustValues
Attributes:
ββββββββββββββ¬ββββββββββ¬ββββββββββββββββ
β Name β Type β Setter β
ββββββββββββββΌββββββββββΌββββββββββββββββ€
β valueFour β integer β setValueFour β
β labelThree β string β setLabelThree β
β labelOne β string β setLabelOne β
β valueOne β integer β setValueOne β
β valueThree β integer β setValueThree β
β valueTwo β integer β setValueTwo β
β labelFour β string β setLabelFour β
β labelTwo β string β setLabelTwo β
ββββββββββββββ΄ββββββββββ΄ββββββββββββββββ
Commands:
βββββββββββββββββ¬βββββββββββββββββ
β Name β Arguments β
βββββββββββββββββΌβββββββββββββββββ€
β setValueThree β value: integer β
β setLabelTwo β value: string β
β setValueOne β value: integer β
β setValueFour β value: integer β
β setValueTwo β value: integer β
β setLabelFour β value: string β
β setLabelOne β value: string β
β setLabelThree β value: string β
βββββββββββββββββ΄βββββββββββββββββ
I then I defined this presentation:
Dashboard States
βββββββββββββββββββββββββββββββββββββββββ¬βββββββββββββββ¬ββββββββ
β Label β Alternatives β Group β
βββββββββββββββββββββββββββββββββββββββββΌβββββββββββββββΌββββββββ€
β {{labelOne.value}} {{valueOne.value}} β none β β
βββββββββββββββββββββββββββββββββββββββββ΄βββββββββββββββ΄ββββββββ
No dashboard actions
No dashboard basic plus items
Detail View Items
βββββββββββ¬βββββββββββββββ
β Label β Display Type β
βββββββββββΌβββββββββββββββ€
β Label 1 β textField β
β Value 1 β slider β
β Label 2 β textField β
β Value 2 β slider β
β Label 3 β textField β
β Value 3 β slider β
β Label 4 β textField β
β Value 4 β slider β
βββββββββββ΄βββββββββββββββ
No automation conditions
No automation actions
(Information is summarized, for full details use YAML or JSON flags.)
I think I followed the process correctly and got this device-config:
β Type β dth β
ββββββββ΄βββββββββββββββββββββββββββββββββββββββ
No DP info
Dashboard States
βββββββββββββ¬βββββββββββββββββββββββββββββββββββββ¬ββββββββββ¬βββββββββ¬ββββββββββββββββββββ
β Component β Capability β Version β Values β Visible Condition β
βββββββββββββΌβββββββββββββββββββββββββββββββββββββΌββββββββββΌβββββββββΌββββββββββββββββββββ€
β main β sensor β 1 β none β none β
β main β actuator β 1 β none β none β
β main β dictionaryfabric11101.adjustValues β 1 β none β none β
βββββββββββββ΄βββββββββββββββββββββββββββββββββββββ΄ββββββββββ΄βββββββββ΄ββββββββββββββββββββ
Dashboard Actions
βββββββββββββ¬βββββββββββββββββββββββββββββββββββββ¬ββββββββββ¬βββββββββ¬ββββββββββββββββββββ
β Component β Capability β Version β Values β Visible Condition β
βββββββββββββΌβββββββββββββββββββββββββββββββββββββΌββββββββββΌβββββββββΌββββββββββββββββββββ€
β main β sensor β 1 β none β none β
β main β actuator β 1 β none β none β
β main β dictionaryfabric11101.adjustValues β 1 β none β none β
βββββββββββββ΄βββββββββββββββββββββββββββββββββββββ΄ββββββββββ΄βββββββββ΄ββββββββββββββββββββ
Detail View Items
βββββββββββββ¬βββββββββββββββββββββββββββββββββββββ¬ββββββββββ¬βββββββββ¬ββββββββββββββββββββ
β Component β Capability β Version β Values β Visible Condition β
βββββββββββββΌβββββββββββββββββββββββββββββββββββββΌββββββββββΌβββββββββΌββββββββββββββββββββ€
β main β sensor β 1 β none β none β
β main β actuator β 1 β none β none β
β main β dictionaryfabric11101.adjustValues β 1 β none β none β
βββββββββββββ΄βββββββββββββββββββββββββββββββββββββ΄ββββββββββ΄βββββββββ΄ββββββββββββββββββββ
Automation Conditions
βββββββββββββ¬βββββββββββββββββββββββββββββββββββββ¬ββββββββββ¬βββββββββ¬ββββββββββββββββββββ
β Component β Capability β Version β Values β Visible Condition β
βββββββββββββΌβββββββββββββββββββββββββββββββββββββΌββββββββββΌβββββββββΌββββββββββββββββββββ€
β main β sensor β 1 β none β none β
β main β actuator β 1 β none β none β
β main β dictionaryfabric11101.adjustValues β 1 β none β none β
βββββββββββββ΄βββββββββββββββββββββββββββββββββββββ΄ββββββββββ΄βββββββββ΄ββββββββββββββββββββ
Automation Actions
βββββββββββββ¬βββββββββββββββββββββββββββββββββββββ¬ββββββββββ¬βββββββββ¬ββββββββββββββββββββ
β Component β Capability β Version β Values β Visible Condition β
βββββββββββββΌβββββββββββββββββββββββββββββββββββββΌββββββββββΌβββββββββΌββββββββββββββββββββ€
β main β sensor β 1 β none β none β
β main β actuator β 1 β none β none β
β main β dictionaryfabric11101.adjustValues β 1 β none β none β
βββββββββββββ΄βββββββββββββββββββββββββββββββββββββ΄ββββββββββ΄βββββββββ΄ββββββββββββββββββββ
I tried deleting the sensor and actuator but it didnβt make any difference.
So, I put the vid into my DTH but nothing displays:
When I create the device type, everything seems to be there:
I am wondering if my device-config needs something else or maybe I am still not referencing the elements correctly in my DTH. My DTH currently looks like this:
metadata {
definition (name: "Adjust New Value Tiles", namespace: "dictionaryfabric11101", author: "guxdude", runLocally: true,
mnmm: "SmartThingsCommunity", vid: "618643e0-5a25-3e10-be53-a8898884c0ec") {
capability "Actuator"
capability "Sensor"
capability "dictionaryfabric11101.adjustValues"
attribute "GVstatus", "string"
command "ResetGV"
} // End of definition
tiles(scale:2) {
valueTile("Label1", "device.labelOne", width: 3, height: 1, decoration: "flat") {
state("val", label:'${currentValue}', foregroundColor: "#000000", backgroundColor: "#FFFFFF", defaultState: true )
}
valueTile("Value1", "device.valueOne", width: 3, height: 2, decoration: "flat") {
state("val", label:'${currentValue}')
}
valueTile("Label2", "device.labelTwo", width: 3, height: 1, decoration: "flat") {
state("default", label:'${currentValue}', foregroundColor: "#000000", backgroundColor: "#FFFFFF" )
}
valueTile("Value2", "device.valueTwo", width: 3, height: 2, decoration: "flat") {
state("default", label:'${currentValue}' /*, foregroundColor: "#FFFFFF",
backgroundColors: [ [value: -1, color: "#FF0000"], [value: 0, color: "#000000"], [value: 1, color: "#00FF00"] ]*/)
}
valueTile("Label3", "device.labelThree", width: 3, height: 1, decoration: "flat") {
state("default", label:'${currentValue}', foregroundColor: "#000000", backgroundColor: "#FFFFFF" )
}
valueTile("Value3", "device.valueThree", width: 3, height: 2, decoration: "flat") {
state("default", label:'${currentValue}' /*, color: "#000000",
backgroundColors: [ [value: -1, color: "#FF0000"], [value: 0, color: "#000000"], [value: 1, color: "#00FF00"] ]*/)
}
valueTile("Label4", "device.labelFour", width: 3, height: 1, decoration: "flat") {
state("default", label:'${currentValue}', foregroundColor: "#000000", backgroundColor: "#FFFFFF" )
}
valueTile("Value4", "device.valueFour", width: 3, height: 2, decoration: "flat") {
state("default", label:'${currentValue}' /*, foregroundColor: "#FFFFFF",
backgroundColors: [ [value: -1, color: "#FF0000"], [value: 0, color: "#000000"], [value: 1, color: "#00FF00"] ]*/)
}
// "Value1" will appear in the things view
main([
"Value1"
])
// these tiles will appear in the Device Details view
// (order is left-to-right, top-to-bottom)
details([
"Label1","Value1",
"Label2","Value2",
"Label3","Value3",
"Label4","Value4"
])
} // End of tiles
// preferences {
// input name: "Positivep", type: "boolean", title: "Positive value", description: "Is setpoint positive?", required: true, defaultValue: true
// } // End of preferences
} // End of metadata
I am thinking I am not referencing the values correctly in my tile definitions? Or maybe I need to reference something from the presentation? The example sort of leaves me hanging for how to actually use this once it is created.
Any suggestions are appreciated. Sorry for the long post.
I forget whether it does the connected screen or the broken cloud when your attributes donβt have values, but youβll definitely need to have them be non-null for it to display properly. Drop in an updated() function that initializes them all to random values.
Also, in my testing early on (havenβt tried recently) I was unable to get more than a single display type to show per capability. Hopefully that will change or has changed.
Then thereβs the cache issue. I created some stuff today that isnβt showing on my regular phone - just getting the connected screen. I deleted and reinstalled the ST app on my spare phone though and I can see everything there.
What a great suggestion. I already had an installed() function so I tried various forms until the values actually showed up. Turns out this is what worked:
def installed() {
sendEvent(name: "labelOne", value: "First Label", displayed: false)
sendEvent(name: "valueOne", value: 41, displayed: false)
So I updated the valueTiles statements to use this same simple syntax but still no display. But all the values showed up when I did an Edit-Update on my device. Progress!
Absolutely. Seeding the attribute values or prompting an early refresh is one of the key things to do when making DTHs new app friendly. Explicitly setting units makes a difference too.
I am slightly dubious about whether the appβs requirement for non-null values is actually reasonable. I think it probably should be considered a bug. Requiring units when the capability explicitly defines default units is definitely a bug.
I donβt have an issue with not having more than one detail type per attribute (though it would make comparitive testing quicker) , but not having more than one attribute per capability would be ridiculous, even temporarily.
Youβll find Edit-Update calls install() but not update() unless you also do something like change the device name (as you do to bust the caching).
If you change handler Settings in the mobile app youβll get update() called. In the IDE if you edit a device it is as I described.
Here is an Edit-Update:
11:43:55 PM: info Back Door Contact [Lumi Mijia MCCGQ01LM] [installed]
Here is Edit-Change Device Name-Update:
11:51:55 PM: info Back Door Contact [Lumi Mijia MCCGQ01LM cb] [updated]
11:51:55 PM: info Back Door Contact [Lumi Mijia MCCGQ01LM cb] [installed]
Interesting looks like that behavior has changed. Just need to keep that in mind while creating DTHβs since Iβm noticing that update is no longer called after install like it does during a pairing process (atleast on my setup).
I looked into things unusually methodically (for me) earlier this year. You may also want to keep an eye on the configure() method to see when that is called. Obviously it depends on the Configure capability but that also depends on how you update a device.
My feeling too is that things have changed, possibly some time in 2019. There are too many older handlers that always called update() from install() even though it wasnβt supposed to be necessary (a variation is calling an initialize() routine from all over the place), and found it necessary to debounce install() and update() as they were called repeatedly (I used to do that, I generally find it unnecessary and unwise now). Apart from the new appβs Settings, which call update() everytime you change anything instead of waiting for you to finish and giving you a βsaveβ option, things just seem to be cleaner now.
I know this is drifting a bit off-topic for this thread, but it is something worth bearing in mind when you are trying to make handlers behave in the new app. Some would really benefit from being cleaned up from top to bottom.
Iβm getting a server error when launching the CLI.
[ERROR] login-authenticator - received βserver_errorβ error when trying to authenticate
[ERROR] login-authenticator - Unexpected server error.
CLI version: [v0.0.0-pre.8]
Steps taken:
- Download CLI (windows version)
- Unziped to C:\smartthings
- Renamed exe file to smartthings.exe
- Open CMD (as Administrator and tried without Admin privs)
- Issued command smartthings.exe --help
a) this works - Issued command smartthings.exe apps
- Browser launches
- Enter credentials
- Prompted to allow access to smartthings-cli
- Clicked button to authorize access
- Exception encountered
I have verified credentials (itβs definitely not a bad username or password). When executing smartthings.exe I verified the appropriate folder is automatically created in %LOCALAPPDATA%@smartthings\cli. I saw a similar issue was encountered by others but this does not appear to be the cause as the folder exists.
I seem to be missing something somewhere. Any help is appreciated. Thanks.
Hi, @mikedill24
In the meantime we take a look at this, I recommend you to create a personal access token and use it with the --token
flag, e.g.:
$ smartthings devices --token <personal_access_token>
Or you can configure it as expressed here.
I canβt get my custom capability to work. Not sure if Iβm missing something (most likely) or if itβs a bug or a combination.
A couple of points/questions:
- I canβt get anything to show up in Live Logging. I read somewhere this was previously reported. Is this still an outstanding issue? Or, is there a workaround or specific manner to get logs to show up? This would help in troubleshooting.
- detailView is not actionable. Meaning, the button does not actuate. The tile renders but itβs read-only. I read this was an issue at the detail level. Is this still outstanding?
I followed the tutorial and have everything in place, I believe. I have my capability created and created a DTH. Since detailView is not working Iβve added the command at the Dashboard level to test this out.
The button on the Dashboard is actionable, I can press it, it just not do anything.
Iβm simply trying to call a URL when I push a button. Iβll get more advanced once I get this working but for now itβs a simple URL call.
This is what I have for capability:
{
"id": "XXXXX.launchUrl",
"version": 1,
"status": "proposed",
"name": "Launch URL",
"attributes": {
"url": {
"schema": {
"type": "object",
"properties": {
"value": {
"type": "string"
}
},
"additionalProperties": false,
"required": [
"value"
]
},
"setter": "setURL",
"enumCommands": []
}
},
"commands": {
"setURL": {
"name": "setURL",
"arguments": [
{
"name": "value",
"optional": false,
"schema": {
"type": "string"
}
}
]
}
}
}
Should the status be βproposedβ? Iβve seen many posts where itβs in this status but Iβve also seen other posts where the status is βliveβ.
This is what I have for capability presentation:
{
"dashboard": {
"states": [
{
"label": "URL Controller"
}
],
"actions": [
{
"displayType": "pushButton",
"pushButton": {
"command": "setURL",
"argument": "url.value"
}
}
],
"basicPlus": []
},
"detailView": [
{
"label": "Call URL",
"displayType": "pushButton",
"pushButton": {
"command": "setURL",
"argument": "url.value"
}
}
],
"automation": {
"conditions": [
{
"label": "Call URL",
"displayType": "textField",
"textField": {
"value": "url.value"
},
"emphasis": false
}
],
"actions": [
{
"label": "Call URL",
"displayType": "textField",
"textField": {
"command": "setURL"
}
}
]
},
"id": "XXXX.launchUrl",
"version": 1
}
In the arguments Iβve tried url.value as well as setURL.value.
This is what I have in the DTH (the structure and almost all content is from an example in this post):
metadata {
definition (name: "URL Call-New App", namespace: "Dizzle", author: "Mike Dill", mnmn: "SmartThingsCommunity", vid: "XXXXXXXXXXX") {
capability "XXXXX.launchUrl"
}
}
//**
def parse(String description) {
log.trace "parse($description)"
}
// *** [ Initialization Methods ] *********************************************
def refresh() {
log.trace "Executing 'refresh'"
initialize()
}
def installed() {
log.trace "Executing 'installed'"
initialize()
}
def updated() {
log.trace "Executing 'updated'"
initialize()
}
private initialize() {
log.trace "Executing 'initialize'"
sendEvent(name: "url", value: "http://someURL")
}
def setURL(String arg) {
log.trace "Executing URL: ${arg}"
sendEvent(name: "url", value: "http://someURL")
}