deconz adapter does not properly surface errors when sending commands to an unsupported cluster

[deviantintegral]

I was debugging adding a device to a group (a zbminil2 that needs a firmware update), and I had a thought: from what I remembered, groups worked fine with the device back when I used a RaspBee II, and no longer worked when I changed my network to a zstack adapter.

I had a ConBee II handy, along with a zzh! stick, so I figured let's compare and see.

• The group add command appears to succeed. But, if you look at the response frame, the zbminil2 is sending 0xc3 (unsupported cluster).
• With zstack, a timeout error is surfaced and the device is not added to the group.
• With the conbee II, no timeout error is surfaced and the device is added to the group (even though it's not actually functional).

Here is the block where zstack throws the error:

zigbee-herdsman/src/controller/model/endpoint.ts

Lines 948 to 963 in eb5b89c

	try {
	const result = await this.sendRequest(frame, optionsWithDefaults);
	if (result) {
	const resultFrame = Zcl.Frame.fromBuffer(result.clusterID, result.header, result.data, device.customClusters);
	if (result && checkStatus && !optionsWithDefaults.disableResponse) {
	this.checkStatus(resultFrame.payload);
	}
	return resultFrame;
	}
	} catch (error) {
	const err = error as Error;
	err.message = `${createLogMessage()} failed (${err.message})`;
	logger.debug(err.stack!, NS);
	throw error;
	}

My best guess is that the deconzAdapter.ts file should handle this case. However, at this point the frame hasn't been decoded yet and it feels odd to look deeply into the payload:

zigbee-herdsman/src/adapter/deconz/adapter/deconzAdapter.ts

Lines 457 to 476 in eb5b89c

	if (data !== null) {
	const response: Events.ZclPayload = {
	address: data.srcAddr16 ?? `0x${data.srcAddr64!}`,
	data: data.asduPayload,
	clusterID: zclFrame.cluster.ID,
	header: Zcl.Header.fromBuffer(data.asduPayload),
	endpoint: data.srcEndpoint,
	linkquality: data.lqi,
	groupID: data.srcAddrMode === 0x01 ? data.srcAddr16! : 0,
	wasBroadcast: data.srcAddrMode === 0x01 || data.srcAddrMode === 0xf,
	destinationEndpoint: data.destEndpoint,
	};
	logger.debug(`response received (${zclFrame.header.transactionSequenceNumber})`, NS);
	return response;
	} else {
	logger.debug(`no response expected (${zclFrame.header.transactionSequenceNumber})`, NS);
	}
	} catch (error) {
	throw new Error(`no response received (${zclFrame.header.transactionSequenceNumber}) ${error}`);
	}

The total hack solution would be to put something like this in, and it totally works preventing the device from being added to the group database. Of course, I'm sure this breaks other cases where the payload doesn't line up:

                if (response.data.at(4) == 0xc3) {
                    throw new Error("UNSUPPORTED_CLUSTER");
                }

Anyways, I'm not going to work on this more because I only use the deconz adapter for testing and sniffing. But hopefully this helps someone else fix this, or at least answers why a device appears to be added to a group but is not working!