Clusters come in pairs:
The device being controlled implements the server (blue) cluster;
The controlling device implements the client (grey) cluster.
A binding tells a device (Source) where (Destination) to send messages associated with the cluster:
Either a (list of) unicast(s) to (an)other device(s), where you specify the IEEE address and endpoint by dragging and dropping the endpoint (not the cluster);
Or a groupcast, where you specify the group ID, by selecting the radio button and edit the group id in hex.
There's nothing magical about a binding, its just a configuration on the source device. Unfortunately, the deCONZ GUI doesn't support querying the binding table, so there's no easy way to check bindings. Most devices have limited (non-volatile) memory for the binding table, so a single binding to a group is preferred over multiple bindings to individual devices.
Now here's the tricky part:
Client clusters send commands to the associated server cluster. Typically you want to use a groupcast message for these, so you'd create a binding from a client (grey) cluster to a group;
Server clusters send notifications (reports) about their (changed) state. Typically you want a unicast message for these, so you'd create a binding from a server (blue) cluster to (typically) the coordinator (RaspBee/ConBee).
Now here's the really tricky part:
A physical device typically implements multiple functions (clusters) and might be the controller for one function and, at the same time, the controlled device for another function. This is actually the case for the Hue dimmer (and, I assume, the smart button), see below;
The same logical function might be implemented differently by different devices. Typically Hue and Xiaomi devices act as controlled devices, sending notifications to the bridge/gateway, whereas Trådfri and most other devices act as controllers, sending commands to (a group of) lights. In other words: Xiaomi switches behave like sensors and the Trådfri motion sensors behave like wireless switches. The device type might give a clue, but better check the clusters to be sure.
Now here's the really, really tricky part: The Hue dimmer and, I assume, the Hue smart button are hybrids:
When paired with the Hue bridge, they act as a sensor, sending notifications about the buttonevent to the bridge.
When used standalone, they act as wireless switch, sending commands to the bound (group of) lights.
This is reflected well by device types on the Hue dimmer endpoints: Non color scene controller on endpoint 0x01 (with the client On/Off and Level control clusters) vs Simple sensor on endpoint 0x02 (with the server 0xfc00 cluster).
So you need the following bindings for the Hue dimmer and, I assume, the Hue smart button:
From the server 0xfc00 cluster to endpoint 0x01 of the ConBee/RaspBee, so that the switch sends buttonevent notifications to the gateway;
From the server Power Configuration cluster to endpoint 0x01 of the ConBee/RaspBee, so that the switch sends battery reports to the gateway (you also need to configure reporting for the Battery Percentage Remaining attribute 0x0021);
From the client On/Off and Level Control clusters to the associated group (which will be reported as config.group once the switch will be supported), to control the lights in that group, even when deCONZ is not running.
Once supported, the REST API plugin should setup these bindings on the switch. Sometimes this fails, and manually creating the bindings fixes this.
After a few minutes, the Button goes in "deep sleep". It is not available in deCONZ and it's not possible to wake up it by pressing the button for a short or long period.
I've seen other switches (Trådfri) hibernate when no appropriate bindings have been setup.