Ubisys D1 - Input raw configuration doesn't get accepted

[wb441]

What happened?

Goal = the two inputs control the dimmable load of the D1. Its documentation shows that it is very similar to Ubisys C4.
There are two ways, with pre-defined templates and with raw configuration.

Here is a link to a case where someone sent a raw configuration to C4 see this link

Now for D1:

This is a raw configuration which is valid for D1, which was used in a Deconz implementation. It can be found at this thread.

I translated this configuration (perhaps here already I made a mistake?) to zigbee2mqtt/D1/set

`
{
"configure_device_setup": {
"input_configurations": [0, 0],
"inputActions": [
[ 0, 13, 2, 8, 0, 4, 254, 1, 0],
[ 0, 3, 2, 8, 0, 4, 54, 1, 0],
[ 1, 13, 2, 8, 0, 4, 54, 1, 0],
[ 1, 3, 2, 8, 0, 4, 0, 1, 0]

    ]
}

}
`

When reading back the configuration with zigbee2mqtt/D1/get/configure_device_setup, the configuration is still the original.
Also, I get this information which doesn't seem to be blocking but is weird nonetheless.

Warning ubisys: Device setup read for 'D1': {"0":[0,0]} Debug Received Zigbee message from 'D1', type 'readResponse', cluster 'manuSpecificPhilips', data '

In conclusion, the raw configuration is not accepted nor rejected.

What did you expect to happen?

I assume (dangerous, I know :-) ) that either

1. My input is wrong
   The configuration is tested working, but the example I based it on is a hex stream all after each other. Based on the example on the C4, I need to convert the values to decimals, but perhaps I'm doing it wrong

This is the base: Link

It is constructed as follows

`

Status	4841			element type: 0x41 (raw data)
	04	00		element count: 0x0004 (4 entries)
works	09			element #1: nine bytes
works	00			InputAndOptions: 0x00
works	0D			Transition: released -> pressed
works	02			Source: Endpoint #2 (hosts primary on/off client cluster on D1)
works	08	00		Cluster ID: 0x0008 – level control
works	04	FF	0E00	ZCL Command Template: Move to level, transitiontime,
works	09			element #2: nine bytes
works	01			InputAndOptions: 0x01
works	0D			Transition: released -> pressed
works	02			Source: Endpoint #2 (hosts primary on/off client cluster on D1)
works	08	00		Cluster ID: 0x0008 – level control
works	04	2A	0E00	ZCL Command Template: Move to level, transitiontime,
works	09			element #3: nine bytes
works	00			InputAndOptions: 0x00
works	03			Transition: any state -> released
works	02			Source: Endpoint #2 (hosts primary on/off client cluster on D1)
works	08	00		Cluster ID: 0x0008 – level control
works	04	2A	0100	ZCL Command Template: Move to level, transitiontime,
works	09			element #4: nine bytes
works	01			InputAndOptions: 0x01
works	03			Transition: any state -> released
works	02			Source: Endpoint #2 (hosts primary on/off client cluster on D1)
works	08	00		Cluster ID: 0x0008 – level control
works	04	00	0100	ZCL Command Template: Move to level, transitiontime,

This is what I converted it to:

`zigbee2mqtt/D1/set

