This is exactly by design. As rossko57 said, restoreOnStartup should occur before the bindings start receiving new states. When the binding starts it will then override the Item with the most recently received state. The driving principle is that the Items in OH should whenever possible exactly match the states of the devices. You wouldn’t want a “fresh” state overwritten by a stale state from the database.
I’ll try to provide an additional explanation. rossko57 covers one use case (i.e. when the command doesn’t match the actual state that an Item carries). In that case, the command would be increase but the state update would be 60%. This is one reason why commands and states are different.
Here is another one. Imagine the following situation. Let’s say you have an MQTT device that reports back whenever it changes state and the binding supports this. In that case what you would want is for OH to not update the Item’s state until after the device reports back that it has become the new state. So you would configure your Item with autoupdate=false. Now, when you send the command, the command will go through the binding out to the device, but the Item won’t actually change state. OH will wait for the device to report back that it has changed as a result of the command and then the binding will update the Item with the new state. I can’t use command because that will cause an infinite loop.
OK, now imagine the case where you have a technology that does not report back the state of the device when it changes. In that case you need to have autoupdate=true and in this case when you send the command, OH will also apply the new state as an update to the Item. In this case, since the device doesn’t report back the new state, we have to assume that our command was successful.
OH has to support both use cases. Therefore updates very deliberately do not get sent out to the binding and the device. Updates are only used to update the state of an Item internally to OH.
restoreOnStartup only performs updates. This again is a very deliberate design choice. For one, theoretically, Rules shouldn’t even be running and potentially the bindings may not even be running yet when the Items gets restored to their previous state. In the best case the commands would be ignored. In the worse case sending a command at this time would result in errors as things start triggering and executing before they are ready.
A binding’s job is to interface between OH and a given API or technology. This interface is exposed to OH as Things and Channels.
Items are used to model your home automation. One way to think about it is that Items are where meaning and context is given to Channels. It also normalizes the way that OH interacts with devices.
Rules are how you coordinate the behaviors of Items based on events. You can’t put Rules in a binding because those Rules could only ever work with that one API or technology. That destroys the whole point of OH.
You can think about it like the layers in the networking stack. Bindings are like the Network Access layer. Things and Channels are the Internet layer. Items are like the Transport layer. And Rules, sitemaps, and persistence are like the Application layer. The simile isn’t perfect but I do think it’s useful. Each layer builds on the previous layer. Each layer has a distinct job to do. And you don’t want to mix the responsibilities of one layer into another layer, particularly another layer down on the stack.
