If logs where generated please post these here using code fences:
16:37:22.810 [INFO ] [smarthome.event.ItemStateChangedEvent] - Corridor_PresenceDetector changed from OFF to ON
16:37:22.815 [INFO ] [smarthome.event.ItemStateChangedEvent] - Corridor_PresenceDetector_Linked changed from NULL to ON
16:37:33.355 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Corridor_PresenceDetector' received command OFF
16:37:33.372 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Corridor_PresenceDetector_Linked' received command OFF
16:37:33.398 [INFO ] [arthome.event.ItemStatePredictedEvent] - Corridor_PresenceDetector predicted to become OFF
16:37:33.417 [INFO ] [smarthome.event.ItemStateChangedEvent] - Corridor_PresenceDetector changed from ON to OFF
The Corridor_PresenceDetector_Linked item is supposed to turn off after 10 seconds, but it stays on forever, and the linked lightbulb doesn’t turn off.
The shown config uses two separate Items, but the same issue happens when I add a second channel with profile="follow" to the Corridor_PresenceDetector item - the Item doesn’t change its state, and the linked lightbulb doesn’t turn off.
This is quite puzzling, as I have used this configuration in the past, and it worked just fine. I have tried downgrading to 2.5.4 and 2.5.3 to no avail.
‘expire’ does what it is supposed to do, and issues a command.
(albeit there is a one second error due to a won’t-fix bug)
That’s it, end of expire involvement.
Next, you rely on autoupdate to predict the likely outcome of the command, and issue a state update.
Autoupdate’s action can be inhibited (vetoed) in some circumstances by channels. Looks like that what is happening here.
No state update, no follow action,
You can test your follow profile by issuing a state update to your Item, see if it triggers the device.
You can circumvent the autoupdate problem by having expire issue a state update, instead of command, which should activate the follow.
Unfortunately that would not then activate the “normal” channel.
We had a thread recently, that showed certain zigbee devices vetoing autoupdate unexpectedly. I wonder if this is related.
Because that is the exact purpose of the follow profile that you chose to configure it with.
External devices do not normally follow Item states, it’s the other way round - command goes out, device reports, Item state follows device.
Follow profile works the other way - Item state goes to device, by way of the follow profile transforming it to act like a command.
No. If you pass a command to an Item, it gets passed to all linked channels/bindings. What they do with it, if anything, depends on specific binding and config.
Ok, I think I get the flow now - expire is acting on the Item, the “following” channel gets the “ON”/“OFF” because the Item state updates.
This doesn’t really explain why the state of the switch gets updated correctly when there’s no “following” channel. I would expect, given these premises, that a command sent by expire won’t have any effect.
It wouldn’t have any effect on Item state - except - every Item has autoupdate feature enabled by default.
So, in the normal course, a command eventually results in state update via autoupdate. It’s like a psuedo-binding.
However … autoupdate polls linked channels for further guidance.
There’s more about this in the zigbee post I linked earlier, but channels can veto the usual autoupdate predictions i.e. suppress a predicted update.
That’s what seems to be happening to you.
It is possible this is because of the zigbee channel you link via profile
maybe its an unexpected effect of follow profile itself, not seen this before.