You have two different definitions for the same physical device at zwave:14. And you are using a change in state in one of the device definitions to trigger a change in state of the other definition. And you are using received update rather than changed from/to as the trigger. This is pretty much guaranteed to end up in a race condition.
You want multiple pathways to manipulate the dimmer setting: the actual physical dimmer, Openhab’s lowest level logical mapping to that dimmer via an item defined at zwave:14, and a proxy for the dimmer where you will intercept actions at runtime to conditionally alter proposed behavior (in form of sendCommands) to different target values.
Generally speaking, you will target all automation commands and UI commands to the PROXY for the dimmer, intercept that via “WHEN diMBRLIght_PROXY received command xx”, examine conditional states in the THEN clause of that rule to modify desired state of the real device, and issue a sendCommand to the zwave-mapped logical mapping of the dimmer. viz.,
RULE "Proxy intercept"
WHEN
Item diMBRLight_PROXY changed from 0
THEN
var new_state=diMBRLight_PROXY.state
//conditional changes to new_state value go here
sendCommand(diMBRLight,new_state)
END
You will also need a sync-ing rule to update the value of the proxy when your manual change of the physical dimmer is the proximate cause. viz,
RULE "PXY_SYNCH..."
WHEN
Item diMBRLight changed from 0
THEN
postUpdate (diMBRLight_PROXY,diMBRLight.state)
END
It is important to use “changed to/from” form here rather than a bare “changed” to avoid triggering race conditions. See Design Patterns Discussion