IKEA Parasoll sensors going offline

What happened?

I've 14 IKEA Parasoll sensors connected to my zigbee network.

The sensors are going offline in Zigbee2MQTT after they should have checked in for the availability check.

My availability settings are set to advanced, 10 min timeout for active devices and 120 mins for passive.

The sensors all have new IKEA LADDA batteries which are the 1.2V type based on other known issues.

The same issue with going offline doesn't appear to happen with ZHA so the issue doesn't appear to be device related

What did you expect to happen?

No response

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

1.37.0

Adapter firmware version

20221226

Adapter

SONFF Zigbee Dongle-P

Setup

Add-on within Home Assistant within Proxmox VM on Intel NUC

Debug log

log1.log

Example:

[2024-05-10 10:32:54] debug: z2m: Passive device 'Back Bedroom Right Window' was last seen '2.00' hours ago. [2024-05-10 10:32:54] debug: z2m: MQTT publish: topic 'zigbee2mqtt/Back Bedroom Right Window/availability', payload '{"state":"offline"}'

I have two of them. One is working fine (for weeks/months), the other is going offline after a few hours (also after repairing).

I humbled across this issue and I just wanted to share my experience with the Parasoll Sensor - due to the same reasons with the new IKEA sensors I put in 1,2V batteries (IKEA Ladda and another brand) as well and my sensor dropped off after few minutes.. ironically I then put in cheap 1,5V discounter batteries (Tronic by Lidl) and my sensor is now running fine since 4 days.

Until today I only had this one Parasoll sensor, but I bought two additional Parasoll, where I put in same brand 1,5V as well - in case this experience changes with the other sensors I'll let you know.

I also have a similar setup:

Adapter SONFF Zigbee Dongle-P

Setup Add-on within Home Assistant within Proxmox VM on HP Laptop (which I recycled as server)

Same issue here, with a large number of Parasoll sensors and a mix of Ikea Ladda and another brand rechargeables. The sensors connect fine, and they work fine for a few hours, but then they stop reporting into Z2M. For another few hours, they are still shown as Online in the Z2M web interface, but state changes aren't reflected anymore. After that, they eventually move to offline, and another day or so later, the battery is drained.

I went through all of them yesterday and they were working, now (~16 hours later) found a few already which aren't updating anymore. I have found a few sub-cases while doing that:

the sensor is still seemingly working (blinks when opening/closing the window), but the state isn't reflected in Z2M; either pressing the reset button, or removing and reinserting the battery brings it back into the network;
the sensor is completely dead (no reaction when opening/closing the window - battery likely drained); replacing the battery brings it back into the network;
on a few occasions, I have found the sensors with the led 'on' and not reacting to window opening/closing; I assume this is some form of error or signalling an impeding battery exhaustion; replacing the battery brings it back into the network. On all of the above, the situation is the same - once back into the network, they work for a few hours, then silently drop off.

The issue is quite universal, regardless of whether the sensors are connected to the coordinator or one of the routers in the network. There doesn't seem to be any relation to signal strength, location, frequency of usage or anything that I can think of. Other Zigbee devices in my network (including various other Ikea products) seem to be working fine.

I tried this with both drivers (ember and ezsp), and a few successive versions of Z2M, and of dongle firmware - same behaviour. I didn't test yet with a different software, but some reports online suggest that the issue only occurs with Z2M (they seem to work fine in ZHA), which would indicate an issue specific to Z2M.

I am not a Z2M expert, so not sure what logs are relevant and what not. Last time I enabled debug logging, I ended up with a machine freeze after a few hours, so I am a little cautious about doing that again. Happy to help with debugging, if someone can point me in the right direction.

After upgrading the firmware of my Sonoff Zigbee USB Dongle Plus (P) coordinator to 20230507, both of my PARASOLL sensors are online and reporting fine, for a few weeks now.

Also using the LADDA rechargables.

I see a similiar issue with the PARASOLL sensors using LADDA rechargables. They get unavailable after approx. 2 weeks.

Running Sonoff ZBDongle-E with MultiPAN RCP firmware 4.3.1.

Dongle-E as well myself, various versions of the NCP firmware. I gave up for now, unless someone has some ideas for troubleshooting.

I switched to NCP 7.4.2.0 FW and the ember driver. Let's see if this helps.

@9shearer Do you use the ezsp or ember driver?

@meiser79 I am facing the same issue on ember and on ezsp (both NCP). Is there a way to enable debug logging for one specific device? I went through the docs and I see ways to exclude devices, but given the size of my network, that would be a tad impractical.

@Koenkk Hi, may we ask for some advice how we could troubleshoot this issue? Thanks a lot!

Does the same problem occur with the ember adapter? (not ezsp)
Scrolling through this issue, it seems that the batteries affect this, isnt this just a battery problem?

After upgrading the firmware of my Sonoff Zigbee USB Dongle Plus (P) coordinator to 20230507, both of my PARASOLL sensors are online and reporting fine, for a few weeks now.

Also using the LADDA rechargables.

To add to the user reports: I am in the same situation of @JBS5 from the beginning of the addition of the 4 Parasoll sensors to my Zigbee network, and I haven't had any connectivity issues ever since (3 months at the time of writing).

I use a Sonoff ZB-Dongle-P with firmware Z-Stack_3.x.0_coordinator_20230507 and I used Ladda batteries for all of the 4 Parasolls - I charged those batteries with the IKEA charger, the Stenkol, before putting them inside the sensors. I started with version 1.36.0 of Zigbee2MQTT and I am currently running version 1.38.0

Does the same problem occur with the ember adapter? (not ezsp)

Yes. Tested with both EZSP and Ember on 7.4.2.0 (and a couple of prior versions on EZSP), no change. If you have some suggestions for targeted logging, I am happy to re-power a few of the sensors (gave up on changing batteries on a daily basis - I do have quite a few of them) and pull data.

Scrolling through this issue, it seems that the batteries affect this, isnt this just a battery problem?

Not in my case. I have a bunch of Parasoll sensors running with a mix of power sources (Ikea Ladda and other generic brand rechargeables, generic one-time batteries). The behavior is always the same:

after ~2-3 days, the sensor first stops reporting changes, but continues showing as "online" (with whichever the last state was, i.e. open or closed) -- If I catch it quickly (typically within a day), a power cycle of the sensor (removing/reinserting the battery) brings it back into the network, and it reports state changes as before (until it drops off again)
after another day or two, the sensor drops completely off the network (shows as "unavailable"/"offline") -- If I don't catch it early, the battery eventually gets exhausted.

Any suggestion regarding targeted logging, @Koenkk ? Setting a global debug and then excluding devices one by one isn't very effective in my case, as I have a lot of devices. In the meanwhile, I think we can also rule out the number of devices as a potential cause. I only had one Parasoll left active in the network, which worked for ~4-5 days and then went missing as well. It had a freshly loaded Ladda battery, and it is 1.5m from the nearest Zigbee router.

This is probably not going to do anything, but it's worth a shot.

If you can run de dev/edge release, try binding the manuSpecificIkeaUnknown cluster to the coordinator.

@sjorge I get below error when trying to bind manuSpecificIkeaUnknown to the cluster.

Error 2024-06-24 07:03:18z2m: Failed to bind cluster 'manuSpecificIkeaUnknown' from 'PARASOLL Bad' to 'Coordinator' (Error: Bind 0x048727fffeb82ce4/1 manuSpecificIkeaUnknown from '0xe0798dfffeeaed17/1' failed (Delivery failed for {"profileId":0,"clusterId":33,"sourceEndpoint":0,"destinationEndpoint":0,"options":4416,"groupId":0,"sequence":8}))

BTW, the LADDA battery lasts for one week in the PARASALL sensor.

Delivery failed for I've never seen that error before :| I wonder if it's similar to a timeout. Was de BADRING awake when you tried to bind?

The PARASOLL sensor was at least shown as available. And I opened the window once to somehow wake it up.

Ive had the same issues and just been replacing the battery thinking it was dead (despite it reporting 100% in Z2M) and after changing the battery is back online. But again about 2 weeks or so and it doesn't show as unavailable or offline, just doesn't update to open or close

• 3 IKEA Parasoll Sensors running • Zigbee2Mqtt with Sonoff P • First failure: 4-8 weeks? (most active sensor) • Reinserting the same battery did not work - new battery worked • Measured voltage: 0,8V • Battery type: IKEA AAA Rechargeable

There's obviously something draining the batteries.

The device which failed had a battery state of 83%. My two others currently have a battery state of 83% and 86%. I'm giving them two more weeks before failing.

Is this an IKEA firmware bug, IKEA hardware bug, or a Zigbee2MQTT thing where it's somehow polling on and on and destroying the battery life?

