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

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:

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!

This sensor?

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:


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:

Yes, the HEIMAN but for Z-Wave networks.

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.

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.

1 Like

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…

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.

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.

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 :thinking:.
What excactly do you mean with “non-null states” in the IDE?

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

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

image

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

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

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.

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

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.