### The problem
**Note! Please keep this issue on topic and concerning only H…ue SML001 sensors becoming unavailable in ZHA.**
This has been split off from [https://github.com/home-assistant/core/issues/86231#issuecomment-1454922708](https://github.com/home-assistant/core/issues/86231#issuecomment-1454922708) at the request of @puddly.
Around 2 weeks ago I switched from a Philips Hue hub based setup (using the integration) to a ZHA one using the Sonoff-E dongle.
Previously the Hue hub based system worked great - I've had the system running for multiple years, and for 1 year in my current house, I had no known issues with devices dropping off the network. In that time I didn't know about or attempt to address issues with Zigbee interference and had the hub was in a very sub-optimal location.
I have 38 hue bulbs / lightstrips / playbars on this system with 14 SML001 motion sensors, 6 SML003 motion sensors and a handful of smart buttons. The house is 300m2 across 2 floors with brick & concrete construction (typical European construction).
Since moving to ZHA I'm dealing with (almost?) all SML001 devices disconnecting and becoming unavailabe. This often coincides with a change in motion state. The device will then be stuck in that state until I press the repair button and re-add the device in ZHA. I'm noticing it affect all SML001 devices, irrespective of location in the house.
The SML003 devices have no similar issues, I don't think I've noticed any times when an SML003 becomes unavailable, even when used in the same room as unstable SML001 devices.
The dongle is on a 2m USB2 shielded cable about 1m from floor height and connected to the USB2 port. HA OS is running on a Pi4 and is up to date.
So far I've tried the following things to fix the issue:
- moving the co-ordinator
- from a similar location to where the happy hue hub was to one more inline with the usual recommendations (higher up, away from sources of EMF, more central to the network, fewer solid walls between the coordinator and the network), but the position is still not optimum.
- changing to channel 20 (this is what the Hue hub was previously running on)
- I did this by making a backup in ZHA, modifying the json and migrating the coordinator to the backup, after restarting ZHA it shows the updated channel and I then manually reset all of the devices and re-pair. To reset the bulbs I re-pair to Hue hub using the serial number and then delete them from the Hue hub to put them back into a pairing state, so a lot of work!
- Changing to channel 25
- Used the same method as above
- I chose 25 after inspecting the Wifi channel usage using `wifi explorer` app and noticing that all of my 2.4 ghz traffic was on wifi channels 1-7 (I have an Eero Pro 6 mesh network which doesn't allow changing the wifi channes, but usually uses channel 1 for 2.4Ghz, the mesh network consists of 5 access points).
- I also only have 2 close neighbours so local Wifi traffic is minimal, usually I barely see any other wifi networks available to connet to other than mine.
- Shutting down the network when all devices are connected to force Zigbee to heal
- This didn't help, I saw dropoffs within 10 mins of bringing the network backup
- Changing the batteries in all of the devices.
- I read that Hue doesn't actually support rechargeable batteries, and I realised that my stable SML003 devices also had the stock batteries (since they were more recent purchases), so to test the hypothesis and eliminate batteries being the problem I purchased 30 Energizer max plus batteries and replaced all SML001 batteries. No changes.
- Interference from baby monitors
- I have 2 baby monitors in the house, I turned both off for a while, but still saw dropouts during this time.
I'm now at a loss about how to proceed. I've gone from a rock-solid Hue setup (I only migrated away to optimise speed of automations by having everything on one device with fewer intermediaries) to an un-usable ZHA setup - all of my lighting is automatic based on these motion sensors.
@TheJulianJes
You requested the following info in the thread I branched this issue from:
`sw_build_id` = `6.1.1.27575`
`current_file_version` = `1107323831`
I also have the following logs from when a sensor dropped off, the folowing are snippets form what seem to be key events, but I also attached the full log showing events just before and after the device becoming un-available.
The device which went offline is `0x9d47`
```log
2023-03-05 10:52:38.443 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame received sendUnicast: [<EmberStatus.SUCCESS: 0>, 200]
2023-03-05 10:52:38.444 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame received messageSentHandler: [<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 50546, EmberApsFrame(profileId=260, clusterId=768, sourceEndpoint=11, destinationEndpoint=11, options=<EmberApsOption.APS_OPTION_NONE: 0>, groupId=0, sequence=200), 73, <EmberStatus.DELIVERY_FAILED: 102>, b'']
2023-03-05 10:52:38.444 DEBUG (MainThread) [bellows.zigbee.application] Received messageSentHandler frame with [<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 50546, EmberApsFrame(profileId=260, clusterId=768, sourceEndpoint=11, destinationEndpoint=11, options=<EmberApsOption.APS_OPTION_NONE: 0>, groupId=0, sequence=200), 73, <EmberStatus.DELIVERY_FAILED: 102>, b'']
2023-03-05 10:52:38.446 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame received changeSourceRouteHandler: [0x470b, 0x009d, <Bool.false: 0>]
2023-03-05 10:52:38.446 DEBUG (MainThread) [bellows.zigbee.application] Received changeSourceRouteHandler frame with [0x470b, 0x009d, <Bool.false: 0>]
2023-03-05 10:52:38.447 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'74f8b1a9d42abcf5c480ad7e'
2023-03-05 10:52:38.447 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8070787e'
2023-03-05 10:52:38.450 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame received incomingRouteErrorHandler: [<EmberStatus.SOURCE_ROUTE_FAILURE: 169>, 0x9d47]
2023-03-05 10:52:38.450 DEBUG (MainThread) [bellows.zigbee.application] Received incomingRouteErrorHandler frame with [<EmberStatus.SOURCE_ROUTE_FAILURE: 169>, 0x9d47]
2023-03-05 10:52:38.450 DEBUG (MainThread) [bellows.zigbee.application] Processing route error: status=EmberStatus.SOURCE_ROUTE_FAILURE, nwk=0x9d47
```
Then one second later this happens:
```log
2023-03-05 10:52:38.935 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame received trustCenterJoinHandler: [0x9d47, 00:17:88:01:08:67:2d:c4, <EmberDeviceUpdate.STANDARD_SECURITY_UNSECURED_REJOIN: 3>, <EmberJoinDecision.DENY_JOIN: 2>, 0xddcd]
2023-03-05 10:52:38.935 DEBUG (MainThread) [bellows.zigbee.application] Received trustCenterJoinHandler frame with [0x9d47, 00:17:88:01:08:67:2d:c4, <EmberDeviceUpdate.STANDARD_SECURITY_UNSECURED_REJOIN: 3>, <EmberJoinDecision.DENY_JOIN: 2>, 0xddcd]
2023-03-05 10:52:38.974 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'47ffb1a90d2ad86f19888c2dabdd85495c82269fadd4bc7e'
2023-03-05 10:52:38.975 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8520dd7e'
2023-03-05 10:52:38.977 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame received incomingRouteRecordHandler: [0xddcd, 00:17:88:01:08:c6:1c:40, 192, -52, [0x4034]]
2023-03-05 10:52:38.978 DEBUG (MainThread) [bellows.zigbee.application] Received incomingRouteRecordHandler frame with [0xddcd, 00:17:88:01:08:c6:1c:40, 192, -52, [0x4034]]
2023-03-05 10:52:38.978 DEBUG (MainThread) [bellows.zigbee.application] Processing route record request: (0xddcd, 00:17:88:01:08:c6:1c:40, 192, -52, [0x4034])
2023-03-05 10:52:39.029 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'57ffb1a9702a522f9db92d2dabdd85499e4dea7660317e'
2023-03-05 10:52:39.029 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8610be7e'
2023-03-05 10:52:39.039 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame received trustCenterJoinHandler: [0x9d47, 00:17:88:01:08:67:2d:c4, <EmberDeviceUpdate.DEVICE_LEFT: 2>, <EmberJoinDecision.NO_ACTION: 3>, 0xddcd]
2023-03-05 10:52:39.040 DEBUG (MainThread) [bellows.zigbee.application] Received trustCenterJoinHandler frame with [0x9d47, 00:17:88:01:08:67:2d:c4, <EmberDeviceUpdate.DEVICE_LEFT: 2>, <EmberJoinDecision.NO_ACTION: 3>, 0xddcd]
2023-03-05 10:52:39.040 INFO (MainThread) [zigpy.application] Device 0x9d47 (00:17:88:01:08:67:2d:c4) left the network
2023-03-05 10:52:39.040 DEBUG (MainThread) [homeassistant.components.zha.core.device] [[0x9D47](https://github.com/home-assistant/core/issues/SML001)](https://SML001): Update device availability - device available: True - new availability: False - changed: True
2023-03-05 10:52:39.040 DEBUG (MainThread) [homeassistant.components.zha.core.device] [[0x9D47](https://github.com/home-assistant/core/issues/SML001)](https://SML001): Device availability changed and device became unavailable
```
Later in the logs (1second later) the device again joins and gets kicked off, you can find those in the attached [log file here](https://github.com/home-assistant/core/files/10913669/sml001-unavailable.log).
I also attached the Logbook entry for when the device went unavailable.
**Note! Please keep this issue on topic and concerning only Hue SML001 sensors becoming unavailable in ZHA.**
### What version of Home Assistant Core has the issue?
core-2023.3.1
### What was the last working version of Home Assistant Core?
_No response_
### What type of installation are you running?
Home Assistant OS
### Integration causing the issue
ZHA
### Link to integration documentation on our website
https://www.home-assistant.io/integrations/zha/
### Diagnostics information
[sml001-unavailable.log](https://github.com/home-assistant/core/files/10913707/sml001-unavailable.log)
<img width="511" alt="Screenshot 2023-03-07 at 20 14 40" src="https://user-images.githubusercontent.com/12051736/223543257-91bf7b46-7aa4-489e-a9f1-647b62213f0e.png">
### Example YAML snippet
_No response_
### Anything in the logs that might be useful for us?
_No response_
### Additional information
_No response_