• 3 IKEA Parasoll Sensors running • Zigbee2Mqtt with Sonoff P • First failure: 4-8 weeks? (most active sensor) • Reinserting the same battery did not work - new battery worked • Measured voltage: 0,8V • Battery type: IKEA AAA Rechargeable

There's obviously something draining the batteries.

The device which failed had a battery state of 81%. My two others currently have a battery state of 83%. I'm giving them two more weeks before failing.

Is this an IKEA firmware bug, IKEA hardware bug, or a Zigbee2MQTT thing where it's somehow polling on and on and destroying the battery life?

Are you thinking something like this issue? https://github.com/Koenkk/zigbee2mqtt/issues/14157

• 3 IKEA Parasoll Sensors running • Zigbee2Mqtt with Sonoff P • First failure: 4-8 weeks? (most active sensor) • Reinserting the same battery did not work - new battery worked • Measured voltage: 0,8V • Battery type: IKEA AAA Rechargeable There's obviously something draining the batteries. The device which failed had a battery state of 81%. My two others currently have a battery state of 83%. I'm giving them two more weeks before failing. Is this an IKEA firmware bug, IKEA hardware bug, or a Zigbee2MQTT thing where it's somehow polling on and on and destroying the battery life?

Are you thinking something like this issue? #14157

Tried the solution described there (disabling the PowerCfg report) - no effect. I replaced the rechargeables in 4 sensors, all close to each other (so presumably similar signal levels). Used 2x Ikea Ladda, 2x other brand, all fully charged upon installation. Now (less than 24h later), after I opened/closed all the 4 doors/windows 5 minutes ago, 3 of the sensors aren't working anymore, as follows:

