Zigbee2mqtt: Stability issue with IKEA Tradfri

[BadEendt]

Hi everybody,

I'm trying to get zigbee2mqtt to work properly, but I'm having serious stability issues.

I'm running the zigbee2mqtt HASS.io (V1.13 and home assistant 0.86.4) add-on version 1.1.1 with a CC2531 flashed with the 2019-01-09 firmware. I got 5 Tradfri 1000lm dimmable bulbs (LED1623G12) , a Trafdri dimmer and a Tradfri outlet hooked up.

My problem is that if i try to switch multiple (like 4), zigbee2mqtt drops all connection's and stops functioning. I can fix this by restarting the add-on, re-plugging and resetting the stick, but the problem occurs multiple times a day so that is not a great fix.

I get these error's:

2019-2-5 19:40:42 - info: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe115554', payload '{"state":"OFF"}'
2019-2-5 19:40:42 - error: Zigbee publish to device '0x000b57fffeec799e', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: rsp error: 17
2019-2-5 19:40:43 - info: Zigbee publish to device '0x90fd9ffffe159fe9', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - null
2019-2-5 19:40:43 - info: Zigbee publish to device '0x000b57fffed83af6', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - null
2019-2-5 19:40:43 - error: Zigbee publish to device '0x90fd9ffffe159fe9', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: rsp error: 17
2019-2-5 19:40:43 - error: Zigbee publish to device '0x000b57fffed83af6', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: rsp error: 17
2019-2-5 19:40:48 - error: Zigbee publish to device '0xd0cf5efffe6d71a0', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.
2019-2-5 19:40:48 - error: Zigbee publish to device '0x000b57fffed83af6', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.

2019-2-5 19:41:12 - error: Zigbee publish to device '0x000b57fffe115554', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: Timed out after 30000 ms

What i tried:

