CC2538 und CC2530+CC2592 ZigBee Raspberry Pi Modul

Deutsche Foren Hardware
#112

I’m currently trying to understand why the issue is happening.

By looking over the sources of the firmware and over the TI forums, I suspect that changing the buffers sizes when compiling the sources is a cause of the bug.

The ‘table’ that gets truncated is actually a struct that has a byte ‘all fresh’ which I think does nothing, two bytes that contain the network manager address (this should be zero, I think), two bytes that contain a counter for transmissions and a byte that represents an ‘update id’. This one seems to be dangerous to be corrupted (along with the network manager address) as it’s uses by devices that ‘think’ they lost the network, to rejoin it. It’s used for network updates.

From what I’ve seen in the sources, the devices might receive a ‘network update’ request which they would ignore if the update id they have in the NIB has a bigger or equal value with the one from the request. It appears that such requests might be sent when the channel and/or the channel mask changed.

Maybe the issue would be solved if setting the channel mask to allow only a single channel? It would be worth testing with such a setting, to see if it solves the problem…

Anyway, my attempt to solve it now is to have the NIB explicitly cleared/filled with 116 zeros when network is initialized. I’ll commit the new sources soon.

1 Like
#113

This is great @Adrian. So in theory, with your fix, the CC2538 will just start working. Or should the devices all be re-paired?

#114

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
#115

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 :grin: 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
#116

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
#117

Great, so no need to delete a backup file as with z2m. Thanks!

#118

Hey,

der Link führt ins Nirvana :grinning:Also beide :grinning:

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

#119

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 :wink:

LG

#120

@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.

#121

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 :crazy_face:

Gruß und danke!

Der Doc

#122

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.

#123

Hey,

any feedback on the solution? Still afraid to do it :flushed::joy:

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 :flushed:

Der Doc

#124

Can confirm it works - at least all bulbs survived a cold boot :wink:

@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
#125

@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

#126

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. :frowning:

Aber ich würde natürlich gerne direkt mit der richtigen Firmware arbeiten. :wink:
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. :frowning:

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!

#127

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 :wink:

1 Like
#128

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 :wink: . 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:

1 Like
#129

Hallo @pmayer und @tsmt, veilen Dank für eure Antworten.

ich habe schon das CC2538 Modul.

20210917_153052~3
20210917_153052~31638×2147 1.2 MB

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:

https://github.com/jethome-ru/zigbee-firmware/blob/master/ti/coordinator/cc2538_cc2592/JH_2538_2592_ZNP_UART_20201010.zip

Auch würde ich ungern das Fimware-Upgrade ohne Spezial-Hardware verlieren. Nur, mit welcher Software bzw. Kommando starte ich das Update?

Vielen Dank!

#130

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
#131

Danke, das werde ich morgen mal alles ausprobieren.