2 sensors (let's call them Sensor A and Sensor B) have a "last_seen" of 7-8h ago. Their LED still blinks when opening the door/window, but state (contact open/closed) isn't updated in Z2M. The last reported battery level is 90+ for both.
1 sensor (let's call it Sensor C) has a "last_seen" of 1 minute ago (very recent). The LED still blinks when opening the door/window, but state (contact open/closed) isn't updated in Z2M. Battery level is 94%. There is something funny I noticed for this one - see next post.
1 sensor (still) works normally (calling it Sensor D). The LED blinks when opening the door/window, state (contact is true/false) gets updated in Z2M as expected. Battery level is 97%. FWIW, I have a few (also Ikea) battery-operated switches, and they work perfectly fine - same batteries for weeks now.

Here's the funny behaviour I noticed for Sensor C mentioned above, while pulling the states for this. When checking first in Z2M (State tab), it looked like this:

{
    "ac_status": false,
    "battery": 94,
    "battery_defect": false,
    "battery_low": false,
    "contact": true,
    "last_seen": "2024-07-06T09:39:46.149Z",
    "linkquality": 96,
    "restore_reports": false,
    "supervision_reports": false,
    "tamper": false,
    "test": false,
    "trouble": false,
    "update": {
        "installed_version": -1,
        "latest_version": -1,
        "state": "idle"
    },
    "update_available": null
}

In the Devices list, it was showing as "last seen" 'just now' or very recently. I went to test it again by opening the respective door/window, and I refreshed the tab where I had the state in Z2M. And this is where I noticed something funny: the "last_seen" entry in the state JSON changed A FEW TIMES in 'real time' - so basically "...09:39:46.149Z" was "09:39:45.xxxZ", then it became "09:39:45.yyyZ", then it became the value listed above and it stopped updating. Throughout all these quick changes, the "contact" value remained unchanged, even if I had opened the respective door/window, and the LED was blinking accordingly. ==> It seemed like the sensor was continuously talking to Z2M, but without sending the new state (door/window opened/closed)

Once the "last_seen" stopped updating, the state tab remained fixed at

{
    "ac_status": false,
    "battery": 94,
    "battery_defect": false,
    "battery_low": false,
    "contact": true,
    "last_seen": "2024-07-06T09:40:21.154Z",
    "linkquality": 96,
    "restore_reports": false,
    "supervision_reports": false,
    "tamper": false,
    "test": false,
    "trouble": false,
    "update": {
        "state": "idle"
    }
}

The "contact" didn't update at all throughout the changes (it stayed 'true', i.e. door/window closed), even if I opened it multiple times and watched the State tab in Z2M in real time - no change whatsoever with regard to the contact tab, but the displayed JSON fluctuated between the two formats above (basically update... -1 and update... idle), and the last_seen value did get updated.

I went to repeat the experiment once more (same sensor, same approach) and now I am even more puzzled. The sensor continued the behaviour described above, but this time the "contact" in Z2M got updated once to "false" (i.e. door/window open) and it stayed like that. No matter if I opened it several times more, it still displayed "false".

I am really confused how this can happen:

some parts of the JSON getting updated, others not, in a seemingly random fashion
the state not getting reflected, even if the sensor is physically working (as attested by the blinking LED upon opening/closing, and the erratic update of the states)

My coordinator is a ZB-Dongle-E, with firmware 7.4.2.0 (flashed with the web flasher from darkxst), on Z2M 1.39.0, driver Ember. I have tens of other devices in the same network which seem to be working just fine.

OK a bit more info. I decided to watch the other sensor that was still working (Sensor D), and it now behaves the same as Sensor C. The "last seen" gets updated several times in quick succession every ~17 seconds (not a scientific measurement), but the open/closed state doesn't get updated anymore. This sensor was working half an hour ago, so I guess it has now also "gone off" and will soon exhaust the battery.

The battery level of Sensor D went from 97% to 86% in approximately 45 minutes. This was plugged in with a freshly-loaded rechargeable less than 24 hours ago. Up until now, it was working perfectly fine (open/close states were reflected correctly in Z2M).

Further experimentation - Sensor A was offline for several hours, LED blinking when door/window was opened/closed, but no updates at all in Z2M (neither contact, neither last_seen, marked as "offline" in the device list).

Pressing the reset button once - no change.

Removing and reinserting the battery - sensor back to normal. Contact state is updated and reflected in Z2M, last_seen is current, no rapid updates of last_seen, battery level is 90% (same as it was when it had gone off the network).

Sensors C and D - which had gone into the "rapid update every ~17 seconds, but no state changes" mode: just noticed their LED had become permanently 'on'. The same "rapid updates" were still happening, but this time the LED wasn't blinking anymore when opening/closing the door/window. Removing and reinserting the battery brought them back to normal behaviour (no rapid last_seen updates, proper reporting of the state in Z2M).

My empiric guess of the state changes is:

Sensor works normally for a few hours
At some point, it stops reporting state changes (open/closed) to Z2M, even if its LED still works as expected (blinking on open/close)
The last_seen starts to update rapidly (several times within a second), every ~17 seconds;
The sensor eventually becomes offline in Z2M
If left unattended, it will at some point exhaust the battery. If the battery is removed/reinserted, it goes back to normal behaviour. I am not sure (and don't have any efficient means of testing) if states 2 and 3 occur at the same moment.

@Koenkk or anyone else, any ideas? Happy to do any specific troubleshooting / logging with a bit of guidance.

@9shearer could you provide the debug logging of a "everything works situation" till step 3?

@Koenkk gladly. Is there a way to enable debug logging for only one / a few devices?

I have tens of Zigbee devices (most of them working fine) and enabling debug logging globally doesn't work (tried once and it killed the machine where Z2M is installed). Conversely, excluding devices one by one (I believe that's what's described in the docs) is pretty cumbersome - might go down that path if there is no other way.

I gave it a shot and enabled debug logging globally last night. I think we might be on to something, as despite the log files not catching the whole interval, I think they did manage to catch the interval when one of the sensors went from "all good" into "rapid fire updates every 17 seconds" behavior (so basically the transition from steps 1 to 2 (or 2 to 3).

Check this out (output of "grep 0x..." from the log file directory with the address of the problem_sensor_C).

Good behaviour (presumably):

log2.log:[2024-07-07 06:04:57] debug:   zh:ember:ezsp: ezspIncomingRouteRecordHandler(): callback called with: [source=24132], [sourceEui=0x059731fffe23ac1f], [lastHopLqi=192], [lastHopRssi=-52], [relayCount=1], [relayList=5246]
log2.log:[2024-07-07 06:13:29] debug:   zh:ember:ezsp: ezspIncomingRouteRecordHandler(): callback called with: [source=24132], [sourceEui=0x059731fffe23ac1f], [lastHopLqi=192], [lastHopRssi=-52], [relayCount=1], [relayList=5246]
log2.log:[2024-07-07 06:44:06] debug:   zh:ember:ezsp: ezspIncomingRouteRecordHandler(): callback called with: [source=24132], [sourceEui=0x059731fffe23ac1f], [lastHopLqi=192], [lastHopRssi=-52], [relayCount=1], [relayList=5246]
log1.log:[2024-07-07 07:03:11] debug:   zh:ember:ezsp: ezspIncomingRouteRecordHandler(): callback called with: [source=24132], [sourceEui=0x059731fffe23ac1f], [lastHopLqi=192], [lastHopRssi=-52], [relayCount=1], [relayList=5246]
log1.log:[2024-07-07 07:24:59] debug:   zh:ember:ezsp: ezspIncomingRouteRecordHandler(): callback called with: [source=24132], [sourceEui=0x059731fffe23ac1f], [lastHopLqi=192], [lastHopRssi=-52], [relayCount=1], [relayList=5246]
log1.log:[2024-07-07 08:01:25] debug:   zh:ember:ezsp: ezspIncomingRouteRecordHandler(): callback called with: [source=24132], [sourceEui=0x059731fffe23ac1f], [lastHopLqi=192], [lastHopRssi=-52], [relayCount=1], [relayList=5246]

While I am wondering about the timing (it seems to check in randomly), I would be happy with it working.

Bad behaviour ("updates" every 17 seconds, but nothing seen in the frontend):

log1.log:[2024-07-07 08:16:03] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:03] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:03] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:03] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:03] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:03] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:03] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:03] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:21] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:21] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:21] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:21] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:21] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:21] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:21] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:21] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:21] debug:   zh:ember:ezsp: ezspIncomingSenderEui64Handler(): callback called with: [senderEui64=0x059731fffe23ac1f]
log1.log:[2024-07-07 08:16:21] debug:   zh:ember:ezsp: <=== [ZDO END_DEVICE_ANNOUNCE nodeId=24132 eui64=0x059731fffe23ac1f capabilities=10000000]
log1.log:[2024-07-07 08:16:21] debug:   zh:controller: Device announce '0x059731fffe23ac1f'
log1.log:[2024-07-07 08:16:21] info:    z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_C","ieee_address":"0x059731fffe23ac1f"},"type":"device_announce"}'
log1.log:[2024-07-07 08:16:21] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=54147]
log1.log:[2024-07-07 08:16:21] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:21] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:21] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:21] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=54147]
log1.log:[2024-07-07 08:16:21] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:21] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:21] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:21] debug:   zh:ember:ezsp: ezspIncomingSenderEui64Handler(): callback called with: [senderEui64=0x059731fffe23ac1f]
log1.log:[2024-07-07 08:16:21] debug:   zh:ember:ezsp: <=== [ZDO END_DEVICE_ANNOUNCE nodeId=24132 eui64=0x059731fffe23ac1f capabilities=10000000]
log1.log:[2024-07-07 08:16:21] debug:   zh:controller: Device announce '0x059731fffe23ac1f'
log1.log:[2024-07-07 08:16:22] info:    z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_C","ieee_address":"0x059731fffe23ac1f"},"type":"device_announce"}'
log1.log:[2024-07-07 08:16:22] debug:   zh:ember:ezsp: ezspIncomingSenderEui64Handler(): callback called with: [senderEui64=0x059731fffe23ac1f]
log1.log:[2024-07-07 08:16:22] debug:   zh:ember:ezsp: <=== [ZDO END_DEVICE_ANNOUNCE nodeId=24132 eui64=0x059731fffe23ac1f capabilities=10000000]
log1.log:[2024-07-07 08:16:22] debug:   zh:controller: Device announce '0x059731fffe23ac1f'
log1.log:[2024-07-07 08:16:22] info:    z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_C","ieee_address":"0x059731fffe23ac1f"},"type":"device_announce"}'
log1.log:[2024-07-07 08:16:22] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:22] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:22] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:22] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:22] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:22] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:22] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:22] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:22] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:22] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:22] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:22] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:22] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:22] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:22] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:22] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:22] debug:   zh:ember:ezsp: ezspIncomingSenderEui64Handler(): callback called with: [senderEui64=0x059731fffe23ac1f]
log1.log:[2024-07-07 08:16:22] debug:   zh:ember:ezsp: <=== [ZDO END_DEVICE_ANNOUNCE nodeId=24132 eui64=0x059731fffe23ac1f capabilities=10000000]
log1.log:[2024-07-07 08:16:22] debug:   zh:controller: Device announce '0x059731fffe23ac1f'
log1.log:[2024-07-07 08:16:22] info:    z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_C","ieee_address":"0x059731fffe23ac1f"},"type":"device_announce"}'
log1.log:[2024-07-07 08:16:22] debug:   zh:ember:ezsp: ezspIncomingSenderEui64Handler(): callback called with: [senderEui64=0x059731fffe23ac1f]
log1.log:[2024-07-07 08:16:22] debug:   zh:ember:ezsp: <=== [ZDO END_DEVICE_ANNOUNCE nodeId=24132 eui64=0x059731fffe23ac1f capabilities=10000000]
log1.log:[2024-07-07 08:16:22] debug:   zh:controller: Device announce '0x059731fffe23ac1f'
log1.log:[2024-07-07 08:16:23] info:    z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_C","ieee_address":"0x059731fffe23ac1f"},"type":"device_announce"}'
log1.log:[2024-07-07 08:16:23] debug:   zh:ember:ezsp: ezspIncomingSenderEui64Handler(): callback called with: [senderEui64=0x059731fffe23ac1f]
log1.log:[2024-07-07 08:16:23] debug:   zh:ember:ezsp: <=== [ZDO END_DEVICE_ANNOUNCE nodeId=24132 eui64=0x059731fffe23ac1f capabilities=10000000]
log1.log:[2024-07-07 08:16:23] debug:   zh:controller: Device announce '0x059731fffe23ac1f'
log1.log:[2024-07-07 08:16:23] info:    z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_C","ieee_address":"0x059731fffe23ac1f"},"type":"device_announce"}'
log1.log:[2024-07-07 08:16:23] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:23] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:23] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:23] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:23] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:23] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:23] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:23] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:23] debug:   zh:ember:ezsp: ezspIncomingSenderEui64Handler(): callback called with: [senderEui64=0x059731fffe23ac1f]
log1.log:[2024-07-07 08:16:23] debug:   zh:ember:ezsp: <=== [ZDO END_DEVICE_ANNOUNCE nodeId=24132 eui64=0x059731fffe23ac1f capabilities=10000000]
log1.log:[2024-07-07 08:16:23] debug:   zh:controller: Device announce '0x059731fffe23ac1f'
log1.log:[2024-07-07 08:16:23] info:    z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_C","ieee_address":"0x059731fffe23ac1f"},"type":"device_announce"}'
log1.log:[2024-07-07 08:16:40] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:40] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:40] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:40] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:40] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:40] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:40] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:40] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:41] debug:   zh:ember:ezsp: ezspIncomingSenderEui64Handler(): callback called with: [senderEui64=0x059731fffe23ac1f]
log1.log:[2024-07-07 08:16:41] debug:   zh:ember:ezsp: <=== [ZDO END_DEVICE_ANNOUNCE nodeId=24132 eui64=0x059731fffe23ac1f capabilities=10000000]
log1.log:[2024-07-07 08:16:41] debug:   zh:controller: Device announce '0x059731fffe23ac1f'
log1.log:[2024-07-07 08:16:41] info:    z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_C","ieee_address":"0x059731fffe23ac1f"},"type":"device_announce"}'
log1.log:[2024-07-07 08:16:41] debug:   zh:ember:ezsp: ezspIncomingSenderEui64Handler(): callback called with: [senderEui64=0x059731fffe23ac1f]
log1.log:[2024-07-07 08:16:41] debug:   zh:ember:ezsp: <=== [ZDO END_DEVICE_ANNOUNCE nodeId=24132 eui64=0x059731fffe23ac1f capabilities=10000000]
log1.log:[2024-07-07 08:16:41] debug:   zh:controller: Device announce '0x059731fffe23ac1f'
log1.log:[2024-07-07 08:16:41] info:    z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_C","ieee_address":"0x059731fffe23ac1f"},"type":"device_announce"}'
log1.log:[2024-07-07 08:16:41] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:41] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:41] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:41] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:41] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:41] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:41] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:41] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:41] debug:   zh:ember:ezsp: ezspIncomingSenderEui64Handler(): callback called with: [senderEui64=0x059731fffe23ac1f]
log1.log:[2024-07-07 08:16:41] debug:   zh:ember:ezsp: <=== [ZDO END_DEVICE_ANNOUNCE nodeId=24132 eui64=0x059731fffe23ac1f capabilities=10000000]
log1.log:[2024-07-07 08:16:41] debug:   zh:controller: Device announce '0x059731fffe23ac1f'
log1.log:[2024-07-07 08:16:41] info:    z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_C","ieee_address":"0x059731fffe23ac1f"},"type":"device_announce"}'
log1.log:[2024-07-07 08:16:41] debug:   zh:ember:ezsp: ezspIncomingSenderEui64Handler(): callback called with: [senderEui64=0x059731fffe23ac1f]
log1.log:[2024-07-07 08:16:41] debug:   zh:ember:ezsp: <=== [ZDO END_DEVICE_ANNOUNCE nodeId=24132 eui64=0x059731fffe23ac1f capabilities=10000000]
log1.log:[2024-07-07 08:16:41] debug:   zh:controller: Device announce '0x059731fffe23ac1f'
log1.log:[2024-07-07 08:16:42] info:    z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_C","ieee_address":"0x059731fffe23ac1f"},"type":"device_announce"}'
log1.log:[2024-07-07 08:16:42] debug:   zh:ember:ezsp: ezspIncomingRouteRecordHandler(): callback called with: [source=24132], [sourceEui=0x059731fffe23ac1f], [lastHopLqi=92], [lastHopRssi=-77], [relayCount=2], [relayList=62431,21066]
log1.log:[2024-07-07 08:16:42] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:42] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:42] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:42] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:42] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:42] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:42] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:42] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:42] debug:   zh:ember:ezsp: ezspIncomingSenderEui64Handler(): callback called with: [senderEui64=0x059731fffe23ac1f]
log1.log:[2024-07-07 08:16:42] debug:   zh:ember:ezsp: <=== [ZDO END_DEVICE_ANNOUNCE nodeId=24132 eui64=0x059731fffe23ac1f capabilities=10000000]
log1.log:[2024-07-07 08:16:42] debug:   zh:controller: Device announce '0x059731fffe23ac1f'
log1.log:[2024-07-07 08:16:42] info:    z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_C","ieee_address":"0x059731fffe23ac1f"},"type":"device_announce"}'
log1.log:[2024-07-07 08:16:42] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:42] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:42] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:42] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
log1.log:[2024-07-07 08:16:43] debug:   zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=62431]
log1.log:[2024-07-07 08:16:43] debug:   zh:controller: Device '0x059731fffe23ac1f' joined
log1.log:[2024-07-07 08:16:43] debug:   zh:controller: Device '0x059731fffe23ac1f' accepted by handler
log1.log:[2024-07-07 08:16:43] debug:   zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'