• Reflashing the cc2531 (tried multiple firmware versions)
• Repairing
• Changing the Zigbee channel
• Removing the Tradfri plug from the network (i suspected it was the problem, but it wasn't)
• Running the Edge extension
• Reinstalling the add-on

I hope anyone can help me the solve this issue

Full debug code:
https://pastebin.com/Pa0rjb14

Regards,

Tijmen

[BadEendt]

Running the latest egde add on i get a few of these errors as well:
2019-2-5 21:05:36 - error: Zigbee publish to device '0xd0cf5efffe6d71a0', genLevelCtrl - read - [{"attrId":0}] - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 183. APS no ack.
https://pastebin.com/XbDVjdNE

[torbjorn2000]

I have the exact same problems since some days when I added more Ikea switches to my network. I have 10 lights and 6 switches now and these errors happen several times a day.

I get the errors with the lights and switches, randomly. Also on a led driver.

Running older firmware 20181024 but same version of home assistant and zigbee2mqtt.

[Koenkk]

Error 17 means that the buffer of the CC2531 is full, probably because the messages cannot propagate through the network, which happens probably because of the errors below.

Errors like 183 and 205 happen due to an unstable Zigbee network. I read more and more reports of TRADFRI users with these kind of problems (some even say that the range of the TRADFRI devices is bad). When you are experiencing such issues, I can recommend the following:

• Add a non TRADFRI router (a CC2530 is a very good choice, https://koenkk.github.io/zigbee2mqtt/how_tos/how_to_create_a_cc2530_router.html)
• Follow tips and tricks from: https://koenkk.github.io/zigbee2mqtt/how_tos/how_to_improve_network_range.html. Especially the USB extension cable trick could be a quick fix in both cases.

[BadEendt]

I already ordered a usb cable so i will try that as soon as it comes in.

What i don't understand is when i was using the ikea bridge i had no problems what so ever and on the network map i don't see any bad connection that isn't reachable via a router?

[Koenkk]

@BadEendt network map looks indeed good. Can you try removing the TRADFRI control outlet from the network and check if the issue persists?

[BadEendt]

I have tried that already. had it set up via bridge and removed it completely but i still had issues. but i dont know how the routing was set up back then so i could try it again if that is what you mean?

[Koenkk]

Is you tradfri bridge still running?

[BadEendt]

Nope, i removed all devices and unplugged it.

[Koenkk]

@BadEendt how often do these errors happen? always or just randomly sometimes?

[BadEendt]

Last few day's it was almost every time i tried switching multiple lights. Strange enough everything stop working altogether yesterday. Since i got it back working to day i haven't got any errors, running the edge add-on.

Only thing that i changed is one bulb isn't setup yet and removed the dimmer battery. I will try to add then back into the mix and check if i can trigger any errors

[Koenkk]

@BadEendt the latest -edge has improved queueing which should make sending multiple commands (e.g. to multiple bulbs), more reliable.

[BadEendt]

Well that seems to do the trick. I will test it for a couple of days if it keeps working correctly i will close the topic then

[BadEendt]

And i got a other error....
zigbee2mqtt:error 2019-2-6 17:32:03 Zigbee publish to device '0x000b57fffed83af6', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: rsp error: 16 zigbee2mqtt:error 2019-2-6 17:32:06 Zigbee publish to device '0x000b57fffeec799e', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: request timeout

This time it happened by real fast switching on and off, sensor was triggered at the same time as i manually turn the lights off

[Koenkk]

How many commands in what timespan? Can you post the complete log?

[BadEendt]

I think about 11 in a second or two, so it might not be a to realist scenario.

But here is the log file, it happend at 17:32:
https://pastebin.com/UietzdD1

[torbjorn2000]

Hi again, as I said I'm having the same problem and is testing at home right now. Bought an USB extension cable now and keeping the USB thingie 1m from the raspberry pie.

What I have experienced is also when sending many commands at once. I have scenarios for all lights on and off. I have Ikea bulbs, outlets and led driver, a total of 22 devices that I turn on and off at once.

One error is that I get a lot of 205, 183 and 16 errors when bursting command. When trying after a few seconds with the failed ones, it works fine.

Another error is that the devices goes completely "offline" at the burst of commands. The requests times out and it stays like that (genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: request timeout). Turning device off/on manually (cut power) does not remedy situation, but restarting zigbee2mqtt (and I had to reset USB stick as well, quite common now) made them work again.

Sending logs for the first problem (log1.log) and the second (log2.log).

I have a theory I will test: I'm always sending brightness and color temp, to all devices. Some of them complain that they cannot handle it, of course. Maybe that puts them in a state of error?

[torbjorn2000]

Another thing my network graph look like a big wheel, where everything is connected to everything. The coordinator has at least 18 devices with arrows to it. Maybe it is a problem with the limit of 15, but since almost all my devices are routers, I would think it would just connect to them instead if coordinator gets full, even if it can reach it.

(couln't get it more high res, but I zoomed in on coordinator)

[BadEendt]

sounds like we have the exact same problem. Are you running the latest edge version?
That seems to help a bit in my situation, though it isn't completely solved

[torbjorn2000]

No I'm running the stable version because of "stable"... ;)

[Koenkk]

If you want to control a lot of bulbs at the same time, I would recommend using groups: https://koenkk.github.io/zigbee2mqtt/information/groups.html. It is know that turning of so many bulbs at the same time is unreliable.

If groups is not a solution, you could try increasing this delay: https://github.com/Koenkk/zigbee2mqtt/blob/dev/lib/zigbee.js#L30 to e.g. 500 (let me know if that solves the problems).

[trekker25]

i also recommend using groups.

I have 11 GU10 tradfri and 4 bulbs split in 4 groups.

I paired the devices with the old firmware with no group support. I tried to switch a group in HA (so not a group in zigbee2mqtt) with 8 spots. Zigbee Network crashed/stopped instant with recovering after a while.

I had a bad feeling about this as i built a new kitchen with 4 fysical switches out of sight (hidden in a cupboard) and placed 4 zigbee switches. I was horrified to replace the fysical switches back on a more normal location.

But the group support changed everything, always working perfectly for about more as a week stable. Also made sure: long usb cable on CC2531. And added more HUE bulbs to create a better path.

[torbjorn2000]

Yes groups seems like a good solution. Was going there anyway just to make the lights go on and off simultaneously. But I have to reflash the stick and repair everything... :(

Will try with the delay as well!

Thanks for all help, and development of this! You are really doing a great job!

[trekker25]

Yes groups seems like a good solution. Was going there anyway just to make the lights go on and off simultaneously. But I have to reflash the stick and repair everything... :(

Will try with the delay as well!

Thanks for all help, and development of this! You are really doing a great job!

repair is not needed. Flash the new firmware with "retain address"

take your stick and PC/NUC/Pi to the attic, wrap the stick in allumium foil and boot up and make sure zigbee2mqtt starts running. This prevents that the new flashed stick get's a different address.

(maybe a network cable) so you can check the logging of zigbee2mqtt. If in the logs you see the new firmware date (2019xxxxx) you can shutdown PC/Nuc/Pi.

Place back in normal positon and unwrap foil and boot up. Now all devices will reconnect without repair.

Same can also be done removing buls/routers from power (and maybe remove battery from sensors, not sure on that), both up with new firmware and after a few minutes give back power to your bulbs/routers/sensors.

[torbjorn2000]

Yes groups seems like a good solution. Was going there anyway just to make the lights go on and off simultaneously. But I have to reflash the stick and repair everything... :(
Will try with the delay as well!
Thanks for all help, and development of this! You are really doing a great job!

repair is not needed. Flash the new firmware with "retain address"

take your stick and PC/NUC/Pi to the attic, wrap the stick in allumium foil and boot up and make sure zigbee2mqtt starts running. This prevents that the new flashed stick get's a different address.

(maybe a network cable) so you can check the logging of zigbee2mqtt. If in the logs you see the new firmware date (2019xxxxx) you can shutdown PC/Nuc/Pi.

Place back in normal positon and unwrap foil and boot up. Now all devices will reconnect without repair.

Same can also be done removing buls/routers from power (and maybe remove battery from sensors, not sure on that), both up with new firmware and after a few minutes give back power to your bulbs/routers/sensors.

Oh that's new! So if I understand correctly:

1. Flash stick normally
2. Start up zigbee2mqtt with flashed stick shielded from other Zigbee devices (with foil)
3. Verify the correct version of stick from the logs
4. Shut down and startup without the shielding

Is the crucial step that it is started up with new firmware without being able to see other Zigbee devices/networks?

And by "Flash the new firmware with retain address", you just mean the process, there is no flag when flashing?

[Bruceforce]

Your first step should be the shielding of the stick I think. After that you can flash the stick, pull it out, remove shielding, bring it back to it's original place and you are done.

Is the crucial step that it is started up with new firmware without being able to see other Zigbee devices/networks?

Yes. Since I only have 1 battery powered device I can just switch off the fuse + remove the battery, so all devices are offline. Flash the stick with a notebook and achieve the same result (as suggested above)

And by "Flash the new firmware with retain address", you just mean the process, there is no flag when flashing?

There is no extra flag. You just have to use the same panID, channel and so on in Zigbee2mqtt configuration.yaml, but that will be always the case if you don't change them with purpose.

But you should definitely try to increase the delay as mentioned above. This worked for me with fewer devices than you have (that's because it's set 170 currently). And if we can find a good value for the delay everyone could profit.

[torbjorn2000]

Good! I will try first with the delay just to see if it improves, then do the flashing. Will come back with report!

[torbjorn2000]

If groups is not a solution, you could try increasing this delay: https://github.com/Koenkk/zigbee2mqtt/blob/dev/lib/zigbee.js#L30 to e.g. 500 (let me know if that solves the problems).

I'm running zigbee2mqtt as an addon in hassio, so I don't really know where to find the zigbee.js file...

[Bruceforce]

I don't know how exactly the hassio addons work but they seem to be simple docker containers.

So you probably could

sudo docker ps

to find out the container name (probably something with "zigbee2mqtt")

then

sudo docker exec -it <NAME_OF_CONTAINER> /bin/sh/
vi /app/lib/zigbee.js
#Change the value to 500 in line 30 and save
exit
sudo docker restart <NAME_OF_CONTAINER>

[torbjorn2000]

I cannot access this from within Hassio... At least I think. I have no idea in what container I end up in when I SSH in.. Is it the underlaying OS or a Docker container? Feels like the Inception movie.. :D

Will flash the stick tomorrow!

[torbjorn2000]

A bit of an update:

• I flashed stick with latest 20190109 firmware. Tin foil didn't help, it could still control devices while wrapped in several layers. Maybe the unwrapped USB extension cord acted as antenna? Anyway, had to re-pair everything.
• After a stable 5 minutes, everything started to mess with me. Devices stopped taking commands (timeouts and missing acks etc). Had to restart+replug all the time. The 60 s "fix shephard" occured every start. After 5-6 restarts, it would no longer start up at all. Could not fix.
• I reflashed stick again. Paired only bulbs (IKEA) with stick and let the outlets be on Trådfri router. I suspected the outlets to be not super compatible.

Current status is that if I use groups to turn off/on the lights it works like a charm! But if I turn off the 10-15 bulbs one by one in a burts (from a group in HA), some lights will stop responding and a restart+replug is required. It seems that the burst of commands takes down the Zigbee network until restart.

One bulb is faulty I think, it may stop responding by random. Restart of bulb fixes that.

Conclusion: Groups are the solution to a large Ikea Trådfri network! Sending burst of commands may kill network requiring restart.

(running stable 1.1.1)

[StyxyDog]

@torbjorn2000 I have the same problem, but instead of using groups, my automatons are in Node-RED and the service calls can be rate limited- I send one per second.
In terms of repairing the Ikea bulbs, it is very time consuming to unsrew them all and take to the co-ordiantor. I have found using a second CC2531 configured as a router and powered up with a battery pack means I can re-pair without having to remove from the light fitting. I just hang the router from the lamp shade and flick the switch to reset the bulb.

[torbjorn2000]

@torbjorn2000 I have the same problem, but instead of using groups, my automatons are in Node-RED and the service calls can be rate limited- I send one per second.

Nice solution! Although it's a nice effect when all the lights turn on or off at the same time. But using groups in ZigBee, you have to have one group for every scenario you want to turn on or off.

In terms of repairing the Ikea bulbs, it is very time consuming to unsrew them all and take to the co-ordiantor. I have found using a second CC2531 configured as a router and powered up with a battery pack means I can re-pair without having to remove from the light fitting. I just hang the router from the lamp shade and flick the switch to reset the bulb.

That's for re-pairing I assume. My bulbs might end up in a state where they require restart, just by flicking the switch off and on again. But speaking of re-pairing, it often work with the bulb quite far away strangely enough.

[Bruceforce]

I have the same problem, but instead of using groups, my automatons are in Node-RED and the service calls can be rate limited- I send one per second.

If that works for you it should also work, if you increase the delay in https://github.com/Koenkk/zigbee2mqtt/blob/dev/lib/zigbee.js#L35 as mentioned above. This would also help other users if you can find a good value and open a PR, since node red is not always applicable (for example if you want to control the devices via Alexa oder Google Assistant).

[dyrkin]

I'm not sure that I'm right and understand everything correctly, but I think it is better not to increase the delay, but to change the logic in the zigbee-shepherd.

1. Add a queue for AfDataRequests
2. Process these request one by one.

How to understand that the request is completed?
Most global cluster commands have its own responses, for example ReadAttributesCommand have ReadAttributesResponse.
For most cluster local commands we can enable DefaultResponse, for example OnCommand doesn't have its own response, but device can respond with DefaultResponse when command execution is completed.

So, the strategy could be like this:

1. Take AfDataRequest from the queue.
2. Generate transaction ID and send this request.
3. Wait for AfDataConfirm with the same transaction id (it's is already implemented in the zigbee-shepherd)
4. 
   
   
   
   • For global commands with own responses. Wait for AfIncomingMessage with the same transaction id and extract command specific response
   
   
   • For local commands without responses. Wait for AfIncomingMessage with the same transaction id and extract DefaultResponse
   
   
5. Go to step one

Does this make any sense?

[Koenkk]

@dyrkin this was something that was previously implemented, but as a AfDataRequest could fail or have a delay, all commands executed after that get delayed as well. Perhaps a per device queue could be a solution?

@BadEendt could you check if this is still an issue at all? Please try with the latest dev branch and the latest dev firmware (20190218)

[BadEendt]

Alright, I will try the latest version. Is there a way to force the latest branch when running the edge extension or do I need to reinstall the plugin?

On a side note, last night the CC2531 crashed after an overload of commands (fist time in weeks), but then i had to re-flash it bring it back online instead of just re-plugging and resetting. I don't know if this issue is related though.

[Koenkk]

Reinstalling should be enough I think.

[BadEendt]

The problem still occurs. If i switch to many lights on and off a couple of times. It seems better in more "normal" use, the last couple of weeks.

https://pastebin.com/1RgAbq8k

[Koenkk]

I could indeed reproduce this by turning on 11 TRADFRI GU10 spots at the same time. This somehow causes a 'DDOS' on the network.

For future reference, I think the behaviour of the scheduler should be as follows:

• Between each Zigbee command there is a delay of 200ms
• Only one zigbee command per device can be active at a time (a command is active when zigbee2mqtt hasn't received a response/timeout for the command)
• A maximum of 3 commands are active at the same time.

We should refine the above values of 3 and 200ms to check what the real boundaries are, I guess this also differs per setup.

I will let you know when the above has been implemented.

[andreasbrett]

I have the same issue for some weeks now. Let me know if I can help you out debugging. My network consists of 18 routers, 15 of them are TRADFRI bulbs (5x E27, 10x GU10). Those GU10s are harder to re-pair so there were times where I only paired the E27s to my network and that worked completely stable. Once I added the GU10s it became unstable again. Not sure though if the GU10s are causing issues (they are smaller and have less space for electronics; also their pairing process takes longer than the E27s) or if it's just because the network grew quite a lot bigger by adding them all. Those GU10s are also part of 2 lamps so switching those lamps will send a lot of zigbee messages as I'm not yet using groups (will look into that).

[Koenkk]

Please try again with the latest dev branch and latest dev firmware (20190222) (https://github.com/Koenkk/Z-Stack-firmware/tree/dev/coordinator/CC2531/bin)

With this, I achieved the following results:

I have a setup with a zigbee network of 40+ nodes. In my test, I controlled 9 different TRADFRI GU10 bulbs. I've made a script (MQTT) which turns these bulbs on and off (= 18 commands per run). I've executed this script 20 times without a delay (resulting in a burst of 360 MQTT commands which results in 360 zigbee commands).

This ran for a few minutes, but eventually finished without a crash of the CC2531 or Zigbee2mqtt. The only errors I encountered were 205 no network route errors, but these were sporadically, the same bulb would respond to the next on/off command (no network hangups). After this all finished, I could you all bulbs as normal.

Let me know about your results.

[martinrosenauer]

@Koenkk, thanks, just flashed now and hope it'll be more stable on 20190222 firmware. Was on 20190218 which I flashed early this morning and unfortunately it stopped responding late afternoon again (https://pastebin.com/raw/QapGCYxt)

I've reset the stick and only see some 205s now which I guess is acceptable considered your message.

Is there any way we can detect a crash and have a notification from Home Assistant ?

[Koenkk]

@martinrosenauer zigbee2mqtt will report as offline (all bulbs should be unavailable in home assistant).

[martinrosenauer]

@Koenkk, ok - but in the scenario from this afternoon (https://pastebin.com/raw/QapGCYxt) it looks like some messages got through, however most of the bulbs didn't respond. (but zigbee2mqtt stayed up).

[Koenkk]

@martinrosenauer could you try with https://github.com/Koenkk/zigbee2mqtt/blob/dev/lib/util/zigbeeQueue.js#L2 increasing that to 500?

[martinrosenauer]

@Koenkk, trying - increased to 500 and restarted zigbee2mqtt on
zigbee2mqtt version 1.1.1 (commit #1fda02a)
Coordinator firmware version: '20190222'

Will let you know if it's stable :) (probably won't know until tomorrow or the day after).

[martinrosenauer]

@Koenkk, IKEA remote still works as expected, which is brilliant, however - how do I reflect the state of a light I control with it in HA ? (e.g. I turn it on by 'toggle' on the remote which is bound directly to a light - I can see the event in zigbee2mqtt but HA is obviously not aware of the change).

[martinrosenauer]

@Koenkk, sorry to bring bad news - looks like it's still not working on 20190222 / #1fda02a and with 500 in delay. If you look at https://pastebin.com/raw/rKfkRCJd the light "traadfri_bryggers_lampe" (0x0017880110570b58) became unresponsive about an hour after starting up zigbee2mqtt. The light is physically right next to the CC2531. Restarting zigbee2mqtt apparently resolves it.

[djchen]

I've been having this issue for the past 2 days on 20190218

[1905343.035202] usb 1-1: USB disconnect, device number 10
[1905354.045115] usb 1-2: new full-speed USB device number 11 using xhci_hcd
[1905354.198865] usb 1-2: New USB device found, idVendor=0451, idProduct=16a8, bcdDevice= 0.09
[1905354.198870] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1905354.198873] usb 1-2: Product: TI CC2531 USB CDC
[1905354.198876] usb 1-2: Manufacturer: Texas Instruments
[1905354.198878] usb 1-2: SerialNumber: __0X00124B0019366410
[1905354.200609] cdc_acm 1-2:1.0: ttyACM0: USB ACM device

I have pretty much all Tradfri devices (lights, control outlet, dimmer, button). Not sure if it is related though.

Edit:
Zigbee2MQTT log:

2/22/2019, 10:12:01 PM - info: Zigbee publish to device '0x000[...]a1', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null
2/22/2019, 10:12:07 PM - error: Zigbee publish to device '0x000[...]a1', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.
2/22/2019, 10:12:07 PM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.","meta":{"entity":{"ID":"0x000[...]a1","type":"device","friendlyName":"Den Lamp"},"message":"{\"state\": \"OFF\"}"}}'

[Koenkk]

How big are your networks?

[djchen]

3x Tradfri LED1622G12, 2x Tradfri Control Outlet, 1x Tradfri Dimmer, 1x Tradfri Remote, 3x Sengled E11-G13, 1x GE 45857GE

[djchen]

I downgraded to 20190109 and removed the Tradfri devices, so far no issues.
3x Sengled E11-G13, 1x GE 45857GE

Will try this out for a week and then try adding a couple Tradfri devices back in.

[Koenkk]

So I've did some more testing today. I think in the older firmwares, the cached routes back to devices are not used properly (due to being expired). I've disabled the route expiry and this seems to improve things, hopefully this doesn't cause any nasty side effects. I've also bumped the routes to remember to 40. Meaning that the CC2531 now remembers routes to 40 routers.

New firmware can be found here: https://github.com/Koenkk/Z-Stack-firmware/tree/dev/coordinator/CC2531/bin (20190223).

BEFORE bursting your network again, make sure that the CC2531 has a route to the device, otherwise you will get a lot of 205 no network route errors again. It seems that during these bursts of command, the routes cannot be determined.

To make sure the CC2531 has a route to each device, send a command (which has to succeed) to every device once (e.g. on/off).

[martinrosenauer]

@koenkk, now upgraded firmware to latest (20190223) and ran update.sh to get the last updates from the dev branch. It seems stable except I have a single Hue that is now not responding. Tried turning off it's power and back on but same result.

Pasted log on https://pastebin.com/raw/BLbqrWqc.

Anything you want me to try ? =) or any suggestions ? (delete and readd may be my next thought)

Thanks!

[Koenkk]

@martinrosenauer just re-power it

[martinrosenauer]

@koenkk, already tried, giving the same result. Will try re-pair.

[djchen]

I downgraded to 20190109 and removed the Tradfri devices, so far no issues.
3x Sengled E11-G13, 1x GE 45857GE

Been running this without issue for 3 days. Issue with TRADFRI devices or was 20190218 broken?

[Koenkk]

@djchen can you try with tradfri and 20190223?

[djchen]

I ran into an issue today where my GE 45857GE dropped out of the network for a period of time.

2/28/2019, 5:45:10 AM - info: Zigbee publish to device '0x0..76', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null
2/28/2019, 5:45:10 AM - error: Zigbee publish to device '0x0..76', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 233. MAC no ack.
2/28/2019, 5:45:10 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Error: AF data request fails, status code: 233. MAC no ack.","meta":{"entity":{"ID":"0x0..76","type":"device","friendlyName":"Kitchen Lights"},"message":"{\"state\": \"OFF\"}"}}'
2/28/2019, 5:45:10 AM - info: Zigbee publish to device '0x0..76', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null
2/28/2019, 5:45:10 AM - error: Zigbee publish to device '0x0..76', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 233. MAC no ack.
2/28/2019, 5:45:10 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Error: AF data request fails, status code: 233. MAC no ack.","meta":{"entity":{"ID":"0x0..76","type":"device","friendlyName":"Kitchen Lights"},"message":"{\"state\": \"OFF\"}"}}'
2/28/2019, 5:45:16 AM - info: Zigbee publish to device '0x0..76', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null
2/28/2019, 5:45:16 AM - error: Zigbee publish to device '0x0..76', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 233. MAC no ack.
2/28/2019, 5:45:16 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Error: AF data request fails, status code: 233. MAC no ack.","meta":{"entity":{"ID":"0x0..76","type":"device","friendlyName":"Kitchen Lights"},"message":"{\"state\": \"OFF\"}"}}'
2/28/2019, 5:45:16 AM - info: Zigbee publish to device '0x0..76', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null
2/28/2019, 5:45:16 AM - error: Zigbee publish to device '0x0..76', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 233. MAC no ack.
2/28/2019, 5:45:16 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Error: AF data request fails, status code: 233. MAC no ack.","meta":{"entity":{"ID":"0x0..76","type":"device","friendlyName":"Kitchen Lights"},"message":"{\"state\": \"OFF\"}"}}'
2/28/2019, 5:45:23 AM - info: Zigbee publish to device '0x0..76', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null
2/28/2019, 5:45:24 AM - error: Zigbee publish to device '0x0..76', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 233. MAC no ack.
2/28/2019, 5:45:24 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Error: AF data request fails, status code: 233. MAC no ack.","meta":{"entity":{"ID":"0x0..76","type":"device","friendlyName":"Kitchen Lights"},"message":"{\"state\": \"OFF\"}"}}'
2/28/2019, 5:45:36 AM - info: Zigbee publish to device '0x0..76', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null
2/28/2019, 5:45:36 AM - error: Zigbee publish to device '0x0..76', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 233. MAC no ack.
2/28/2019, 5:45:36 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Error: AF data request fails, status code: 233. MAC no ack.","meta":{"entity":{"ID":"0x0..76","type":"device","friendlyName":"Kitchen Lights"},"message":"{\"state\": \"OFF\"}"}}'
2/28/2019, 5:47:14 AM - info: MQTT publish: topic 'zigbee2mqtt/Kitchen Lights', payload '{"state":"OFF","linkquality":21}'
2/28/2019, 6:03:56 AM - info: MQTT publish: topic 'zigbee2mqtt/Kitchen Lights', payload '{"state":"OFF","linkquality":10}'
2/28/2019, 6:20:37 AM - info: MQTT publish: topic 'zigbee2mqtt/Kitchen Lights', payload '{"state":"OFF","linkquality":0}'
2/28/2019, 6:37:18 AM - info: MQTT publish: topic 'zigbee2mqtt/Kitchen Lights', payload '{"state":"OFF","linkquality":2}'
2/28/2019, 6:53:58 AM - info: MQTT publish: topic 'zigbee2mqtt/Kitchen Lights', payload '{"state":"OFF","linkquality":26}'
2/28/2019, 7:10:39 AM - info: MQTT publish: topic 'zigbee2mqtt/Kitchen Lights', payload '{"state":"OFF","linkquality":23}'
2/28/2019, 7:27:20 AM - info: MQTT publish: topic 'zigbee2mqtt/Kitchen Lights', payload '{"state":"OFF","linkquality":21}'
2/28/2019, 7:41:31 AM - info: MQTT publish: topic 'zigbee2mqtt/Kitchen Lights', payload '{"state":"ON","linkquality":31}'
2/28/2019, 7:42:32 AM - info: MQTT publish: topic 'zigbee2mqtt/Kitchen Lights', payload '{"state":"OFF","linkquality":5}'

Maybe interference caused it to lose connection with the coordinator?
I'll try to pair a IKEA Tradfri Control Outlet in between to boost the signal.

What is also weird is the linkquality was consistently 45+ before and is much lower now. I don't have any other router devices on the network. The Sengled's are all end devices.

[BadEendt]

Hi, I'm using 20190223 now for a couple of days and it seems stable. No need for resetting and replugging.
What i am noticing is when i issue multiple commands the response seems a bit slower and my Gledopto bulb sometimes causes error's but it will start working again after a minute or so.

3/1/2019, 10:47:26 AM - info: Zigbee publish to device '0x00124b001b503afa', genLevelCtrl - moveToLevelWithOnOff - {"level":127,"transtime":0} - {"manufSpec":0,"disDefaultRsp":0} - 11
3/1/2019, 10:47:27 AM - info: MQTT publish: topic 'zigbee2mqtt/0x00124b001b503afa', payload '{"state":"ON","color_temp":370,"color":{"x":0.323,"y":0.329},"brightness":80}'
3/1/2019, 10:47:27 AM - info: Zigbee publish to device '0x00124b001b503afa', lightingColorCtrl - moveToColorTemp - {"colortemp":370,"transtime":0} - {"manufSpec":0,"disDefaultRsp":0} - 11
3/1/2019, 10:47:27 AM - error: Zigbee publish to device '0x00124b001b503afa', lightingColorCtrl - moveToColorTemp - {"colortemp":370,"transtime":0} - {"manufSpec":0,"disDefaultRsp":0} - 11 failed with error Error: AF data request fails, status code: 233. MAC no ack.
3/1/2019, 10:47:27 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Error: AF data request fails, status code: 233. MAC no ack.","meta":{"entity":{"ID":"0x00124b001b503afa","type":"device","friendlyName":"0x00124b001b503afa"},"message":"{\"state\": \"ON\", \"brightness\": 127, \"color_temp\": 370}"}}'
3/1/2019, 10:47:27 AM - info: Zigbee publish to device '0x00124b001b503afa', genLevelCtrl - read - [{"attrId":0}] - {"manufSpec":0,"disDefaultRsp":0} - 11

