search

Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
12.21k stars 1.68k forks source link

lights problem #24293

Open ankokdog opened 1 month ago

ankokdog commented 1 month ago

What happened?

All of my lights have strange behavior or do not respond only after a restart works for a while and the same behavior happen again, also they go offline. I have about 90 devices most of them routers. My old coordinator was a sonoff zb3 plus and replaced by a zigstar uzg-1 and flashed to the latest updates and firmware. also i have two sonoff zb3 plus flashed as routers. nothing changed. the same problems. restart home assistant restart z2m i have trayed everything. i set up another zha and pair the lights there with another coordinator and they work just fine. I use channel 25 and my wifi is at 11 channel. for about two years i had no problems and the last month i cant make it work. i have a filling that the problem is the availability option in z2m because when is enabled i have hundred of ping errors.

What did you expect to happen?

solve the issue with an update

How to reproduce it (minimal and precise)

Screenshot 2024-10-11 175228

Zigbee2MQTT version

1.40.2

Adapter firmware version

20240710

Adapter

zigstar usg-1

Setup

pc with i5 8th gen 16gb ram and m2 ssd 512gb

Debug log

No response

zyankali333 commented 1 month ago

Got the same Problem since like an Week, Door Sensors, Remotes and Plugs still work but the lights not. Happens like every 24 Hours. Also on this Version 1.40.2 in Home Assistent on an Raspi 4, SLZB-06p7 Coordinator.

ankokdog commented 1 month ago

Got the same Problem since like an Week, Door Sensors, Remotes and Plugs still work but the lights not. Happens like every 24 Hours. Also on this Version 1.40.2 in Home Assistent on an Raspi 4, SLZB-06p7 Coordinator.

i also have SLZB-06p7 and set it as coordinator for zha. Remove some of the lights (8 tuya e14) from z2m and pair them to zha and work fine.

purche42 commented 1 month ago

Similar issue here. All devices are online. Anythings looks fine also in HA, I get status from sensors, lights switches. But I cannot turn on / off any devices. This starts with 1.40.2. I'm usng the docker image image: koenkk/zigbee2mqtt:latest -> (1.40.2) Updateing coordinator (type zStack3x0 )to version 20240710 does not solve the problem.

Restarting Z2M solve problem temporarly. With next restart I have the same problem again. I switched back to 1.40.1 . This seems to be the last working version for me.

ankokdog commented 1 month ago

The last stable for me was 1.39.... but i do not have backup of it.

On Mon, Oct 14, 2024, 09:46 purche42 @.***> wrote:

Similar issue here. All devices are online. Anythings looks fine also in HA, I get status from sensors, lights switches. But I cannot turn on / off any devices. This starts with 1.40.2. I'm usng the docker image image: koenkk/zigbee2mqtt:latest -> (1.40.2) Updateing coordinator (type zStack3x0 )to version 20240710 does not solve the problem.

Restarting Z2M solve problem temporarly. With next restart I have the same problem again. I switched back to 1.40.1 . This seems to be the last working version for me.

— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/24293#issuecomment-2410175480, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ4DLE2ADJTTKQCP26DYQQTZ3NSDRAVCNFSM6AAAAABPZC23PKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJQGE3TKNBYGA . You are receiving this because you authored the thread.Message ID: @.***>

jerkovicl commented 1 month ago

Similar issue here. All devices are online. Anythings looks fine also in HA, I get status from sensors, lights switches. But I cannot turn on / off any devices. This starts with 1.40.2. I'm usng the docker image image: koenkk/zigbee2mqtt:latest -> (1.40.2) Updateing coordinator (type zStack3x0 )to version 20240710 does not solve the problem.

Restarting Z2M solve problem temporarly. With next restart I have the same problem again. I switched back to 1.40.1 . This seems to be the last working version for me.

Same thing for me, it stopped working with latest version 1.40.2. Restarting z2m docker container solves it temporarily

woutervdkolk commented 1 month ago

+1. Since 1.40.2-1. Exactly the same symptoms: light switches stop working after some hours, but motion sensors, air quality sensors still continue to work. So it seems not an adapter problem. Restarting addon make switches work again for some hours, but after some time they stop working again. The cycle goes on and on.

