New App: My Custom DTH shows tiles although no capabilities are set for them

[rockberte]

I bought a device for which there was no device handler available. This is a gas sensor from HEIMAN. So I wrote a custom DTH that can be found here:

rockberte/st-zwave-heiman-gas-sensor-hs1cg

I used a “Smoke Detector” capability as it seems to bring all I need for visualization and alarming.

What the new ST app show me is the following:

I wonder from where the new app gets the information to show the “Battery” and “Carbon monixide detector” capability?
Is there a way to reliable work around this?

I assume that this is caused by some tries while implementing and testing the DTH.
Is there a way to “reset” the DTH information for my device somehow (without need to reinclude the whole device)?

Thanks in advance!

[johnconstantelo]

@rockberte

I bought a device for which there was no device handler available. This is a gas sensor from HEIMAN.

This sensor?

Gas Detector Recommendation Please Zigbee Only

I believe both Xiaomi Honeywell and Heiman are supported. Which one should I go for? What are the differences between both and which one works or responds better? Does Xiaomi have two versions, gas and smoke?

I think there’s a zwave version of the zigbee DTH out there somewhere, let me see if I can find it. I thought I remember seeing it. Be right back.

You might find these discussions helpful for developing in the new app:

Schema Devices and Custom Capabilities

Creating custom capabilties for schema devices Using the SmartThings CLI and Developer Workspace We are going to create a Cloud Connected Device using Schema and webhooks. Our base device will be a basic switch. The first part of this tutorial will cover create the connector, oAuth server, and adding the Switch to SmartThings. The second part of the tutorial will cover adding a custom capability to this new device. Prerequisites: Samsung Account Developer Workspace Access Developer Mode Enabled Glitch Account Text File Step 1: Remix this Glitch account (connector) Set the values in the .env file using .env-example as a guide. Once the remixed app is up and running copy its URL to your text file. Register the webhook url in SmartThings Developer Workspace and deploy it for test…

Custom Capability and CLI Developer Preview

Overview At SmartThings we want to provide tooling to allow developers to get their device integrations working in the SmartThings app. These changes will allow an integrator to move from using custom commands and attributes to custom capabilities. DTH Migration For Custom Capabilities In order to follow along with the example set forth in this guide, you will want to have the CLI set up, so make sure that you take this step first. You can download the CLI here from the releases tab and read more about it in the README. It is also recommended that you familiarize yourself with the concepts: Custom Capabilities Capability Presentations Walkthrough We are going to walk through a simple example of updating our Device Type Handler (DTH) so that devices installed with the DTH will be …

[johnconstantelo]

@rockberte

I wonder from where the new app gets the information to show the “Battery” and “Carbon monixide detector” capability?
Is there a way to reliable work around this?

I assume that this is caused by some tries while implementing and testing the DTH.
Is there a way to “reset” the DTH information for my device somehow (without need to reinclude the whole device)?

Thanks in advance!

If you were testing other DTH’s, then it’s likely you’ve got some caching issues (known) when editing DTH’s and the new app. You can swap to another DTH and then back to yours and the tiles should change. My gut feel says it won’t.

I recommend using the CLI tool to create a custom VID for your DTH. Here’s a discussion I was having to do the same thing for a LUX sensor:

Another question for developers. Code for default tile/value

Capabilities have their own presentations that define how they look when they are used as the status on the dashboard tile, as the action on the dashboard tile, as tiles on the detail pages, and in automations. You don’t need to worry about that here as that is already defined. What you need to work with is the device config, which says which capabilities are to be used in the dashboard, details page and automations for anything using your device handler, and sometimes in what order. This device config is combined with the info in the capability presentations, and probably some other fluff, to create a device presentation. Prerequisites: The UUID for your device handler as installed in your IDE. It is in the URL. The CLI installed. Let’s call it ‘st’. First you need to generate a de…

[rockberte]

@johnconstantelo

This sensor?

Yes, the HEIMAN but for Z-Wave networks.

@johnconstantelo

