IKEA Kajplats GU10 CWS

Device Requests
1

Hi all,

I can read from this guide that I cannot make a GitHub request for a New Device: Request Device Support · dresden-elektronik/deconz-rest-plugin Wiki · GitHub as my issue exactly is, that the device I would like added does not have a Manufacturer Name nor Model Identifier. Hence trying here.

I have been using IKEA Trådfri lights with great success, mainly their GU10s. Now Trådfri is a thing of the past, and Matter-over-Thread enabled Kajplats is the name of the game. Kajplats should however be backwards compatible with IKEAs former Zigbee devices, hence Zigbee must still a way to communicate with Kajplats.

I have bought a couple of Kajplats GU10 CWS, 470 lm, named LED2410R5. I assume they are very similar to LED2110R3 on the Zigbee-part, but not sure.

In deCONZ, like on most other Coordinator forums I have read e.g. [New device support]: Ikea Kajplats Bulb (not working) · Issue #30211 · Koenkk/zigbee2mqtt · GitHub, they show up with no Manufacturer Name and Model Identifier. Also in deCONZ:

image
image1235×658 129 KB

I am however able to communicate with the bulb e.g. from the Identify-Cluster, and it joins Zigbee Mesh with no issues:

image
image1028×611 91.5 KB

I would like the router and switch to be on the same mesh network, to avoid the latency (all of my switches are Zigbee) of there possibly will be introduced by adding a Thread network just for the sake of Kajplats. So how do I do this?

Note: I had to power-cycle the bulb 12 times, then it flashes bright white a couple of times, and shows up in deCONZ. IKEA item code is 106.085.78.

Node details:

image
image980×613 132 KB

TIA

2

Very interesting!
I would like to use Zigbee for the time being as well.

3

But don’t think there is or will be support. :innocent:

4

Honneslty, I don’t see how this kind of device can be handled …

For the API, it’s sure, it will be not possible, without model ID and manufacture name.
For deconz alone IDK, I think the application will not ask for thoses missing attribute if you don’t ask for them, so on zigbee side I don’t think it will be a problem.

But if you try to include a new device, the application will try to include this one too and you can have problems during the inclusion.

5

@Smanar I found this for device identification.

deviceID: 269 = color, 268 = color temp

    {
        fingerprint: [
            {
                // https://github.com/Koenkk/zigbee2mqtt/issues/30211#issuecomment-3660923636
                modelID: "",
                manufacturerName: "",
                hardwareVersion: 1,
                dateCode: "",
                softwareBuildID: "",
                zclVersion: 8,
                applicationVersion: 0,
                endpoints: [
                    {ID: 1, profileID: 260, deviceID: 269, inputClusters: [0, 3, 4, 5, 6, 8, 768, 4096], outputClusters: []},
                    {ID: 242, profileID: 41440, deviceID: 97, inputClusters: [], outputClusters: [33]},
                ],
            },
        ],
        model: "KAJPLATS_RGB",
        vendor: "IKEA",
        description: "KAJPLATS color/white spectrum light",
        extend: [m.light({colorTemp: {range: [153, 555]}, color: true})],
    },
    {
        fingerprint: [
            {
                // https://github.com/Koenkk/zigbee2mqtt/issues/30211#issuecomment-3696471655
                modelID: "",
                manufacturerName: "",
                hardwareVersion: 1,
                dateCode: "",
                zclVersion: 8,
                applicationVersion: 0,
                endpoints: [
                    {ID: 1, profileID: 260, deviceID: 268, inputClusters: [0, 3, 4, 5, 6, 8, 768, 4096], outputClusters: []},
                    {ID: 242, profileID: 41440, deviceID: 97, inputClusters: [], outputClusters: [33]},
                ],
            },
        ],
        model: "KAJPLATS_CT",
        vendor: "IKEA",
        description: "KAJPLATS white spectrum light",
        extend: [m.light({colorTemp: {range: [153, 454]}})],
    },
6

But the problem is deconz use the modelID/Manufacture name to reconize device, I don’t think the code can work without them, deconz will ask them again, up to have them.

7

I am also under @Smanar’s impression on how deconz works. I can give the custom ddf a try, but already tried experimenting with that (and failed miserably - this could however be due to me being afraid of messing the ddf my working TRADFRI GU10s uses).

As I see it, what is basically required to get KAJPLATS to work in deconz (and subsequently in API/Phoscon) is a capability to assign a ddf to the physical address (MAC) of the bulb. Or, somehow manipulate deconz to override the bulb’s manufacturer and device IDs, based on the physical address, before it maps a device to a ddf. The latter would probably be more suitable for the API.

IDK how Dresden’s take on this is. But to protect their customer’s investments made in deconz coordinated zigbee networks, they could consider this as a feature request to how deconz works.

8

@Smanar is right, with an unknown modelID/Manufacture, deCONZ will simply use the legacy code again, just like it does now.

9

So, in other words, with IKEA’s shift from TRADFRI to KAJPLATS, this marks the end of IKEA bulbs on deconz controlled Zigbee networks?

Would really like to get Dresden Elektronik’s view on this.