ankokdog commented 1 month ago

I have pir sensors, mmwave sensors, door sensors, many many switches, the only problem is with the lights.

ben33880 commented 1 month ago

Same problem, only lights

taenzelnderFlamingo commented 1 month ago

I have got the same problem. Everything works fine for two years with ~90 devices and then out of the blue I get random timeouts. Always a different device. Lights, switches, thermostats, just about everything except sensors ans wallplugs it seems. A power cycle of the unresponsive device or a restart of z2m fixes in temporarily and sometimes it works for a day or two and sometimes just 2 minutes. Often I have to remove the device and re-pair it, which gets kind of annoying. I'm using the sonoff 3.0 dongle cc2652p and a raspberry pi 4b. Any help is appreciated. Thanks in advance.

purche42 commented 4 weeks ago

I have got the same problem. Everything works fine for two years with ~90 devices and then out of the blue I get random timeouts. Always a different device. Lights, switches, thermostats, just about everything except sensors ans wallplugs it seems. A power cycle of the unresponsive device or a restart of z2m fixes in temporarily and sometimes it works for a day or two and sometimes just 2 minutes. Often I have to remove the device and re-pair it, which gets kind of annoying. I'm using the sonoff 3.0 dongle cc2652p and a raspberry pi 4b. Any help is appreciated. Thanks in advance.

Hi taenzelnderFlamingo

you should switch back to an older release (1.40.1) at least solve the On/Off problem for me. I have even updated the coordinator, removed and/or re-paired some devices, which does not solve the issue.

I also have some disconnects with door sensors in the last week - but this could be also caused by empty batteries of 5-6 sensors at the same time. I hope the next Z2M version will revert the changes in 1.40.2 which causes our problems.

ankokdog commented 4 weeks ago

Versions 1.40.xxx are very unstable. I home they fix them soon. I replace some zigbee bulbs to old wifi that i had because they do not work whatever i do.

taenzelnderFlamingo commented 3 weeks ago

Thanks for the advice. I tried to use a backup with some 1.39 version (i think), I cannot remember which one, but I had the same issues. Shortly after I updated back to the current version. I guess I have to wait for the next release and hope it will be resolved.

taenzelnderFlamingo commented 3 weeks ago

It seems update 1.41.0-1 fixed it for me. At least today everything worked as it did the past year. Thanks for the quick fix. I hope it helps others as well.

Well, on day two it started to malfunction again :/

ben33880 commented 3 weeks ago

Same problem with 1.41

purche42 commented 3 weeks ago

Same problem re-occurs with 1.41 . Not fixed - back to 1.40.1. I hope that changes which causes errors will be checked and fixed with next version.

This is the first severe error of this kind with Z2M in the last years.

ankokdog commented 3 weeks ago

I re-pair the lights and i think that they respond a little bit better. The problem is still there...

On Sat, Nov 2, 2024, 19:47 purche42 @.***> wrote:

Same problem re-occurs with 1.41 . Not fixed - back to 1.40.1. I hope that changes which causes errors will be checked and fixed with next version.

This is the first severe error of this kind with Z2M in the last years.

— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/24293#issuecomment-2453060545, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ4DLE4P3BEWIADRCULFP6LZ6UF3JAVCNFSM6AAAAABPZC23PKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTGA3DANJUGU . You are receiving this because you authored the thread.Message ID: @.***>

purche42 commented 3 weeks ago

Hi ankokdog I have deleted and repaired lights. This did not help. I have also updated coordinator with no effect. It turns out that a change from 1.40.1 to 140.2 caused the error.

The only solution as of today is the downgrade to the last working release. Lights on / off feature is not unimporttant for me ;)...

Koenkk commented 3 weeks ago

@purche42 could you provide the debug log of:

ankokdog commented 3 weeks ago

i just find out that one bulb that i have to the backyard works fine, it is the Tuya TS0505B_1_1 all the others that i have problem are Tuya CK-BL702-AL-01

purche42 commented 3 weeks ago

