Custom Capability and CLI Developer Preview

[jody.albritton (Jody)]

@Alwas

Before telling users to migrate to the new app, wouldn’t it be better to make sure it works first? to have your own beta testers to make sure the new app is functional before you release it to the masses? I think you’re going about things the wrong way around.

This is specifically related to third party developers and third party devices with custom capabilities. We released this into the open ahead of the full migration. We cannot possibly test every custom attribute/command combo conversion to a custom capability internally. This has to be done in coordination with our external developers. If you see the title of this thread, is is not being advertised as a production ready ready tool. We are testing internally but we also need feedback from our external developers on how to move forward. The users that have been offered the (optional) migration have been targeted to have the devices that do work in the new app today.

[tweason]

Maybe it would be better if there was a way to change between the production and developer environments (or even stand up and point our hubs to local servers) on the hubs. That would be something worth looking at. I started watching this thread to wait on some significant improvements before I even bother starting to work on my custom apps and device handlers.

[SZaf]

The users that have been offered the (optional) migration have been targeted to have the devices that do work in the new app today.

I want to support you on that.

I have no problem spending a little time and try your new features. No one forces me and I am aware of the chance things don’t work. It also gives me the opportunity to ask for new features in this nice system that you develop (On that note - a simple way to upload custom designed “displayTypes” will be very welcomed…).

I want to migrate to the new app but I’m not ready to give up on the few custom devices that I have (and the ability to build more in a simple way). So count me in the list of users to test features - If I find the time then I will.

btw - the custom capabilities still haven’t reappeared. Also after creating a new DTH and a new vid it doesn’t show at all (I played with your example DTH).

[vseven (Allan)]

@jody.albritton

The users that have been offered the (optional) migration have been targeted to have the devices that do work in the new app today.

Yeah…that doesn’t seem to be true. Got the notice in mine and I have multiple devices using the ST_Anything integration in which some DTH’s haven’t been fully updated, most work but some do not and I have spent a lot of time trying to get them too (unsuccessfully). Even extremely simple devices, just temperature measurement, will show “Checking status…” in the new app and when you click on them show just fine. A RGB bulb implementation which is based directly on the standard ST one (copy and paste for the most part other then the send to device) works perfect in classic but in the new app kinda…you click a command (on/off, dimmer, color picker, etc) and the command works and the light changes but then it hangs for 20 seconds and pops up “A network or server error occurred. Try again later”. Click ok and you can do another command, successfully, but again hangs and pops up the error.

Not sure who is getting the migration notice but it is definitely not only people with “working” types.

[Panos]

Hello.
When I issue the command
$ smartthings presentation:device-config:create -j -i deviceConfig.json

I get the following error:

[2020-08-03T19:47:52.650] [ERROR] cli - caught error Error: Request failed with status code 400: {“requestId”:“4F9A7D29-DE7A-42C1-A5A9-9922C7F1646C”,“error”:{“code”:“UnexpectedError”,“target”:null,“message”:“unsuccessful-http-call status=400”,“details”:}}

Any suggestions?

deviceConfig.json

{
“mnmn”: “SmartThingsCommunity”,
“vid”: “1b631f28-0d29-3474-a612-e5eff44ac98e”,
“type”: “dth”,
“dpInfo”: null,
“iconUrl”: null,
“dashboard”: {
“states”: [
{
“component”: “main”,
“capability”: “sensor”,
“version”: 1,
“values”: ,
“visibleCondition”: null
},
{
“component”: “main”,
“capability”: “boardmedia46837.htequivalentdose”,
“version”: 1,
“values”: ,
“visibleCondition”: null
}
],
“actions”: [
{
“component”: “main”,
“capability”: “sensor”,
“version”: 1,
“values”: ,
“visibleCondition”: null
},
{
“component”: “main”,
“capability”: “boardmedia46837.htequivalentdose”,
“version”: 1,
“values”: ,
“visibleCondition”: null
}
]
},
“detailView”: [
{
“component”: “main”,
“capability”: “sensor”,
“version”: 1,
“values”: ,
“visibleCondition”: null
},
{
“component”: “main”,
“capability”: “boardmedia46837.htequivalentdose”,
“version”: 1,
“values”: ,
“visibleCondition”: null
}
],
“automation”: {
“conditions”: [
{
“component”: “main”,
“capability”: “sensor”,
“version”: 1,
“values”: ,
“visibleCondition”: null
},
{
“component”: “main”,
“capability”: “boardmedia46837.htequivalentdose”,
“version”: 1,
“values”: ,
“visibleCondition”: null
}
],
“actions”: [
{
“component”: “main”,
“capability”: “sensor”,
“version”: 1,
“values”: ,
“visibleCondition”: null
},
{
“component”: “main”,
“capability”: “boardmedia46837.htequivalentdose”,
“version”: 1,
“values”: ,
“visibleCondition”: null
}
]
}
}