@Koenkk I hope the above helps. With my little knowledge, I guess the issue occurs when the "check-in method" switches from ezspIncomingRouteRecordHandler to ezspTrustCenterJoinHandler (no idea why/how that works). And despite nothing changing (IEEE address, node ID etc) and the ezspTrustCenterJoinHandler seemingly working (device... joined, device ... accepted, not interviewing...), this seems to go into a loop. Which, if left alone for long enough, will kill the battery. I further guess the battery removal (if done before the battery gets exhausted) breaks this infinite loop, which puts the device back into the "good" state - until whatever causes the switch mentioned above happens again, and then it goes into the loop, and so on.

Did a little research in the meanwhile and the issue seems superficially similar to 22611. Quote from that thread:

When I push button, last seen is refresh in Z2M but no action is received and so on, send to MQTT....

And the same calls to ezspTrustCenterJoinHandler() for the misbehaving device, although it does seem that in the other thread, this is a permanent rather than temporary situation (the devices there don't work at all, while my Ikea Parasolls work for some time, until they don't).

Just want to chime in that I see the exact same issue as @9shearer.

Sensor works normally for a few hours

At some point, it stops reporting state changes (open/closed) to Z2M, even if its LED still works as expected (blinking on open/close)

The last_seen starts to update rapidly (several times within a second), every ~17 seconds;

The sensor eventually becomes offline in Z2M

If left unattended, it will at some point exhaust the battery. If the battery is removed/reinserted, it goes back to normal behaviour.