@purche42 could you provide the debug log of:

  • Start z2m 1.40.1 -> control light -> works
  • Start z2m 1.41.0 -> control light -> doesn't work

Hi Koen

here you'll find debug log of 2 test runs

first run - all light on / off works coorectly 2nd run - lights status visible but cannot switch

I hope logs helps

jerkovicl commented 3 weeks ago

I have mostly Ikea tradfri lights and it stopped working after 1.40, last release didn't fix the problem

Koenkk commented 3 weeks ago

@purche42 the logs are a bit big, what is the device you are controlling?

purche42 commented 3 weeks ago

Hi Koen,

I have a Slaesh's CC2652RB stick and 75+ devices from different brands. Ikea, Tuya, Innr, Aqara, Osram, Lidl, Sonoff, Paulmann etc. Some devices are noisy (e.g. MMW sensor but anythings works fine.

Are this big log files unusual ?

Koenkk commented 2 weeks ago

sorry, I meant what is the name of the light you are trying to control?

ankokdog commented 2 weeks ago

sorry, I meant what is the name of the light you are trying to control?

most of my bulbs (15) are Tuya CK-BL702-AL-01, i purchase a moes TS0505B MOES ZB-TDC6-RCW-E14 to test, and this one works perfect.

purche42 commented 2 weeks ago

sorry, I meant what is the name of the light you are trying to control?

I'm using Ikea Tradfri components (bulbs, panels and drivers and plugss):

and also

it seems that the change from 1.40.1 to newer versions changes or removed something in the Switch On/Off behavior.

Koenkk commented 2 weeks ago

@purche42 I mean, what is the friendly name of the device you are trying to control?

purche42 commented 2 weeks ago

@purche42 I mean, what is the friendly name of the device you are trying to control?

friendly names are

Esstisch Eingang Boardlampe LampeRGB LampeE27 Flurschrank

and more

BoronFinder commented 2 weeks ago

I have the same problem on Openhabian: after starting zigbee2mqtt, everything works for a variable amount of time (I've had a maximum of around 2 hours), and then all actors I've tried (lamps and power outlets) become unresponsive. So, for science, I've run a test so I could pinpoint as good as possible the exact point in the log where things go awry - I made a rule that changes the brightness of OG_KI_DeckenleuchteKind1 (friendly name) between 95% and 100% every 15 seconds. Between 15:56 and 15:57 in the log, the error occured. (I've modified the log only slightly for privacy, replacing some friendly names and the network ID.) The log is complete from zigbee2mqtt start (via manual npm start) to a few minutes after the error occured.

I tried to stop the process afterwards in the terminal, but it wouldn't stop (Ctrl+C only stopped it partially, disconnecting from the MQTT server and stopping zigbee-herdsman, but zh:zstack:unpi:parser still keeps running in the terminal and won't respond to any command I've tried - you can see it at the bottom of the log), which I find a bit weird. What I also noticed is that when I run zigbee2mqtt as a systemd service as usual, stopping or restarting takes a lot of time - around 1 or 2 minutes. Is that normal?

For completeness: the system is a Raspberry Pi 4B+ 4GB, running Debian Bookworm/Openhabian in the latest image that I know of. I reinstalled Zigbee2mqtt just yesterday. Everything was running stable until I upgraded to version 1.41 a few days ago. Most of my devices are Ikea Tradfri bulbs in lamps with regular on/off switches, so it's normal that many are offline and don't respond to pings. (That's why I'm pinging them every 10 minutes, so I get a somewhat up-to-date device status in openHAB.) I also noticed that when the error occurs, the zigbee2mqtt GUI keeps claiming that they're online although more than 10 minutes have passed since the last failed ping. log.log

Koenkk commented 2 weeks ago

@purche42 I cannot download your logs anymore, could you make a new one where you (for both 1.41.0 and 1.40.1) where you:

See this on how to enable debug logging.

@BoronFinder when downgrading z2m, does it work again?

BoronFinder commented 2 weeks ago

@BoronFinder when downgrading z2m, does it work again?