Full log:
https://pastebin.com/LT7Q6GNk

[DeliriousMetro]

I am now having issues since updating the co-ordinator to firmware 20190223 from a release in January (logs deleted so can't tell which revision).

Phillips Hue bulbs connect to the stick and show the correct states, but changing the brightness or toggling the switch causes the issues mentioned here:

3/11/2019, 10:29:31 AM - debug: Received MQTT message on 'zigbee2mqtt/Phillips Hue (Hallway)/set' with data '{"state": "OFF"}'

3/11/2019, 10:29:31 AM - error: Zigbee publish to device '0x00178801102985d2', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.

3/11/2019, 10:29:31 AM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Error: AF data request fails, status code: 205. No network route. Please confirm that the device has (re)joined the network.","meta":{"entity":{"ID":"0x00178801102985d2","type":"device","friendlyName":"Phillips Hue (Stairs)"},"message":"{\"state\": \"OFF\"}"}}'

All other devices (Xiaomi door sensors, temperature sensors and motion sensors appear to be working fine).

[Koenkk]

@DeliriousMetro please try to re-pair the problematic device.

[DeliriousMetro]

@DeliriousMetro please try to re-pair the problematic device.

Sorted. Thanks :wink:

[djchen]

I've been running 20190223 with the dev branch and the following devices: 2x Tradfri Control Outlet, 3x Sengled E11-G13, 1x GE 45857GE. Pretty much no issues for almost 2 weeks.

