The network should be re-initialized, so the devices need re-pair.
I would remove the devices from the network, then issue a reset from the command line, then re-pair them.
2 Likes
I didn’t create a full blown script to github, but just instructions on how to reset your controller. This is due to the fact that I had problems with handling NPM from bash script. Basically because npm doesn’t respect signal handling pretty well 
and I didn’t have the time to find reliable workarounds for it.
Anyway, here is a very detailed tutorial together with some scripts to repair your devices.
@dr_snuggles
In deutsch. ich hab das aus Faulheit mit DeepL übersetzt und nur drüber gelesen. Falls da noch verständnisschwierigkeiten sind, schreib mir gerne nochmal dann bessere ich das aus.
German
@Adrian
Sorry I don’t really know how homegear handles zigbee that’s why there is a TODO in the tutorial. If you can give me a short instruction if homegear does buffer the NIB_TABLE and how I could instruct users to reset it until you find a in-software way around it, that would be great.
Also, if you do a PR to homegear which fixes this, can you notify me because I would just be interested in how you solve this.
2 Likes
It doesn’t buffer NIB table. It just explicitly erases it now at network initialization / commissioning, as a workaround for the firmware bug.
1 Like
Great, so no need to delete a backup file as with z2m. Thanks!
Hey,
der Link führt ins Nirvana 
Also beide
Kannst mal prüfen ob da ein zahlen Dreher drin ist.
Für mich nochmal zum Verständnis funktioniert das jetzt nur für Zigbee2mqtt oder auch wenn man zigbee im homegear nutzt.
Danke und Gruß
Der Doc
Link sollte jetzt gehen. Sorry, das github repo war auf privat gestellt.
Ja, das läuft über zigbee2mqtt. Hab aus beruflichen Gründen momentan leider nicht die Zeit, da ein extra tool für zu bauen. Du kannst danach zigbee2mqtt wieder löschen. Während du das script laufen lässt, mach bitte homegear aus 
LG
@here
Please wait using the mentioned tutorial, another test showed it might still be unstable.
Bitte noch nicht das script anwenden. Der Prozess scheint instabil zu sein, ist mir in meiner Produktionsumgebung eben aufgefallen.
Wollte noch sagen, englisch ist kein Problem es sind eher die Grundkenntnisse raspberry die mir hier fehlen. Brauchst dir also keinen abbrechen und das ins Deutsche zu bringen. Schritt für Schritt in Englisch reicht vollkommen für mich aber eben auf Anfänger Level 
Gruß und danke!
Der Doc
Haha okay. Sorry, hatte das so verstanden, dass du gerne etwas deutsches hättest, was ja auch kein problem ist.
@all
Regarding my problem after I put the tutorial onto my production instance.
tl;dr: I’m pretty sure it’s a hardware issue, not software/firmware connected to the CC2538 fix. So I would suggest continuing with that if you like.
I think you can continue with the script as it it, since I did a lot more with the latest changes overnight
- updated raspberry pi OS (since I had some kind of unfixable firmware/kernel problem because I just used a rpi3 SD in a rpi4)
- backed up homegear/openhab-docker/influx/grafana/homeassistant-docker from the old pi
- restored everything on the new one
- for zigbee2mqtt I did a complete new install with the NIB_TABLE fix.
- updated homegear
After that, all devices worked pretty well. Until this morning.
It seems to be a hardware issue very clear. My raspberry has
- problems connecting to any device with the HomematicBidCos with CC1101 SPI module.
- problems connecting to any zigbee devices with zigbee2mqtt with CC2538 UART module
I found out it’s connected to my CC2538 and CC1101 antennas, since when I remove them, all my (near) connections work fine.
I’m not very good with electronics to be honest. Overnight after I connected all devices, I had the two antennas placed directly next to each other (I think they were even stacked). Now it seems that both of them are broken and have bad signal. Maybe the electronics people like @pmayer can say if this is some kind of nogo ^^.
Also, they are placed on the Pi case with ~1,5cm distance. Would it be better if I place one of them on the complete other side, so they have approx 4cm distance?
I always thought Zigbee is using 2.4Ghz band and Homematic 868Mhz, so I expected them not to have too many interference.
Hey,
any feedback on the solution? Still afraid to do it 
So to understand you right I have to install Zigbee2mqtt do what you write and then uninstall Zigbee2mqtt. Correct? How do I uninstall Zigbee2mqtt? I looked around but didn’t find it
Der Doc
Can confirm it works - at least all bulbs survived a cold boot
@dr_snuggles You don’t have to uninstall z2m. If you have it up and running (e.g. confirm that you can pair a Zigbee device from the web UI) you have to stop z2m, delete data/coordinator_backup.json and then run node scripts/zStackEraseAllNvMem.js /dev/ttyAMA0 from your z2m folder. Afterwards restart z2m. The newly created coordinator_backup.json should have an entry ZCD_NV_NIB with "len":116.
1 Like
@trapperjohn thanks for your feedback! Iwans busy the last weeks so could not answer.
I’m not using Zigbee2mqtt I use the zigbee client in homegear from @Adrian. That‘s why I thought about uninstalling Zigbee2mqtt after the fix. The question is there maybe already another solution to fix it with Adrian‘s version?
Doc
Hallo mal wieder.
So, nun ist es passiert. Mein Raspberry Pi mit dem Zigbee Adapter ist gecrasht. Und da das Bootmedium durch ist, muss ich vollständig neu installieren. 
Aber ich würde natürlich gerne direkt mit der richtigen Firmware arbeiten.
Aktuell habe ich diese Firmware drauf: 20200211.
Das checkLen Script aus dem Repository https://github.com/codm/cc2538-fix funktioniert nicht, da in meinem coordinator-backup dieser ganze Pfad nicht drin ist. Die Datei fängt so an, danach folgen nur noch Geräte.
{
"metadata": {
"format": "zigpy/open-coordinator-backup",
"version": 1,
"source": "zigbee-herdsman@0.13.138",
"internal": {
"date": "2021-09-16T13:56:08.828Z",
"znpVersion": 2
}
},
"stack_specific": {
"zstack": {
"tclk_seed": "0c1005acc07d90816c602d289e1e6aa8"
}
},
"coordinator_ieee": "xxxxxxxxxxxxxxx",
"pan_id": "xxxx",
"extended_pan_id": "xxxxxxxxxxxxxxxx",
"nwk_update_id": 0,
"security_level": 5,
"channel": 11,
"channel_mask": [
11
],
Kein Wort von der Länge.
Was muss ich nun tun? Welche Firmware ist denn nun empfohlen, und mit welchem Prozess sollte ich die aufspielen. Ich weiss nicht, ob ich was übersehen habe, aber irgendwie fehlt entweder der Abschluss der Problematik, oder ich sehe ihn einfach nicht.
Vielen Dank für eure Hilfe!
Hattest du nicht nen CC2652? (blaues Modul)
Aktuelle Firmware für CC2538 (schwarzes/grünes Modul) findest du hier: https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.0.x/bin oder hier https://github.com/reverieline/CC2538-CC2592-ZNP/. Ich glaube es gibt keine neuere.
Und wenn die Pairings bei dir schon “rebootfest” waren, benötigst du den Fix eh nicht
1 Like
Ich kann zu deinem Problem gerade nichts sagen @job, Lass uns erst mal klären ob die Hardware stimmt, falls du ein CC2652-Modul hast dann bringt das script tatsächlich nichts. Ansonsten müsste ich mal mein z2m updaten und schauen ob sich die dateistruktur der config geändert hat und das Array für den key woanders liegt. Kann aber leider nicht genau sagen wann ich dazu dann komme.
Aber ein kleiner Erfahrungsbericht:
Ich kann sagen die Pairings sind sogar sehr rebootfest. Ich habe Anfang des Sommers beim Frühjahrsputz den kompletten Pi gezogen und vergessen wieder einzustecken, die Heizungssteuerung benötige ich ja nicht . Als ich letzte Woche mal den Stromverbrauch vom Kühlschrank mit einer Zigbee Steckdose messen wollte ist mir aufgefallen, dass der Pi den ganzen Sommer nicht lief. Die Pairings waren aber alle noch da. Sogar bei den 2 Sonoff Temperatursensoren, die vermutlich schon länger den Akku leer hatten, musste ich nach dem Akkuwechsel nicht neu pairen.
Alles tutti soweit bei mir 
1 Like
Hallo @pmayer und @tsmt, veilen Dank für eure Antworten.
ich habe schon das CC2538 Modul.
Ich gehe davon aus, dass die neue z2m Version einfach ein neues Format des Coordinator Backups schreibt. Es sieht für mich auch eher hardwareunabhängig aus.
Nachdem mein RPi gecrasht ist, funktionierten die Geräte erst nach einem neuen Pairing wieder, obwohl sie alle im Coordinator_backup mit Adressen drinstehen.
Daher vermute ich, dass das Problem bei mir besteht.
Ich habe jetzt ein paar leicht erreichbare Geräte wieder gepairt und sie funktionieren als wäre nix passiert. Bevor ich jetzt aber alle Geräte wieder paire, würde ich gerne wissen, ob das Problem besteht.
Wenn ich jetzt das Ding runterfahre und vom Strom trenne, sollten die Geräte doch …
- …alle nicht mehr funktionieren, wenn das Problem besteht.
oder - …alle noch funktionieren, wenn das Problem nicht besteht.
Falls das Problem besteht müsste ich dann wohl diese Firmware installieren:
Auch würde ich ungern das Fimware-Upgrade ohne Spezial-Hardware verlieren. Nur, mit welcher Software bzw. Kommando starte ich das Update?
Vielen Dank!
Auf dem Pi https://github.com/1248/cc2538-prog ausführen, mit beendeten Diensten die auf den CC2538 zugreifen.
./cc2538-prog -d /dev/ttyAMA0 -f JH_2538_2592_ZNP_UART_20201010.hex
Davor Flash am Modul halten, reset drücken, loslassen und danach Flash loslassen. Dann cc2538-prog starten.
Es gibt mittlerweile einen aktuelleren Fork von cc2538-prob von ElectroLama. Das sind die, die den zzh! bauen: https://github.com/electrolama/llama-bsl
Das habe ich aber noch nicht getestet.
1 Like
Danke, das werde ich morgen mal alles ausprobieren.
So, das habe ich getestet.
- reboot => Geräte funktionieren noch
- shutdown, Stecker ziehen, Stecker rein => Geräte funktionieren noch
Zumindest die Meisten. Ich habe ein Gerät, das habe ich meiner Erinnerung nach bereits gepaired, das ist aber jetzt unbekannt.
Kann es sein, dass das Problem nur bei einigen Geräten auftritt? Oder sind immer Alle oder Keins betroffen?
1 Like
Wenn dann alle, meiner Erfahrung nach. Wobei, “eingehende Kommunikation”, also wenn das Gerät sich meldet, ging manchmal. Ausgehend nie.