[erickv (Erick)]

Hi, @Panos

Thanks for sharing!

Our team is aware of this issue. I’ll proceed to include this information to the report.

Additionally, could you please confirm that your capability already has a defined presentation?

[Panos]

@erickv

@erickv

Additionally, could you please confirm that your capability already has a defined presentation?

Thanks for your reply.
Yes, at first I created a new “state” presentation to use this capability

Also I was unable to delete a custom capability.
I get the following error:

$ st capabilities:delete 1
capability {“id”:“1”} deleted
(node:7864) UnhandledPromiseRejectionWarning: Error: Request failed with status code 500
at createError (/snapshot/smartthings-cli/node_modules/axios/lib/core/createError.js:16:15)
at settle (/snapshot/smartthings-cli/node_modules/axios/lib/core/settle.js:17:12)
at IncomingMessage.handleStreamEnd (/snapshot/smartthings-cli/node_modules/axios/lib/adapters/http.js:236:11)
at IncomingMessage.emit (events.js:327:22)
at IncomingMessage.EventEmitter.emit (domain.js:482:12)
at endReadableNT (_stream_readable.js:1221:12)
at processTicksAndRejections (internal/process/task_queues.js:84:21)
(node:7864) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see Command-line API | Node.js v21.2.0 Documentation). (rejection id: 2)
(node:7864) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

[erickv (Erick)]

Thanks, @Panos

You can delete your custom capability by running the smartthings capabilities:delete command and passing the index once you’ve been prompted to declare which capability you want to remove.

[Panos]

@erickv

smartthings capabilities:delete

Hi, I tried that but still no luck:

$ st capabilities:delete

capability {} deleted
(node:8201) UnhandledPromiseRejectionWarning: Error: Request failed with status code 500
    at createError (/snapshot/smartthings-cli/node_modules/axios/lib/core/createError.js:16:15)
    at settle (/snapshot/smartthings-cli/node_modules/axios/lib/core/settle.js:17:12)
    at IncomingMessage.handleStreamEnd (/snapshot/smartthings-cli/node_modules/axios/lib/adapters/http.js:236:11)
    at IncomingMessage.emit (events.js:327:22)
    at IncomingMessage.EventEmitter.emit (domain.js:482:12)
    at endReadableNT (_stream_readable.js:1221:12)
    at processTicksAndRejections (internal/process/task_queues.js:84:21)
(node:8201) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:8201) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

-EDIT-

The correct syntax is:

smartthings capabilities:delete boardmedia46837.equivalentDose 1

It’s working. My apologies

[tweason]

@jody.albritton

The users that have been offered the (optional) migration have been targeted to have the devices that do work in the new app today.

I am going to be another to contradict you on this. Several of my custom devices and smart apps I know do not work in the new app. Or, if they do, they do not work the way they do in the old app (such as color temperature bulbs from ikea that I have grouped to work together)

Think I will pass until I see some better results and stop seeing all the capabilities issues etc. popping in my notifications from this thread.

If ST wants to keep users as customers, they REALLY need to fix it so that we do not have to re-write everything from scratch. If I have to do that, I am going to write for another platform.

[jody.albritton (Jody)]

That’s why I added the optional bit. Some devices that are custom can and do function with the stock handlers so you may not need to re-write anything. For everything else we are working on tools to create custom capabilities that do work in the current app. If you haven’t tried the stock handlers in a while you might want to give them another go. Else, specify which devices are giving you pause on migrating