I am not sure (and don't have any efficient means of testing) if states 2 and 3 occur at the same moment.

Just catched one at step 2 and reinserted the battery to get it going again. Battery went from 66% to 37% in a matter of 2.5h.

@9shearer do you also have the log of the moment it goes from the working to failed state?

@Koenkk I tried to extract all the relevant events. As I said, I have a big network and there's a lot of logged data; if there is a possibility to only log for the relevant item, I will gladly do it (or if there is some specific event to look for in the full log).

In brief:

up until 08:01:25: nothing unusual, the "regular check-in" happens every 10-20 minutes. "Device requested OTA" happens every 10 minutes and there are 3-4 entries 2-3 seconds apart in each "burst"
08:01:25: regular check-in (still seems to be working)
08:05:46: device requested OTA
08:05:49: device requested OTA
08:05:52: device requested OTA
08:05:55: device requested OTA
08:05:58: device requested OTA
... nothing for about 10 minutes
08:15:59: device requested OTA
08:16:02: device requested OTA
08:16:03: goes into the loop with ezspTrustCenterJoinHandler()

[2024-07-07 08:01:25] debug:    zh:ember:ezsp: <=== [FRAME: ID=89:"INCOMING_ROUTE_RECORD_HANDLER" Seq=6 Len=20]
[2024-07-07 08:01:25] debug:    zh:ember:ezsp: ezspIncomingRouteRecordHandler(): callback called with: [source=24132], [sourceEui=0x059731fffe23ac1f], [lastHopLqi=192], [lastHopRssi=-52], [relayCount=1], [relayList=5246]
[2024-07-07 08:01:25] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-07-07 08:01:25] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=7]
[2024-07-07 08:01:25] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=7 frmNum=6] Added to rxQueue
[2024-07-07 08:01:25] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=7]
[2024-07-07 08:01:25] debug:    zh:ember:ezsp: <=== [FRAME: ID=69:"INCOMING_MESSAGE_HANDLER" Seq=6 Len=32]
[2024-07-07 08:01:25] debug:    zh:ember:ezsp: ezspIncomingMessageHandler(): callback called with: [type=UNICAST], [apsFrame={"profileId":260,"clusterId":1,"sourceEndpoint":1,"destinationEndpoint":1,"options":256,"groupId":0,"sequence":32}], [lastHopLqi=192], [lastHopRssi=-52], [sender=24132], [bindingIndex=255], [addressIndex=255], [messageContents=187d0a21002086]
[2024-07-07 08:01:25] debug:    zh:controller: Received payload: clusterID=1, address=24132, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=192, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":125,"commandIdentifier":10},"payload":[{"attrId":33,"dataType":32,"attrData":134}],"command":{"ID":10,"name":"report","parameters":[{"name":"attrId","type":33},{"name":"dataType","type":32},{"name":"attrData","type":1000}]}}
[2024-07-07 08:01:25] debug:    z2m: Received Zigbee message from 'problem_sensor_C', type 'attributeReport', cluster 'genPowerCfg', data '{"batteryPercentageRemaining":134}' from endpoint 1 with groupID 0
[2024-07-07 08:01:25] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/problem_sensor_C', payload '{"ac_status":false,"battery":67,"battery_defect":false,"battery_low":false,"contact":true,"last_seen":"2024-07-07T06:01:25.582Z","linkquality":192,"restore_reports":false,"supervision_reports":false,"tamper":false,"test":false,"trouble":false,"update":{"installed_version":-1,"latest_version":-1,"state":"idle"},"update_available":null}'
[2024-07-07 08:01:27] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-07-07 08:01:27] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=7]
[2024-07-07 08:01:27] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=7 frmNum=7] Added to rxQueue
[2024-07-07 08:01:27] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=0]
[2024-07-07 08:05:46] debug:    z2m: Received Zigbee message from 'problem_sensor_C', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
[2024-07-07 08:05:46] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/problem_sensor_C', payload '{"ac_status":false,"battery":67,"battery_defect":false,"battery_low":false,"contact":true,"last_seen":"2024-07-07T06:05:46.251Z","linkquality":192,"restore_reports":false,"supervision_reports":false,"tamper":false,"test":false,"trouble":false,"update":{"installed_version":-1,"latest_version":-1,"state":"idle"},"update_available":null}'
[2024-07-07 08:05:46] debug:    z2m: Device 'problem_sensor_C' requested OTA
[2024-07-07 08:05:46] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-07-07 08:05:46] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0]
[2024-07-07 08:05:46] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0 frmNum=4] Added to rxQueue
[2024-07-07 08:05:46] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=5]
[2024-07-07 08:05:46] debug:    zh:ember:ezsp: <=== [FRAME: ID=89:"INCOMING_ROUTE_RECORD_HANDLER" Seq=55 Len=20]
[2024-07-07 08:05:46] debug:    zh:ember:ezsp: ezspIncomingRouteRecordHandler(): callback called with: [source=7367], [sourceEui=0xa4c138ef68981106], [lastHopLqi=216], [lastHopRssi=-46], [relayCount=1], [relayList=16716]
[2024-07-07 08:05:46] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-07-07 08:05:46] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0]
[2024-07-07 08:05:46] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0 frmNum=5] Added to rxQueue
[2024-07-07 08:05:46] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=6]
[2024-07-07 08:05:46] debug:    zh:ember:ezsp: <=== [FRAME: ID=69:"INCOMING_MESSAGE_HANDLER" Seq=55 Len=39]
[2024-07-07 08:05:46] debug:    zh:ember:ezsp: ezspIncomingMessageHandler(): callback called with: [type=UNICAST], [apsFrame={"profileId":260,"clusterId":25,"sourceEndpoint":1,"destinationEndpoint":1,"options":320,"groupId":0,"sequence":34}], [lastHopLqi=192], [lastHopRssi=-52], [sender=24132], [bindingIndex=255], [addressIndex=255], [messageContents=017e01017c117732190000010100]
[2024-07-07 08:05:46] debug:    zh:controller: Received payload: clusterID=25, address=24132, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=192, frame={"header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":0,"disableDefaultResponse":false,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":126,"commandIdentifier":1},"payload":{"fieldControl":1,"manufacturerCode":4476,"imageType":12919,"fileVersion":16777241},"command":{"ID":1,"response":2,"parameters":[{"name":"fieldControl","type":32},{"name":"manufacturerCode","type":33},{"name":"imageType","type":33},{"name":"fileVersion","type":35}],"name":"queryNextImageRequest"}}
[2024-07-07 08:05:49] debug:    zh:ember:ezsp: <=== [FRAME: ID=69:"INCOMING_MESSAGE_HANDLER" Seq=58 Len=39]
[2024-07-07 08:05:49] debug:    zh:ember:ezsp: ezspIncomingMessageHandler(): callback called with: [type=UNICAST], [apsFrame={"profileId":260,"clusterId":25,"sourceEndpoint":1,"destinationEndpoint":1,"options":320,"groupId":0,"sequence":35}], [lastHopLqi=192], [lastHopRssi=-52], [sender=24132], [bindingIndex=255], [addressIndex=255], [messageContents=017f01017c117732190000010100]
[2024-07-07 08:05:49] debug:    zh:controller: Received payload: clusterID=25, address=24132, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=192, frame={"header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":0,"disableDefaultResponse":false,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":127,"commandIdentifier":1},"payload":{"fieldControl":1,"manufacturerCode":4476,"imageType":12919,"fileVersion":16777241},"command":{"ID":1,"response":2,"parameters":[{"name":"fieldControl","type":32},{"name":"manufacturerCode","type":33},{"name":"imageType","type":33},{"name":"fileVersion","type":35}],"name":"queryNextImageRequest"}}
[2024-07-07 08:05:49] debug:    z2m: Received Zigbee message from 'problem_sensor_C', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
[2024-07-07 08:05:49] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/problem_sensor_C', payload '{"ac_status":false,"battery":67,"battery_defect":false,"battery_low":false,"contact":true,"last_seen":"2024-07-07T06:05:49.235Z","linkquality":192,"restore_reports":false,"supervision_reports":false,"tamper":false,"test":false,"trouble":false,"update":{"installed_version":-1,"latest_version":-1,"state":"idle"},"update_available":null}'
[2024-07-07 08:05:49] debug:    z2m: Device 'problem_sensor_C' requested OTA
[2024-07-07 08:05:52] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-07-07 08:05:52] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=3]
[2024-07-07 08:05:52] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=3 frmNum=7] Added to rxQueue
[2024-07-07 08:05:52] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=0]
[2024-07-07 08:05:52] debug:    zh:ember:ezsp: <=== [FRAME: ID=69:"INCOMING_MESSAGE_HANDLER" Seq=58 Len=39]
[2024-07-07 08:05:52] debug:    zh:ember:ezsp: ezspIncomingMessageHandler(): callback called with: [type=UNICAST], [apsFrame={"profileId":260,"clusterId":25,"sourceEndpoint":1,"destinationEndpoint":1,"options":320,"groupId":0,"sequence":36}], [lastHopLqi=192], [lastHopRssi=-52], [sender=24132], [bindingIndex=255], [addressIndex=255], [messageContents=010001017c117732190000010100]
[2024-07-07 08:05:52] debug:    zh:controller: Received payload: clusterID=25, address=24132, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=192, frame={"header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":0,"disableDefaultResponse":false,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":0,"commandIdentifier":1},"payload":{"fieldControl":1,"manufacturerCode":4476,"imageType":12919,"fileVersion":16777241},"command":{"ID":1,"response":2,"parameters":[{"name":"fieldControl","type":32},{"name":"manufacturerCode","type":33},{"name":"imageType","type":33},{"name":"fileVersion","type":35}],"name":"queryNextImageRequest"}}
[2024-07-07 08:05:52] debug:    z2m: Received Zigbee message from 'problem_sensor_C', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
[2024-07-07 08:05:52] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/problem_sensor_C', payload '{"ac_status":false,"battery":67,"battery_defect":false,"battery_low":false,"contact":true,"last_seen":"2024-07-07T06:05:52.219Z","linkquality":192,"restore_reports":false,"supervision_reports":false,"tamper":false,"test":false,"trouble":false,"update":{"installed_version":-1,"latest_version":-1,"state":"idle"},"update_available":null}'
[2024-07-07 08:05:52] debug:    z2m: Device 'problem_sensor_C' requested OTA
[2024-07-07 08:05:55] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-07-07 08:05:55] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=3]
[2024-07-07 08:05:55] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=3 frmNum=0] Added to rxQueue
[2024-07-07 08:05:55] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=1]
[2024-07-07 08:05:55] debug:    zh:ember:ezsp: <=== [FRAME: ID=69:"INCOMING_MESSAGE_HANDLER" Seq=58 Len=39]
[2024-07-07 08:05:55] debug:    zh:ember:ezsp: ezspIncomingMessageHandler(): callback called with: [type=UNICAST], [apsFrame={"profileId":260,"clusterId":25,"sourceEndpoint":1,"destinationEndpoint":1,"options":320,"groupId":0,"sequence":37}], [lastHopLqi=192], [lastHopRssi=-52], [sender=24132], [bindingIndex=255], [addressIndex=255], [messageContents=010101017c117732190000010100]
[2024-07-07 08:05:55] debug:    zh:controller: Received payload: clusterID=25, address=24132, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=192, frame={"header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":0,"disableDefaultResponse":false,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":1,"commandIdentifier":1},"payload":{"fieldControl":1,"manufacturerCode":4476,"imageType":12919,"fileVersion":16777241},"command":{"ID":1,"response":2,"parameters":[{"name":"fieldControl","type":32},{"name":"manufacturerCode","type":33},{"name":"imageType","type":33},{"name":"fileVersion","type":35}],"name":"queryNextImageRequest"}}
[2024-07-07 08:05:55] debug:    z2m: Received Zigbee message from 'problem_sensor_C', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
[2024-07-07 08:05:55] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/problem_sensor_C', payload '{"ac_status":false,"battery":67,"battery_defect":false,"battery_low":false,"contact":true,"last_seen":"2024-07-07T06:05:55.203Z","linkquality":192,"restore_reports":false,"supervision_reports":false,"tamper":false,"test":false,"trouble":false,"update":{"installed_version":-1,"latest_version":-1,"state":"idle"},"update_available":null}'
[2024-07-07 08:05:55] debug:    z2m: Device 'problem_sensor_C' requested OTA
[2024-07-07 08:05:58] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-07-07 08:05:58] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=3]
[2024-07-07 08:05:58] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=3 frmNum=1] Added to rxQueue
[2024-07-07 08:05:58] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=2]
[2024-07-07 08:05:58] debug:    zh:ember:ezsp: <=== [FRAME: ID=69:"INCOMING_MESSAGE_HANDLER" Seq=58 Len=39]
[2024-07-07 08:05:58] debug:    zh:ember:ezsp: ezspIncomingMessageHandler(): callback called with: [type=UNICAST], [apsFrame={"profileId":260,"clusterId":25,"sourceEndpoint":1,"destinationEndpoint":1,"options":320,"groupId":0,"sequence":38}], [lastHopLqi=192], [lastHopRssi=-52], [sender=24132], [bindingIndex=255], [addressIndex=255], [messageContents=010201017c117732190000010100]
[2024-07-07 08:05:58] debug:    zh:controller: Received payload: clusterID=25, address=24132, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=192, frame={"header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":0,"disableDefaultResponse":false,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":2,"commandIdentifier":1},"payload":{"fieldControl":1,"manufacturerCode":4476,"imageType":12919,"fileVersion":16777241},"command":{"ID":1,"response":2,"parameters":[{"name":"fieldControl","type":32},{"name":"manufacturerCode","type":33},{"name":"imageType","type":33},{"name":"fileVersion","type":35}],"name":"queryNextImageRequest"}}
[2024-07-07 08:05:58] debug:    z2m: Received Zigbee message from 'problem_sensor_C', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
[2024-07-07 08:05:58] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/problem_sensor_C', payload '{"ac_status":false,"battery":67,"battery_defect":false,"battery_low":false,"contact":true,"last_seen":"2024-07-07T06:05:58.183Z","linkquality":192,"restore_reports":false,"supervision_reports":false,"tamper":false,"test":false,"trouble":false,"update":{"installed_version":-1,"latest_version":-1,"state":"idle"},"update_available":null}'
[2024-07-07 08:05:58] debug:    z2m: Device 'problem_sensor_C' requested OTA
[2024-07-07 08:15:59] debug:    zh:ember:ezsp: <=== [FRAME: ID=69:"INCOMING_MESSAGE_HANDLER" Seq=167 Len=39]
[2024-07-07 08:15:59] debug:    zh:ember:ezsp: ezspIncomingMessageHandler(): callback called with: [type=UNICAST], [apsFrame={"profileId":260,"clusterId":25,"sourceEndpoint":1,"destinationEndpoint":1,"options":320,"groupId":0,"sequence":40}], [lastHopLqi=192], [lastHopRssi=-52], [sender=24132], [bindingIndex=255], [addressIndex=255], [messageContents=010301017c117732190000010100]
[2024-07-07 08:15:59] debug:    zh:controller: Received payload: clusterID=25, address=24132, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=192, frame={"header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":0,"disableDefaultResponse":false,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":3,"commandIdentifier":1},"payload":{"fieldControl":1,"manufacturerCode":4476,"imageType":12919,"fileVersion":16777241},"command":{"ID":1,"response":2,"parameters":[{"name":"fieldControl","type":32},{"name":"manufacturerCode","type":33},{"name":"imageType","type":33},{"name":"fileVersion","type":35}],"name":"queryNextImageRequest"}}
[2024-07-07 08:15:59] debug:    z2m: Received Zigbee message from 'problem_sensor_C', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
[2024-07-07 08:15:59] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/problem_sensor_C', payload '{"ac_status":false,"battery":67,"battery_defect":false,"battery_low":false,"contact":true,"last_seen":"2024-07-07T06:15:59.456Z","linkquality":192,"restore_reports":false,"supervision_reports":false,"tamper":false,"test":false,"trouble":false,"update":{"installed_version":-1,"latest_version":-1,"state":"idle"},"update_available":null}'
[2024-07-07 08:15:59] debug:    z2m: Device 'problem_sensor_C' requested OTA
[2024-07-07 08:16:02] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-07-07 08:16:02] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0]
[2024-07-07 08:16:02] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0 frmNum=6] Added to rxQueue
[2024-07-07 08:16:02] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=7]
[2024-07-07 08:16:02] debug:    zh:ember:ezsp: <=== [FRAME: ID=69:"INCOMING_MESSAGE_HANDLER" Seq=167 Len=39]
[2024-07-07 08:16:02] debug:    zh:ember:ezsp: ezspIncomingMessageHandler(): callback called with: [type=UNICAST], [apsFrame={"profileId":260,"clusterId":25,"sourceEndpoint":1,"destinationEndpoint":1,"options":320,"groupId":0,"sequence":41}], [lastHopLqi=192], [lastHopRssi=-52], [sender=24132], [bindingIndex=255], [addressIndex=255], [messageContents=010401017c117732190000010100]
[2024-07-07 08:16:02] debug:    zh:controller: Received payload: clusterID=25, address=24132, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=192, frame={"header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":0,"disableDefaultResponse":false,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":4,"commandIdentifier":1},"payload":{"fieldControl":1,"manufacturerCode":4476,"imageType":12919,"fileVersion":16777241},"command":{"ID":1,"response":2,"parameters":[{"name":"fieldControl","type":32},{"name":"manufacturerCode","type":33},{"name":"imageType","type":33},{"name":"fileVersion","type":35}],"name":"queryNextImageRequest"}}
[2024-07-07 08:16:02] debug:    z2m: Received Zigbee message from 'problem_sensor_C', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
[2024-07-07 08:16:02] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/problem_sensor_C', payload '{"ac_status":false,"battery":67,"battery_defect":false,"battery_low":false,"contact":true,"last_seen":"2024-07-07T06:16:02.440Z","linkquality":192,"restore_reports":false,"supervision_reports":false,"tamper":false,"test":false,"trouble":false,"update":{"installed_version":-1,"latest_version":-1,"state":"idle"},"update_available":null}'
[2024-07-07 08:16:02] debug:    z2m: Device 'problem_sensor_C' requested OTA
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0]
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0 frmNum=7] Added to rxQueue
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=0]
[2024-07-07 08:16:03] debug:    zh:ember:ezsp: <=== [FRAME: ID=36:"TRUST_CENTER_JOIN_HANDLER" Seq=167 Len=19]
[2024-07-07 08:16:03] debug:    zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=61025]
[2024-07-07 08:16:03] debug:    zh:controller: Device '0x059731fffe23ac1f' joined
[2024-07-07 08:16:03] debug:    zh:controller: Device '0x059731fffe23ac1f' accepted by handler
[2024-07-07 08:16:03] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/problem_sensor_C', payload '{"ac_status":false,"battery":67,"battery_defect":false,"battery_low":false,"contact":true,"last_seen":"2024-07-07T06:16:03.659Z","linkquality":192,"restore_reports":false,"supervision_reports":false,"tamper":false,"test":false,"trouble":false,"update":{"installed_version":-1,"latest_version":-1,"state":"idle"},"update_available":null}'
[2024-07-07 08:16:03] debug:    zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0]
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0 frmNum=2] Added to rxQueue
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=3]
[2024-07-07 08:16:03] debug:    zh:ember:ezsp: <=== [FRAME: ID=36:"TRUST_CENTER_JOIN_HANDLER" Seq=167 Len=19]
[2024-07-07 08:16:03] debug:    zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=61025]
[2024-07-07 08:16:03] debug:    zh:controller: Device '0x059731fffe23ac1f' joined
[2024-07-07 08:16:03] debug:    zh:controller: Device '0x059731fffe23ac1f' accepted by handler
[2024-07-07 08:16:03] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/problem_sensor_C', payload '{"ac_status":false,"battery":67,"battery_defect":false,"battery_low":false,"contact":true,"last_seen":"2024-07-07T06:16:03.666Z","linkquality":192,"restore_reports":false,"supervision_reports":false,"tamper":false,"test":false,"trouble":false,"update":{"installed_version":-1,"latest_version":-1,"state":"idle"},"update_available":null}'
[2024-07-07 08:16:03] debug:    zh:controller: Not interviewing '0x059731fffe23ac1f', completed 'true', in progress 'false'

