If your other devices are Z-Wave, you might be able to use Z-Wave Association to do what you want. Hubitat's built-in driver doesn't support this (I'm not sure any of theirs really do), but there are probably ways to set it up, or I could somehow add it to mine (but it wasn't really created with that use case in mind). If they aren't Z-Wave--or they are but you prefer a hub-based automation instead--my driver can definitely work. Here's one example.
Say you want the top left small button to toggle on/off a light. This is button 1, and a single push will give "button 1 pushed" (if you're using multi-taps: note that a double tap on this button is "button 6 pushed," and other assignments as above, in order to assign all possible actions a Hubitat event). You could use Button Controller to create something that uses the ZEN32 as a device, then assign "button 1 pushed" the action of toggling your other light.
Then there's the LED. Here, you'll need a rule or custom app. My recommendation would be a rule. If you want the LED to reflect the switch state of a device called Dimmer 1, then I'd do something like this:
Trigger events: Dimmer 1 *changed* (choose "Switch" for the trigger capability--not "Dimmer")
Actions to run:
IF (Dimmer 1 is on) THEN
setLED(1,"white",0) on ZEN32
ELSE
setLED(1,"white",100) on ZEN32
END-IF
The setLED() thing here is a custom command, which you can do by creating an action under Set Mode or Variables, Run Custom Action > Run Custom Action. Choose the ZEN32 as the device (any capability it supports will work to get it selected, like "Switch" or "Dimmer"--it will ask but doesn't matter beyond this), choose setLED() as the command, and create three parameters: the first as a number (integer--the button number 1 to 5), the second as a string ("white", "blue", "green", or "red"--no quotes), and the third as the level (technically anything 0-100 will work, with 0 being converted to off in my driver and anything above that getting rounded to the nearest value the ZEN32 actually supports: 30, 60, or 100).
You could also really do this all in the same rule if you wanted (maybe using a conditional action to check if the dimmer is currently on or off, then running the opposing command and optimistically setting the LED), but I think the above is better because it accurately reflects the dimmer state as Hubitat actually sees it, not according to what it should be set to.