The queue for a subscriber of type ‘class org.openhab.core.io.rest.sitemap.internal.WidgetsChangeListener’ exceeds 5000 elements. System may be unstable

Setup, Configuration and Use Beginners
1
  • Platform information:
    • Hardware: DELL R510, 16 GB RAM
    • OS: Ubuntu 24.04.x LTS

2026-07-03 16:23:25.861 [WARN ] [ab.core.internal.events.EventHandler] - The queue for a subscriber of type ‘class org.openhab.core.io.rest.sitemap.internal.WidgetsChangeListener’ exceeds 5000 elements. System may be unstable.
2026-07-03 16:23:25.862 [WARN ] [ab.core.internal.events.EventHandler] - The queue for a subscriber of type ‘class org.openhab.core.io.rest.sitemap.internal.WidgetsChangeListener’ exceeds 5000 elements. System may be unstable.
2026-07-03 16:23:25.862 [WARN ] [ab.core.internal.events.EventHandler] - The queue for a subscriber of type ‘class org.openhab.core.io.rest.sitemap.internal.WidgetsChangeListener’ exceeds 5000 elements. System may be unstable.

Since some last Changes I get these unstable messages.

How to configure system to get rid of them? RAM ist widely free, system runs on less 1% CPU usage most time.

Main issue is, that there are tons of logs written as there are 2-6 logfile rows per ms

2

What OH version?

3

Hi Lolodomo,

it’s Version

openHAB 5.1.4 Release Build

Meanwhile I found, that this was caused by a rule, as I track changes of Battery-Devices with “received update” to check if they went out off battery. With zwave that is needed somehow.

As I got first ZigBee devices looks like ZigBee Batterydevices have a very high frequency of updates? While uncomment the rule check received updates for my first zigbee device, this warning is gone.

The rule:

//rule “989.28_Check UG_Humidity” when Member of gTuH1 received update then UG_Vorrat_TuH_Sensor_LastValue.postUpdate(new DateTimeType()) end

So looks like my rule just not compatible with Zigbee Behavior.

4

You could just add e.g a minimum interval condition to the rule, so that the rule will never run more often than what you allow. That should allow you to keep using the rule, without filling up the queue.

5

That sounds great. Do you have a syntax or do I need to check last update?

6

That depends entirely on how you’ve made your rule. If it’s a “UI rule”, you can just add the condition in the UI, if it’s a YAML rule, I have a pending PR that documents this where you can look at the preview: YAML Rules | Documentation Preview

This is the condition I had in mind: Standard Conditions | Documentation Preview

If it’s a DSL rule, conditions are supported from 5.2.0, but I don’t think anybody has written the documentation for how to use them yet. It’s not very hard though, you add but only if between when and then, but I don’t remember the exact syntax for that condition.

If it’s some other scripting language, you must consult the documentation for the add-on to see how you use conditions.

7

As I still work with DSL rules, need to use a way with if and lastUpdate, I think. Seems like should change language for rules in the future :slight_smile:

8

There’s no need to change, you can use conditions with DSL in 5.2, the problem is just that nobody has written the documentation yet.

It’s easy enough to look up the definitions in the source code however, and it reveals:

This means that all you need to do to use this condition in OH 5.2, is to add:

when
  ..triggers..
but only if
  2000 ms between executions
then
  ..action

..to make sure that the rule never runs more often than every 2 seconds.

9

Thank you very much. I will check as soon I update to 5.2

10

I tested with Openhab 5.2, but it does not work. I did a lot of tests:

What I found out (Try to explain):

=> Syntax is o.k.

=> Rules are sometime double-fired (Trigger all 5 minutes, but runs then twice) only runs one time with this. (Thats great)

=> 2000 ms between execution prevents rule to be executed if trigger e.g. comes all 1s.

Seems like this only if 200 ms between execution is something like: if last Trigger is more than 2s ago. If trigger is every second, then the rule never will be executed.

Looks like between executions means “only if last trigger is more than 2000 ms ago”. So if trigger is every seconds: This is never to be reached.

I think there should be better two different only if:

only if xxx ms since last (or between) executions (should really listen to executions)

only if xxx ms since last (or between) trigger (what is the actual between execution-

11

This is how the code of the condition looks:

    public boolean isSatisfied(Map<String, Object> inputs) {
        long currentTime = System.nanoTime();
        if (lastAcceptedTime == null || currentTime - lastAcceptedTime >= minInterval) {
            lastAcceptedTime = currentTime;
            return true;
        }
        return false;
    }

It will only update lastAccepted if it’s currently accepted, so it shouldn’t prevent the rule from running if the interval was 2 seconds and the trigger triggered every second. But, it doesn’t “schedule a timer”, so it relies on the rule being triggered again later.

The condition is “isolated”, it doesn’t know anything about executions or other conditions. So, if you have another condition that prevents it from running, it will still update lastAccepted if it accepts that the rule can run now. But, from what I understand, you don’t have other conditions interfering.

So, from what I can see in the code, it shouldn’t work the way you describe.

12

From the Code you are right, but no idea why my experience is some other.

To remember:

I have a Zigbee device sending updates very offen and Trigger is “if Member of received update then”

All Items with a channel of the device are in this group.

The rule only only sets a current datetime in the item “LastSeenDevice”

This item receives updates all few microseconds.

With only if 2000 ms between I didn’t get any update of LastSeenDevice.

My solution is now update LastSeenDevice only if LastSeenDevice.lastUpdate() is at least 5 minutes ago.

13

I would have to do some testing myself to see how it behaves for me, but I find it strange that you see the behavior you do.

14

If I use a rule with a 1s cron and only if 5000 ms between executions, then it works like you said.

Tried just with an empty rule creates a log entry.

No idea why this not work in combination with "if Member of received update

I fully write a new short rule now and will report here.

15

No idea why: Now it works.

It may be the member had (because of new included zigbee) an unusual rhythm made me confused.

Sorry made a wrong alarm, many thanks for your support