That's a good question. I'll have try. Beforehand, I'm testing if the problem is maybe tied to the availability pings. (Last round, z2m was working longer than usual while all lights were on, so there were no ping timeouts. After I switched them off, the error soon occured again.) I'll deactivate any availability and see if the error still occurs. If yes, I'll downgrade next.

The shutting down/restarting behaviour is actually weird, last round z2m also didn't restart with the restart button on the z2m frontend - basically the same behaviour when I tried to Ctrl+C the terminal running "npm start": the frontend was shut down, but zh:zstack:unpi:parser kept running. Only "systemctl restart zigbee2mqtt" helped. That seems to be tied to the error, as restarting through the frontend works without problems as long as the error hasn't occured yet.

purche42 commented 2 weeks ago

@purche42 I cannot download your logs anymore, could you make a new one where you (for both 1.41.0 and 1.40.1) where you:

I will try to reproduce error .. since the error occurs after (unknown) period I have to collect log. I have attached the last non working debug log so that you may analyze the error.

Device with friendly name is Boardlampe

line 4511 

[2024-11-02 21:43:37] debug:    z2m:mqtt: Received MQTT message on 'zigbee2mqtt/Boardlampe/set' with data '{"state":"ON"}'
[2024-11-02 21:43:37] debug:    zh:controller:endpoint: ZCL command 0x000b57fffeb82174/1 genLevelCtrl.moveToLevelWithOnOff({"level":5,"transtime":10}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false})

in contrast this is the log from the working environment (1.40.1)

ln6600

[2024-11-02 21:36:34] debug:    z2m:mqtt: Received MQTT message on 'zigbee2mqtt/Boardlampe/set' with data '{"state":"ON"}'
[2024-11-02 21:36:34] debug:    z2m: Publishing 'set' 'state' to 'Boardlampe'
[2024-11-02 21:36:34] debug:    zh:controller:endpoint: ZCL command 0x000b57fffeb82174/1 genLevelCtrl.moveToLevelWithOnOff({"level":5,"transtime":10}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false})
[2024-11-02 21:36:34] debug:    zh:zstack: sendZclFrameToEndpointInternal 0x000b57fffeb82174:21354/1 (0,0,12)
[2024-11-02 21:36:34] debug:    zh:zstack:znp: SREQ: --> AF - dataRequest - {"dstaddr":21354,"destendpoint":1,"srcendpoint":1,"clusterid":8,"transid":183,"options":0,"radius":30,"len":6,"data":{"type":"Buffer","data":[1,67,4,5,10,0]}}
[2024-11-02 21:36:34] debug:    zh:zstack:unpi:writer: --> frame [254,16,36,1,106,83,1,1,8,0,183,0,30,6,1,67,4,5,10,0,226]
[2024-11-02 21:36:35] debug:    zh:zstack: sendZclFrameToEndpointInternal 0x90fd9ffffeea4077:10675/1 (0,2,12)
[2024-11-02 21:36:35] debug:    zh:zstack: sendZclFrameToEndpointInternal 0x44e2f8fffe1aa29b:13143/1 (1,0,12)
[2024-11-02 21:36:35] debug:    zh:zstack: sendZclFrameToEndpointInternal 0x00124b001b799010:5919/1 (0,2,12)

or "Esstisch"

line 6021 - non working.log

