lights problem #24293

ankokdog · 2024-10-11T14:53:11Z

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)

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 · 2024-10-12T08:34:03Z

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 · 2024-10-12T09:21:11Z

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 · 2024-10-14T06:45:55Z

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 · 2024-10-14T07:23:54Z

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 <#24293 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZ4DLE2ADJTTKQCP26DYQQTZ3NSDRAVCNFSM6AAAAABPZC23PKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJQGE3TKNBYGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

jerkovicl · 2024-10-14T12:06:58Z

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 · 2024-10-16T09:15:02Z

+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 · 2024-10-16T11:33:05Z

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

ben33880 · 2024-10-16T12:00:27Z

Same problem, only lights

taenzelnderFlamingo · 2024-10-27T19:27:44Z

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 · 2024-10-28T11:36:55Z

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 · 2024-10-28T12:08:02Z

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 · 2024-10-31T19:06:03Z

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 · 2024-11-01T22:18:13Z

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 · 2024-11-02T02:03:12Z

Same problem with 1.41

purche42 · 2024-11-02T17:47:11Z

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 · 2024-11-02T17:53:34Z

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 <#24293 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZ4DLE4P3BEWIADRCULFP6LZ6UF3JAVCNFSM6AAAAABPZC23PKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTGA3DANJUGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

purche42 · 2024-11-02T18:08:43Z

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 · 2024-11-02T19:52:13Z

@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

ankokdog · 2024-11-02T20:41:04Z

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 · 2024-11-02T21:01:43Z

@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 · 2024-11-03T09:01:43Z

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

Koenkk · 2024-11-03T14:00:00Z

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

purche42 · 2024-11-05T17:54:20Z

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 · 2024-11-06T20:37:54Z

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

ankokdog · 2024-11-06T21:14:50Z

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 · 2024-11-07T06:09:18Z

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):

TRADFRI bulb E27 WS opal 980lm: 2
TRADFRI Driver 30W: 2
SURTE door WS 38x64: 2
TRADFRI bulb E14 WS 470lm: 1
TRADFRI bulb E27 CWS opal 600lm: 1
TRADFRI bulb E27 W opal 1000lm: 1
FLOALT panel WS 30x90: 1

and also

Paulmann - 500.45:
GIDEALED - Smart Zigbee RGB LED strip controller
Innr RB 145

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

Koenkk · 2024-11-07T19:42:30Z

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

purche42 · 2024-11-08T07:57:54Z

@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 · 2024-11-10T16:21:13Z

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 · 2024-11-10T19:30:55Z

@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:

Start z2m
Control a single light (please provide the friendly name of the light you trying to control)
Stop z2m

See this on how to enable debug logging.

@BoronFinder when downgrading z2m, does it work again?

BoronFinder · 2024-11-10T20:42:54Z

@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 · 2024-11-11T13:47:57Z

@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}]}}

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 · 2024-11-12T20:20:26Z

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 · 2024-11-13T20:31:53Z

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

BoronFinder · 2024-11-25T06:33:59Z

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 · 2024-11-25T18:02:50Z

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

frlequ · 2024-11-25T21:40:57Z

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.
Koenkk/zigbee-herdsman-converters#8049

BoronFinder · 2024-11-26T23:41:28Z

The state of commit d289194 already contains the problem (that doesn't mean that this PR actually caused it). I'm working my way backwards from there, testing commit 03b5b00 to surround the problem.

BoronFinder · 2024-11-27T18:42:26Z

Commit 03b5b00 seems to run stable, commit d3de77d also ran stable for 3,5 hours. Next up is testing commit da2a697

BoronFinder · 2024-11-30T10:16:22Z

I have good news and bad news: every commit up to 7ad51ce runs stable - and the latter is running since a few hours, so I consider it stable, too.
That means it must be the changes introduced in d289194 that cause the instability. Which i can't test further, as I don't know how to pull specific files from a dependency packaged in npm.
And I guess that wouldn't work anyway, either, since it's all in this one commit in zigbee-herdsman Koenkk/zigbee-herdsman@d84725b that is the only difference between zigbee-herdsman versions 1.0.1 and 1.1.0
What can we do now?

Koenkk · 2024-11-30T12:58:00Z

It's likely the same as #24671

BoronFinder · 2024-11-30T13:31:29Z

Thanks! I gather from the other thread that you suspect a different commit (the next "big" one) to be the culprit. I'll do a last test with zigbee-herdsman 1.1.0, but I think the problem already starts there. I'll carry the discussion over to the other thread to keep it in one place.

ankokdog added the problem Something isn't working label Oct 11, 2024

patagonaa mentioned this issue Oct 26, 2024

SONOFF ZBMINIL2 stops responding after a few minutes #24265

Closed

This was referenced Nov 18, 2024

After around 1 day z2m is still running, but devices do not respond to commands #24806

Closed

Since version 1.40.2 and after few hours, unable to change state of lights #24671

Closed

lights problem #24293

lights problem #24293

Comments

ankokdog commented Oct 11, 2024

What happened?

What did you expect to happen?

How to reproduce it (minimal and precise)

Zigbee2MQTT version

Adapter firmware version

Adapter

Setup

Debug log

zyankali333 commented Oct 12, 2024

ankokdog commented Oct 12, 2024

purche42 commented Oct 14, 2024

ankokdog commented Oct 14, 2024 via email

jerkovicl commented Oct 14, 2024 • edited Loading

woutervdkolk commented Oct 16, 2024

ankokdog commented Oct 16, 2024

ben33880 commented Oct 16, 2024

taenzelnderFlamingo commented Oct 27, 2024

purche42 commented Oct 28, 2024

ankokdog commented Oct 28, 2024

taenzelnderFlamingo commented Oct 31, 2024

taenzelnderFlamingo commented Nov 1, 2024 • edited Loading

ben33880 commented Nov 2, 2024

purche42 commented Nov 2, 2024

ankokdog commented Nov 2, 2024 via email

purche42 commented Nov 2, 2024

Koenkk commented Nov 2, 2024

ankokdog commented Nov 2, 2024

purche42 commented Nov 2, 2024 • edited Loading

jerkovicl commented Nov 3, 2024 • edited Loading

Koenkk commented Nov 3, 2024

purche42 commented Nov 5, 2024

Koenkk commented Nov 6, 2024

ankokdog commented Nov 6, 2024

purche42 commented Nov 7, 2024

Koenkk commented Nov 7, 2024

purche42 commented Nov 8, 2024

BoronFinder commented Nov 10, 2024

Koenkk commented Nov 10, 2024

BoronFinder commented Nov 10, 2024

purche42 commented Nov 11, 2024 • edited Loading

BoronFinder commented Nov 12, 2024

Koenkk commented Nov 13, 2024

BoronFinder commented Nov 25, 2024

frlequ commented Nov 25, 2024

frlequ commented Nov 25, 2024

BoronFinder commented Nov 26, 2024 • edited Loading

BoronFinder commented Nov 27, 2024

BoronFinder commented Nov 30, 2024

Koenkk commented Nov 30, 2024

BoronFinder commented Nov 30, 2024

jerkovicl commented Oct 14, 2024 •

edited

Loading

taenzelnderFlamingo commented Nov 1, 2024 •

edited

Loading

purche42 commented Nov 2, 2024 •

edited

Loading

jerkovicl commented Nov 3, 2024 •

edited

Loading

purche42 commented Nov 11, 2024 •

edited

Loading

BoronFinder commented Nov 26, 2024 •

edited

Loading