Next up, will need to test if the Tradfri Bulbs (LED1622G12) cause problems.

[BadEendt]

Same here! Running 20190223 with the stable branch (v 1.2.1) and i have not experienced any stability issues lately.

@djchen, I almost exclusively use the E27 variant of those bulbs (LED1623G12), so i think it should go without any problems.

[PuckStar]

I'm on the latest versions but my 1 tradfri light isn't turning off lately. It worked fine yesterday (when I added it + the tradfri motion sensor to zigbee2mqtt), but today I get errors like this all the time:

3/22/2019, 11:18:59 PM - info: Zigbee publish to device '0x000b57fffe381c00', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null
3/22/2019, 11:18:59 PM - error: Zigbee publish to device '0x000b57fffe381c00', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 233. MAC no ack.
3/22/2019, 11:18:59 PM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Error: AF data request fails, status code: 233. MAC no ack.","meta":{"entity":{"ID":"0x000b57fffe381c00","type":"device","friendlyName":"WC Light"},"message":"{\"state\": \"OFF\"}"}}'

Strangely the tradfri motion sensor seems to work fine and it's like 30cm next to the bulb.
Also aqara motion sensor about 50cm next to it works fine.
Also a hue motion sensor upstairs works fine.

Can it be because the bulb tries to link to a router instead instead of the coordinator (to which is really close to)?
Or that the coordinator choses to go via the router instead of directly?
this is the part of my map where you see the bulb etc.

