Device profile broken, community drivers

[Pamaliska]

I was experimenting with some community drivers on one of my dimmers.
When I decided to go back to a ST driver, I have noticed that the interface is no longer the same as it used to be.
Upon checking device profiles, it became apparent that the dimmer got its profile somehow changed. I did factory reset and re-aded the device multiple times, nothing helped. How do I say the device that it should be Light?

The one with issues:

Identical device that did not go through my experiments with drivers:

[Andreas_Roedl]

Does the device work with the switch-level profile?

[Pamaliska]

the functionality remained unchanged. What bothers me is the deference in interface among same type of devices.

[Andreas_Roedl]

They just renamed and reorganized it. If you remove and add the other devices, they’ll look the same.

Lights are basically switches and dimmers are switches where you can set the level. Switch-level devices.

This is how a typical Matter light looks like:

[orangebucket (Graham)]

‘Light’ is a device name, not a profile, and with Edge drivers the name is set at device creation to the initial implicit device profile name. It is read-only and pretty useless. I suspect it is a relic of the old platform where it also didn’t do much.

Have you had these devices a long time? Long enough to have been migrated from the old Groovy platform perhaps? Only it looks like your old devices were recognised as lights, whereas the device is now assumed to be a switch and migration might be the reason.

The only difference in the actual profiles is the Category. If you change the device icon you should be able to influence that.

Correction: It used to be the case that changing a device icon in the mobile app might also add or change the user category. So for example choosing a door icon for a contact sensor added the use category ‘Door’. Back in March this year it was observed that this no longer happened. I’d forgotten about that.

[Pamaliska]

Both devices are identical hardware wise.
This is an unaffected device interface:

Compared to the problematic one:

Swaping icons does not introduce any changes.

[h0ckeysk8er (Bruce Pinsky)]

@Pamaliska

Both devices are identical hardware wise.
This is an unaffected device interface:

Compared to the problematic one:

Swaping icons does not introduce any changes.

Well, the capabilities displayed seem to be identical. The fact that the mobile app design elements are slightly different doesn’t change the functionality.

[Pamaliska]

I am not yet aware of possible automation limitations for the device as it is not recognised by ST as lights, but rather a switch.

[h0ckeysk8er (Bruce Pinsky)]

@Pamaliska

I am not yet aware of possible automation limitations for the device as it is not recognised by ST as lights, but rather a switch.

It is not recognized as “lights”. The one with the updated UI is using the switch-level profile and the other one is using the on-off-level profile. They both have the exact same capabilities with the only difference being the default name assigned to the device during onboarding:

name: switch-level
components:
- id: main
  capabilities:
  - id: switch
    version: 1
  - id: switchLevel
    version: 1
    config:
      values:
        - key: "level.value"
          range: [1, 100]
  - id: firmwareUpdate
    version: 1
  - id: refresh
    version: 1
  categories:
  - name: Switch

name: on-off-level
components:
- id: main
  capabilities:
  - id: switch
    version: 1
  - id: switchLevel
    version: 1
    config:
      values:
        - key: "level.value"
          range: [1, 100]
  - id: firmwareUpdate
    version: 1
  - id: refresh
    version: 1
  categories:
  - name: Light

[TapioX]

@Pamaliska

This is an unaffected device interface:

Device’s Category is Light

@Pamaliska

Compared to the problematic one:

Device’s Category is Switch
If light uses a generic fingerprint it’s category is Switch (Zigbee Switch Driver).

If Device’s Category is Light then it’s possible to select more icons.

At least these icons were new to me. I’m using ST App Android version.

[orangebucket (Graham)]

@Pamaliska

Swaping icons does not introduce any changes.

Yes, sorry about that. It used to be the case that changing the device icon using the mobile apps would in some cases add an extra category of type ‘user’ that would override the default ‘manufacturer’ category assigned in the device profile. So this meant that, for example, a contact sensor device could have an additional category such as ‘Door’.

I made a comment to this effect on a thread back in March and it was pointed out that this was no longer happening and changing icons would set any ‘user’ category type to the default. This may have been because it was conflicting with the summary tiles which use categories to identify which devices to work with, or it could have been because it doesn’t really bear close scrutiny as in the case of the example a door might have a contact sensor but it might have other properties too.

The mobile app has only started tarting up what it assumes to be the key attribute of a device component comparatively recently. Given the assumption is often completely wrong one would hope there might be further changes to come.

[Andreas_Roedl]

I wish power-energy-powerConsumption would offer all kinds of icons (badges) because it could be anything:

It’s actually an Eve Energy. What a strange and random selection:

We should be able to choose freely from all available icons/badges.

[TapioX]

@Andreas_Roedl

I wish power-energy-powerConsumption would offer all kinds of icons (badges)

I hope so too, but SmartThings doesn’t want us to freely choose icons. ST is smarter than its users.

[Andreas_Roedl]

My bathroom fan is a lamp.

[TapioX]

@Andreas_Roedl

I wish power-energy-powerConsumption would offer all kinds of icons (badges)

This device and driver are intended for energy measurements. Energy measurements can be placed in St App own room, for example. In principle, devices can be operated from these measuring devices if you make enough routines or Rules API rules to control them.