[2024-11-02 21:44:15] debug:    z2m:mqtt: Received MQTT message on 'zigbee2mqtt/Esstisch/set' with data '{"state":"ON"}'
[2024-11-02 21:44:15] debug:    z2m: Publishing 'set' 'state' to 'Esstisch'
[2024-11-02 21:44:15] debug:    zh:controller:database: Writing database to '/app/data/database.db'
[2024-11-02 21:44:15] debug:    zh:controller:endpoint: ZCL command 0x00158d000448cce8/1 genLevelCtrl.moveToLevelWithOnOff({"level":3,"transtime":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false})
[2024-11-02 21:44:16] debug:    zh:zstack:unpi:parser: <-- [254,33,68,129,0,0,0,239,21,247,1,1,0,116,0,242,91,97,0,0,13,9,17,2,0,196,109,2,0,4,0,0,1,182,21,247,29,165]
[2024-11-02 21:44:16] debug:    zh:zstack:unpi:parser: --- parseNext [254,33,68,129,0,0,0,239,21,247,1,1,0,116,0,242,91,97,0,0,13,9,17,2,0,196,109,2,0,4,0,0,1,182,21,247,29,165]
[2024-11-02 21:44:16] debug:    zh:zstack:unpi:parser: --> parsed 33 - 2 - 4 - 129 - [0,0,0,239,21,247,1,1,0,116,0,242,91,97,0,0,13,9,17,2,0,196,109,2,0,4,0,0,1,182,21,247,29] - 165
[2024-11-02 21:44:16] debug:    zh:zstack:znp: <-- AREQ: AF - incomingMsg - {"groupid":0,"clusterid":61184,"srcaddr":63253,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":116,"securityuse":0,"timestamp":6380530,"transseqnumber":0,"len":13,"data":{"type":"Buffer","data":[9,17,2,0,196,109,2,0,4,0,0,1,182]}}
[2024-11-02 21:44:16] debug:    zh:controller: Received payload: clusterID=61184, address=63253, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=116, frame={"header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":17,"commandIdentifier":2},"payload":{"seq":50176,"dpValues":[{"dp":109,"datatype":2,"data":{"type":"Buffer","data":[0,0,1,182]}}]},"command":{"ID":2,"parameters":[{"name":"seq","type":33},{"name":"dpValues","type":1011}],"name":"dataReport"}}
[2024-11-02 21:44:16] debug:    zh:controller:endpoint: ZCL command 0xa4c1388fb84deeb7/1 manuSpecificTuya.defaultRsp({"cmdId":2,"statusCode":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"transactionSequenceNumber":17,"writeUndiv":false})
[2024-11-02 21:44:16] debug:    zh:zstack:unpi:parser: --- parseNext []

and in contrast this is the log from the working environment (1.40.1) with Esstisch ln7788 working.log 

[2024-11-02 21:36:53] debug:    z2m:mqtt: Received MQTT message on 'zigbee2mqtt/Esstisch/set' with data '{"state":"ON"}'
[2024-11-02 21:36:53] debug:    z2m: Publishing 'set' 'state' to 'Esstisch'
[2024-11-02 21:36:53] debug:    zh:controller:database: Writing database to '/app/data/database.db'
[2024-11-02 21:36:53] debug:    zh:controller:endpoint: ZCL command 0x00158d000448cce8/1 genLevelCtrl.moveToLevelWithOnOff({"level":3,"transtime":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false})
[2024-11-02 21:36:53] debug:    zh:zstack: sendZclFrameToEndpointInternal 0x00158d000448cce8:34792/1 (0,0,7)
[2024-11-02 21:36:53] debug:    zh:zstack:znp: SREQ: --> AF - dataRequest - {"dstaddr":34792,"destendpoint":1,"srcendpoint":1,"clusterid":8,"transid":223,"options":0,"radius":30,"len":6,"data":{"type":"Buffer","data":[1,78,4,3,0,0]}}
[2024-11-02 21:36:53] debug:    zh:zstack:unpi:writer: --> frame [254,16,36,1,232,135,1,1,8,0,223,0,30,6,1,78,4,3,0,0,221]
[2024-11-02 21:36:53] debug:    zh:zstack:unpi:parser: <-- [254,1,100,1,0,100]
[2024-11-02 21:36:53] debug:    zh:zstack:unpi:parser: --- parseNext [254,1,100,1,0,100]
[2024-11-02 21:36:53] debug:    zh:zstack:unpi:parser: --> parsed 1 - 3 - 4 - 1 - [0] - 100
[2024-11-02 21:36:53] debug:    zh:zstack:znp: SRSP: <-- AF - dataRequest - {"status":0}
[2024-11-02 21:36:53] debug:    zh:zstack:unpi:parser: --- parseNext []
[2024-11-02 21:36:53] debug:    zh:zstack:unpi:parser: <-- [254,3,68,128,0,1,223,25]
[2024-11-02 21:36:53] debug:    zh:zstack:unpi:parser: --- parseNext [254,3,68,128,0,1,223,25]
[2024-11-02 21:36:53] debug:    zh:zstack:unpi:parser: --> parsed 3 - 2 - 4 - 128 - [0,1,223] - 25
[2024-11-02 21:36:53] debug:    zh:zstack:znp: AREQ: <-- AF - dataConfirm - {"status":0,"endpoint":1,"transid":223}
[2024-11-02 21:36:53] debug:    zh:zstack:unpi:parser: --- parseNext []
[2024-11-02 21:36:53] debug:    zh:zstack:unpi:parser: <-- [254,25,68,129,0,0,8,0,232,135,1,1,0,112,0,220,71,74,0,0,5,24,78,11,4,0,232,135,29,52]
[2024-11-02 21:36:53] debug:    zh:zstack:unpi:parser: --- parseNext [254,25,68,129,0,0,8,0,232,135,1,1,0,112,0,220,71,74,0,0,5,24,78,11,4,0,232,135,29,52]
[2024-11-02 21:36:53] debug:    zh:zstack:unpi:parser: --> parsed 25 - 2 - 4 - 129 - [0,0,8,0,232,135,1,1,0,112,0,220,71,74,0,0,5,24,78,11,4,0,232,135,29] - 52
[2024-11-02 21:36:53] debug:    zh:zstack:znp: AREQ: <-- AF - incomingMsg - {"groupid":0,"clusterid":8,"srcaddr":34792,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":112,"securityuse":0,"timestamp":4868060,"transseqnumber":0,"len":5,"data":{"type":"Buffer","data":[24,78,11,4,0]}}
[2024-11-02 21:36:53] debug:    zh:controller: Received payload: clusterID=8, address=34792, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=112, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"transactionSequenceNumber":78,"commandIdentifier":11},"payload":{"cmdId":4,"statusCode":0},"command":{"ID":11,"name":"defaultRsp","parameters":[{"name":"cmdId","type":32},{"name":"statusCode","type":32}]}}

