[gelöst] zigbee update - Configuration is not consistent

[fiddle]

Der nächste Spucker wohnt meilenweit weg.

Aber das ist doch hier echt nicht die Frage, oder? Ich habe den Adapter nicht gebeten mich zu "attitüdisieren" (ich würde, frei nach den Ärzten glaube ich, mal sagen: der weiß hoffentlich nicht mal was Attitüde heißt )

Das Problem liegt doch vermutlich nicht (nicht nur?) an 16xD - oder ist der Adapter seit einer bestimmten Version >1.3.0 "belehrendes Attitüdenmoralapostel"? Was macht 16xD technisch zu 16x irgendwas gewürfeltes für einen Unterschied? Ist byte nicht einfach byte? 16xD ist auch eine "zufällige" Wahl aus dem "Hex-Raum". Ich fürchte ja: egal was ich da jetzt eintrage (und dann alles neu anlerne - na danke...), das "Problem" ist damit vielleicht nur für diesen Schritt behoben. Muss ja einen Grund (jenseits von 16xD ? ) geben warum das update nicht einfach ein update ist.

[Thomas Braun]

@fiddle

Dann lass es halt so falsch.
Aber halt nicht wundern, wenn das falsch aufgesetzte Zeuch dann auch 'falsch' reagiert.

[fiddle]

antworte mir mal selbst...
könnte (!) damit zu tun haben, dass ab Version 1.5.6 Probleme in der Kombi mit cc2538 mit bestimmter Firmware und der (eigentlich nicht falschen...) 16xD EPAN auftreten: https://github.com/ioBroker/ioBroker.zigbee#160-2021-08-09
Werde also die Tage tatsächlich mal alles zerrupfen und ein firmware update wagen und dann alles neu... na dann Frohes Fest

[Asgothian]

@fiddle sagte in zigbee update - Configuration is not consistent:

antworte mir mal selbst...
könnte (!) damit zu tun haben, dass ab Version 1.5.6 Probleme in der Kombi mit cc2538 mit bestimmter Firmware und der (eigentlich nicht falschen...) 16xD EPAN auftreten: https://github.com/ioBroker/ioBroker.zigbee#160-2021-08-09
Werde also die Tage tatsächlich mal alles zerrupfen und ein firmware update wagen und dann alles neu... na dann Frohes Fest

Könnte. Sollte es aber nicht. Der Firmware Fehler beim CC2538 führt üblicherweise dazu das du gar keine Werte bei "adapter" stehen hast.

Du solltest das Netzwerk stabil laufen bekommen wenn du die Werte aus "adapter" in die Konfiguration des Zigbee Adapters übernimmst. Dabei ist zu beachten das die ExtPanID und der Network Key ggf. "invertiert" werden müssen (8 byte in reverse order).

Ansonsten kannst du auf die 1.6.9 von Github hoch ziehen, da gibt es einen Knopf mit dem du den Adapter auch mit inkonsistenter Konfiguration starten kannst.

[fiddle]

@asgothian Danke für den Input! Bevor ich das (frühestens übermorgen...) versuche: Wenn ich die Werte aus den Fehlermeldungen für "Adapter" in die Konfig schreibe, dann schreibe ich da also (ggf. invertiert) die EPAN rein, die dann nicht mehr 16xD lautet. Ist damit nicht das Netzwerk "futsch"? Alles neu anlernen muss ich dann trotzdem, oder?

Und: bei dem verlinkten Issue wird Firmware von 2019 erwähnt. Gerade noch mal in meine Logs des funktionierenden setups geschaut:

Coordinator firmware version: {"type":"zStack30x","meta":{"transportrev":2,"product":2,"majorrel":2,"minorrel":7,"maintrel":2,"revision":20200211}}

