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)

[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 😉

[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]

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

[tim-devel]

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.