[tweason]

So, I have a custom presence sensor (virtual) that allows me to switch between phones. It also allows me to manually toggle if my phone presence sensor doesn’t detect arrival or departure. It doesn’t even doesn’t even show in the new app. I have multiple routines that I have built over time to automate things depending on the virtual presence sensors that do not show up in the new app. It shows in the IDE and the old app, but it is not available in the new app.

I also have MULTIPLE light groups using Trendsetter that allow me to control multi light fixtures and control the color temperature. While I can toggle them on/off in the new app, I cannot control the color temperature there.

Also, have several smart locks being managed by Rboy apps. But I see he is having issues with trying to get his apps converted. According to the wording of the migration tool in the app, I may not be able to use his app to manage my locks?

I can supposedly keep my routines? But I will not be able to edit the ones I currently have?

Still not sure what happens to my custom notifications on smart home monitor. It appears from the verbiage in the migration tool in the app that they will go away?

So, based on the fact that I do have devices in my IDE that either do not even show in the new app, or do not work properly in the new app, the statement that the only people being asked to migrate are those that only have devices that are compatible is incorrect.

I believe someone else mentioned that it would be better if the new system was actually ready for production before it was pushed out to everyone. From where I sit, it is not. Yet, every day, I have to scroll past the erroneous “The new smartthings app is ready for you” banner.

Once again, if I had any confidence that I could get this all done in a weekend and be done with it, I might attempt to go through my 156 devices and individually verify that each of them are working as expected and verify all the routines have successfully converted to automations and scenes.

Smartthings absolutely has the legal right to make their users jump through all these hoops to keep their existing set ups. I am not questioning that. However, I planned on waiting till most (or the majority of some) of these bugs were worked out before I wasted time transitioning. I have no desire to be your beta tester and redo everything I spent so much time setting up. If I am going to spend that time again, it is likely going to be on something I host locally and don’t have to upgrade/change unless I want to.

[jkp]

@tweason

virtual presence sensors that do not show up in the new app.

I have a simulated presence sensor that shows in the new app

[vseven (Allan)]

Smart Home Monitor is a big one for me also. I like the new app and I primarily use it. But you have a API to access the old Smart Home Monitor so things like ActionTiles can use it to arm/disarm easily. There is no direct access on the new system (although ActionTiles does have a work around) but it would be nice if that was opened back up. I have a tablet that I use for quick access to the system and it’s so much more convenient then opening the app each time and just being able to tap a icon on a wall mounted tablet:

[Automated_House (Jimmy)]

Is it possible to create a device profile in the dev workspace as outlined here and then use it in a Groovy DTH?

SmartThings Developers

[erickv (Erick)]

Hi, @Automated_House

Yes, however, to make it effective you’ll need to apply some changes to the device profile. Below are some steps on how to proceed:

• Instead of using the --dth flag while generating your device config, pass your device profile’s Id.
• Update your device profile’s mnmn and vid values that the device-config has created.

Note: To save your device profile JSON and update it, you can run the following command:

smartthings deviceprofiles <profileId> -j -o <profile.json>

For the moment, I’d recommend you to create your device profiles directly from the ST CLI with the following structure:

{
    "name": "<profileName>",
    "components": [
        {
            "label": "main",
            "id": "main",
            "capabilities": [
                {
                    "id": "namespace.<capabilityId>",
                    "version": 1
                }
            ],
            "categories": []
        }
    ],
    "metadata": {}
}

[Automated_House (Jimmy)]

ugh, i was hoping to not have to use the CLI if I was using standard capabilities. I mostly use my work laptop which blocks installing the CLI, so its easier to use the online workspace. Hopefully and some point in the future it call all be done in the workspace.

[RBoy (www.rboyapps.com - Making SmartThings Easy!)]

Erick, is there any advantage to using device profiles instead of dth’s to create a custom profile at this time?

[cscheiene]

@erickv is this issue resolved? The custom capabilities have not returned in the new app for me

[flannanl]

@jody.albritton Is there a way to update the presentation:device-config for my device handler? I did a presentation:device-config:create with an updated input JSON, but it seems the update never applies.