Meine ist also von 2020-02-11, nicht 2019. Habe bisher noch kein changelog oder sowas gefunden woraus hervorgeht ab welcher Rev der FW das (nicht mehr) auftritt... woher wissen wir, welchen Teil des Problems wer hat? Die Issues auf Github sind (soweit ich sie verstehe) nicht wirklich "resolved" - oder gibt es eine "known good" Kombi aus FW und Adapter ab der's nicht mehr hakt? Und vielleicht doch einen "sauberen" Weg die existierende Kombi (über zwischen-Versionen oder "Hintertürchen") zu einer aktuellen Kombi zu überführen?

[Asgothian]

@fiddle sagte in zigbee update - Configuration is not consistent:

@asgothian Danke für den Input! Bevor ich das (frühestens übermorgen...) versuche: Wenn ich die Werte aus den Fehlermeldungen für "Adapter" in die Konfig schreibe, dann schreibe ich da also (ggf. invertiert) die EPAN rein, die dann nicht mehr 16xD lautet. Ist damit nicht das Netzwerk "futsch"? Alles neu anlernen muss ich dann trotzdem, oder?

Wenn das sichern des NVRam bei deinem Stick funktioniert hat dann meldet das System unter "adapter" die intern benutzten Einstellungen, weswegen das Netz wenn diese in der Konfiguration eingetragen sind auch funktionieren sollten.

Insgesamt gibt es diese Updateprobleme üblicherweise in den Fällen wo

• eine veraltete Firmware das sichern des Nvram nicht unterstützt.
• durch den Eintrag von 16xD in einer der in den verschiedenen Versionen des zigbee-Herdsman verwendeten Sonderfällen genutzt wird.

Insgesamt ist das Startverhalten durch das im Herdsman integrierte abspeichern des NVRam deutlich stabiler und sicherer geworden. Dadurch das das Netzwerk restauriert und nicht neu aufgebaut wird gibt es letztendlich weniger Probleme beim Start. So sind Fälle bei denen das Netzwerk nicht gestartet werden konnte weil der Koordinator ein bestehendes, nicht passendes Netzwerk delektiert hat dadurch ausgeschlossen.

A.

[fiddle]

@asgothian sagte in zigbee update - Configuration is not consistent:

Wenn das sichern des NVRam bei deinem Stick funktioniert hat dann meldet das System unter "adapter" die intern benutzten Einstellungen, weswegen das Netz wenn diese in der Konfiguration eingetragen sind auch funktionieren sollten.

Bedeutet das dann: Das derzeit bestehende Netz verwendet gar nicht 16xD als EPAN, sondern den Wert "88 e5 ea bc 56 31 e1 f9"?
Als erster Test - bevor ich irgend etwas update - müsste es dann also auch ohne neu Anlernen funktionieren, wenn ich im jetzigen 1.3.0 Adapter die 16xD durch obigen Wert 88... (oder invertiert "f9 e1 31 56 bc ea e5 88") ersetze (natürlich ohne Leereichen), oder verstehe ich dich jetzt falsch?

[Asgothian]

@fiddle sagte in zigbee update - Configuration is not consistent:

@asgothian sagte in zigbee update - Configuration is not consistent:

Wenn das sichern des NVRam bei deinem Stick funktioniert hat dann meldet das System unter "adapter" die intern benutzten Einstellungen, weswegen das Netz wenn diese in der Konfiguration eingetragen sind auch funktionieren sollten.

Bedeutet das dann: Das derzeit bestehende Netz verwendet gar nicht 16xD als EPAN, sondern den Wert "88 e5 ea bc 56 31 e1 f9"?
Als erster Test - bevor ich irgend etwas update - müsste es dann also auch ohne neu Anlernen funktionieren, wenn ich im jetzigen 1.3.0 Adapter die 16xD durch obigen Wert 88... (oder invertiert "f9 e1 31 56 bc ea e5 88") ersetze (natürlich ohne Leereichen), oder verstehe ich dich jetzt falsch?

