Expire + Follow Profile not working as expected

  • Platform information:
    • Hardware: RPI4
    • OS: Raspbian
    • Java Runtime Environment: openjdk 1.8.0_212
    • openHAB version: 2.5.5
  • Issue of the topic: when using expire combined with a follow profile, expire doesn’t properly update the Item anymore.
  • Please post configurations (if applicable):
Dimmer Corridor_Light1 <lightbulb> (Corridor_Lights) {channel="zigbee:device:b2825b07:841826000000eebd:841826000000EEBD_3_dimmer", ga="Light"[name="Light", roomHint="Corridor"]}
Switch Corridor_PresenceDetector_Linked <motion> (Corridor_PresenceDetectors)
  {channel="zigbee:device:b2825b07:00158d000461c36d:00158D000461C36D_1_occupancy", expire="10s,command=OFF", channel="zigbee:device:b2825b07:841826000000eebd:841826000000EEBD_3_dimmer"[profile="follow"]}
Switch Corridor_PresenceDetector <motion> (Corridor_PresenceDetectors)
  {channel="zigbee:device:b2825b07:00158d000461c36d:00158D000461C36D_1_occupancy", expire="10s,command=OFF"}
  • 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.

Does this turn off after 10seconds as expected?

Yes.

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.

Using state instead of command indeed did the trick.
As a reference for posterity, what’s the “right” way, for simple cases like setting dimmers? State updates or commands?

Thanks for your help :slight_smile:

As a generalism, that was the right way. If you want “something to happen”, then send a command. If you just want to make a note, update a state.

There is something slightly amiss (I guess with zigbee binding) but if you’re happy with a workaround…

Note that with your expire-command version setup, the command gets also passes to zigbee channel xxx-occupancy, whatever that is. Maybe it doesn’t accept commands and that is related to your issue.

If you want “something to happen”, then send a command. If you just want to make a note, update a state.

Yeah, that’s why I had that configuration in the past, and why I’m surprised that using state makes it work - if I’m only “making a note”, why is the following channel reacting to it?

I’m fine with a workaround for now, but eventually I’d be more happy to have a permanent fix :slight_smile:

Note that with your expire-command version setup, the command gets also passes to zigbee channel xxx-occupancy , whatever that is. Maybe it doesn’t accept commands and that is related to your issue.

Is there a way not to have the command passed to that channel?
I don’t think that’s what breaks it, as it works fine with the item that has only the occupancy channel.

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.

1 Like

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
or
maybe its an unexpected effect of follow profile itself, not seen this before.

Fair enough. I’ll stick to this configuration for now, when I’ll have more time to play with my zigbee network I’ll take a second look at it.

This is fixed in 2.5.7, follow works as expected.