Custom Capability and CLI Developer Preview

Developer Programs Tutorials
,
1072

Yes. As far as ST is concerned it is a different handler even if the code is identical.

1073

Brilliant!

Thanks once again, Graham.

1074

Anyone else notice that in iOS, in detailView, the status control label field doesn’t render {{attribute.value}} for new capabilities. Seems to be working on Android, on iOS it just displays {{attribute.value}} on the screen instead displaying the attribute value.

UPDATE: it looks like the iOS server is having caching issues and ignoring updates to presentations despite a new VID. It eventually caught up the next day.

1075

@nayelyz is there a way to control the active/inactive state of an ocfDeviceType icon?

1 Like
1076

yes, you need to set the property “type” in the alternatives as active or inactive in the capability presentation. If you don’t include it, the default value for all the alternatives is active.
In the sample below I’m using Smart Lock as device Type.

iconAlternativeChange
iconAlternativeChange2194×831 79.2 KB

Note: Up to now, it works fine on Android devices. I already reported that the icon is not changing correctly on iOS devices, so our engineering team is working on this fix.

1077

@nayelyz @cscheiene
The issue when a demical number don’t showing up on dashboard tile still remains on iOS.
Same thing with automations. They don’t showing up for custom capabilities.
Is there any update regarding there issues?
Can you report these on the engineering team too?

Also is there a way to change between active/inactive icons, based on attribute value?
Etc:
if attr.value is < 100 -> inactive
if attr.value >=100 -> active

Thanks

1078

@nayelyz Thank you! Very helpful, I will check it out

1 Like
1079

This issue is already reported, thanks for your feedback.

Automations are not available for display on the mobile app yet; once they are supported, your configuration will be shown.

Up to now, it’s possible only using the alternatives. You could create a custom capability to change the icon and change its value when the other capability meets the condition (<100 or =<100). I can think of using Rules to do so, here’s an example:

1 Like
1080

Is there a way to change in the device presentation the label of a capability ?
For example “momentary” capability has a default “Momentary” as a label (i18n.label). Is it possible to change it in the detailView of the device?

I tried to play with “values” under detailView but I got back errors


1081

The “values” property at the device configuration is used to set the supported values of a capability, such as ThermostatOperatingState in your device, or to change the range of the numeric capabilities.
Up to now, the presentation (label, display type, etc.) of a stock capability cannot be modified.

1082

thank you. So is the only way to have a different label is to duplicate the stock capability into a custom one?

1083

You’re right, they might look different though, eg. “Battery” has a slider display type and in the app, a color bar appears to represent it because it uses customized UI, a feature not available for custom capabilities yet.

1084

I tried to create a dynamic label that takes the value of the “unit” property.

for ex., :

"detailView": [
    {
        "label": "{{txstat.unit}}",
        "displayType": "state",
        "state": {
            "label": "{{txstat.value}}"
		}
    }
],

but the label shows as txtstat.unit despite setting the"unit" with SendEvent to a value.

Is it possible to have a dynamic label (the headline not the value)?

1085

Up to now, only the State display type label is dynamic, the unit can be included there too. The card’s label is a simple String.

1086

Hello - my understanding is that right now the Developer Workspace does not give you the option of using cc’s created by others when you are defining direct connect devices. Is this under consideration for the future or will we always have to create any cc’s under our own namespace? Once the IDE goes away, the Developer Workspace needs to allow specifying cc’s created by others.

1088

That rather depends on the distribution model for community developed handlers.

I wouldn’t use someone else’s custom capability in my own integration. They could change or delete it and potentially break every device using it.

1089

Yes I can see it could be problematic but on the other hand we want to share projects with others that will probably include custom devices. If you have to tell people they have to go learn cli and recreate the devices themselves
 well forget that!

1090

Yes, but we can’t project the current custom DTH model forwards. It sucks now, so why repeat it? Even if a similar code sharing model was used, why would you share the code but not the source of the capabilities?

1091

Both would be ideal, but hey I’d be happy with the minimum of at least being able to find & select others’ custom capabilities in the Developer Workspace.

But I certainly understand all the focus right now is getting the heritage groovy-stuff ready for whatever transition is going to happen, so I’ll just have to be patient


1092

We don’t even know what is replacing the ide for hub connected devices.
And basically most custom DTHs act as hub connected devices.
So for now we’re just speculating.