[djchen]

Same here! Running 20190223 with the stable branch (v 1.2.1) and i have not experienced any stability issues lately.

@djchen, I almost exclusively use the E27 variant of those bulbs (LED1623G12), so i think it should go without any problems.

+1
I've been running with the 3x Tradfri bulbs added without any issues. I even added several other new devices (GE 45853GE, Xiaomi MCCGQ01LM, Xiaomi DJT11LM) for a total of 11 devices. I'm using the smart outlets spaced out evenly to get better connection with all the devices.

[djchen]

Can it be because the bulb tries to link to a router instead instead of the coordinator (to which is really close to)?
Or that the coordinator choses to go via the router instead of directly?
this is the part of my map where you see the bulb etc.

Your WC Light bulb has nearly no signal (linkquality) to the coordinator and other devices.
How far is the coordinator from the WC Light? Can you add a powered router to increase the range?
(I recommend the Tradfri control outlets, it works better than the CC253x based router. Even now, your CC2350 router doesn't have that great of a connection to the coordinator.)

[PuckStar]

Can it be because the bulb tries to link to a router instead instead of the coordinator (to which is really close to)?
Or that the coordinator choses to go via the router instead of directly?
this is the part of my map where you see the bulb etc.

Your WC Light bulb has nearly no signal (linkquality) to the coordinator and other devices.
How far is the coordinator from the WC Light? Can you add a powered router to increase the range?
(I recommend the Tradfri control outlets, it works better than the CC253x based router. Even now, your CC2350 router doesn't have that great of a connection to the coordinator.)

I think the previous map was when the whole network was not yet finished meshing. This is the network now:

What I find strange is that WC Motion, WC Light and WC Deur are all in very same toilet room and in the past when I had WC Light and Motion linked to Tradfri Hub I NEVER had issues with the light not turning on or off.
The tradfri hub was in the same closet as the zigbee2mqtt stick and I actually powered off the tradfri hub to prevent interference.

It's nice to see the WC Light also finds the router (which is much farther away than the coordinator but why then does it often not work well? Even with 2 routes.

To me it just seems like Zigbee2mqtt doesn't work well with a Tradfri Light.
Again, I had zero issues when it was linked to a Tradfri hub but now the light stays on very often.

These are the messages I still get:

3/29/2019, 7:14:53 PM - info: Zigbee publish to device '0x000b57fffe381c00', genLevelCtrl - moveToLevelWithOnOff - {"level":10,"transtime":0} - {"manufSpec":0,"disDefaultRsp":0} - null
3/29/2019, 7:14:53 PM - error: Zigbee publish to device '0x000b57fffe381c00', genLevelCtrl - moveToLevelWithOnOff - {"level":10,"transtime":0} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 233. MAC no ack.
3/29/2019, 7:14:53 PM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Error: AF data request fails, status code: 233. MAC no ack.","meta":{"entity":{"ID":"0x000b57fffe381c00","type":"device","friendlyName":"WC Light"},"message":"{\"state\": \"ON\", \"brightness\": 10}"}}'
3/29/2019, 7:14:53 PM - info: Zigbee publish to device '0x000b57fffe381c00', genLevelCtrl - read - [{"attrId":0}] - {"manufSpec":0,"disDefaultRsp":0} - null
3/29/2019, 7:14:53 PM - error: Zigbee publish to device '0x000b57fffe381c00', genLevelCtrl - read - [{"attrId":0}] - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 233. MAC no ack.
3/29/2019, 7:14:54 PM - info: MQTT publish: topic 'zigbee2mqtt/WC Motion Sensor', payload '{"occupancy":true,"linkquality":10,"battery":34}'
3/29/2019, 7:14:54 PM - info: MQTT publish: topic 'zigbee2mqtt/WC Motion Sensor', payload '{"occupancy":true,"linkquality":5,"battery":34}'
3/29/2019, 7:14:54 PM - info: Zigbee publish to device '0x000b57fffe381c00', genLevelCtrl - moveToLevelWithOnOff - {"level":10,"transtime":0} - {"manufSpec":0,"disDefaultRsp":0} - null
3/29/2019, 7:14:54 PM - error: Zigbee publish to device '0x000b57fffe381c00', genLevelCtrl - moveToLevelWithOnOff - {"level":10,"transtime":0} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 233. MAC no ack.
3/29/2019, 7:14:54 PM - info: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"zigbee_publish_error","message":"Error: AF data request fails, status code: 233. MAC no ack.","meta":{"entity":{"ID":"0x000b57fffe381c00","type":"device","friendlyName":"WC Light"},"message":"{\"state\": \"ON\", \"brightness\": 10}"}}'
3/29/2019, 7:14:54 PM - info: Zigbee publish to device '0x000b57fffe381c00', genLevelCtrl - read - [{"attrId":0}] - {"manufSpec":0,"disDefaultRsp":0} - null
3/29/2019, 7:14:54 PM - error: Zigbee publish to device '0x000b57fffe381c00', genLevelCtrl - read - [{"attrId":0}] - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: AF data request fails, status code: 233. MAC no ack.

