First Matter Device - Items are flapping once after sending a command

Setup, Configuration and Use Items & Sitemaps
1

I recently installed my first Matter Device, a AIDot LightBulb (Matter over Wifi).

.things:

Bridge matter:controller:home "Matter Controller" [    
]

Thing matter:node:home:12674515890592221448 (matter:controller:home) [nodeId="12674515890592221448"]

.items:

Switch AIDOT_BULB_COUCH_Switch "Couchlampe Schalter" <light> (gWohnzimmerLight_Couch, gsWohnzimmer) ["Switch", "Light"]
    { channel="matter:node:home:12674515890592221448:1#colorcontrol-color" }

Dimmer AIDOT_BULB_COUCH_Brightness "Couchlampe Helligkeit [%d %%]" <dimmablelight> (gWohnzimmerLight_Couch, gsWohnzimmer) ["Control", "Light"]
    { channel="matter:node:home:12674515890592221448:1#colorcontrol-color" }

Color AIDOT_BULB_COUCH_Color "Couchlampe Farbe" <colorlight> (gWohnzimmerLight_Couch, gsWohnzimmer) ["Control", "Color"]
    { channel="matter:node:home:12674515890592221448:1#colorcontrol-color" }

Dimmer AIDOT_BULB_COUCH_ColorTemp "Couchlampe Farbtemperatur [%d %%]" <colorwheel> (gWohnzimmerLight_Couch, gsWohnzimmer) ["Control", "ColorTemperature"]
    { channel="matter:node:home:12674515890592221448:1#colorcontrol-temperature" }

There are no more rules yet on this Lightbulb that could interfere.

E.g. when I now change the On/Off Switch from On to Off, it quickly jumps back to “On” and short time later (ca. 1 second) it goes to “Off”.

Same with brightness, e.g. when changing from 10% to 80% via the slider, it jumps back to 10%, and short time later to 80.

It’s only the Items, no flickering on the device itself.

Something that seems to be strange (I manged to set it up with Gemini’s help) is, that these Bulbs don’t expose channels for brightness etc., only for the colorcontrol. According to Gemini’s suggestion I just linked all the Items (On/Off, Brightness, etc.) to the colorcontrol channel.

When integrating the items to the rest of the Logic, this flickering unfortunately interferes with some rules.

Do you have an idea how this flapping happens and how I could get rid of the behaviour?

2

It sounds like autoupdate. Look in events.log. You will likely see your command, then a prediction from autoupdate followed by an update to the Item, and then you see a third update to the Item. Pay attention to the source at the end of the line in the logs in events.log.

The first update likely comes from autoupdate and the second one from the binding. Though it could be the opposite if there’s something weird going on.

You can turn off autoupdate by adding autoupdate=false between the { } or through metadata in the UI.

If this is the source of the extra events, it should eliminate one of those updates.

3

I don’t see the autoupdate as source.

following the events.log when switching the switch from ON to OFF:

