This is the third part of a five-part post:

Before progressing too far into the design/coding process, it’s useful to put down on “paper” a list of required and desired functionality, as well as a very preliminary idea of how the various pieces might be implemented.

Doing so helps refine, and make clearer those elements that are core, those are are useful, but clearly optional, and those that are blatantly superfluous.

This remains true even for small personal projects.

And so here is the list of planned functionality for the Aqara E1 Moult firmware.

Mandatory features

Full Zigbee binding support.

This is my biggest gripe with most cheap Zigbee switches. They’re usually fine if intermediating everything through a hub, but are next to useless for direct device -> device control.

Finding and binding support is also required.

Scene recall for remote groups/devices.

Binding binds like clusters, such as an onOff server (e.g. light bulb) to an onOff client (e.g. remote control), but the switch should also be able to trigger scenes on remote devices and groups, without the coordinator in the middle.

Sending arbitrary ZCL commands.

The ZCL spec. has tried to account for most usage situations, but it is relatively inflexible. Binding requires every possible client cluster to implemented on the controlling device, and for a toggle button, there is no clear mapping of button tap → command sent. For example should a single-tap send an open, close, or stop command to a window covering?

Furthermore many devices operate on non-standard clusters (e.g. Tuya), and so binding is not possible.

For these situations, the ability to precisely specify the command that is sent (including payload) for a particular button tap is needed.

Single, double, and triple button taps.

Each button should support single, double and triple taps for all possible actions, with fully configurable delays.

Instant response to single taps when no double/triple tap is required.

The flexibility to detect double and triple taps should not be at the cost of delayed reaction to single taps if the double/triple tap is not needed.

Flexible button → action mapping.

Each single/double/triple tap should be capable of any combination of the aforementioned actions:

• Switching local relay
• Switching bound devices on/off
• Triggering remote scenes
• Sending arbitrary ZCL commands

Timer off.

Allow a timeout to be set for each channel such that the output turns off after a set time.

Configurable LEDs.

The LEDs should of course be configurable in terms of color, output state → LED state mapping and the like.

Potential features

These are things that I’m still considering, which may or may not be useful.

Ability to configure the LEDs as output devices for notifications.

In addition to their role as indicators of the channel output state, the LEDs should be configurable as output devices.

Next step: Actually writing the firmware.