Open jacme31 opened 1 year ago
mdeweerd
commented
12 months ago I just got several of these plugs too - same behavior.
For reference: HA forum discussion .
It indicates that this works with Z2M where it is declared in lidl.js .
I tested the Tuya Magic Spell - not working better.
mdeweerd
commented
12 months ago Here are some decodings of relevant packets from a sniffer log.
It's the device that is requesting to leave the network.
MattWestb
commented
12 months ago I have only fast looking and the device is getting the network key OK and then the coordinator is requesting and getting the Node Descriptor Request, OK (R22 device) and the device is requesting the same and is getting R22 so shall being OK. Then the device shall requesting updating the TC-Link key (R19 and higher is supporting it) but its not doing it so its policy is it must updating the TC-Link key => Leaving.
Must looking deeper of the flags and comparing with other device sniffs that is working OK.
PS Its one TELink choped devices so can being buggy.
MattWestb
commented
12 months ago By the way is the Ti coordinator running on updated firmware (2023) ?
mdeweerd
commented
12 months ago @MattWestb Thanks for checking!
It's not a TI coordinator for me - it's an EZSP.
I opened a topic to see if anybody has the way to update the EZSP: https://community.home-assistant.io/t/how-bellows-zigbee-repairs-nv3-interface-not-available-in-this-firmware-please-upgrade/635319 .
I've seen and add-on that seems to help with that, but not much of a procedure.
MattWestb
commented
12 months ago Im very sorry but its only 2 frames with key and both looks the same only network key and the sender is 0x000= and its .. . .
Frame 83: 73 bytes on wire (584 bits), 73 bytes captured (584 bits) on interface unknown, id 0
IEEE 802.15.4 Data, Dst: 0x0d6a, Src: 0x0000, Bad FCS
ZigBee Network Layer Data, Dst: 0x0d6a, Src: 0x0000
Frame Control Field: 0x0008, Frame Type: Data, Discover Route: Suppress Data
Destination: 0x0d6a
Source: 0x0000
Radius: 30
Sequence Number: 239
[Extended Source: TexasIns_00:01:6a:41:0c (00:12:4b:00:01:6a:41:0c)]
[Origin: 4]
ZigBee Application Support Layer Command
Frame Control Field: Command (0x21)
Counter: 206
ZigBee Security Header
Security Control Field: 0x30, Key Id: Key-Transport Key, Extended Nonce
Frame Counter: 552963
Extended Source: TexasIns_00:01:6a:41:0c (00:12:4b:00:01:6a:41:0c)
Message Integrity Code: f2f2bfe3
[Key: 5a6967426565416c6c69616e63653039]
[Key Label: ZigBeeAlliance09 Key]
Command Frame: Transport Key
Frame 282: 73 bytes on wire (584 bits), 73 bytes captured (584 bits) on interface unknown, id 0
IEEE 802.15.4 Data, Dst: 0x0d6a, Src: 0x0000, Bad FCS
ZigBee Network Layer Data, Dst: 0x0d6a, Src: 0x0000
Frame Control Field: 0x0008, Frame Type: Data, Discover Route: Suppress Data
Destination: 0x0d6a
Source: 0x0000
Radius: 30
Sequence Number: 188
[Extended Source: TexasIns_00:01:6a:41:0c (00:12:4b:00:01:6a:41:0c)]
[Origin: 4]
ZigBee Application Support Layer Command
Frame Control Field: Command (0x21)
Counter: 18
ZigBee Security Header
Security Control Field: 0x30, Key Id: Key-Transport Key, Extended Nonce
Frame Counter: 552964
Extended Source: TexasIns_00:01:6a:41:0c (00:12:4b:00:01:6a:41:0c)
Message Integrity Code: a3e26415
[Key: 5a6967426565416c6c69616e63653039]
[Key Label: ZigBeeAlliance09 Key]
Command Frame: Transport KeyHave you burning one new IEEE in the Silabs chip ?
Extended Source: TexasIns_00:01:6a:41:0c (00:12:4b:00:01:6a:41:0c)
MattWestb
commented
12 months ago The latest EZSP and RCP 7.3.x / 4.3.x can loading one software IEEE that is not burned in the chip (stored in the NVM3) but its no problem running older firmware that cant do it only if migrating to one other hardware if not having that support ZHA is burning one new IEEE in the chip and cant being reverted (with SWD flashing its possible then its in user data that cant being OTA flashed normally).
mdeweerd
commented
12 months ago Have you burning one new IEEE in the Silabs chip ?
Yes - I migrated from a CC2531.
An add-on I found to flash is: https://github.com/home-assistant/addons/tree/master/silabs_flasher .
MattWestb
commented
12 months ago Shall working OK i have not testing it as addon only before in veritual env. Try with different EZSP version if some is working OK. The 6.7.8.X is stable production and 6.10.X is candidate. All 6.8 and 6.9 is alpa and is not good for production. The 7.1.X is little beta and the same with 7.2.X and normally is 7.3.2 the best if having one MG21 device. Witch device is you using in your system is it any free firmware for it ?
mdeweerd
commented
12 months ago I have SonOFF ZBDongle-E to enable - it had v6.10.3 . I just made an update using the webflasher.
The Multiprotocol Add-on did not want to startup (did not find the port), so I have reboots the HAOS system (OS itself). It still complains about "Failed to connect, secondary seems unresponsive" .
Trying to find out what to do...
mdeweerd
commented
12 months ago I did not program the correct firmware, it was Zigbee FW with new version. After flashing the RCP version, the integration started. However I have lost all related entities.
The insturctions indicate:
If you had an existing ZHA setup, you will need to remove this entirely. > Make sure to backup your network first!
So I removed it using the UI and then the configuration as well, but after restoration I do not have the entities .. Kind of furious...
However, I could pair the TS011F
MattWestb
commented
12 months ago One very interesting question is the RCP using the original IEEE or the burned one from the CC2531 but now you shall also having the possibility changing it without burning the chip IF our Puddly have making all right. Then if its using the original IEEE i think ZHA is thinking its one new instance and do not reusing all old saved devices.
mdeweerd
commented
12 months ago It's using the TI IEEE address.
To recover entities (different than those I had), I:
Luckily I had an export of the critical devices in devices.csv with zha-toolkit which helped map the devices to their original entity names and locations.
MattWestb
commented
12 months ago If the IEEE was the same in the "new network" and the old backup its likely the frame counter was set to zero and the network was throwing all frames from the coordinator as replay attack.
Great that you is up and running after some hardware digging (its little different for code digging but its more my thing as code is yours) !!
jacme31
commented
12 months ago @MattWestb and @mdeweerd : Thank you very much for your investigation into this issue. I am not competent enough to understand all your exchanges in detail. It seems to me that I have generally understood from your analyzes and experiences that the problem came from the zigbee coordinator and that a new radio firmware could solve the problem. For my part I use an HA Yellow with the on-board radio chip:
"ezsp": {
"manufacturer": "Nabu Casa",
"board": "Yellow v1.2",
"version": "6.10.3.0 version 297",
"stack_version": 8,
"can_burn_userdata_custom_eui64": false,
"can_rewrite_custom_eui64": false
}I have no idea how this network firmware can be updated even though I saw the following links: https://github.com/home-assistant/addons/tree/master/silabs_flasher. https://github.com/NabuCasa/silabs-firmware/wiki/Flash-Silicon-Labs-radio-firmware-manually Generally speaking, I'm a little fearful, and I'd rather not use my new SAPZ devices than lose my network and have to re-pair all existing devices...
mdeweerd
commented
12 months ago If the IEEE was the same in the "new network" and the old backup its likely the frame counter was set to zero and the network was throwing all frames from the coordinator as replay attack.
I migrated many months ago already and the migration was flawless!
I think that changing to the RCP FW using the multiprotocol Add-on should also be don by initiating a migration rather than removing "everything" - the only issue being the port - ZHA might grab the port before the add-on does. So the trick would be to change the ZHA port to a bad port (currently by hacking) or disabling it until the add-on starts up I guess.
Great that you is up and running after some hardware digging (its little different for code digging but its more my thing as code is yours) !!
My things are HW and SW (I design HW boards and SW from FW to application level - I've also worked on design and verification of baseband ASICs for phones) !
However you noticed the Link key issue!
Generally speaking, I'm a little fearful, and I'd rather not use my new SAPZ devices than lose my network and have to re-pair all existing devices...
I'ld suggest you to stick with the Zigbee SW version.
Nabu Casa indicates there are no known issues with the current FW, but this is one!
https://skyconnect.home-assistant.io/firmware-update/
The add-on silabs-flasher seems to be an official method to update the key.
I'ld make sure to have a recent backup, then proceed with the upgrade (implies disabling - not removing - zha) and enable zha again. The network info is probably maintained and if not you can restore it. IMHO the only reason for the issues I had was that the documentation for the alternative code said to remove zha... . I did not have to repair the devices, but I did have to remap the devices to the entities I was using - and one of the side-effets there is that in several cases the entity_name postfix was incremented (_6 to _7 for instance).
Of course - up to you if and when you want to try the upgrade. And I would report this to Nabu Casa anyway. A Coordinator FW change fixes it so it can be argued that there is an issue with the coordinator FW.
jacme31
commented
10 months ago Finally I configured the Multi Protocol Support of my HA Yellow (even though I'm not using Thread at the moment) After that, pairing worked well. We might think that the multiprotocol has a different zigbee stack... (Micrologiciel : 7.3.1.0 build 0)
MacDada
commented
8 months ago During the pairing ZHA loads the quirk "zhaquirks.tuya.ts011f_plug.Plug" and everything seems to works, but the device stays in pairing mode, it disconnect/ reconnects multiple times before disconnecting defintevly.
I have the same exact issue with Nous A1Z Smart ZigBee Socket (identified by ZHA as TS011F by _TZ3000_2putqrmw, Firmware: 0x0000004d).
HA OS 2024.2.1
Sonoff Dongle–P (identified by ZHA as CC2652 by Texas Instruments, Firmware: Z-Stack 20230507)
aalwash
commented
4 months ago Any update on this? I have the same issue as @MacDada Can I provide any logs, if so, which logs and how can I collect them?
I have Sonoff Zigbee Dongle Firmware Z-Stack 20210708
silvar05123
commented
3 weeks ago I have also the same problem any Updates?
Problem description
I try to pair a LIDL Device (Silvercrest SAPZ A2 : a new version sold in France with power consumption measuremenst of the SAPZ A1 which already works well with ZHA) . During the pairing ZHA loads the quirk "zhaquirks.tuya.ts011f_plug.Plug" and everything seems to works, but the device stays in pairing mode, it disconnect/ reconnects multiple times before disconnecting defintevly.
Solution description
A well connected ZHA device ...
Screenshots/Video
Screenshots/Video
[  ]Device signature
Device signature
```json [{ "node_descriptor": "NodeDescriptor(logical_type=Diagnostic information
Diagnostic information
```json [{ "home_assistant": { "installation_type": "Home Assistant OS", "version": "2023.11.1", "dev": false, "hassio": true, "virtualenv": false, "python_version": "3.11.6", "docker": true, "arch": "aarch64", "timezone": "Europe/Paris", "os_name": "Linux", "os_version": "6.1.21-v8", "supervisor": "2023.10.1", "host_os": "Home Assistant OS 11.1", "docker_version": "24.0.6", "chassis": "embedded", "run_as_root": true }, "custom_components": { "signal_ecogaz": { "version": "0.1.0", "requirements": [ "Async-OAuthlib==0.0.9" ] }, "waste_collection_schedule": { "version": "1.43.0", "requirements": [ "icalendar", "recurring_ical_events", "icalevents", "bs4", "lxml" ] }, "rte_ecowatt": { "version": "0.6.3", "requirements": [ "Async-OAuthlib==0.0.9" ] }, "ha_strava": { "version": "3.2.28", "requirements": [ "aiohttp>=3.6.1", "voluptuous>=0.11.7" ] }, "pollens": { "version": "2023.06.01", "requirements": [] }, "metar": { "version": "2021.07.1", "requirements": [ "metar" ] }, "zha_toolkit": { "version": "v1.1.4", "requirements": [ "pytz" ] }, "myEnedis": { "version": "2.3.0", "requirements": [ "packaging>=20.8" ] }, "garmin_connect": { "version": "0.2.17", "requirements": [ "garminconnect==0.2.3", "tzlocal" ] }, "garbage_collection": { "version": "4.10.2", "requirements": [ "python-dateutil>=2.8.2" ] }, "scheduler": { "version": "v0.0.0", "requirements": [] }, "dreame_vacuum": { "version": "v1.0.1", "requirements": [ "pillow", "numpy", "pybase64", "requests", "pycryptodome", "python-miio", "py-mini-racer", "tzlocal" ] }, "resmed_myair": { "version": "0.1.11", "requirements": [ "beautifulsoup4", "PyJWT" ] }, "pyscript": { "version": "1.5.0", "requirements": [ "croniter==1.3.8", "watchdog==2.3.1" ] }, "holidays": { "version": "1.9.6", "requirements": [ "python-dateutil>=2.8.2", "holidays>=0.14.2" ] }, "hacs": { "version": "1.33.0", "requirements": [ "aiogithubapi>=22.10.1" ] } }, "integration_manifest": { "domain": "zha", "name": "Zigbee Home Automation", "after_dependencies": [ "onboarding", "usb" ], "codeowners": [ "@dmulcahey", "@adminiuga", "@puddly" ], "config_flow": true, "dependencies": [ "file_upload" ], "documentation": "https://www.home-assistant.io/integrations/zha", "iot_class": "local_polling", "loggers": [ "aiosqlite", "bellows", "crccheck", "pure_pcapy3", "zhaquirks", "zigpy", "zigpy_deconz", "zigpy_xbee", "zigpy_zigate", "zigpy_znp", "universal_silabs_flasher" ], "requirements": [ "bellows==0.36.8", "pyserial==3.5", "pyserial-asyncio==0.6", "zha-quirks==0.0.106", "zigpy-deconz==0.21.1", "zigpy==0.59.0", "zigpy-xbee==0.19.0", "zigpy-zigate==0.11.0", "zigpy-znp==0.11.6", "universal-silabs-flasher==0.0.14", "pyserial-asyncio-fast==0.11" ], "usb": [ { "vid": "10C4", "pid": "EA60", "description": "*2652*", "known_devices": [ "slae.sh cc2652rb stick" ] }, { "vid": "1A86", "pid": "55D4", "description": "*sonoff*plus*", "known_devices": [ "sonoff zigbee dongle plus v2" ] }, { "vid": "10C4", "pid": "EA60", "description": "*sonoff*plus*", "known_devices": [ "sonoff zigbee dongle plus" ] }, { "vid": "10C4", "pid": "EA60", "description": "*tubeszb*", "known_devices": [ "TubesZB Coordinator" ] }, { "vid": "1A86", "pid": "7523", "description": "*tubeszb*", "known_devices": [ "TubesZB Coordinator" ] }, { "vid": "1A86", "pid": "7523", "description": "*zigstar*", "known_devices": [ "ZigStar Coordinators" ] }, { "vid": "1CF1", "pid": "0030", "description": "*conbee*", "known_devices": [ "Conbee II" ] }, { "vid": "10C4", "pid": "8A2A", "description": "*zigbee*", "known_devices": [ "Nortek HUSBZB-1" ] }, { "vid": "0403", "pid": "6015", "description": "*zigate*", "known_devices": [ "ZiGate+" ] }, { "vid": "10C4", "pid": "EA60", "description": "*zigate*", "known_devices": [ "ZiGate" ] }, { "vid": "10C4", "pid": "8B34", "description": "*bv 2010/10*", "known_devices": [ "Bitron Video AV2010/10" ] } ], "zeroconf": [ { "type": "_esphomelib._tcp.local.", "name": "tube*" }, { "type": "_zigate-zigbee-gateway._tcp.local.", "name": "*zigate*" }, { "type": "_zigstar_gw._tcp.local.", "name": "*zigstar*" }, { "type": "_uzg-01._tcp.local.", "name": "uzg-01*" }, { "type": "_slzb-06._tcp.local.", "name": "slzb-06*" } ], "is_built_in": true }, "data": { "ieee": "**REDACTED**", "nwk": 20544, "manufacturer": "_TZ3000_ynmowqk2", "model": "TS011F", "name": "_TZ3000_ynmowqk2 TS011F", "quirk_applied": true, "quirk_class": "zhaquirks.tuya.ts011f_plug.Plug", "quirk_id": "tuya.plug_on_off_attributes", "manufacturer_code": 4417, "power_source": "Mains", "lqi": 180, "rssi": -55, "last_seen": "2023-11-06T19:28:56", "available": false, "device_type": "Router", "signature": { "node_descriptor": "NodeDescriptor(logical_type=Logs
Logs
```python [ 2023-11-06 17:40:48.340 DEBUG (MainThread) [zigpy.application] Device is initializedCustom quirk
Custom quirk
```python [Paste your custom quirk here] ```Additional information
No response