{
"configure_device_setup": {
"input_configurations": [0, 0],
"inputActions": [
[ 0, 13, 2, 8, 0, 4, 254, 1, 0],
[ 0, 3, 2, 8, 0, 4, 54, 1, 0],
[ 1, 13, 2, 8, 0, 4, 54, 1, 0],
[ 1, 3, 2, 8, 0, 4, 0, 1, 0]

    ]
}

}
`

2. Is the message not converted right to the device

• Perhaps zigbee herdsman converters drops part of the configuration because it is longer than expected?
• In the documentation, every part has to be preceded by a marker which indicates the length in bytes of what follows. Perhaps this 'wrapping' goes wrong?

Thank you very much for any help.

Perhaps @felixstorm you are the genius which can shed some light here?

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

1.22.1

Adapter firmware version

20190608

Adapter

Electrolama Zig-a-zig-ah

Debug log

Debug Received MQTT message on 'zigbee2mqtt/D1/set' with data '{ "configure_device_setup": { "input_configurations": [0, 0], "inputActions": [ [ 0, 13, 2, 8, 0, 4, 254, 1, 0], [ 0, 3, 2, 8, 0, 4, 54, 1, 0], [ 1, 13, 2, 8, 0, 4, 54, 1, 0], [ 1, 3, 2, 8, 0, 4, 0, 1, 0] ] } }'
Debug Publishing 'set' 'configure_device_setup' to 'D1' Submitted
Debug Received Zigbee message from 'D1', type 'readResponse', cluster 'manuSpecificPhilips', data '{"0":[0,0]}' from endpoint 232 with groupID 0 Weird that it's mentioning Philips
Debug No converter available for 'D1' with cluster 'manuSpecificPhilips' and type 'readResponse' and data '{"0":[0,0]}'
Warning ubisys: Device setup read for 'D1': {"0":[0,0]}
Debug Received Zigbee message from 'D1', type 'readResponse', cluster 'manuSpecificPhilips', data '{"1":[{"data":[0,13,2,6,0,1],"type":"Buffer"},{"data":[0,3,2,6,0,0],"type":"Buffer"},{"data":[1,13,2,6,0,1],"type":"Buffer"},{"data":[1,3,2,6,0,0],"type":"Buffer"}]}' from endpoint 232 with groupID 0
Debug No converter available for 'D1' with cluster 'manuSpecificPhilips' and type 'readResponse' and data '{"1":[{"data":[0,13,2,6,0,1],"type":"Buffer"},{"data":[0,3,2,6,0,0],"type":"Buffer"},{"data":[1,13,2,6,0,1],"type":"Buffer"},{"data":[1,3,2,6,0,0],"type":"Buffer"}]}' No converter, wonder why
Warning ubisys: Device setup read for 'D1': {"1":[{"type":"Buffer","data":[0,13,2,6,0,1]},{"type":"Buffer","data":[0,3,2,6,0,0]},{"type":"Buffer","data":[1,13,2,6,0,1]},{"type":"Buffer","data":[1,3,2,6,0,0]}]} Change wasn't successful

[wb441]

@felixstorm Would you be able to detect where I'm going wrong?
Best regards

[felixstorm]

@wb441 Sorry for not answering any earlier - I am quite busy at the moment. I had already taken a quick look at your issue when you opened it, but unfortunately there is nothing that catches my eyes with it. The fact that it mentions "Philips" is completely fine AFAIR - the same numerical cluster id gets used by multiple vendors (that`s ok with the ZigBee standard) and when receiving the frame zigbee-herdsman does not yet know about the device details, so it takes the first cluster name that matches the numerical id. This is also ok for us in this situation as the frame contents are still dumped correctly and we only want to have the data in the logs to be able to manually verify that everything worked out fine.
Same goes for "No converter": Due to the problem matching the correct cluster definition, it would be hard to provide a converter - and since we only want to see the bytes in the log, it's completely fine without one.

But to get back to your problem: Generally configuring ubisys inputs should work or at least did work for me a few weeks ago, but unfortunately I do not really have a setup at hand to reproduce your exact issue. Things that come to my mind that you could try:

• While writing the next item in my list something does indeed catch my eye: Are you sure that your request is valid? You send input_configurations and inputActions - but IMHO both should be snake case, i.e. input_actions?
• You could separate the request into two separate MQTT requests - one for input_configurations and one for input_actions (but AFAIK it should generally be ok to send them together in one request).
• If that still does not help, I would need another debug log with zigbee-herdsman debugging turned on as well: https://www.zigbee2mqtt.io/guide/usage/debug.html#zigbee-herdsman-debug-logging
  Also, it would be very helpful if you could format the log as code (a line with only ``` above and below the log) or attach it somehow etc. - that makes it a whole lot easier to read.

Felix

[wb441]

Embarassingly, input**_a**ctions was indeed the problem.
This worked immediately:

{
    "configure_device_setup": {
        "input_configurations": [0, 0],
	"input_actions": [
		[0,13,2,8,0,4,254,0,0],
		[1,13,2,8,0,4,54,0,0],
		[0,3,2,8,0,4,54,0,0],
		[1,3,2,8,0,4,0,0,0]

        ]
    }
}

Once again z2m works brilliantly and I was the issue ;-)
Thank you so much!

[felixstorm]

@wb441 No problem - I'm glad that it works now!