Sending a command to an item by default changes its state to match the command, unless you add autoupdate="false" to the binding section of the item, in which case this is suppressed. I always assumed that this default behavior exists so that the user interface would immediately feed back to the user that they just toggled a switch, changed a setpoint, etc.
In cases where the true state of the item cannot be fed back to openHAB immediately but the command was in fact passed to the binding, this default auto-update behavior makes sense. However, the UI is, in a way at that moment, “lying” about the state of the item when the item is bound to one or more underlying systems that may not have yet, or may never, process the command so that the desired command is reflected faithfully in the bound system(s).
The bindings I’m familiar with do in fact update the state of the item at some point after the command is sent (if they can), but the binding update is usually not noticed because the auto-update logic described above already changed the state when the user requested it. The problem, however, is that some bindings take a long time to get around to updating the state, so the auto-update logic fills in the user-experienced time gap between user action and the binding updating the item, in order to give the appearance of an instantaneous change. The is a sound user-interface practice, in my opinion.
The way I view bindings is that they are simply trying to update the states of items as best they can over time to match the systems they are integrating to, but the binding in no way “owns” control over the items it is bound to. So when a user or rule sends a command to an item, and openHAB propagates that command to your binding, your binding will try to execute that command as best it can, but is not in a position to update the item’s state if it doesn’t actually know the state. So if your binding is in a disconnected state, at that moment you simply don’t know what state the item should have, and so you simply shouldn’t be setting the state when you don’t know it.
I think the big issue here has more to do with giving better feedback to users about whether your binding is working when it needs to be working. The next generation of openHAB has an improved concept of “bridge thing” that tries to represent the state of the path from openHAB to a device, and more sophisticated semantics exist when the path to the thing is not possible because of the state of the bridge. At the end of the day, I think these are more user-interface issues, and trying to compensate for it by changing per-binding semantics would be a step in the wrong direction. Also, the idea that one binding would have very different semantics about how it processes updates and commands from other bindings gives me chills, as this would add yet a new level of complexity to an already very complex system.
Perhaps the Homematic binding could instead support item bindings that report the last time you communicated with the underlying equipment, or have a simple status message update a String item, so the user has better feedback that what they are trying to do won’t, or didn’t, work?