Rule not triggering on change to UNDEF via expiration

Setup, Configuration and Use Runtime
1

OH 3.4.5 on Raspbian (I know, working on it…)

My Ecobee items stop updating at random intervals. Everything appears to be OK, but no updates happen … so my solution was to create a group with several items that should be updated regularly and put an expiration timer on the group. This works well – when updates top, the group item changes to UNDEF.

value: 0h2m0s
config: {}

My rule is set to trigger on the group item changing to UNDEF, but never seems to fire.

configuration: {}
triggers:
  - id: "2"
    configuration:
      itemName: EcobeeUpdateMonitor
      state: UNDEF
    type: core.ItemStateChangeTrigger
conditions: []

I see in the events log that the group is updated as things go along, but an update to UNDEF never appears, only from UNDEF (I’ve set the timeout artificially low to force the issue):

2025-06-19 20:31:41.542 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item '**EcobeeUpdateMonitor**' changed from 76.7 °F to 76.5 °F through ThermostatCave_ActualTemperature
2025-06-19 20:31:41.547 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item '**EcobeeUpdateMonitor**' changed from 76.7 °F to 76.5 °F through ThermostatOffice_ActualTemperature
2025-06-19 20:32:42.634 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item '**EcobeeUpdateMonitor**' changed from 76.5 °F to 76.6 °F through ThermostatOffice_ActualTemperature
2025-06-19 20:32:42.636 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item '**EcobeeUpdateMonitor**' changed from 76.5 °F to 76.6 °F through ThermostatHall_ActualTemperature
2025-06-19 20:34:45.372 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item '**EcobeeUpdateMonitor**' changed from UNDEF to 76.6 °F through ThermostatBedroom_ActualTemperature
2025-06-19 20:35:48.403 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item '**EcobeeUpdateMonitor**' changed from 76.6 °F to 76.7 °F through ThermostatStudio_ActualTemperature
2025-06-19 20:36:50.253 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item '**EcobeeUpdateMonitor**' changed from 76.7 °F to 76.8 °F through ThermostatBedroom_ActualTemperature
2025-06-19 20:38:53.594 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item '**EcobeeUpdateMonitor**' changed from UNDEF to 76.9 °F through ThermostatCave_ActualTemperature
2025-06-19 20:41:57.531 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item '**EcobeeUpdateMonitor**' changed from UNDEF to 76.9 °F through ThermostatBedroom_ActualTemperature
2025-06-19 20:43:00.780 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item '**EcobeeUpdateMonitor**' changed from 76.9 °F to 77 °F through ThermostatOffice_ActualTemperature
2025-06-19 20:43:00.783 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item '**EcobeeUpdateMonitor**' changed from 76.9 °F to 77 °F through ThermostatBedroom_ActualTemperature
2025-06-19 20:45:02.456 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item '**EcobeeUpdateMonitor**' changed from UNDEF to 77 °F through ThermostatBedroom_ActualTemperature

I assume the update from. UNDEF occurring multiple times consecutively is because multiple items are updated from one ecobee API call and is not interesting re: this problem.

Is there a difference in how changes originating with expiration are handled that would cause the rule to not fire?

Update: I’ve changed the expiration timer from “update state” to “send command”. Will monitor overnight with the short timeout.

  • Platform information:
    • Hardware: Pi 4
    • OS:
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
  • Java Runtime Environment: OpenJDK Runtime Environment (build 11.0.21+9-post-Raspbian-1deb10u1)
  • openHAB version: 3.4.5
2

There definitely is a difference given the events.log. There is no GroupItemsChangedEvent for UNDEF which means there’s no event to trigger the rule. I don’t know if that’s a deliberate choice or not but suspect this behavior only exists for Group Items.

It used to be the case that you could not update a Group Item at all. I don’t know when that changed, but it very well could have changed after OH 3.4.

If there is a bug here, a fix certainly will not be back ported to OH 3.4.5, so you’ll either need to work around this or see if the problem persists in the latest OH 5 milestone and file an issue if it does.

To work around it, I can think of several potential ideas:

I’m pretty sure you cannot send UNDEF and NULL as a command, only an update.

3

thanks for the reply, Rich.
Changing to send command has removed any sign of UNDEF from the log – even with time gaps big enough to trigger it. I had one of those d’oh moments just now, since this is only used for this monitoring purpose, I can use any value, so I’ve just changed the expiration value to update state to -1 and the rule to match.
As I typed this, a change to -1 showd up the same as UNDEF in the log (i.e., only the change “from” -1). I’m changing back to Send Command to see what happens.

I have an alert sent to Slack when the rules runs, so I should know within an hour or so.

will not be back ported to OH 3.4.5,

I’m fine with that. Have a system set up with OH4 to test as soon as I can put several consecutive hours together.

4

Welp, that didn’t take long.

Successful forumla:

  • expiration timer sends command -1 to the group
  • rule on command received -1

Unsuccessful:

  • Any combination using UNDEF
  • changing state to -1 (state changed, but rule did not fire)

Sometimes explaining a problem to someone else clarifies things. Decades ago a CmpSci professor said he’d make a million if he could sell big giant ears to programmers; explain the problem to the ear as if it was a person.

For anyone who may be having a similar issue with Ecobee that finds this, the rule simply disables and then reenables the Ecobee account thing:

var ecobeeAccountThing = things.getThing(ecobeeAccountThingId);

ecobeeAccountThing.setEnabled(false);
ecobeeAccountThing.setEnabled(true);
5

It’s called “rubber ducking” or “rubber duck debugging”. Keep a rubber duck on your desk and explain the problem to the duck.

1 Like
6

Thanks for the reference! Pragmatic Programmer came out about 20 years after I heard this from Chuck Forney, who was the Assistant Director of the PSU computer center in the late 70s. Now I’m up to date with the modern term.