# Rule not triggering on change to UNDEF via expiration **URL:** \ **Category:** Runtime\ **Tags:** openhab3\ **Created:** [June 20, 2025, 1:52am UTC](https://community.openhab.org/t/rule-not-triggering-on-change-to-undef-via-expiration/164602 "2025-06-20T01:52:24Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![tcgerhard](https://community.openhab.org/letter_avatar_proxy/v4/letter/t/e79b87/32.png) [@tcgerhard](https://community.openhab.org/u/tcgerhard)\ **Post date:** [June 20, 2025, 1:52am UTC](https://community.openhab.org/t/rule-not-triggering-on-change-to-undef-via-expiration/164602/1 "2025-06-20T01:52:24Z")
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. ```auto value: 0h2m0s config: {} ``` My rule is set to trigger on the group item changing to UNDEF, but never seems to fire. ```auto 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): ```auto 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: - ```auto 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 ---
**Author:** ![rlkoshak](https://community.openhab.org/user_avatar/community.openhab.org/rlkoshak/32/75251_2.png) [@rlkoshak](https://community.openhab.org/u/rlkoshak)\ **Post date:** [June 20, 2025, 2:02pm UTC](https://community.openhab.org/t/rule-not-triggering-on-change-to-undef-via-expiration/164602/2 "2025-06-20T14:02:03Z")
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: - [Open Reminder [3.3.0;3.4.9)](https://community.openhab.org/t/open-reminder-3-3-0-3-4-9/138199) or [Threshold Alert [3.2.0;3.4.9)](https://community.openhab.org/t/threshold-alert-3-2-0-3-4-9/128258) - link all of the channels to one status Item and put the expire on that status Item - crate a status Item that gets updated when the members of the Group update and set the expire on that Item - implement a [Design Pattern: Motion Sensor Timer](https://community.openhab.org/t/design-pattern-motion-sensor-timer/14954) > [@tcgerhard](#): > > Update: I’ve changed the expiration timer from “update state” to “send command”. Will monitor overnight with the short timeout. I’m pretty sure you cannot send UNDEF and NULL as a command, only an update. ---
**Author:** ![tcgerhard](https://community.openhab.org/letter_avatar_proxy/v4/letter/t/e79b87/32.png) [@tcgerhard](https://community.openhab.org/u/tcgerhard)\ **Post date:** [June 20, 2025, 5:43pm UTC](https://community.openhab.org/t/rule-not-triggering-on-change-to-undef-via-expiration/164602/3 "2025-06-20T17:43:30Z")
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. ---
**Author:** ![tcgerhard](https://community.openhab.org/letter_avatar_proxy/v4/letter/t/e79b87/32.png) [@tcgerhard](https://community.openhab.org/u/tcgerhard)\ **Post date:** [June 20, 2025, 6:23pm UTC](https://community.openhab.org/t/rule-not-triggering-on-change-to-undef-via-expiration/164602/4 "2025-06-20T18:23:46Z")
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: ```auto var ecobeeAccountThing = things.getThing(ecobeeAccountThingId); ecobeeAccountThing.setEnabled(false); ecobeeAccountThing.setEnabled(true); ``` ---
**Author:** ![rlkoshak](https://community.openhab.org/user_avatar/community.openhab.org/rlkoshak/32/75251_2.png) [@rlkoshak](https://community.openhab.org/u/rlkoshak)\ **Post date:** [June 20, 2025, 6:31pm UTC](https://community.openhab.org/t/rule-not-triggering-on-change-to-undef-via-expiration/164602/5 "2025-06-20T18:31:38Z")
> [@tcgerhard](#): > > 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. It’s called “rubber ducking” or “rubber duck debugging”. Keep a rubber duck on your desk and explain the problem to the duck. > **[Rubber duck debugging](https://en.wikipedia.org/wiki/Rubber_duck_debugging)** > > Rubber duck debugging (or rubberducking) is a debugging technique in software engineering, wherein a programmer explains their code, step by step, in natural language—either aloud or in writing—to reveal mistakes and misunderstandings. > The name is a reference to a story in the book The Pragmatic Programmer. It tells a story of a developer who carried a rubber duck and explained their code to it line by line. Variations of the practice use other objects or even pets; teddy bears are especially ... ---
**Author:** ![tcgerhard](https://community.openhab.org/letter_avatar_proxy/v4/letter/t/e79b87/32.png) [@tcgerhard](https://community.openhab.org/u/tcgerhard)\ **Post date:** [June 21, 2025, 11:21pm UTC](https://community.openhab.org/t/rule-not-triggering-on-change-to-undef-via-expiration/164602/6 "2025-06-21T23:21:18Z")
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.