Want better endpoint.writeStructured()

[sjorge]

Ubisys changed to this for their switch configuration, so we would need this to fix Koenkk/zigbee2mqtt#15875

My initial attempt simple swapped the current write() call's to writeStructure() call's but that does not work.

https://github.com/Koenkk/zigbee-herdsman-converters/blob/b9f29f55d3f0531c9235e38a6848908c9a493042/src/devices/ubisys.ts#L509-L512

It seems our current endpoint.write() does some handling for the attribute data to generate a payload to pass to Zcl.ZclFrame.create().

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

Lines 358 to 399 in 487996a

	public async write(
	clusterKey: number | string, attributes: KeyValue, options?: Options
	): Promise<void> {
	const cluster = Zcl.Utils.getCluster(clusterKey);
	options = this.getOptionsWithDefaults(options, true, Zcl.Direction.CLIENT_TO_SERVER, cluster.manufacturerCode);
	options.manufacturerCode = this.ensureManufacturerCodeIsUniqueAndGet(
	cluster, Object.keys(attributes), options.manufacturerCode, 'write',
	);
	const payload: {attrId: number; dataType: number; attrData: number| string | boolean}[] = [];
	for (const [nameOrID, value] of Object.entries(attributes)) {
	if (cluster.hasAttribute(nameOrID)) {
	const attribute = cluster.getAttribute(nameOrID);
	payload.push({attrId: attribute.ID, attrData: value, dataType: attribute.type});
	} else if (!isNaN(Number(nameOrID))){
	payload.push({attrId: Number(nameOrID), attrData: value.value, dataType: value.type});
	} else {
	throw new Error(`Unknown attribute '${nameOrID}', specify either an existing attribute or a number`);
	}
	}
	const log = `Write ${this.deviceIeeeAddress}/${this.ID} ` +
	`${cluster.name}(${JSON.stringify(attributes)}, ${JSON.stringify(options)})`;
	debug.info(log);
	try {
	const frame = Zcl.ZclFrame.create(
	Zcl.FrameType.GLOBAL, options.direction, options.disableDefaultResponse,
	options.manufacturerCode, options.transactionSequenceNumber ?? ZclTransactionSequenceNumber.next(),
	options.writeUndiv ? "writeUndiv" : "write", cluster.ID, payload, options.reservedBits
	);
	const result = await this.sendRequest(frame, options);
	if (!options.disableResponse) {
	this.checkStatus(result.frame.Payload);
	}
	} catch (error) {
	error.message = `${log} failed (${error.message})`;
	debug.error(error.message);
	throw error;
	}
	}

This is missing in endpoint.writeStructured()

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

Lines 700 to 724 in 487996a

	public async writeStructured(clusterKey: number | string, payload: KeyValue, options?: Options): Promise<void> {
	const cluster = Zcl.Utils.getCluster(clusterKey);
	options = this.getOptionsWithDefaults(
	options, true, Zcl.Direction.CLIENT_TO_SERVER, cluster.manufacturerCode);
	const frame = Zcl.ZclFrame.create(
	Zcl.FrameType.GLOBAL, options.direction, options.disableDefaultResponse,
	options.manufacturerCode, options.transactionSequenceNumber ?? ZclTransactionSequenceNumber.next(),
	`writeStructured`, cluster.ID, payload, options.reservedBits
	);
	const log = `WriteStructured ${this.deviceIeeeAddress}/${this.ID} ` +
	`${cluster.name}(${JSON.stringify(payload)}, ${JSON.stringify(options)})`;
	debug.info(log);
	try {
	await this.sendRequest(frame, options);
	// TODO: support `writeStructuredResponse`
	} catch (error) {
	error.message = `${log} failed (${error.message})`;
	debug.error(error.message);
	throw error;
	}
	}

Which seems to expect a raw payload that is passed to Zcl.ZclFrame.create().

We should probably update this one and also add the missing writeStructuredResponse and readStructure* variants as we probably also want to be able to read the data we write. Perhaps this can be done when we do #902.

