It seems the circlefield05082.binstatus capability isn’t working properly. I installed your DTH and effectively, the attribute’s value is displayed in the IDE tool but it is not saved in the API:
"circlefield05082.binstatus": {
"binStatus": {
"value": null
}
}
I replaced it with my capability and the binStatus card is displayed correctly (VID:4d6d6231-cec9-3d33-a20b-e28709397a6f). I suggest you create a new capability with the same config but a different name.
Great success!
(For those wondering what the solution was, I made a new capability with a new name, new attribute name, and new setter command.)
Hi, I saw your previous post. They are displayed correctly in the Detail View capability card but I saw they are rounded in the event’s history and Dashboard View.
There’s no configuration available to modify that yet, but what you can do (if you just want to show a value), is using a String type capability, and instead of sending only the number, concatenate it with other text, eg.
sendEvent(name: "decimal", value: "Value 18.5555")
I seem to be running into an issue with my device configuration / presentation not taking effect in the app regardless of what I put in the config. I took the stock Z-Wave Lock DTH and added the Switch capability to it. After that I followed the steps in this thread to create a device config based on the DTH. The issue is no matter what I add or remove from the dashboard or detailView sections of the device config, the app always shows the switch capability in the dashboard tile and both the switch and lock capabilities in the detail view. The detail view is less of a problem, but I wanted the dashboard tile to show the lock capability instead.
I have tried clearing the cache, creating new DTH’s, and new VID’s to no avail. Unsure if it’s a caching problem or not.
Edit:
I did some more testing and the response from the device presentation endpoint looks right with the lock capability in the dashboard section. It’s just that the app for some reason chooses to display the switch capability instead.
Do you mean this DTH?
If so, have to consider the following:
vid and mnmn properties in the DTH. You can verify which VID (presentationId) your device is using when you get the devices list from the API.I also installed the DTH, added the Switch Capability, create the device-config and it is displayed correctly:
Edit:
I finally figured out what was wrong. It turns out I have been reading mnmn as mnmm this whole time. After fixing the typo it works now. Thank you for the help and I’m going to schedule an eye doc appointment now.
Don’t worry, it happens. Just to clarify, you can only show one stock capability in the dashboard View. The custom capabilities have a property named “group” in the presentation that allows you to show more than one.
@nayelyz Your help in the past to me and others in this thread have been extremely helpful so I hope you can direct me once again:
I completed the upgrade of my Pool Control DTH to add several custom capabilities, struggled through the debilitating cache issues like everyone else, but finally got a working implementation. After testing it for a week or so I published the new DTH to my forum for them to install:
You can imagine my disappointment when I found that even my end users are also facing caching issues. They install the updated DTH in the IDE, which has a different DTH name, namespace and vid from the old one they had been using, then they change their previously paired Z-Wave device to reference the new DTH, but they still get no detailed presentation in the new App. They’ve tried closing and reopening the App to no avail. Both users gave up but then miraculously the next day the new custom device presentation appears and they can use it successfully.
As a developer I struggled through the endless process of recreating new custom capabilities every time I made a change, new VIDs, etc, but I never anticipated that my end users would also experience unexplainable delays just trying to install a new DTH. Is there any suggestion you can offer to IDE/App end users who are not developers to quickly install and use a new DTH?
In previous posts @orangebucket, myself and others have asked for a simple App button to force the App to fully reset and flush all caches. This can’t be that hard and would eliminate so much anxiety…
Anyway, any suggestion you can offer to my users would be so appreciated!
The caching issue is related to the device in general because it’s linked to a DTH and its presentation.
If the users have the device installed and only change the handler, the update will take some time.
The options to force the refresh are:
Enable the developer mode before making the update.Are you saying developer mode is supposed to disable caching?
Hello - I was never able to get this work. In fact I’ve had little success in getting any of my automation changes to show up in the mobile app.
In the “value” attribute line that you had me add to my alternatives list, does that attribute value have to be in double curly brackets like it does in the state label? So rather than:
"value": "zoneBypass.value"
should it be:
"value": "{{zoneBypass.value}}"
I am having real trouble trying to get changes I make to my capability presentation json to automation conditions alternatives list items to actually show up in the mobile app Automations. I do an API get to be sure my updates are there and they are, but it’s as if they are being ignored. I’ve tried various combinations of the following:
None of these things seem to work, so there is something else wrong somewhere.
Is the Automation functionality still unstable for custom capabilities? I’ve never seen any formal announcement from Samsung that it is supposed to be working now for custom capabilities. Perhaps it is still considered alpha or beta level??
I’m so tired of trying to get this to work, so any help you can provide would be greatly appreciated!
My experience is you have one chance to get everything right. If something is wrong you can’t fix it without hitting the cache problem, so you’ll need to make a new capability with a different name to start over.
It’s pretty ridiculous that this hasn’t been solved, but that’s how it is right now.
@nayelyz Thank-you once again for your rapid and helpful reply. A couple follow-up questions:
Thank-you very much!!
No, it only helps to get the updates faster in the mobile app.
The instructions you shared are correct. The option of “my testing devices” is used for another kind of integration, not for DTH (as you work with them through the IDE).
This is available for Android devices. The steps may vary depending on your device’s menu but they are basically:
Those are the things that can help you, they can be effective but sometimes they’re not enough that’s why I put reinstall the device as the last resource, but if it’s more complex than waiting for the update, then you can omit it.
@nayelyz, please send feedback to the engineering team that due to the way the mobile app works when you do this (blow away the app cache) it causes a very negative impact to the end user - essentially resetting EVERYTHING about the app to default. Including placement of all favorites and scenes on the app home screen. When you have over 150 devices it becomes VERY problematic and should not be considered a ‘matter of fact’ intervention for issues. It should be an intervention of last resort. Yes I realize it’s sometimes the only way to impact this caching issue - but it’s like swatting a fly with a nuclear weapon.
you are confusing clearing cache with clearing data.
but either way, I’ve never had this work for me to resolve caching issues with DTHs.
There’s a regression issue with child component devices display, the app now doesn’t honor the order of components in the detailView. It used to do it earlier.
Now when I generate a new VID the child components devices are ALWAYS displayed at the bottom of page even if the include them in the middle of the configuration.
can you share the DTHs and device-config you’re using, please?
I’ve never had much luck with it either, which is why I always favoured name changes.
The problem is that there now seems to be a cache on changing the ‘vid’ in a DTH. Adding still works fine, but changing hits a cache. It can be hours before devices pick up the new vid, regardless of what you do with the device, including creating a new one.
I’m not even sure that creating a new DTH, which is the last option left, works either, but I’m only just bringing that into my routine.