I'm inclined to move the Light and Motion back to Tradfri but would be sad about it because I wanted to get rid of as many of zigbee hubs.

Anyone any other idea's left?

[djchen]

To me it just seems like Zigbee2mqtt doesn't work well with a Tradfri Light.
Again, I had zero issues when it was linked to a Tradfri hub but now the light stays on very often.

Are you running the latest firmware (20190223) on your stick? and the latest zigbee2mqtt?

I have a bunch of Tradfri devices (including 4x Tradfri LED1622G12 lights) and I can tell you the CC25x stick doesn't have anywhere near as much range as the Tradfri hub. You definitely have to compensate for that by adding additional routers in between. The easy choice for me was to add a couple Tradfri control outlets in between. I have 1 control outlet about 2 ft from the coordinator and another about 15 ft away.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bartplessers]

Seems I have this same issue:
My IKEA Tradfri light turns on/off randomly.

In logs, I see (0xd0cf5efffe0bb71a is the device ID of the light)

9/29/2019, 5:35:19 PM - info: Zigbee publish to device '0xd0cf5efffe0bb71a', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - 1
9/29/2019, 5:35:19 PM - info: MQTT publish: topic 'zigbee2mqtt/0xd0cf5efffe0bb71a', payload '{"state":"OFF","linkquality":39,"brightness":255,"color_temp":500,"color_mode":2,"color":{"x":0.4599,"y":0.4106}}'
(...)
9/29/2019, 6:27:05 PM - info: Zigbee publish to device '0xd0cf5efffe0bb71a', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - 1
9/29/2019, 6:27:05 PM - info: MQTT publish: topic 'zigbee2mqtt/0xd0cf5efffe0bb71a', payload '{"state":"ON","linkquality":39,"brightness":255,"color_temp":500,"color_mode":2,"color":{"x":0.4599,"y":0.4106}}'
(...)
9/29/2019, 7:15:38 PM - info: Zigbee publish to device '0xd0cf5efffe0bb71a', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - 1
9/29/2019, 7:15:39 PM - info: MQTT publish: topic 'zigbee2mqtt/0xd0cf5efffe0bb71a', payload '{"state":"OFF","linkquality":39,"brightness":255,"color_temp":500,"color_mode":2,"color":{"x":0.4599,"y":0.4106}}'
(...)
9/29/2019, 8:06:16 PM - info: Zigbee publish to device '0xd0cf5efffe0bb71a', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - 1
9/29/2019, 8:06:17 PM - info: MQTT publish: topic 'zigbee2mqtt/0xd0cf5efffe0bb71a', payload '{"state":"ON","linkquality":39,"brightness":255,"color_temp":500,"color_mode":2,"color":{"x":0.4599,"y":0.4106}}'
(...)
9/29/2019, 8:55:17 PM - info: Zigbee publish to device '0xd0cf5efffe0bb71a', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - 1
9/29/2019, 8:55:18 PM - info: MQTT publish: topic 'zigbee2mqtt/0xd0cf5efffe0bb71a', payload '{"state":"OFF","linkquality":39,"brightness":255,"color_temp":500,"color_mode":2,"color":{"x":0.4599,"y":0.4106}}'

