2025.12.0: On bootup strange ZHA message for Bellows Stick (NV3 interface not available in this firmware, please upgrade!)

[uschindler]

The problem

On startup of Home Assistant 2025.12.0 the ZHA integration (with a bellows stick, ) show the following warning. It did not happen in 2025.11.x and before, so this seems new. The used coordinator "Sonoff Zigbee 3.0 USB Dongle Plus V2" has the default firmware (as recommended by Sonoff for Home Assistant) and was therefore never updated. Do I need to update now with new ZHA version (I am afraid to do this as I need to use the web updater on another computer and I am afraid that my whole Zigbee network breaks or has to be re-learned with tens of devices)? The code showing this message is not new in bellows, it wa sadded long ago, so why does the warning only triggers in 2025.12.0?:

Logger: bellows.zigbee.repairs
Quelle: components/zha/__init__.py:185
Erstmals aufgetreten: 3. Dezember 2025 um 23:35:18 (2 Vorkommnisse)
Zuletzt protokolliert: 00:01:48

NV3 interface not available in this firmware, please upgrade!

What version of Home Assistant Core has the issue?

core-2025.12.0

What was the last working version of Home Assistant Core?

core-2025.11.3

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

config_entry-zha-01JFB5EYHD0QBN6KKT10EDA6PR.json

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

No response

[home-assistant]

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

---

Please make sure your report includes the following things:

1. Please enable ZHA debug logging, let it run for 10-15 minutes, and make sure to capture whatever problem you're having in the debug log. 2. Download diagnostics JSON for the ZHA Integration for the specific devices you're having problems with. 3. Any issues whatsoever with Tuya devices or device support requests in general need to be made in the ZHA quirks repo https://github.com/zigpy/zha-device-handlers/issues, not Core's issue tracker. 5. Fill out the issue template and include whether or not you're using a VM/Proxmox with USB passthrough, what addons you have installed, and so on.
   ZHA does not have low-level control over your network, the mesh is self-organizing. If you started having network issues in a specific release, the release probably didn't cause the issue. Check your environment for new sources of 2.4GHz interference and make sure you're using an extension cable, not placing the coordinator near SSDs and USB 3.0 ports, etc. Just because things worked in the past with a bad setup doesn't mean they'll keep working in the future.
   _{^{(message by IssueContext)}}

---

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

[uschindler]

I can provide debug logs for sure, but this issue happens only when booting up HASS and its ZHA integration, so I left them out.

[uschindler]

Is this related to the newly implemented get power info in bellows? The message seems to come from a try catch block around the code called from there to get maximum power of stick.

If this is the case it would be better to give more information WHAT exactly is missing in the stick's firmware. To me this requires no update of stick's firmware as I am not interested in power anyways (and i don't want any regulatory domain to limit power of my stick...). So please add context to the warning!

[puddly]

zigpy/bellows#702 will reduce the log level.

To me this requires no update of stick's firmware as I am not interested in power anyways

The manufacturer should include the NVRAM read/write component in their firmware no matter what. Without it, we cannot read/write the adapter's IEEE address arbitrarily and repairs such as fix_invalid_tclk_partner_ieee don't work. If they provide a newer firmware, you should use it.

and i don't want any regulatory domain to limit power of my stick...

This isn't used unless you are using the Connect ZBT-2 adapter or your adapter manufacturer implements our firmware extensions for this feature.

[uschindler]

Hi, thanks for the update! Well appreciated.

In the meantime I updated my stick to the latest firmware 8.0.2 provided by the "Sonoff Dongle Flasher Addon". The process of updating worked very well, so it was not so bad as expected because you were able to do it without removing the stick (the adon just disabled ZHA extension temporarily)! After reenabling, the message mentioned before disappeared. It now reports:

          "ezsp": {
            "chip_info": null,
            "stack_version": 14,
            "can_burn_userdata_custom_eui64": true,
            "can_rewrite_custom_eui64": true,
            "flow_control": null,
            "ezspVersion": 14
          }

(previosly it was ezspVersion 8 and can_rewrite_custom_eui64 was false. Full diagnostic data after update: config_entry-zha-01JFB5EYHD0QBN6KKT10EDA6PR-after-update.json

I greatly appreciate that the message is now debug level, because most people use the SONOFF ZBDongle E and use the default firmware as shipped by them.

Anyways: It would be good to maybe modify the message (also in debug mode) a bit to actually say what was tried. The problem is that theres no stack trace in the logs, as t is only a repair and the message is the same for multiple NV3 interface accesses).

Uwe

[jhemak]

I am getting this error with an Aeotec Zi-Stick on 2025.12.1 ... is that still expected? I do not know of a way to update the firmware on this controller.

[TheJulianJES]

The change to reduce the log level hasn't landed in 2025.12.1 yet. There'll be no real functional changes when it does land, you just won't see the message anymore by default.

[chrismcca]

Still seeing this in 2025.12.3 with HubZ dongle. I guess I can just ignore it. Still logging as WARNING.