Before 08:01:25, did the device do any OTA requests?
Could you share the log from 08:01:25 to 08:16:03, I'm especially interested if you see lines like: Responded to OTA request of

Before 08:01:25, did the device do any OTA requests?

Yes. Clusters of 10 requests every 10 minutes, like clockwork. There's something very interesting: the last OTA request (at 08:16:02) is the 4th in the cluster that started at 08:15:59 (there aren't 10 requests as in the prior occasions at 8:05, 7:55, 7:45...). Then (after this 4th OTA request) the misbehavior with the ezspTrustCenterJoinHandler() begins. I have other Ikea battery-powered devices and I see the OTA request behavior is partially consistent - e.g. water leak detector has the same 10 requests every 10 minutes, but light switches don't.

Could you share the log from 08:01:25 to 08:16:03, I'm especially interested if you see lines like: Responded to OTA request of

No such messages, neither before 08:01:25, nor after. Also, the only log entries specific to this device between 08:01:25 and 08:16:03 is the OTA check-in at 08:05, which seems in line to the prior things (exactly 10 minutes from the previous one, exactly 10 requests). This is the log at the critical moment - you can see there are just two seemingly unrelated messages between the OTA request and the ezspTrustCenterJoinHandler() thing.

[2024-07-07 08:16:02] debug:    z2m: Device 'problem_sensor_C' requested OTA
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0]
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0 frmNum=7] Added to rxQueue
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=0]
[2024-07-07 08:16:03] debug:    zh:ember:ezsp: <=== [FRAME: ID=89:"INCOMING_ROUTE_RECORD_HANDLER" Seq=167 Len=20]
[2024-07-07 08:16:03] debug:    zh:ember:ezsp: ezspIncomingRouteRecordHandler(): callback called with: [source=61314], [sourceEui=0x8189b6efffe19234], [lastHopLqi=180], [lastHopRssi=-55], [relayCount=1], [relayList=55678]
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0]
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0 frmNum=0] Added to rxQueue
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=1]
[2024-07-07 08:16:03] debug:    zh:ember:ezsp: <=== [FRAME: ID=89:"INCOMING_ROUTE_RECORD_HANDLER" Seq=167 Len=20]
[2024-07-07 08:16:03] debug:    zh:ember:ezsp: ezspIncomingRouteRecordHandler(): callback called with: [source=61314], [sourceEui=0x8189b6efffe19234], [lastHopLqi=180], [lastHopRssi=-55], [relayCount=1], [relayList=55678]
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA]
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0]
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=0 frmNum=1] Added to rxQueue
[2024-07-07 08:16:03] debug:    zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=2]
[2024-07-07 08:16:03] debug:    zh:ember:ezsp: <=== [FRAME: ID=36:"TRUST_CENTER_JOIN_HANDLER" Seq=167 Len=19]
[2024-07-07 08:16:03] debug:    zh:ember:ezsp: ezspTrustCenterJoinHandler(): callback called with: [newNodeId=24132], [newNodeEui64=0x059731fffe23ac1f], [status=STANDARD_SECURITY_SECURED_REJOIN], [policyDecision=NO_ACTION], [parentOfNewNodeId=61314]
[2024-07-07 08:16:03] debug:    zh:controller: Device '0x059731fffe23ac1f' joined
[2024-07-07 08:16:03] debug:    zh:controller: Device '0x059731fffe23ac1f' accepted by handler
[2024-07-07 08:16:03] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/problem_sensor_C', payload '{"ac_status":false,"battery":67,"battery_defect":false,"battery_low":false,"contact":true,"last_seen":"2024-07-07T06:16:03.659Z","linkquality":192,"restore_reports":false,"supervision_reports":false,"tamper":false,"test":false,"trouble":false,"update":{"installed_version":-1,"latest_version":-1,"state":"idle"},"update_available":null}'

