On a Raspberry pi with opanhabian and OH2.5M5 I get the following event.log entries:
2019-12-02 09:19:48.867 [ome.event.ItemCommandEvent] - Item 'Loc_Home' received command OFF
2019-12-02 09:19:48.895 [nt.ItemStatePredictedEvent] - Loc_Home predicted to become ON
2019-12-02 09:19:48.909 [ome.event.ItemCommandEvent] - Item 'Loc_Work' received command ON
2019-12-02 09:19:48.927 [nt.ItemStatePredictedEvent] - Loc_Work predicted to become OFF
For other items it look alright:
2019-12-02 09:29:30.813 [ome.event.ItemCommandEvent] - Item 'Heat_HzMode' received command day
2019-12-02 09:29:30.882 [nt.ItemStatePredictedEvent] - Heat_HzMode predicted to become day
Any idea why this could be wrong with the command interpretation?
The command comes in from nodeRED, but the same result when trigering from karaf.
My expectation would be, that regardless where I trigger the item (classic rule, nodered, karaf) the event.log should reflect the same result.
I still had the gps tracker binding linked to the item, which was now handled by nodeRED and distance from home for home zone triggers.
The strange entries disappeared.
Although it’s stange that the conflicting sendCommand (from nodeRED and the GPSTracker binding) did not show up completely.
I would have expected two of each “received command” and “predicted to” events
Autoupdate consults each linked binding for their prediction, before falling back to its own prediction (or getting vetoed altogether).
Bear in mind the primary purpose of autoupdate is really just to guess the likely effect of a command for a speedy UI effect, where a real device might take some time to respond.
As such, bindings which have more specialized “knowledge” about the target device or service can override autoupdate.
If we apply that logic to your situation above - that Item represents a person’s location? … no amount of sending commands to your Item will affect the real-life location of a person/phone/car, so if the GPS tracker rejects the proposed autoupdate, that seems right to me.
So this means that even a command ON has been received, another command / state update might overrride it?
In other words the assumption that the prediction will be reflected in the upcoming state is not always given?
It’s the prediction that is affected. Bindings can make their own predictions, or veto any prediction. Autoupdate will use a binding prediction in preference to its own; or provide no prediction at all in the case of veto. If there is a prediction, then it gets actioned as a state update.
There’s never been a direct link from command to state at all. Either a binding/device, or autoupdate (which I think of like a psuedo-binding) reacts to command to give state update.
Think dimmer command INCREASE , result might be 75% for example.
Think a binding linked to a switch that is currently broken; command ON and a sensible response might be UNDEF. Autoupdate could never guess that, but the binding can.
Many of the current bindings actually offer no opinions in this process.
