Incoming and Outgoing command flags should be cleaned when changing the side of cluster.

[erjiaqing]

We have 4 state of commands, incoming_server, incoming_client, outgoing_server, outgoing_client.

Per spec 7.10

The server cluster supports attribute data, events and cluster commands. The client cluster initiates interactions, including invocation of cluster commands.

The initiator should be a client

Then, if a cluster is configured as server, the command with outgoing_server mask must be a response to some other commands. And if a cluster is configured as a client, it should not accept commands expect the responses.

However, current code might mix the server and client commands -- if a cluster is configured as client and configured some response commands (A) with "incoming" flag, then when it is reconfigured as server only, and checked the "outgoing" flag, the command A in the emitted .zap will be "incoming" + "outgoing" instead of "outgoing" only.

[brdandu]

For zigbee 3.0 or zigbee pro we do have commands which are initiated on the server side but are not actually command responses(for eg Terminate Key establishment command). However, I see your point. When you change the side of the cluster enabled, you should see a warning sign in your command configuration. I know we had an issue with showing the right warning message but do you not see a warning sign in the command configuration UI when you switched the side of the cluster after configuring your commands like you mentioned?

[erjiaqing]

For zigbee 3.0 or zigbee pro we do have commands which are initiated on the server side but are not actually command responses(for eg Terminate Key establishment command). However, I see your point. When you change the side of the cluster enabled, you should see a warning sign in your command configuration. I know we had an issue with showing the right warning message but do you not see a warning sign in the command configuration UI when you switched the side of the cluster after configuring your commands like you mentioned?

I only see a message for "The configuration is missing the server cluster which is required for this endpoint's device type." when it is configured as "Client" cluster on endpoint 0.

However, the zap file will contain:

2013           "side": "server",
 2014           "enabled": 1,
 2015           "commands": [
 2016             {
 2017               "name": "ArmFailSafeResponse",
 2018               "code": 1,
 2019               "mfgCode": null,
 2020               "source": "server",
 2021               "incoming": 1,
 2022               "outgoing": 1
 2023             },

The incoming flag for ArmFailSafeResponse should not be 1 when the "side" is "server"

[brdandu]

For zigbee 3.0 or zigbee pro we do have commands which are initiated on the server side but are not actually command responses(for eg Terminate Key establishment command). However, I see your point. When you change the side of the cluster enabled, you should see a warning sign in your command configuration. I know we had an issue with showing the right warning message but do you not see a warning sign in the command configuration UI when you switched the side of the cluster after configuring your commands like you mentioned?

I only see a message for "The configuration is missing the server cluster which is required for this endpoint's device type." when it is configured as "Client" cluster on endpoint 0.

However, the zap file will contain:

2013           "side": "server",
 2014           "enabled": 1,
 2015           "commands": [
 2016             {
 2017               "name": "ArmFailSafeResponse",
 2018               "code": 1,
 2019               "mfgCode": null,
 2020               "source": "server",
 2021               "incoming": 1,
 2022               "outgoing": 1
 2023             },

The incoming flag for ArmFailSafeResponse should not be 1 when the "side" is "server"

Use the ZAP UI for confirming your configuration. Do not use the .zap file in edit mode to figure out the current configuration. The zap file saves your prior UI interaction in case you enable a previously disabled cluster setting again such that you do not have to redo your selections again. However if you still have an issue with the UI. Could you give me the steps for reproducing your issue?