To clarify, openHAB UIs only issue commands to Items.
That may or may not cause an Item state update later, depending on how you have chosen to configure autoupdate on that Item, and depending if it is linked to a binding channel that might respond.
Obviously it is your choice if any rule issues a command or a state update, with different effects.
In the normal course of things, a binding will pick up OH commands and pass to real devices, while incoming device status gets passed as OH Item updates.
The KNX xxx-control type channels are the exceptions to that general rule, so that incoming from device presents as command in openHAB. That allows something like a wall control panel to act in a similar way to openHAB own UI.
This function inversion is two-way, so that an OH Item state update is passed to a configured real device (you might light an indicator on a control panel, for example).
None of that takes any account of anything that might happen independently, like your wall control directly controlling the dimmer.
Assuming thewallswitch is independently controlling blinds, you don’t need openHAB to “do” anything, only “observe” wallswitch use, right? Just configure it as ordinary non-control channel, and have your rules listen for updates. You’ve no reason to send the wallswitch any OH command.
An alternative approach you might want to use for consistency, make the wallswitch a xxx-control type channel. Your rules would now listen for commands representing manual poking.
If you set your Item’s autoupdate to false, the Item state will not update.