Da verstehst du mich falsch. Insbesondere wenn du den 1.3.0 Adapter mit geänderten Werten startest ist nicht sicher zu sagen was passsiert
Das liegt daran das in dieser Version der Adapter das Netz immer versucht neu aufzubauen - es ist also denkbar das es zu Problemen kommt.

A.

[fiddle]

@asgothian Tatsache... geht. Ich habe einfach:

1. den Adapter auf 1.6.6 aktualisiert,
2. invertierten (!) EPAN Wert (aus der Fehlermeldung bei Adapter=...) sowie die um 1 erhöhte PAN in der Config des Adapters eingetragen
3. den Adapter gestartet... und das Netz ist noch komplett da

Muss ich ja nicht verstehen warum man in der (früheren) Adapter-Konfig andere Werte angeben kann als Stick + Clients offenbar nutzen, bzw. dass die ja wohl irgendwann bei einer Anlern-Runde diese anderen (von mir nie eingetrageneb) Werte "unter sich ausgemacht" haben. ZickenBienenVolk, das....

Und wenn ich jetzt ein FW Update auf dem Stick mache... dann ist alles futsch und ich muss neu anlernen?

[Asgothian]

@fiddle Das hängt leider von der Firmware und Hardware Deines Sticks ab. Sicher kann ich nicht zusagen das es geht ohne das du neu anlernen musst.

A.

[fiddle]

@asgothian

Der hier:
https://modkam.ru/2019/08/07/koordinator-zigbee-v3/
Und da die obere (ursprüngliche?) Variante:
http://modkam.ru/wp-content/uploads/2019/08/3D-предпросмотр-2019-08-07-09.39.06.jpg

Und seit einem "Midnight-HW-Upgrade" gerade eben auch mit dem Flash Taster zwischen PA7 <> GND so wie hier:
https://easyeda.com/mercenaruss/zigbee-stick-v3

Firmware müsste diese sein (genau weiß ich's nicht, weil ich mir den Stick damals vom Verkäufer (nicht hier im Forum aktiv) habe flashen lassen - aber dem FW-Datum nach sollte die das sein):
https://github.com/egony/MODKAM-STICK-V3/blob/master/firmware/cc2538/Riverieline_2020-02/MODKAMRU_V3_USB_with_SBL.hex

[fiddle]

So, gelöst. Call me braveheart ;-), der ZickenDrache ist besiegt.
Herz gefasst, JTAG vom RPi verwendet (kein J-link im Fundus...), neue FW drübergebraten, wieder angesteckt, Adapter gestartet - alles noch da - puuuuh.

Mit dieser Firmware:
https://github.com/jethome-ru/zigbee-firmware/raw/master/ti/coordinator/cc2538_cc2592/JH_2538_2592_ZNP_USB_20211222.zip

Ganz grob so gemacht:

• Generell diese Anleitung; da steht wie man's ohne einen Flash-Adapter direkt an einen RPi verkabelt (den man vorher mittels "enable_jtag_gpio=1" in der "/boot/config.txt" entsprechend ertüchtigt und rebooted haben muss)
• VCC 3.3V erstmal noch nicht an den Stick, der kann erstmal "aus" bleiben
• Dann dieser Antwort-Post dort um openOCD aufzusetzen.
• Dann den Flash-("BSL")-Button auf dem Stick gedrückt halten und VCC an den Stick stecken; Flash für ~10s gehalten (**)
• Dann sinngemäß so den Flash durchgeführt
  (Vorher natürlich noch ein paar openOCD-Tests "read only" gemacht um zu sehen, ob die ganze Sache überhaupt "spricht").

(**) Hätte eigentlich auch ohne den "Flash" button funktionieren müssen glaube ich, openOCD war aber nach einem erfolgversprechenden "programming startet" mit einem "Invalid ACK (0) in DAP response" fehlgeschlagen. Dann 2. Versuch mit Flash-Knopf drücken wie oben beschreiben und zack, ging.

Und wäre vermutlich auch mit anderen tools auf anderen Wegen gegangen....

Danke für die Hilfe!!