Firmware flashen, da fehlt mir die komplette Hardware. Ich warte mal bis es eine Lösung gibt die abgesichert ist 
es läuft ja und meine 4 Steckdosen kriege ich beim Stromausfall wieder integriert 
Wenn du was weißt sag Bescheid
Ansonsten funktioniert das Modul Klasse und defekte Firmware ist ja nicht unbedingt dein Fehler.
Gruß und Danke für deinen Support hier
Der Doc
Du kannst es direkt am Pi flahen 
Danke!
Hiermit entschuldige ich mich offiziell fürs nerven, danke für dein Verständnis.
Danke für die Antwort, ich werde mal diese GitHUB sachen durchblättern.
aber nach dem ich nun seit das Board da ist täglich den Raspi und indirekt meine Familie damit quäle und ich zu keinem Ergebnis gekommen bin…
SSD an USB2, USB3, Raspbian 32 / 64bit, SD-Card ohne SSD, die Platine am FTDI an USB, die Platine mit Verlängerungskabeln am GPIO, jedesmal wenn der Strom abgestellt wird sind die Geräte nicht mehr ansprechbar.
Beruhigend das das Problem auch anderweitig auftritt und ich mir erstmal nicht mehr selbst wegen Unfähigkeit die Schuld geben muss.
aber zurück zum wesentlichen,
ist mit dieser Firmware denn der Fehler Behoben oder ist es ein Strohhalm?, im Change Log steht nix davon herinnen und dann mal einfach umflashen …, da bin ich kein Freund von.
Danke 
Aktuell Strohhalm. Hast du die Lösung im Issue schon probiert? Bzw. hast du es schon mal mit Homegear probiert? Da hätten wir zumindest hier im Forum den ZigBee-Homegear-Modul-Entwickler, der uns helfen könnte.
bin halt grad von FHEM auf iobroker gewechselt und hab da schon ne menge Zeit benötigt, nun wieder an anderes System “ausprobieren”, ich hab mal das Image gezogen und auf SD-Card gespielt, ich werde den “Schreibtisch-Aufbau” morgen mal damit füttern.
Ich werde mal den Strohhalm drauf ballern, und berichten.
Will ja die Hoffnung nicht ganz zerstören aber Adrian weiß Bescheid und hat aktuell auch keine Lösung 
Man kann das bestimmt, nur ich nicht bin quasi mit der ersten Zeile der Erklärung schon „überfordert“
Install and Complie cc2538-prog
Sorry bin mit dem ganzen Linux noch nicht 100% auf Augen Höhe. Man ist da doch sehr verwöhnt von Windows.
Vielleicht wenn du mal 5 min Zeit hast kannst mir das mal in ein paar Sätzen für einen Neuling erläutern so Schritt für Schritt
Gruß Der Doc
Ich hatte die Jethome Firmware geflasht - leider besteht das Problem (bei mir) weiterhin. Ich warte jetzt auf ein Ersatzmodul (nur um sicher zu gehen, dass nicht doch bspw. das NVRAM eine Macke hat).
Kleiner Tipp am Rande (falls nicht allseits bekannt): Sollte das Problem nicht kurzfristig zu lösen sein, kann man per “group” und “bind” zumindest Lampen/Fernbedienungen koppeln, ohne dass das Zigbee Gateway funktionieren muss.
In Zigbee2mqtt eine neue Group anlegen und alle gewünschten Lampen hinzufügen. Dann unter den Eigenschaften einer Fernbedienung ein “bind” auf die neue Gruppe durchführen. Die “default_bind_group” muss man dafür löschen, damit das auch funktioniert.
Jetzt sollte die Fernbedienung alle Geräte dieser Gruppe bedienen können, selbst ohne eingeschaltetes Gateway.
Ich habe in den letzten Wochen bestimmt 10x alle meine 21 Zigbee Geräte neu angelernt - mittlerweile bin ich zwar recht gut darin, den 6x an/aus Rhythmus der Ikea Lampen zu treffen, aber so langsam lässt der Spaß nach
Gruß,
Florian
Danke euch allen für die super Diskussion.
Hat einer von euch schon mal bei ModKam oder JetHome in den Issues kommentiert?
Ich mein, das Problem muss denen ja bekannt sein…
Ja, hier:
Aber noch nix weiter gehört…
Ok, das ist das Issue was ich auch kenne.
Es gibt halt sehr viele Varianten des CC2538 die alle die ModKam oder JetHome-Firmware nutzen, das Problem muss also schon mal jemand gehabt haben.
Ich gehe nicht davon aus, dass das nur mit der UART-Variante so ist.
@Adrian maybe you can give some insight here. Still havin the problem that the CC2538 “forgets” all non active devices after reboot.
2538 has non volatile memory as well as volatile one. For the later, its contents are lost in case of the ‘stick’ losing power. Because of that, it should contain only the program stack and variables that do not need saving.
My guess is that they did some firmware adjustments that moved something critical in the volatile memory so some very important settings are lost when losing power.
The solution would be to use a firmware that does not have those changes (it won’t be able to deal with so many devices, though).
Thank you Adrian.
Did you come across the problem on both, the modkam and jethome, firmware?
I’ve just asked Giovanni on Tindie if he has the same issues: https://www.tindie.com/products/GiovanniCas/zigbee-hat-with-cc2538-for-raspberry/
Only modkam one was signaled to me.
Jethome is here:
It’s also linked by Koenkk:
Currently testing zigbee2mqtt with modkam from March last year. Connected are an innr plug and an xiaomi battery temperature sensor.
I will try different firmwares and check for the behavior.
Getting back to you guys as soon as I have some insight.
Currently replicateable:
CC2538 (dev board of mine) with ModKam from 2020-03-27 (should be revierline), innr plug, xiaomi sensor.
"coordinator":{"meta":{"maintrel":2,"majorrel":2,"minorrel":7,"product":2,"revision":20200327,"transportrev":2},"type":"zStack30x"}
Both worked, sudo halt on the PI, removed power and put it back, after boot start zigbee2mqtt. No devices react/send. Waited 15minutes, still the same.
Pushed the button on the Xiaomi, typically it sends data then -> nothing can be seen in z2m
Switched the plug -> nothing can be seen in z2m
long press xiaomi to repair:
Zigbee2MQTT:info 2021-01-19 12:43:47: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00158d000309a241","ieee_address":"0x00158d000309a241"},"type":"device_announce"}'
Zigbee2MQTT:info 2021-01-19 12:43:47: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"announce","meta":{"friendly_name":"0x00158d000309a241"},"type":"device_announced"}'
Zigbee2MQTT:info 2021-01-19 12:43:48: MQTT publish: topic 'zigbee2mqtt/0x00158d000309a241', payload '{"battery":100,"humidity":55.43,"linkquality":199,"pressure":972.7,"temperature":22.6,"voltage":3055}'
long press on the innr plug:
Zigbee2MQTT:info 2021-01-19 12:44:24: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x680ae2fffe7249a8","ieee_address":"0x680ae2fffe7249a8"},"type":"device_announce"}'
Zigbee2MQTT:info 2021-01-19 12:44:24: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"announce","meta":{"friendly_name":"0x680ae2fffe7249a8"},"type":"device_announced"}'
both working.
Other step’s I’ve taken to reproduce:
So, I’ve tested all for me know variants of the firmware and all have the same problem:
zigbee2mqtt 1.17.0
zigbee-herdsman 0.13.46
| Revision | cold reboot | reboot | reboot + wait | z2m restart | comment | |||
|---|---|---|---|---|---|---|---|---|
| revierline | 20200327 | no | no | no | yes | without SBL | ||
| jethome | 20201010 | no | no | no | yes | with SBL | ||
| modkam | 20200211 | no | no | no | yes | with SBL |
“yes” means you did not have to re-pair respectively to “anounce” the device again. Often a complete re-pair is not needed.
I find it rather confusing that obviously nobody ever made that observation. Is it confirmed that this also happens with the USB variants of the CC2538?
Hello Peter, thanks to invite me…
I’ve asked to perform same test with different firmware using my hardware and will let you know.
I don’t have any USB stick (all sold out) but I’ll do same test with CC2538 via USB once I’ll have new batch of dongles…
Giovanni