Custom Capability and CLI Developer Preview

Hey, @LucasRyu

Great news! Our engineers have been looking into this issue, and it was indeed related to the namespace appleinside37634.

So, the fix will be implemented as soon as possible and once I get the update, I’ll share the details with you.

Cheers!

Glad to hear good news! Hope to use my own capabilities soon.

Thanks.

1 Like

@jody.albritton, none of the links are working anymore. They are from the old documentation and only a We’ve Moved! message what they reach now.

And what is funny, the forwarding link loads the new page, then the Developer Console page loads another one from the old pages:

https://smartthings.developer.samsung.com/workspace

And the link LEARN MORE ABOUT INTEGRATING DEVICES loads the We’ve Moved! page again…

The other link LEARN MORE ABOUT CREATING AN AUTOMATION does the same…

Seriously, is there anybody who takes care of any of the documentations and these changes?

@nayelyz, @erickv, @garrett.kranz

Thank you, @GSzabados. I made some changes to the links, please, let me know if something is still pending.

1 Like

@nayelyz, Just read my updated comment above…

Thanks again, I will report the problem with the link on “Learn more” in the Developer Workspace.
The team is continuously improving the developer documentation (take a look at the release notes). Due to this, there might be some links that won’t work anymore, I will check the old tutorials posts to update the links and avoid confusion.

1 Like

Dear @nayelyz,

Due to this, you do testing and apply QC/QA, what sometimes involves clicking over all the links to make sure they point to the right page.

This must be the same since the new page has been deployed before the 24th of September 2021, as that is the first log in your release notes.

Question and possibly new function request regarding visible conditions defined in the device configuration json:

I have a capability that I want to include in the device details screen, but have it grayed-out in the condition that a device user setting is defined to disable it. Ideally, I would like there to be an option to define this directly in the device config visible conditions. Today they only trigger based on capability attributes, but if you could add a way to alternatively link a device setting to it, that would be ideal.

So given that I have to trigger the visible condition based on a capability - can I specify an attribute of the capability itself as the trigger? So for the capability I want to gray out in certain conditions, if it has an attribute that is a numeric value, for example, could I set that numeric value to some special number, say -999 from my driver and that would gray out the capability? Or is there a requirement that the triggering capability has to be another capability and not itself?

I hope I’m making sense…

1 Like

By any chance are you working on a sensor what you can connect to all sort of meters? :wink:

Those sensors reported values could be kWh, liters/gallons or m3/feet3. It should just depend what setting is set on the device and what it reports. But each reported value falls under a different capability.

1 Like

Good guess, but no! :grin: This is for the R1/R1PM that have optional temperature sensors you can connect to add those capabilities. Thus, I want to have it grayed out for the cases where they are not connected.

The 3EM has those options included (and more!), so it’s more straight forward.

I am going to say yes. I never managed to get visible conditions to work and it always baffled me that they would be working when the most basic functionality I needed on day one wasn’t even available after a year or so. So I’ve never seen it for myself. But yes.

Hello, @TAustin
Excuse my ignorance, could this be related to the improvement announced in beta firmware 041x?

I asked what they meant and how to use it and I have still received an answer.

In case it helps you, as another option for what you want to do.

Now that the profile changes work better and it is only necessary to clear the cache the first time it is done, I am using this method to do something similar to what you want to do.

  • I create two profiles, one with all the capabilities and the other without the optional capability

  • I create only one VID with all the Capabilities and apply it to both profiles.

  • I create a preference or a custom capability to enable or disable the capability that I want as an option.

  • If you do it with custom capability, you have to put it in the VID and you can also enable and disable it with routines.

  • The infoChnged code, if you use preferences, or in the custom capaility handler, you write the profile change code.

  • When you disable it, the capbility disappears from the detail and automation view and if you enable it, it appears just by closing and opening the app.

  • It’s working fine for me

Profile with Motion Sensor Enabled:

Profile with Motion Sensor Disabled:

1 Like

It’s still a mystery what they were referring to there, but sounds intriguing! Maybe it could help, I don’t know.

The profile change is definitely an alternative way to handle it; my only concern is, would it actually work in the iOS mobile app; would the presentation dynamically change like that?iPhones don’t seem to be too good with that type of thing. I’ve got a capability presentation I’ve changed DAYS ago that’s STILL not displaying with those updates…even if I create a new device, or delete and reinstall the driver altogether and create a new device! (or unload and reload the ST app, etc. etc… same old problems)

I can’t help you with IOS, as I use Android.

On Android it is working quite well, since now it is only necessary to clear the cache of the app the first time the profile is changed, then the capabilities are shown and disappear just by closing the app and reopening it.

On the other hand,
What I have noticed today is that three times a driver has been left hanging when installing a new version with the CLI and device running. Having to uninstall the driver from hub and reinstall it.
This hadn’t happened to me in a long time. I don’t know if it has to do with the Beta 041.x firmware version. I’ll keep an eye on him.

This happens to me CONSTANTLY, and is my biggest issue with Edge at this point. For me, with LAN drivers, if the driver re-install does proceed, it is often stopped by a cosock error and then goes into an infinite re-install loop. I was SO disappointed this wasn’t fixed with the new firmware…

Yes, I just made a test using the SmokeDetector capability and it worked.

{
    "component": "main",
    "capability": "smokeDetector",
    "version": 1,
    "values": [],
    "patch": [],
    "visibleCondition": {
        "capability": "smokeDetector",
        "version": 1,
        "component": "main",
        "value": "smoke.value",
        "operator": "EQUALS",
        "operand": "detected"
    }
}

Although, I need to ask the team for more details, as it didn’t work with the thermostatMode capability but maybe it was caused by something specific in it.
Please, let me know if you find something strange.

2 Likes

Very cool; thank you!

I’ve been successful with it; I use it my LAN Device Monitor driver and it works well.

Please, where can I find information on this in the documentation?

Is this condition set in the vid presentation por capability presentation?

Thanks

This property is used in the device-configuration, you can find more details about it in the API reference documentation > create device-configuration. Open the sub-menu in Detail View and you’ll find the supported operators inside visibleCondition

1 Like