2026-08-24 21:13:30.854 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'AIDOT_BULB_COUCH_Switch' received command OFF (source: org.openhab.ui.basic$default:gWohnzimmerLight_Couch=>org.openhab.android=>org.openhab.core.io.rest)
2026-08-24 21:13:32.031 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'AIDOT_BULB_COUCH_Switch' changed from ON to OFF (source: org.openhab.core.thing$matter:node:home:12674515890592221448:1#colorcontrol-color)
2026-08-24 21:13:32.033 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'AIDOT_BULB_COUCH_Brightness' changed from 40 to 0 (source: org.openhab.core.thing$matter:node:home:12674515890592221448:1#colorcontrol-color)
2026-08-24 21:13:32.034 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'AIDOT_BULB_COUCH_Color' changed from 40.197,41.80800,40 to 40.197,41.80800,0 (source: org.openhab.core.thing$matter:node:home:12674515890592221448:1#colorcontrol-color)

The actual flapping seems to be not even shown in the events.log, yet I see 1,2 seconds delay, between “…received command OFF” and “…changed from ON to OFF”.

4

Then where are you seeing the flapping, the UI? Note that the UI will show the toggle to show that you’ve clicked on it, but given the delay in the device responding or what ever else is causing the delay, it might be that the Item is updating between the command and the change (updates are not shown in events.log by default). If an update is happening in that two second delay, the UI would update the UI based on that update. Is that what you mean by flapping?

events.log contains the actual events that make it on to the event bus. This log file is going to be the ground truth as to what is happening inside openHAB.

The two second delay seems like a lot but if this is your only Matter device and it doesn’t have a good connection with your router or otherwise it has issues maybe that could account for the delay. An expert in Matter and the OH binding would be needed to diagnose that.

Autoupdate is indeed off here though.

The events I see are the events I would expect given you have the same light linked to three different Items. (Note, you can send ON/OFF and PercentType commands to a Color Item so there is rarely a need to create separate Items for the Switch and the Dimmer. The Color Item is a Switch and a Dimmer and can be treated as such by itself.

But I see the command, then, even with the unexpected delay, we see the Switch, Dimmer and Color Item changing state in response to the command.

5

Yes, I think that’s what I mean by flapping. It’s flapping in the UI (BasicUI).

Might there be a chance to enable logging of updates in events.log (or openhab.log) as well? Would it help for debugging at all?

Connection should be good, it’s located just 2.5 meters away from the wifi repeater.

6

Setting openhab.events.ItemStateUpdatedEvent logger to INFO will show the Item updates to events.log.

I can’t really help diagnose the delay itself. It’s happening between when the binding gets the ON command and the binding reports back the new state of the device. Debug or trace level logs from the Matter binding may help but I can’t really pinpoint anything that specific. I barely use Matter so far.

I also don’t use sitemaps. It may be that the sitemap waits a bit for the Item to update it’s state and if it doesn’t it returns to the old state. I could see that happening. So it might be a different overall reason but the same root cause: two seconds is too long of a delay.

7

That’s relly strange. I now have the update in the logs (btw. thanks - I wished for these logs for long), but they also don’t reflect the flaps of the switch in the UI :frowning:

2026-08-24 21:58:34.671 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'AIDOT_BULB_COUCH_Switch' received command OFF (source: org.openhab.ui.basic$default:gWohnzimmerLight_Couch=>org.openhab.android=>org.openhab.core.io.rest)
2026-08-24 21:58:35.927 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'AIDOT_BULB_COUCH_Switch' updated to OFF
2026-08-24 21:58:35.929 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'AIDOT_BULB_COUCH_Switch' changed from ON to OFF (source: org.openhab.core.thing$matter:node:home:12674515890592221448:1#colorcontrol-color)
2026-08-24 21:58:35.933 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'AIDOT_BULB_COUCH_Brightness' updated to 0
2026-08-24 21:58:35.934 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'AIDOT_BULB_COUCH_Brightness' changed from 40 to 0 (source: org.openhab.core.thing$matter:node:home:12674515890592221448:1#colorcontrol-color)
2026-08-24 21:58:35.941 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'AIDOT_BULB_COUCH_Color' updated to 40.197,41.80800,0
2026-08-24 21:58:35.942 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'AIDOT_BULB_COUCH_Color' changed from 40.197,41.80800,40 to 40.197,41.80800,0 (source: org.openhab.core.thing$matter:node:home:12674515890592221448:1#colorcontrol-color)

Shouldn’t at least the UI updates (ON → OFF → ON → OFF) be visible each as a a Update log in events.log?

8

Only if those events are actually occuring.

Again, I don’t use sitemaps but I suspect what’s happening is you click the toggle on the sitemap. The sitemap shows you’ve clicked on it by toggling it. The command goes out to the device. The sitemap notices that the Item hasn’t acutally updated to the new state after a time and toggles the UI element back. After two seconds the device responds, the Item updates and the sitemap changes the UI element.

There is no intermediate event at all. It’s just a timer in the sitemap.

What you see in events.log are the actual events that occurred on the Item. If you see stuff happing in the UI that do not correspond to those, it’s the UI doing visual stuff on it’s own.

But again, the root cause is that the binding or device is taking too long to respond.

Turning on autoupdate may actually help in this case. With autoupdate being true, the Item will receive an update based on the predicted new state (you’ll see that in events.log as the prediction is an event in and of itself. That will make the UI happy since the Item immediately changes to the new state in response to the command. However, it will mask that two second delay which is the root cause of all the problems.