uniqueid is the same for configuration tool and the virtual daylight sensor in the api

[rcmcronny]

As the subject says, the id for configuration tool and the virtual daylight sensor is using the same uuid.

Deconz: 2.05.75/8.3.2020

TYPE       HUEDevice
manufacturername dresden elektronik
modelid    ConBee II
name       Configuration tool 4
swversion  0x26530700
type       Configuration tool
uniqueid   00:21:2e:ff:ff:05:4d:cd-01

(see also https://forum.fhem.de/index.php?topic=109842)

Sensor Update Info:

2020.04.16 21:28:02 5: deCONZ: websocket data: $VAR1 = {
  'e' => 'changed',
  'id' => '1',
  'r' => 'sensors',
  'state' => {
    'dark' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
    'daylight' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
    'lastupdated' => '2020-04-16T19:28:02',
    'status' => 220,
    'sunrise' => '2020-04-16T04:15:33',
    'sunset' => '2020-04-16T18:09:25'
  },
  't' => 'event',
  'uniqueid' => '00:21:2e:ff:ff:05:4d:cd-01'
};

[ebaauw]

Unfortunately, uniqueid isn't. Only for /lights resources and for ZHA* /sensors resources it is unique (since derived from Zigbee mac address, endpoint and cluster of the device). For resources not linked to a Zigbee device (CLIP sensors, the virtual Daylight sensor, groups) it's best ignored. Personally I think, it should never have been introduced. See #514.

[justme-1968]

you are right.

if the configuration tool is exposed as a light (which is a discussion all by itself, it should be a sensor) then it should implement the endpoint correctly and provide a unique id or provide no id at all.

hardcoding some model names to be able to ignore some devices is the wrong approach.

[Smanar]

But it could have been useful, if the Daylight senor and the configuration tool don't share the same endpoint.
There isn't "Clip" in the name, and the UniqueId look relay like a a real one. In my mind too the "Daylight sensor" is a real sensor.

[ebaauw]

if the configuration tool is exposed as a light (which is a discussion all by itself, it should be a sensor)

The configuration tool is exposed as a Configuration tool, using a /lights resource. Same as many other non-light Zigbee devices, such as repeaters, wired in-wall switches, smart plugs. The unfortunate names of the resources (/lights and /sensors) have nothing to do with the type of the device linked to the resource. Use the type attribute for that.

But it could have been useful, if the Daylight sensor and the configuration tool don't share the same endpoint.

Only Zigbee devices have a mac address and endpoints. The Daylight sensor is created by software, and doesn't have an endpoint. But I couldn't agree more: it shouldn't use the same value for uniqueid as the resource for the configuration tool. Moreover, imho, the Daylight sensor should never have gotten a uniqueid in the first place. uniqueid, in its current format of mac address, endpoint, and, optionally, cluster, only makes sense for resources related to Zigbee devices.

Same holds for the uniqueid for /groups resources, which isn't guaranteed to be unique. Note that uniqueid for CLIP sensors can be set on creation, so there's no guarantee that uniqueid is unique for these either.

There isn't "Clip" in the name

Sensor names are user changeable, and should never be used to infer anything. Instead use type to determine the type of resource. Not all types that are not linked to Zigbee devices start with CLIP: next to Daylight the Hue bridge also uses the undocumented Geofence.

In my mind too the "Daylight sensor" is a real sensor.

I'll leave that to the philosophers. It's not linked to a Zigbee device.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.