core Brand new SML004 Philips Hue Outdoor Motion Sensor from Signify Netherlands unstable on ZHA

The problem

My new SML004 Philips Hue Outdoor Motion Sensor from Signify Netherlands appears to join the Zigbee network successfully but then immediately becomes unavailable then rejoins until eventually becoming permanently unavailable. The behavior is the same as described in issue #102008.

I have an SML002 that is up and running with the TRUST_CENTRE_POLICY fix described by Puddly in issue #89311

What version of Home Assistant Core has the issue?

core-2024.2.3

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

Philips Hue on ZHA

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

Feb 26 '24 01:02 hageson

Hey there @dmulcahey, @adminiuga, @puddly, @thejulianjes, mind taking a look at this issue as it has been labeled with an integration (zha) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of zha can trigger bot actions by commenting:

@home-assistant close Closes the issue.
@home-assistant rename Awesome new title Renames the issue.
@home-assistant reopen Reopen the issue.
@home-assistant unassign zha Removes the current integration label and assignees on the issue, add the integration domain after the command.
@home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
@home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

zha documentation zha source _{^{(message by IssueLinks)}}

Feb 26 '24 01:02 home-assistant[bot]

I have an SML002 that is up and running with the TRUST_CENTRE_POLICY fix described by Puddly in issue https://github.com/home-assistant/core/issues/89311

The second-gen motion sensors (SML003 and SML004) should work without any issues. Changing the trust center policy isn't needed for these. Chip and firmware are completely different compared to the 1st gen motion sensors.

You didn't fill-out the issue template. Please attach ZHA integration diagnostic information (can be downloaded by clicking on Integrations -> ZHA - > three dots). Also, attach diagnostic information for the motion sensor (can be downloaded on the device page). Debug logs from when the device becomes unavailable are also helpful.

Did you previously migrate your network from another coordinator to your EZSP coordinator?

Feb 26 '24 01:02 TheJulianJES

In preparing to re-add the SML004 to my network this morning I noticed that a new version of the OS was available so I installed that. When I then added the device, the behaviour was different from yesterday. These are the series of text boxes I think I observed:

Interviewing (NWK: Oxb42d - I don't know what NWK means or if it's useful info but I did notice that it changed with later text boxes. See below)
Initializing (I think)
Configuring (NWK: Ox1dea)
Ready to use. It allowed me to identify the location. I didn't change the name. I noticed that the device icons were in the faded blue color, which I believe indicates that the entities are unavailable. But then this text box suddenly disappeared, and it went back to Configuring.
Configuring (NWK: Oxfa18)
Configuring (NWK: Ox960a)

These steps happened in fairly quick succession. The information box documenting the last step persisted:

The device was in the device list so it looked like a successful addition.

The entity icons are dark blue and therefore look like they are available, but the device does not appear on the network visualization and it isn't detecting occupancy changes, which is the whole point. Also, the "last seen" timestamp hasn't changed for over an hour now. Clearly, it isn't part of the network. And I'm quite sure the entity states will eventually change to Unavailable.

I have attached the ZHA and device diagnostic information plus the log entries that show an error at about the right time - so I assume it is relevant. config_entry-zha-56a4df57acc1726fb11337aa68a37fe6.json Log entry showing error.txt zha-56a4df57acc1726fb11337aa68a37fe6-Signify Netherlands B.V. SML004-c003f58b197723c7327da5eabb7ce040.json

I'm happy to redo this and provide other or more detailed information if that will help you. But you will have to guide me since I am pretty much out of my depth.

Oh, and yes, I migrated from Raspberry PI 3 and Conbee II to Yellow - many months ago now.

Thanks for doing what you do.

Feb 26 '24 19:02 hageson

Could you also enable debug logging for the ZHA integration, reload it, and disable debug logging after two minutes? The startup log has useful info as well.

Feb 26 '24 19:02 puddly

As requested. home-assistant_zha_2024-02-26T19-50-20.495Z.log

Hopefully I did this right!

Feb 26 '24 19:02 hageson

From the logs:

2024-02-26 10:05:08.234 WARNING (MainThread) [bellows.zigbee.repairs] Fixing invalid TCLK partner IEEE [...] 2024-02-26 10:05:08.235 WARNING (MainThread) [bellows.zigbee.repairs] NV3 interface not available in this firmware, please upgrade!

It seems like you migrated your network multiple times and the IEEE on the Yellow was already changed once. You need to update the firmware version on the Yellow Zigbee module to fix that issue. On newer versions, the IEEE can be overwritten multiple times. Bellows/ZHA will do that on startup.

I think you should be able to use the "Silicon Labs Flasher" addon to flash new firmware.

Feb 26 '24 20:02 TheJulianJES

Oh OK. Thanks.

I wasn't aware of having migrated more than once but perhaps there was some trial and error.

I don't know how to upgrade the firmware on the Yellow Zigbee module. I imagine the information exists somewhere on the web though. Can you point me at something? Otherwise, not to worry, Google is my friend! And if all else fails I can ask the powers that be.

Feb 26 '24 20:02 hageson

I edited my comment shortly after posting to add additional information (doesn't show in notification emails):

I think you should be able to use the "Silicon Labs Flasher" addon to flash new firmware.

Feb 26 '24 20:02 TheJulianJES

Thanks for this.

I have installed the Flasher and now I need to supply the URL where the Flasher will find the firmware. But it isn't clear to me which file is the correct file. I have found what I think is the correct repository at: https://github.com/NabuCasa/silabs-firmware/tree/main/EmberZNet. Two of them seem likely candidates: https://github.com/NabuCasa/silabs-firmware/blob/main/EmberZNet/NabuCasa_Yellow_EZSP_v6.10.3.0_PA32_ncp-uart-hw_115200.gbl and https://github.com/NabuCasa/silabs-firmware/blob/main/EmberZNet/NabuCasa_Yellow_EZSP_v6.10.3.0_PA32_ncp-uart-hw_115200_ext.gbl. The only difference being the _ext at the end. Do you know whether one of these is the correct file? If so, which one?

I imagine it would not be a good thing to choose the wrong one!

Feb 27 '24 00:02 hageson

The flasher already comes with up-to-date firmware for your Zigbee module. All you need to do is disable ZHA, run the flasher, and start ZHA back up.

Feb 27 '24 00:02 puddly

Oh - so simple.

From the log: 2024-02-26 16:00:51 core-silabs-flasher universal_silabs_flasher.flasher[144] INFO Detected ApplicationType.EZSP, version '6.10.3.0 build 297' (6.10.3.0.297) at 115200 baudrate (bootloader baudrate 115200) NabuCasa_Yellow_EZSP_v7.3.1.0_PA32_ncp-uart-hw_115200.gbl [16:01:30] INFO: universal-silabs-flasher-up script exited with code 0

So I guess I am now up to date!

Thanks again.

Feb 27 '24 00:02 hageson

This morning, I removed the now unavailable SML004 that I added yesterday and re-added it. Unlike yesterday, the steps this time were a straightforward "Starting Interview", "Configuring", "Initializing" and "Device is ready to use". It is sensing occupancy and displaying illuminance changes, etc. 30 minutes later. It feels like it will continue working. I think it is fixed.

Thanks to Puddly and TheJulianJES

Feb 27 '24 20:02 hageson

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

May 27 '24 21:05 issue-triage-workflows[bot]

Everything continues to work flawlessly!

May 28 '24 18:05 hageson

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

Aug 26 '24 20:08 issue-triage-workflows[bot]