and this triggers the light to go on/off.

I'm running

• Zigbee2mqtt on bare-metal RPI3
• CC2531_USB-stick (using an USB extension cable)
• latest version: CC2531_DEFAULT_20190608.zip

Is there anything I can do to get this more stable?

Here is an overview of my network

and more specific

Any help is appreciated!

[Koenkk]

@bartplessers

For the random turn on/off can you provide the logging when the bulb turns on/off when running with debug logging enabeld

To enable debug logging set in configuration.yaml:

advanced:
  log_level: debug

[bartplessers]

OK, I will check my logs.
Currently, it seems more ore less stable since yesterday evening...
But as you can see, I had a kind of a flashing light last days.:

keep you informed!
Bart

[bartplessers]

Here is already something weird:

• light: 0xd0cf5efffe0bb71a
• light is turned off (see last lines in log-1.txt)
• restart zigbee2mqtt
• light is automatically turned on after restart zigbee2mqtt (see log-2.txt)

is this normal behaviour?
I would expect that state of bulb will be the same, and starting zigbee2mqtt does not change the state.

log-1.txt
log-2.txt

[timstanley1985]

One for you to check - this happened to me a few months ago and I pulled out my hair trying to work out why my lights turned on every time I restarted zigbee2mqtt. It turned out i had a retained mqtt message on my mqtt server that was getting picked up by zigbee2mqtt at startup and switching on the light