So far there is only one usage of endpoint.writeStructured() here https://github.com/Koenkk/zigbee-herdsman-converters/blob/b9f29f55d3f0531c9235e38a6848908c9a493042/src/converters/toZigbee.ts#L2082

[sjorge]

More confusing things while looking into this, I tried generated the payload in zhc to see if I could at least get the write to work without messing with herdsman yet.

https://github.com/Koenkk/zigbee-herdsman-converters/blob/b9f29f55d3f0531c9235e38a6848908c9a493042/src/devices/ubisys.ts#L509

+                    const cluster = Zcl.Utils.getCluster('manuSpecificUbisysDeviceSetup');
+                    const attributes = {'inputActions': {elementType: 'octetStr', elements: resultingInputActions}};
+                    const payload: {attrId: number; dataType: number; attrData: number| string | boolean}[] = [];
+                    for (const [nameOrID, value] of Object.entries(attributes)) {
+                        if (cluster.hasAttribute(nameOrID)) {
+                            const attribute = cluster.getAttribute(nameOrID);
+                            payload.push({attrId: attribute.ID, attrData: value, dataType: attribute.type});
+                        } else if (!isNaN(Number(nameOrID))){
+                            // NOTE: tsc trisp here, but we take the prev branch
+                            //payload.push({attrId: Number(nameOrID), attrData: value.value, dataType: value.type});
+                        } else {
+                            throw new Error(`Unknown attribute '${nameOrID}', specify either an existing attribute or a number`);
+                        }
+                    }
+
+                    await devMgmtEp.writeStructured(
+                        'manuSpecificUbisysDeviceSetup',
+                        payload,
+                        manufacturerOptions.ubisysNull,
+                    );
+                    /*
                     await devMgmtEp.write(
                         'manuSpecificUbisysDeviceSetup',
                         {'inputActions': {elementType: 'octetStr', elements: resultingInputActions}},
                         manufacturerOptions.ubisysNull,
                     );
+                    */

TSC is very much not happy with this:

src/devices/ubisys.ts:517:65 - error TS2322: Type '{ elementType: string; elements: unknown[]; }' is not assignable to type 'string | number | boolean'.

517                             payload.push({attrId: attribute.ID, attrData: value, dataType: attribute.type});
                                                                    ~~~~~~~~

  src/devices/ubisys.ts:513:71
    513                     const payload: {attrId: number; dataType: number; attrData: number| string | boolean}[] = [];
                                                                              ~~~~~~~~
    The expected type comes from property 'attrData' which is declared here on type '{ attrId: number; dataType: number; attrData: string | number | boolean; }'


Found 1 error in src/devices/ubisys.ts:517

Which leaves me very confused as the original write passes {'inputActions': {elementType: 'octetStr', elements: resultingInputActions}}, as attributes param to endpoint.write() and that somehow does work but the code I added was copied from that function 😕

Edit 1:
I think we somehow end up here:

zigbee-herdsman/src/zcl/buffaloZcl.ts

Lines 160 to 167 in 487996a

	private writeArray(value: ZclArray): void {
	const elTypeNumeric = typeof value.elementType === 'number' ? value.elementType : DataType[value.elementType];
	this.writeUInt8(elTypeNumeric);
	this.writeUInt16(value.elements.length);
	value.elements.forEach(element => {
	this.write(DataType[elTypeNumeric], element, {});
	});
	}

Which would make sense given this attribute is an array (ZCL data type 0x48) of raw binary data (ZCL data type 0x41).
Somehow for the endpoint.write() we bypass a tsc check somewhere allowing us to get here which in my hacked attempt to generate the payload in ZHC we hit.

Edit 2:
Completely manually massaging the ZclPayload:

                    await devMgmtEp.writeStructured(
                        'manuSpecificUbisysDeviceSetup',
                        [{attrId: 0x0001, selector: {}, dataType: Zcl.DataType.array, elementData: {elementType: 'octetStr', elements: resultingInputActions}}],
                        manufacturerOptions.ubisysNull,
                    );

Seems to work

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days

[sjorge]

Unstale

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days