Log files from test run: z2m.tar.gz

Bulbs are Tradfri/Ikea and Paulmann. All other light were also affected - maybe also other switches.

Maybe this is logs are already sufficient - but I try to reproduce the error. I try to setup a test bed with one light - but i need to find some HW ;)

BoronFinder commented 2 weeks ago

Follow-up: turning availability off didn't help. My current (sketchy) workaround is a crontab entry that restarts the zigbee2mqtt service every hour.

@Koenkk I'll downgrade next. Can you give me a quick hint on how to do that? Can I reuse my configuration.yaml or do I need to start from scratch to play it safe? (As I only have around 10-12 devices right now, it's not that much of a hassle.) Do I just need to download the source code of the older version and put it into /opt/zigbee2mqtt, do "npm run build" and call it a day? (...provided that the necessary entries in configuration.yaml are there)

Koenkk commented 1 week ago

@BoronFinder if you are using the git based installation, just do git checkout 1.40.0 in the z2m dir

BoronFinder commented 1 day ago

So far, I have tested releases 1.40.0 and 1.40.1 - both are working flawflessly in my setting, so either 1.40.2 or 1.41.0 must be the culprit. I'll carry on testing. Round 2 would be to find out which exact commit is causing this behaviour.

frlequ commented 1 day ago

I'm running 1.40.2 with the same problem. Guess it's started with this version.

frlequ commented 1 day ago

it seems that the change from 1.40.1 to newer versions changes or removed something in the Switch On/Off behavior.

This PR was added in 1.40.2 to ikea bulbs. It's a nice feature, but don't know what else was broken. https://github.com/Koenkk/zigbee-herdsman-converters/pull/8049

BoronFinder commented 3 hours ago

The state of commit https://github.com/Koenkk/zigbee2mqtt/commit/d289194a71f67dd821335d467532f74b3d47f03a already contains the problem (that doesn't mean that this PR actually caused it). I'm working my way backwards from there, testing commit https://github.com/Koenkk/zigbee2mqtt/commit/03b5b0043a314c9fa14832ed0111b8582deb1857 to surround the problem.