if ST could speak do you think they might say - “please stop sharing our highly confidential private plans with the community.”? 
1 Like
I know you were just kidding, but just to be clear, they announced that the IDE was being retired as phase 3 and they’ve already completed phases 1 and 2 so based on that I’d say it’s safe to assume they plan on retiring the IDE in 2021.
I just generated a new device config for an existing handler that didn’t already have one and I can’t get it to display any of the custom capabilities so they definitely broke something this week…
I’m dead in the water until they fix this which completely sucks because I have 3 more handlers to write…
Hi @nayelyz,
Here is the definition of my capability.
{ "id": "tigerpanel18153.colorTemperature", "version": 1, "status": "proposed", "name": "Color Temperature", "attributes": { "colorTemperature": { "schema": { "type": "object", "properties": { "value": { "type": "integer", "minimum": 2200, "maximum": 7000 } }, "additionalProperties": false, "required": [ "value" ] }, "setter": "setColorTemperature", "enumCommands": [] } }, "commands": { "setColorTemperature": { "name": "setColorTemperature", "arguments": [ { "name": "value", "optional": false, "schema": { "type": "integer", "minimum": 2200, "maximum": 7000 } } ] } } }
And here is the presentation of my capability.
{ "dashboard": { "states": [ { "label": "{{colorTemperature.value}} {{colorTemperature.unit}}" } ], "actions": [], "basicPlus": [] }, "detailView": [ { "label": "Color Temperature", "displayType": "slider", "slider": { "range": [ 2200, 7000 ], "step": 1, "unit": "colorTemperature.unit", "command": "setColorTemperature", "argumentType": "integer", "value": "colorTemperature.value", "valueType": "integer" } } ], "automation": { "conditions": [ { "label": "Color Temperature", "displayType": "slider", "slider": { "range": [ 2200, 7000 ], "step": 1, "unit": "colorTemperature.unit", "value": "colorTemperature.value", "valueType": "integer" } } ], "actions": [ { "label": "Color Temperature", "displayType": "slider", "slider": { "range": [ 2200, 7000 ], "step": 1, "unit": "colorTemperature.unit", "command": "setColorTemperature", "argumentType": "integer" } } ] }, "id": "tigerpanel18153.colorTemperature", "version": 1 }
Then it shows as followed pictures.
I also create a new capability as Color Temperature State that modified the slider display type to the state display type.
The definition of Color Temperature State capability:
{ "id": "tigerpanel18153.colorTemperatureState", "version": 1, "status": "proposed", "name": "Color Temperature State", "attributes": { "colorTemperature": { "schema": { "type": "object", "properties": { "value": { "type": "integer", "minimum": 2200, "maximum": 7000 } }, "additionalProperties": false, "required": [ "value" ] }, "setter": "setColorTemperature", "enumCommands": [] } }, "commands": { "setColorTemperature": { "name": "setColorTemperature", "arguments": [ { "name": "value", "optional": false, "schema": { "type": "integer", "minimum": 2200, "maximum": 7000 } } ] } } }
The presentation of Color Temperature State capability:
{ "dashboard": { "states": [ { "label": "{{colorTemperature.value}} {{colorTemperature.unit}}" } ], "actions": [], "basicPlus": [] }, "detailView": [ { "label": "Color Temperature", "displayType": "state", "state": { "label": "colorTemperature.value", "unit": "colorTemperature.unit" } } ], "automation": { "conditions": [ { "label": "Color Temperature", "displayType": "slider", "slider": { "range": [ 2200, 7000 ], "step": 1, "unit": "colorTemperature.unit", "value": "colorTemperature.value", "valueType": "integer" } } ], "actions": [ { "label": "Color Temperature", "displayType": "slider", "slider": { "range": [ 2200, 7000 ], "step": 1, "unit": "colorTemperature.unit", "command": "setColorTemperature", "argumentType": "integer" } } ] }, "id": "tigerpanel18153.colorTemperatureState", "version": 1 }
definition (name: "colorTemperatureState", namespace: "tigerpanel18153", author: "Ray", mnmn: "SmartThingsCommunity", vid: "1e670ea6-10f2-34db-b689-e434a48a93fa") { capability "tigerpanel18153.colorTemperatureState" }
This is my device presentation from device list:
{ "manufacturerName": "SmartThingsCommunity", "presentationId": "1e670ea6-10f2-34db-b689-e434a48a93fa", "mnmn": "SmartThingsCommunity", "vid": "1e670ea6-10f2-34db-b689-e434a48a93fa", "iconUrl": null, "dashboard": { "states": [ { "label": "{{colorTemperature.value}} {{colorTemperature.unit}}", "alternatives": null, "group": null, "capability": "tigerpanel18153.colorTemperatureState", "version": 1, "component": "main", "visibleCondition": null } ], "actions": [], "basicPlus": [] }, "detailView": [ { "capability": "tigerpanel18153.colorTemperatureState", "version": 1, "label": "Color Temperature", "displayType": "state", "toggleSwitch": null, "standbyPowerSwitch": null, "switch": null, "slider": null, "pushButton": null, "playPause": null, "playStop": null, "list": null, "textField": null, "numberField": null, "stepper": null, "state": { "label": "colorTemperature.value", "unit": "colorTemperature.unit" }, "multiArgCommand": null, "component": "main", "visibleCondition": null } ], "automation": { "conditions": [ { "capability": "tigerpanel18153.colorTemperatureState", "version": 1, "label": "Color Temperature", "displayType": "slider", "slider": { "range": [ 2200, 7000 ], "step": 1, "unit": "colorTemperature.unit", "value": "colorTemperature.value", "valueType": "integer" }, "list": null, "numberField": null, "textField": null, "emphasis": null, "exclusion": [], "component": "main", "visibleCondition": null } ], "actions": [ { "capability": "tigerpanel18153.colorTemperatureState", "version": 1, "label": "Color Temperature", "displayType": "slider", "slider": { "range": [ 2200, 7000 ], "step": 1, "unit": "colorTemperature.unit", "command": "setColorTemperature", "argumentType": "integer" }, "list": null, "textField": null, "numberField": null, "multiArgCommand": null, "emphasis": null, "component": "main", "visibleCondition": null, "exclusion": [] } ] }, "dpInfo": [ { "os": "ios", "dpUri": "plugin://com.samsung.ios.plugin.stplugin/assets/files/index.html", "operatingMode": null }, { "os": "android", "dpUri": "plugin://com.samsung.android.plugin.stplugin", "operatingMode": null }, { "os": "web", "dpUri": "wwst://com.samsung.one.plugin.stplugin", "operatingMode": null } ], "language": null }
In my side, the state display type works incorrectly in dashboard view and detail view.
I see the battery presentation from smartthings original, it uses slider display type, but I uses the slider display type in my custom capabilities presentation, those detail view are very different. If I want to show the light bar that could display current value like battery tile in detail view, how could I do?
The battery presentation from smartthings original:
{ "dashboard": { "states": [ { "label": "{{battery.value}} {{battery.unit}}" } ], "actions": [], "basicPlus": [] }, "detailView": [ { "label": "___PO_CODE_SMARTTHINGS_DREAM_SAC_TMBODY_BATTERY", "displayType": "slider", "slider": { "range": [ 0, 100 ], "unit": "battery.unit", "value": "battery.value", "valueType": "integer" } } ], "automation": { "conditions": [ { "label": "___PO_CODE_SMARTTHINGS_DREAM_SAC_TMBODY_BATTERY", "displayType": "numberField", "numberField": { "value": "battery.value", "valueType": "integer", "unit": "battery.unit", "range": [ 0, 100 ] } } ], "actions": [] }, "id": "battery", "version": 1 }
Well, I gave up on getting things to display correctly on the new app. I have moved to Hubitat and everything is off my SmartThings hubs now. I am much happier!
4 Likes
I haven’t experimented for a few days, but the issue was more that the nature of the VID had changed, or rather the nature of how it was used by the app.
If I created a new vidX that included customCapabilityA, then I could still get customCapabilityA to display. However it is the way that customCapabilityA was displayed that was the issue. It was no longer displaying one way with vidX and another with vidY and it made no difference if devices dev1 and dev2 that used the same vidY had been cache busted or not.
All that mattered was what the latest capability presentation for customCapabilityA was. It didn’t matter what each VID said.
The really big problem was getting the app to pick up the latest customCapabilityA presentation. I just couldn’t do it even by clearing the cache on the app or stopping and starting it. Then I’d give up late in the evening and wake up in the morning and find it everywhere in the app.
That was the show stopper for me. I can change the way in which I do things to avoid screwing with live capabilities, but I need to be able to test new capability presentations instantly and I’d lost that.
Thanks, that did it.
The docs aren’t updated to reflect this, however. It uses the explicit name for the overridden value as it’s listed in the capability.
However it seems that while this does it for ST, it is hardcoded in the google home implementation so in there the max stays at 32 (which isn’t even the default max for ST).
Can we override the labels from the config?
Also, how should I go for overriding lists entries with alternatives and such? “enum” instead of range doesn’t seem to do it.
The reason I am asking is because quite a few of the “thermostatMode” options (away, day off, custom, schedule) show up as _PO_CODE_THERMOSTAT_THERMOSTAT_MODEwhatever the name of the mode is whenever i use the custom vid, and are showing as they should when using the DTH without the vid.
Curious thing is that when i check the presentation the names are all fine there, but are broken in the app.
I can’t get any of the new vids I’ve generated tonight to display. I’ve had no problems with the 15+ handlers I’ve created device configs for in the past so either something changed within the last few days or my account is messed up…
Since there’s no way to update or delete device configs, I must have at least 100 floating out there so if it’s not a global problem then maybe that something to do with it…?
so we have one issue where the new vid won’t display and another where only the newest version of the custom capability presentation is displayed irrespective of the vid in use.
i realize ST sees custom capabilities as a way for device manufacturers creating their own capabilities via these new APIs. but maybe a bit more communication from them on what’s going on with the open issues and what the near term plans are for upcoming releases would help the tinkerers in the community stay on the platform.
recent posts in this thread would suggest that phase 2 is far from complete.
1 Like
I didn’t include the SmartThingsCommunity mnmn in one of the handlers I was fighting with which would explain the behavior I was seeing, but I added it and tried all the usual techniques to force it to update and I’m still only seeing tiles for button and battery
The other handler I was fighting with did have the correct mnmn so I still think there’s a new issue, but we should probably wait for someone else to confirm the behavior I’m seeing before officially declaring it a bug.
Sorry for spreading misinformation and thank you for correcting me.
I mixed up the “changes to the legacy platform” topic with the “updates to the platform” topic and thought that since all the dates they provided have past, the phase 2 changes were complete. Although it looks like there is still a change in that "updates’ topic that didn’t have a date so I don’t know what I was thinking…
1 Like
didn’t think you were spreading misinformation … just thought you were taking the ST provided dates in the legacy platform update thread a bit literally. 
the only meaningful definition of complete here is developers using the ST platform APIs are able to do so in a consistently reliable manner. our collective experiences shared via multitude of daily posts on this thread would suggest that it is far from complete. that’s from a developer point of view. no idea what ST thinks.
1 Like
I have been down this road before also. Once I tried everything and it wouldn’t update and I just gave up. the next day I went to look at it again and it had finally registered my change. It is so frustrating and such a colossal waste of time.
1 Like
@nayelyz
ok. as you suggested I swapped the capabilities and now I am using “faithboard04631.coffeemachine” for the selectitem
however, I still have the same “network error occured” problem when I select an item from that list.
so both of my capabilities have the issue.
what is the problem ?
you’ve mentioned that you’d investigate that further. found anything ?
The labels for the Thermostat mode appeared fine on my device.
Then I changed the supported values using the attribute supportedThermostatModes with:
//eventType: "ENTITY_UPDATE" can be omitted
sendEvent(name: "supportedThermostatModes", value: ["off", "heat", "cool"], eventType: "ENTITY_UPDATE", displayed: false)
Please, share the configuration of your device presentation and a picture of how it’s displayed.
These are okay in here, the problem appears with other modes like “away”, “schedule”, “custom”, etc. And again, they show up fine when not using a vid, but are garbled when I use a vid, despite the fact that they are okay when i check the presentation from the CLI
When I checked today my iPhone was showing the correct UI, but my Android still wasn’t.
Forcing the app to stop didn’t work, but clearing the app’s data and cache caused the mobile app to display the download prompt when I opened the device and now it’s showing the custom capabilities.
I have a few more handlers I plan on updating this weekend so I’ll report back if I run into the same issue with those…
What does this represent?
it’s actually pretty cool. in rooms manager app i have settings to use thermostat or in room ac and/or heater to manage the temperature of the room. in the new app the settings are controllable through the thermostat modes card.
by default thermostat modes has a command named emergency mode which i have no use for in my app. after sending that event and removing emergency as a supported command here’s what it looks like afterwards when i click on the gear icon on the mode card:
for another room which has no thermostat or ac or heater after sending that event with all other commands except off removed here’s what it looks like:
the gear icon is no longer present since off is now the only supported thermostat mode for that room.
imagine it works the same way for other capabilities and adds extensibility for any capability.
1 Like
@bangali This feature has been there for a very long time and it’s implementation is specific to the new ST app using the presentation layer conditional attributes.
What’s new I see is eventType: "ENTITY_UPDATE”. The supportedThermostatModes works even without this attribute. So what’s this new attribute in sendEvent @nayelyz? What is eventType and what are the supported values?
didn’t know that could be done in classic as well to dynamically update the supported commands for a device using sendEvent … will have to give that a try.
thank you.
Not Classic, i mean this feature has been in the new app for about a year AFAIK, but the sendEvent attribute is new. It (used to) work without this attribute, so my question is what’s this new attribute in sendEvent?