Alter handling of 'composite' exposes

[asgothian]

A review of several devices in the zigbee-herdsman-converters has shown a tendency to move towards 'composite' exposes for more complex functionalities.

Currently, these are translated into separate states. While there seems to be an internal connection between the different states this is not visible to the user and can lead to strange behavior if specific states of the composite are not set, as well as multiple messages with different content as several parts of the composite are changed to achieve a specific setting.

I propose to change this in the following way:

Lets use the device SD-8SCZSB as an example. The expose definition lists this composite expose:

warning: Can be set by publishing to zigbee2mqtt/FRIENDLY_NAME/set with payload {"warning": {"mode": VALUE, "level": VALUE, "strobe_level": VALUE, "strobe": VALUE, "strobe_duty_cycle": VALUE, "duration": VALUE}}

• mode (enum): Mode of the warning (sound effect). Allowed values: stop, burglar, fire, emergency, police_panic, fire_panic, emergency_panic
• level (enum): Sound level. Allowed values: low, medium, high, very_high
• strobe_level (enum): Intensity of the strobe. Allowed values: low, medium, high, very_high
• strobe (binary): Turn on/off the strobe (light) during warning. Allowed values: true or false
• strobe_duty_cycle (numeric): Length of the flash cycle.
• duration (numeric): Duration in seconds of the alarm.

Currently, this would be translated into the following states:

mode as enum, level as enum, strobe as boolean, strobe_duty_cycle as number, duration as number which have to be set separately in order to set the warning parameters and activate the warning.

After the proposed change, we would obtain the following states warning_object as string, accepting a payload object as described in the Zigbee2mqtt.io documentation. This would be the only state which directly communicates with the zigbee-herdsman-converters warning.mode as enum warning.level as enum warning.strobe as boolean warning.strobe_duty_cycle as number warning.duration as number

The 5 states with a . would all be contained in the channel warning. Changes to the states would effectively trigger an update of the warning_object state, and as such trigger the communication with the device. A delay between changing the state in the channel and updating the warning_object (defined in the channels common properties and set to a default via the adapter configuration) would allow for a script to set the desired single states to a value before the composite payload is sent to the zigbee device.

Additionally, the states in the channel would all need to contain a default value following the table below:

• enum: Default is the first entry of the enum
• number: default is 0
• string: default is ""
• boolean: default is false

Use of this method of interpreting composite states would need to be configurable in the adapter config due to the breaking change it implements as it also relates to the "color" state which is also set as a composite state.

This would make using these composite states easier for the end user and more transparent with the zigbee2mqtt documentation.

Thoughts on this ?

A.

[arteck]

i find the idea good. new folder with single states. under the dev object

[arteck]

@kirovilya ?

[kirovilya]

Hi guys. Now it’s hard for me to think about issues - there are a lot of other worries. The idea of grouping composite fields is a good one, but we need to consider working in "legacy" mode. Moreover, for the new pairing devices, we need to make a new mode as default, and for those already added - 'legacy', with the ability to switch.

[asgothian]

Hi Ilya,

I understand the situation. I will attempt to make a proposal with an option to keep some / all devices in legacy mode. This will take time. It is a lot more than just a few detail changes.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.