Should I disable the OTA cluster binding and see what happens?

Interesting, Ota cluster isn't even bound on these devices. I checked on a few apart from those that I am using for testing. I now have 4 sensors with fresh batteries. Two have Ota and manuSpecificIkeaUnknown bound, two only have Ota bound (in addition to the default GenPollCtrl and PowerCfg). Let's see if this changes anything.

OK... very interesting. I now DO get some "responded to OTA request of ... with 'NO_IMAGE_AVAILABLE'". @Koenkk my statement a couple of posts above that there's no such message referred to the old logs from ~4 days ago.

The first occurrence of this message is a few hours ago; was there some recent change in the Z2M "repository" that is used for OTA? Unfortunately my logs got rolled over, so the earliest I have is from a few hours ago.

Other behaviors seem identical:

on a 'grep -i OTA log.log' => 10 log entries (it's actually 5x2 = 5 times of "received zigbee message... type 'commandQueryNextImageRequest'" and 5 times "device ... requested OTA") from each device every 10 minutes
these messages come from all devices, regardless of whether they have the Ota cluster bound or not

Another interesting element:

the "responded to OTA request ... NO_IMAGE_AVAILABLE" seems to only arrive on the first burst of OTA requests, exactly 65 seconds after the last pair of "commandQuery..." and "requested OTA" in that respective burst
it does NOT arrive on the next OTA call (10 minutes later) or on subsequent ones - only arrives once per device

grep -i ota log.log | grep problem_sensor_D

llog.log:[2024-07-12 16:49:03] debug:    z2m: Received Zigbee message from 'problem_sensor_D', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
log.log:[2024-07-12 16:49:03] debug:    z2m: Device 'problem_sensor_D' requested OTA
log.log:[2024-07-12 16:49:06] debug:    z2m: Received Zigbee message from 'problem_sensor_D', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
log.log:[2024-07-12 16:49:06] debug:    z2m: Device 'problem_sensor_D' requested OTA
log.log:[2024-07-12 16:49:09] debug:    z2m: Received Zigbee message from 'problem_sensor_D', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
log.log:[2024-07-12 16:49:09] debug:    z2m: Device 'problem_sensor_D' requested OTA
log.log:[2024-07-12 16:49:12] debug:    z2m: Received Zigbee message from 'problem_sensor_D', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
log.log:[2024-07-12 16:49:12] debug:    z2m: Device 'problem_sensor_D' requested OTA
log.log:[2024-07-12 16:49:15] debug:    z2m: Received Zigbee message from 'problem_sensor_D', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
log.log:[2024-07-12 16:49:15] debug:    z2m: Device 'problem_sensor_D' requested OTA
log.log:[2024-07-12 16:50:20] debug:    z2m: Responded to OTA request of 'problem_sensor_D' with 'NO_IMAGE_AVAILABLE'
log.log:[2024-07-12 16:59:15] debug:    z2m: Received Zigbee message from 'problem_sensor_D', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
log.log:[2024-07-12 16:59:15] debug:    z2m: Device 'problem_sensor_D' requested OTA
log.log:[2024-07-12 16:59:18] debug:    z2m: Received Zigbee message from 'problem_sensor_D', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
log.log:[2024-07-12 16:59:18] debug:    z2m: Device 'problem_sensor_D' requested OTA
log.log:[2024-07-12 16:59:21] debug:    z2m: Received Zigbee message from 'problem_sensor_D', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
log.log:[2024-07-12 16:59:21] debug:    z2m: Device 'problem_sensor_D' requested OTA
log.log:[2024-07-12 16:59:24] debug:    z2m: Received Zigbee message from 'problem_sensor_D', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
log.log:[2024-07-12 16:59:24] debug:    z2m: Device 'problem_sensor_D' requested OTA
log.log:[2024-07-12 16:59:27] debug:    z2m: Received Zigbee message from 'problem_sensor_D', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":1,"fileVersion":16777241,"imageType":12919,"manufacturerCode":4476}' from endpoint 1 with groupID 0
log.log:[2024-07-12 16:59:27] debug:    z2m: Device 'problem_sensor_D' requested OTA

About 24h later - of the 4 sensors where I replaced the batteries, 2 are now dead, and 2 are still functional. These are partially different from those that I tested with last time, to avoid the risk of a broken sensor completely messing things up.

Funny enough, those which are still working are those NOT using Ikea Ladda batteries.

Also funny (not), the two sensors that failed have zero log entries in the last 3-4 hours (that's as far back as my logs go, they seem to roll over when hitting a certain size.). I find that suspicious, as I think the sensors were shown as online in Z2M (despite the multi-hour delay in last_seen), yet they were de facto off the network.

Detailed status below: sensor A - functional as a sensor, but not reporting into Z2M

last_seen ~18h ago
LED blinking on open/close, but not updating state in Z2M
Ota cluster bound, manuSpecificIkeaUnknown cluster not bound
battery removed & reinserted => back to normal
no log entries in the last 7h

sensor B - fully functional, updating in Z2M

last seen 5 minutes ago
LED blinking on open/close, state updates fine in Z2M
Ota cluster bound, manuSpecificIkeaUnknown specific cluster not bound
OTA requests every 10 minutes; only one "Responded to OTA... with NO_IMAGE_AVAILABLE" about 2h ago

sensor C - completely failed

last seen ~11h ago
LED not blinking on open/close, no state updates in Z2M
Ota cluster not bound, manuSpecificIkeaUnknown specific cluster bound
battery removed & reinserted => back to normal
no log entries in the last 7h

sensor D - fully functional, updating in Z2M

last seen 5 minutes ago
LED blinking on open/close, state updates fine in Z2M
Ota cluster not bound, manuSpecificIkeaUnknown specific cluster bound
OTA requests every 10 minutes; only one "Responded to OTA... with NO_IMAGE_AVAILABLE" about 1.5h ago

Do the devices also fail when you put them very close to the coordinator and re-pair them there (such that they have a direct connection)?

Do the devices also fail when you put them very close to the coordinator and re-pair them there (such that they have a direct connection)?

I would say historically yes. I have one in the same room as the coordinator, and that one wasn't spared of the misbehaviour. I will swap its battery today and re-pair to the coordinator to be certain. At the moment, from my 4 test sensors, none are paired directly to the Coordinator (A and D are paired to one smartplug, B and C to another one, both relatively close to them (<5m)).

Status update about 14h since my prior post: of the 4 sensors, 3 are working (A, B, and C). Sensor D (which was working last time) is now malfunctioning:

LED blinks on open/close
State doesn't update in Z2M on open/close (stays "contact: true" even if it isn't)
Device shows as 'online' in Z2M, with last_seen ~9h ago
no Z2M log entries (oldest I still have is about 6h ago, so I guess after the device went missing)
removing/reinserting the battery brought it back into the network

Swapped batteries on 3 more sensors (call them D, E, and F) and re-paired; D and E stayed connected to the Coordinator, F decided to go to a different router, with a much worse LQI, for some reason, even if the Coordinator was the only device to permit joining while I was re-pairing them one by one.

just wanted to chime in and get involved with this thread, same issue with me, putting a new battery in brings the sensor back up. Sowing 100% battery in Z2MQTT but sensor not reporting any changes.

That’s not the described issue here. The battery replacement fixes the issue temporarily.

8h later: sensors A, B, and D (which were fine at the previous check) are now all gone "away". LEDs blink when doors/windows are opened, but no status update in Z2M. Same log behaviour - multiple OTA requests (5 requests = 10 messages every 10 minutes) and then the device suddenly disappears. Sample excerpt from logs after it disappeared:

[2024-07-14 14:14:15] debug:    z2m: Device 'problem_sensor_A' announced itself
[2024-07-14 14:14:15] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_A","ieee_address":"0x051231fffe8c35ed"},"type":"device_announce"}'
[2024-07-14 14:14:16] debug:    z2m: Device 'problem_sensor_A' announced itself
[2024-07-14 14:14:16] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_A","ieee_address":"0x051231fffe8c35ed"},"type":"device_announce"}'
[2024-07-14 14:14:18] debug:    z2m: Retrieving state of 'problem_sensor_A' after reconnect

Interestingly, if I grep for announce and reconnect, there are many more "device_announce" messages than "reconnect" ones. The device_announce seems to occur every 17 seconds, in batches of 3 messages (these likely correspond to the three rapid updates of last_seen, if you watch the state tab in Z2M), while the "retrieving state.. after reconnect" seems to be rarer. In a 30-minute interval, there are 192 entries of device_announce, and 77 "retrieving state... after reconnect".

@9shearer but what if they are paired directly to the coordinator?

@9shearer but what if they are paired directly to the coordinator?

2 of the 3 additional devices (sensors D E F) I connected 1.5 days ago are now gone. One of these was connected to the coordinator according to Z2M map, the other wasn't. For those two devices, the only log messages I have (unfortunately, the logs got rolled over and I can only look a few hours back) are "passive device ... last seen 25.00 hours ago" and the corresponding MQTT publish for availability: offline. These two sets of messages arrived within ~6 minutes of each other (the two devices were brought into the network at about the same time, roughly 35 hours before they went offline). One of them still blinks, but no update into Z2M, second one doesn't even blink (likely battery is dead), third one still works.

For the 3rd sensor (the one that still works), I see the "good" pattern of OTA (received Zigbee message ... type 'commandQueryNextImageRequest', cluster 'genOta'; device... requested OTA) - 5 such pairs every 10 minutes. No "no_image_available" in the last few hours. Sensor works normally (blinks and updates in Z2M) and was (and is) connected to the Coordinator.

Last surviving sensor mentioned above is now misbehaving (about 2 days after being connected): It is paired directly to the coordinator, and the behaviour is very similar to the others. When I checked up on it, it had a "last_seen" about 7h ago. I think I somehow resurrected it by opening the respective door, which caused the last_seen to update, but not the actual state (open/closed). It is now in the loop of announcing itself, which will happen until the battery dies (or I remove / reinsert it which brings it back to normal for a day or two). The LED on it still works normally, blinking when the door is opened/closed.

To your earlier question @Koenkk , there are still many more "device_announce" than "retrieving state..." messages (output of "grep problem_sensor_E log.log | egrep -e device_announce -e reconnect" below), even if it is connected directly to the coordinator:

[2024-07-16 19:17:50] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:17:52] debug:    z2m: Retrieving state of 'problem_sensor_E' after reconnect
[2024-07-16 19:18:07] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:18:09] debug:    z2m: Retrieving state of 'problem_sensor_E' after reconnect
[2024-07-16 19:18:25] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:18:27] debug:    z2m: Retrieving state of 'problem_sensor_E' after reconnect
[2024-07-16 19:18:42] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:18:44] debug:    z2m: Retrieving state of 'problem_sensor_E' after reconnect
[2024-07-16 19:18:59] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:19:01] debug:    z2m: Retrieving state of 'problem_sensor_E' after reconnect
[2024-07-16 19:19:16] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:19:17] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:19:19] debug:    z2m: Retrieving state of 'problem_sensor_E' after reconnect
[2024-07-16 19:19:34] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:19:36] debug:    z2m: Retrieving state of 'problem_sensor_E' after reconnect
[2024-07-16 19:19:52] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:19:52] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:19:53] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:19:55] debug:    z2m: Retrieving state of 'problem_sensor_E' after reconnect
[2024-07-16 19:20:43] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:20:44] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:20:45] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:20:45] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:20:47] debug:    z2m: Retrieving state of 'problem_sensor_E' after reconnect
[2024-07-16 19:21:26] info:     z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"problem_sensor_E","ieee_address":"0x051a31fffe2226c8"},"type":"device_announce"}'
[2024-07-16 19:21:28] debug:    z2m: Retrieving state of 'problem_sensor_E' after reconnect