I think there’s a zwave version of the zigbee DTH out there somewhere, let me see if I can find it. I thought I remember seeing it. Be right back.

Fine, thanks in advance. I didn’t find one, so that’s why I started to write my own one. If there’s another one that works for me I’m fine.

@johnconstantelo

If you were testing other DTH’s, then it’s likely you’ve got some caching issues (known) when editing DTH’s and the new app. You can swap to another DTH and then back to yours and the tiles should change. My gut feel says it won’t.

I tried this already, and your feeling is right - the tiles do not change.

And thanks for the many links - I’ll will read them and decide whether to live with the view or start writing a custom capability and/or custom VID.

[johnconstantelo]

@rockberte

Fine, thanks in advance.

No worries. I did a search in Github too, and all I found were many variations for HomeAssistant, and other HA systems.

Before trying your own VID, I noticed that ST has one for the Orvibo sensor. You might want to try adding this to your code’s metadata -> definition line and see if it does anything:

, mnmn: “SmartThings”, vid: “SmartThings-smartthings-Orvibo_Gas_Sensor”)

You may need to do the DTH swap or clear cache trick…

[orangebucket (Graham)]

@rockberte

I used a “Smoke Detector” capability as it seems to bring all I need for visualization and alarming.

Is the Gas Detector capability not working in the app yet?

[rockberte]

@orangebucket

@rockberte

I used a “Smoke Detector” capability as it seems to bring all I need for visualization and alarming.

Is the Gas Detector capability not working in the app yet?

Well is there any?
I didn’t find that capability in the ST capability reference therefore I was not aware that there is such a cabability and used the “Smoke Detector” that brings all I need in my opinion. But I’ll give that a try, thanks for the hint.

[rockberte]

@johnconstantelo

Before trying your own VID, I noticed that ST has one for the Orvibo sensor. You might want to try adding this to your code’s metadata -> definition line and see if it does anything:

, mnmn: “SmartThings”, vid: “SmartThings-smartthings-Orvibo_Gas_Sensor”)

You may need to do the DTH swap or clear cache trick…

This seems to look a bit better as it only shows the “Gassensor”, but still the “Battery”. In the order “Gassensor” then “Battery”. And also I like that the texts are localized now.

[Automated_House (Jimmy aka prjct92eh2)]

Does your device have non-null states for the battery and gas sensor in the IDE?

[rockberte]

@Automated_House

Does your device have non-null states for the battery and gas sensor in the IDE?

Sorry, but now my ST know how is at the limit .
What excactly do you mean with “non-null states” in the IDE?

[Automated_House (Jimmy aka prjct92eh2)]

When you view the device page at https://account.smartthings.com do all of the states have a value?

[rockberte]

Aah ok - these are the current states and their values:

This should be that what you wanted to know, right?

There is no “battery” state at all.
The “smoke” represents the “gas” state.

[rockberte]

@johnconstantelo

If you were testing other DTH’s, then it’s likely you’ve got some caching issues (known) when editing DTH’s and the new app. You can swap to another DTH and then back to yours and the tiles should change. My gut feel says it won’t

Is there a chance that this caching issue is solved in the near future? This behavior is very very weird.

I’m writing another DTH at the moment and switched to another DTH and back to let the new app consider new capabilities I added to my DTH.
The other DTH brings more capabilities I need and use in my own DTH. The affect is, that I always see the unused capabilities of the DTH I switched to in between. The only way to get rid of that tiles is to reinclude the device which I really don’t want to do everytime this happens. Deleting the apps cache or whatever I could try doesn’t help.

I think I can try to add a dummy DTH without caps, states, attributes or whatever to switch to it to avoid this behavior.

But there is one use case where this behavior is really bad - in case that ST selects the “wrong” DTH while including the device. With this you’ll never ever get rid of the useless tiles.

[pablopoo]

In my experience, I always have to delete the device and add it again to see the UI changes.

[rockberte]

Yeah - same here.
This is excactly what I always have to do and which I meant with “reincluding” the device (z-wave in my case).

IMHO this is neither customer nor developer friendly.