It sounds like you're not too far off, you just need to spend a bit more time understanding the elements of the mapping file for XMidiCtrl. The plugin has a debug mode which will show the real-time midi signals that ARE coming in, even if they're not mapped to any functions. So, that would be where I'd start. THe TOML file contains a device name, port numbers (identifying inbound vs outbound commands), a channel number (mine is 11 for all commands), and 'cc' numbers which distinguish one command from another.
Here's an example of a rotary knob mapping:
{ ch = 11, cc = 1, type = "enc", command_up = "CL650/DCP/1/baro_up", command_down = "CL650/DCP/1/baro_down" },
And here's an example of a button mapping:
{ ch = 11, cc = 63, sl = "0", type = "cmd", command = "CL650/CCP/1/menu_push" },
I am using a stock profile for the CL650 for XMidiCtrl, however, I did have to load a 'layer file' from the PC to the XMidiCtrl that came with XMidiCtrl using a Behringer tool, otherwise the inbound commands were very different. Specifically, the knobs can send an absolute value based on the knobs position (such as a volume control being at 0%, 50% or 100%), or they can send a relative change (ie, increase 1 or decrease 1). Out of the box, the hardware was sending absolute values. Uploading the layer file reprogrammed the unit with specific CC values for the various buttons AND changed the knobs to relative mode. How that applies to the Loupedeck I'm not sure, however, the debugging mode in XMIdiCtrl should go a long way to helping you determine what is going on.
Make sure you understand the format of the TOML file to some degree, or you'll be miserable.