@9shearer would you mind sharing the complete debug log from the working situation until the device announce loop?

Sorry for the belated response @Koenkk . I was pretty close to giving up - have plugged in again two sensors into Z2M and two others into ZHA in the meanwhile. Of the two sensors in Z2M, one is now completely offline, and the other is shown as "last seen 10h ago" (but no update if I open/close the respective door/window) . The two in ZHA work fine (3 days into it, so not calling it yet). I will stand up a separate Z2M network / instance tonight, with a couple of sensors for testing only. Will share the log here in a couple of days.

Ikea usually puts EmberZNet stack in their devices if I'm not mistaken, so, there might be something there. There are a couple of fixes regarding end devices in 8.0.0 from what I've glanced, which could be relevant here if these devices have an affected firmware version. Also, are you using EmberZNet adapters on both Z2M and ZHA instances?

that's as far back as my logs go, they seem to roll over when hitting a certain size

You should be able to find rotated logs (10MB) in your z2m data folder.

Ikea usually puts EmberZNet stack in their devices if I'm not mistaken, so, there might be something there. There are a couple of fixes regarding end devices in 8.0.0 from what I've glanced, which could be relevant here if these devices have an affected firmware version. Also, are you using EmberZNet adapters on both Z2M and ZHA instances?

Both adapters (ZB Dongle-E) are using EmberZNet and firmware (flashed from darkxst/silabs) 7.4.3.0. Same behaviour on 7.4.2.0 though. How do I figure out whether the firmware on these Parasolls is affected? The ones I have is 1.0.19, build date 20230516. Neither ZHA, nor Z2M ever suggested any firmware upgrade.

that's as far back as my logs go, they seem to roll over when hitting a certain size

You should be able to find rotated logs (10MB) in your z2m data folder.

I know. The problem is that my main instance generates so much logging in debug mode, that the three files it keeps (log2.log, log1.log, log.log) only cover the last 3-4 hours.

I have a third adapter (also a ZB Dongle-E), flashed with 7.4.2.0, that I am struggling to set up a test instance with (same machine as the primary one). It simply refuses to start with:

[2024-07-22 18:47:52] info:     zh:ember:uart:ash: ======== ASH stopped ========
[2024-07-22 18:47:52] error:    zh:ember:uart:ash: Failed to init port with error Error: Error Resource temporarily unavailable Cannot lock port
[2024-07-22 18:47:52] error:    z2m: Error while starting zigbee-herdsman
[2024-07-22 18:47:52] error:    z2m: Failed to start zigbee
[2024-07-22 18:47:52] error:    z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
[2024-07-22 18:47:52] error:    z2m: Exiting...
[2024-07-22 18:47:52] error:    z2m: Error: Failed to start EZSP layer with status=HOST_FATAL_ERROR.
    at EmberAdapter.initEzsp (/app/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:889:19)
    at EmberAdapter.start (/app/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:2722:24)
    at Controller.start (/app/node_modules/zigbee-herdsman/src/controller/controller.ts:129:29)
    at Zigbee.start (/app/lib/zigbee.ts:63:27)
    at Controller.start (/app/lib/controller.ts:139:27)
    at start (/app/index.js:154:5)

Permissions on /dev/ttyACM1 on the docker host (because the ttyACM0 is the dongle mapped to the main instance) are 777, the host symlink in /dev/serial/by-id/... points correctly to ttyACM1, the device is mapped correctly to the container (visible as /dev/ttyACM0 in the container environment), and the dongle itself works (had it flashed with router firmware until yesterday). Went through the troubleshooting document mentioned in the error - can't find anything using /dev/ttyACM1, nor can I see anything else wrong.

Container config below:

  z2m-test:
    container_name: z2m-test
    image: koenkk/zigbee2mqtt
    restart: unless-stopped
    volumes:
      - /z2m-test/data:/app/data:z
      - /run/udev:/run/udev:ro
    ports:
      # Frontend port
      - 9999:8080
    devices:
      - /dev/ttyACM1:/dev/ttyACM0
    group_add:
      - dialout

Am I missing something obvious?

Koenkk / zigbee2mqtt