Child devices in new app

I have a Qubino 1D flush relay. It shows up and works correctly in the classic app (and on https://graph.api.smartthings.com/). With the new app I am not able to see the status of the child device.
Does anyone know if this is due to a general lack of child devices in the new app or if there is way to add the child device?

Can you elaborate on this?

In the old app the status shows up as seen in the picture to the left. In the new app there is no such illustration. In addition I am able to use the “Smart Home Monitor” to create a rule that informs me if the garage has been left open for more than 30 min.

In the new app there is no such illustration. I only got the activity history (which I only realized after taking the picture to illustrate this post). In addition I am not able to use the status of the contact sensor status as a condition for an automation the way I could using the classic app.

The DTH needs to be updated to support the new app

1 Like

Here is an example groovy dth

2 Likes

@jody.albritton

Is there some info on how the new app displays the groovy DTH?

If I add capabilities to the DTH it will display some of them in the new app, but not all. If I add “ocfDeviceType”, it will change the main tile. If I add “vid” it will change the layout the a pre-made one.

For example Im trying to add: capability “Carbon Dioxide Measurement” to display in the new app, but I cant find a way to do it in the groovy DTH. The ST docs says that the capability is live

I will see if there is someone from the hub connected team who can better respond today.

From our docs

Step 3: Create a Device Handler in the IDE

A Device Handler is a representation of a physical device in the SmartThings platform. It is responsible for communicating between the actual device and the SmartThings platform.

  1. Under “My Device Handlers”, click “Create a New Device Handler”.
  2. In the From Template tab, select the protocol (Zigbee Home Automation [HA] or 3.0; Zigbee Light Link [ZLL]; Z-Wave) and capabilities that correspond to your device.
  • If there is no Device Handler match (i.e. a New Device Handler Form is created), we recommend creating a Device Handler From Example . See below.
  • If there is a Device Handler match, the corresponding Device Handler is shown. Enter the required fields to create a unique fingerprint for your device. Required fields may include: Manufacturer Name/ID, Product ID, Model Name/ID, Device Join Name, Namespace, Device Handler Name.
  1. Click the “Update Existing Device Handler” or “Create” button. You will see the template code.
  2. Click “Save”. Then click “Publish” and “For Me” to publish this Device Handler in your account.
1 Like

Also the following community thread might be helpful:

New app — which CUSTOM DTH’s will work?

1 Like

@jody.albritton and @blake.arnold it would be very helpful if someone from ST could clarify the relationship between Groovy DTH and new app UI. It would make the transition from Classic to new app for custom DTH smoother. Some things i’m thinking of specifically:

  1. How does MCD work and how does one convert from classic app child devices to MCD (if needed)
  2. How does ocfDeviceType metadata influence new app icon/tile
  3. A list of valid ocfDeviceType entries and what icon t hey represent
  4. How does mnmn and vid metadata influence the device UI?
  5. A list of “standard” vid entries and what capability combinations they represent

This will at least give custom DTH creators a head start on getting their DTH minimally working with the new app. Then a logical next step would be discussing custom capabilities, but for now having a documented process for minimal viable DTH for the new app would be very helpful.

7 Likes

Thanks @Automated_House, Jody and I had a discussion about this earlier this morning and are already on it. We’re also planning to provide a broader explanation of how DTHs work in OneApp vs. Classic, specifically the difference between attributes and capabilities and what is required to get the latter to render properly in OneApp. Appreciate the help and list - if anyone has topics to add, please let us know and we’ll do our best to make sure there’s clear documentation.

8 Likes

Great news Blake!

Yes! What @Automated_House is a asking is just what I’m looking for.

@jody.albritton I managed to get the capabilities to display if I made the DH from scratch and preselected the capabilities as per the docs you linked to. Its a start, but before I was able to the change the main tile in the new app by changing the ocfDeviceTypeIf I do that now, the icon change but not the value. Info/guide on how all this work together would be very much appreciated

@jody.albritton @blake.arnold

Can you provide a way to change the main tile in the new app. Adding ocfDeviceType will do that, but only if “vid” is also used. But if I use “vid” it will override my selected capabilities to a preset one.

This is a very timely discussion, thanks for your reply @blake.arnold and @jody.albritton I have a quick question?

DTH : https://github.com/SmartThingsCommunity/SmartThingsPublic/blob/master/devicetypes/smartthings/aeon-home-energy-meter.src/aeon-home-energy-meter.groovy

I took this stock ST handler and only changed 1 metadata element: (was set to true)
runLocally: false

And then I tweaked “parameterNumber: 111” to have the device report faster than 5 minutes.

After I did that and applied the DTH, the new ST app can’t bring up the device. I can see the tiles with spinning icons, and new tiles that include battery and Refresh, but I now get the error “a network or server error occurred, try again.”.

What could I have done to have caused that?

Any help would be appreciated!

@johnconstantelo I found that making modifications before you create the DH works much better for the new app. I was trying to add some capabilities, but not until I deleted the DH and created the new one (with the same code) did the new app read the new capabilities correctly. I don’t know of this would help in you case. But changes to the DH are not instant in the new app like they are in the classic app. Often changing to another DH and back again works for me

1 Like

I found out that ocfDeviceType only changes the icon on the main tile, but not the value. The main tile is preset by the vid, but I have not found a way to select the value for the main tile without using a preselected vid

I’ve tried all those tricks as well. I just updated my version of that DTH to add the vid “generic-switch-power-energy” and to remove ocfDeviceType: “x.com.st.d.energymeter”. That seemed to have worked for me, but I have no idea why


@blake.arnold, my understanding is that, OneApp works with device plugins, some capabilities from the classic app has equivalent device plugins in OneApp, like Temperature measurement or Switch. If this is listed in the DH then the OneApp will pick it up and provide the plugin for it, and if the attributes and commands were followed then it can work in the OneApp without any issue. (I am not mentioning here some dependencies of capabilities like Switch and Health check.)
For device development there are some already made path with the device profiles and vendor ids. If a device profile has already been created and published then it can be reused by any DH if the corresponding vendor id (vid) is referenced in the metadata. If it referenced then the OneApp will follow the device plugin assigned to the vid and will disregard the selected capabilities when it displayed in the app. Ie. If a DH of a switch would have the vid generic-thermostat, then it will not display any Switch option in the OneApp, but temperature, operating state etc. (Just for example as misassigning capabilities related to the real functionality.)
@mark_cockcroft has made a list in the other topic of the thermostat related vids. I guess he looked into the DHs of the public repo and searched for vid and the connected capabilities. Device Handler update to support new STSC app
The only problem, that the current documentation is not containing all capabilities and, I haven’t found yet, there isn’t a list of vendor ids and connected capabilities. Some of us could reuse the already published vids, meanwhile others should have to create new device plugins to match functionality with the Classic app.
It is more frustrating that some of the documentation seems to be incorrect, or not working. I was in a search for a device profile/vid for a camera which does Image Capture. Indeed, I have Image Capture as capability in my DH, but it is not working in the OneApp and neither listed as a capability in the developer documentation, neither selectable in the Dev workspace, but it must exist as the Cloud-connected devices section of the documentation has a reference table to device handler types with c2c-camera-2 and c2c-doorbell-2. Although c2c-music-player-2 is in the reference list with Music Player and Audio Notification capacities, but Music Player is depreciated and Audio Notification is not documented. Anyhow, I couldn’t make my camera working with Image Capture in the OneApp yet (tried c2c-camera-2). I know that the Ring and Smartthings cameras are working in the OneApp and they have corresponding device plugins.
So, it would be really useful if the documentation could be updated to be a bit more complete and accurate. And it would be useful for all of us, if we could have a generic list of vids with connected capabilities what we could use in our DHs. I believe it would make our integration/transition to the OneApp easier. Later on then we can try to work on custom device plugins if the generic ones wouldn’t be good enough. That is a small step forward, but it would make it worth for the whole community.
Please correct me if I understand the things wrongly.

Thanks for the help!

Gabor

1 Like

This is interesting reading. I’m not so far along in my understanding and haven’t experimented. The following has been exercising me this morning and I’d like to throw it into the mix:

The Vendor ID (vid) is part of a device profile and presumably it needs to be used in combination with an organisation ID (mnmn ?) to uniquely identify it. That would also suggest it could be considered to be ‘owned’ by the organisation that created it. If I create a device that does something similar to the Nadir Widget and reference ‘mnmn: nadir vid: nadir-widget-v1’ I would be a bit daft because Nadir might move the goalposts, but would there also be intellectual property issues? On similar lines, are the SmartThings Vendor IDs that have been used my many custom handlers really intended for general use in this way?