[Koenkk]

@bartplessers it seems that they are indeed retained MQTT messages (like @timstanley1985 mentions). In the log you see that these are received and applied just after zigbee2mqtt starts.

[bartplessers]

@Koenkk, @timstanley1985

problem happened again at 4:31 PM, see line 3366 in attached debug log

log.txt

I will now clean my mqtt-broker database to remove all persistent messages:

sudo systemctl stop zigbee2mqtt

sudo systemctl stop mosquitto.service
sudo rm /var/lib/mosquitto/mosquitto.db
sudo systemctl start mosquitto.service

sudo systemctl start zigbee2mqtt

and see what happens

Grtz

[bartplessers]

hmmm.
First test: after cleaning up all messages from mosquitto.db, and restarting zigbee2mqtt, my IKEA bulb goes ON again...

Is there something else I can do?

log after reboot attached
log.txt

[Koenkk]

@bartplessers perhaps you do have a home assistant automation or e.g. node red setup sending this message? You need to figure out where it comes from..

[bartplessers]

Hi @Koenkk ,
I have several instances of hass and node-red running, but none of them are having automations like "turn on bulb if zigbee2mqtt comes online"
You can also see in the log above that immediately after rebooting zigbee2mqtt, there is a ON message (9:46:25 PM). It's not a "proof", but timestamp suggest that zigbee2mqtt itselfs produces the message...

I will let it run a day now.
If problem still persists, I will turn down all my domotica services (4 x hass, 3x domoticz, 3x openhab, 3x node-red)... :-)

grtz & thanx for help and following up!
B

[bartplessers]

Unfortunatly,
Here we go again:

log.txt

(see line nr 5592-5594)

No buttons pressed, no automations...
BUT...

• around that time, I pressed a 433Mhz remote to turn on a light
• I was walking in the same room. NO motion sensor or automation, but can it be that this disturbs zigbee2mqtt. C2531 stick and bulb are approximately 3m from each other

Any possibility that this causes interference?
Anyway, this will not explain the earlier posted screenshot of my "flashbulb" where light turns on/off during whole night (unless I have a mouse in the house :-) )

any advice appreciated!

[bartplessers]

AHAAAAAAA,....
In the above log, I see also, just befor my bulb turns on:

This device is a IKEA TRADFRI Dimmer, and YES...there was an automation here:

- id: '0x000b57fffe73012f_brightness'
  alias: (R03) Dimmer Woonkamer
  trigger:
    platform: state
    entity_id: sensor.0x000b57fffe73012f_brightness
  condition: []
  action:
    service: light.turn_on
    entity_id: light.0xd0cf5efffe0bb71a_light
    data_template:
      brightness: >
        {{ state_attr('sensor.0x000b57fffe73012f_brightness','brightness')|int }}
      transition: 1

So I think this is what happened:

• the IKEA TRADFRI Dimmer is very, very, very sensitive
• I' living in an old house with wooden floors
• vibrations of walking around triggered zigbee-messages from dimmer
• automation triggered light.turn_on

Could this be the case?

Any suggestion for better automation for the dimmer?

kind regards,
Bart

[andreasbrett]

Yeah those trådfri dimmers are very sensitive. If you take them out of their base and put them back nearly every time it will trigger something during that motion. I mostly use them stationary as otherwise they are simply a pain. I think it's very possible that they get triggered by minor vibrations due to your wooden floors.