NEWS
iob diag - Skript
iob diag - Skript
-
Sorry Thomas ist wohl zu spät für mich! Es passt alles.
Deine 5 Instanzen haben dazu geführt, das ich mir den Code nochmal komplett anders überlegt habe und das ganze Konstrukt von mehreren Dutzend chaotischen und schwer zu pflegenden Zeilen auf nur noch 15 Zeilen eingedampft wurde.
Und ich mich endlich mal genauer mit FOR-Schleifen beschäftigen musste.
Danke!
-
@pmayer sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
Moin,
mal ne Frage: Bei mir häufen sich die Supportanfragen, ob man am Coordinator auch die IEEE Adresse ändern kann.
Ja, das kann man aber wieso?Die Leute sagen man müsste das machen, wenn man von nem anderen Coordinator (zstack) auf unseren Coordinator umziehen will - um das Neuanlernen zu vermeiden.
Meines wissens reicht es doch die gleiche PanID/ExtPanID zu haben mit der (unser) Coordinator läuft? Und wenn nicht, braucht man nur das NVRAM am Coordinator löschen damit die diecoordinator_backup.jsonzurückgespielt werden kann.Zur Info: Wir testen den Coordinator natürlich und da nehmen wir die default PanID. Wenn man eine andere nutzt musst man das NVRAM löschen.
https://docs.codm.de/zigbee/faq/#startup-failed-configuration-adapter-mismatchLieg ich hier fasch?
@arteck, du kannst doch sicher was dazu sagen.Gruß,
PatrikHallo Patrick,
du liegst da zum Teil falsch. Allerdings ist das ein "user" Problem.
Vorab - ich gehe fest davon aus das ihr nach eurem Test das NVRam löscht ?
Wenn die User die bisher im Adapter vorgesehene Standard-PanID (16x D) nicht umstellen, dann wird bei Koordinatoren die eine IEEE besitzen deren IEEE als ExtPanID genutzt (abweichend von der Konfiguration). Das bedeutet das sich dann im NVRam (auf dem Koordinator sowie auf der Sicherung im Adapter) eine andere ExtPanID befindet als in der Adapter-Konfiguration angegeben ist. Da diese in dieser Situation Hardwarespezifisch ist kann das natürlich zu Problemen führen, insbesondere wenn man die Hardware austauschen will.
Die korrekte Gegenmassnahme ist das eintragen einer eigenen ExtPanID un der Adapter Konfiguration. Wenn Das Kind bereits im Brunnen ist - sprich der Adapter schon mit 16D und einem modernen Koordinator läuft - muss man die im NVRam eingetragene ExtPanID ermitteln und diese im Adapter eintrage. Das iobroker Diag Skript kann diese ausgeben. Auch ein Blick in die nvbackup.json zeigt diesen Wert.
Bei der (in Entwicklung befindlichen) 2.0 des Adapters wird der Adapter mit einer zufälligen Zeichenfolge vor-initialisiert, so das dieser Effekt weg sein sollte.
Insgesamt sehe ich nicht das es notwendig ist die Hardware IEEE des Koordinators umstellen zu können.
A.
@asgothian sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
Das iobroker Diag Skript kann diese ausgeben.
Aber noch nicht die Version in der 'freien Wildbahn'.
Geht im Moment nur in der Beta des skriptes.Ich schau aber mal, das diese Version jetzt zeitnah auch offiziell ausgeliefert wird.
-
@asgothian sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
Das iobroker Diag Skript kann diese ausgeben.
Aber noch nicht die Version in der 'freien Wildbahn'.
Geht im Moment nur in der Beta des skriptes.Ich schau aber mal, das diese Version jetzt zeitnah auch offiziell ausgeliefert wird.
-
@thomas-braun OK, ich dachte das wäre inzwischen der Fall. Wobei ich die ja sowieso nutzen muss - RPI
@asgothian sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
Wobei ich die ja sowieso nutzen muss - RPI
OT:
Kannst du das mal testen? Gestern ist eine neue Version (02.02.2025) von 'iob diag' hochgeladen worden, die hoffentlich auch wieder direkt auf RPI läuft. -
@asgothian sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
Wobei ich die ja sowieso nutzen muss - RPI
OT:
Kannst du das mal testen? Gestern ist eine neue Version (02.02.2025) von 'iob diag' hochgeladen worden, die hoffentlich auch wieder direkt auf RPI läuft. -
@thomas-braun Klar - welcher Link ? der gleiche wie vorher ?
-
-
@thomas-braun geht bei mir. Lt. Versionsangabe auch die Version von gestern
Prima. Dann kann ich die Ergänzungen aus den letzten Monaten (u. a. auch der zigbee-nvram-Part) dann in den nächsten Tagen nachschieben.
-
Prima. Dann kann ich die Ergänzungen aus den letzten Monaten (u. a. auch der zigbee-nvram-Part) dann in den nächsten Tagen nachschieben.
@thomas-braun Zwei Auffälligkeiten hab ich noch:
ich bekomme beim Start diese beiden Meldungen:
The state system. host.stormbroker. versions. nodeNewestNext was not found! The state system. host.stormbroker. versions.npmNewestNext was not found!Das dürfte daran liegen das innerhalb des ioBrokers der Host als 'raspberrypi' bezeichnet wird, während der Systemname auf Betriebssystemebene 'stormbroker' ist.
Auf einem 2. System started das besagte Skript nicht - es kommt weiter die Fehlermeldung das erst der fixer laufen muss - obwohl lt. ioBroker oberfläche das System aktuell ist (deswegen auch die Uptime von 0h) :Da war etwas anderes im Wege - jetzt ging es - nach einiger Wartezeit. Kann an der langen Leitung liegen - der ioBroker ist 1800 km entfernt
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@thomas-braun Zwei Auffälligkeiten hab ich noch:
ich bekomme beim Start diese beiden Meldungen:
The state system. host.stormbroker. versions. nodeNewestNext was not found! The state system. host.stormbroker. versions.npmNewestNext was not found!Das dürfte daran liegen das innerhalb des ioBrokers der Host als 'raspberrypi' bezeichnet wird, während der Systemname auf Betriebssystemebene 'stormbroker' ist.
Auf einem 2. System started das besagte Skript nicht - es kommt weiter die Fehlermeldung das erst der fixer laufen muss - obwohl lt. ioBroker oberfläche das System aktuell ist (deswegen auch die Uptime von 0h) :Da war etwas anderes im Wege - jetzt ging es - nach einiger Wartezeit. Kann an der langen Leitung liegen - der ioBroker ist 1800 km entfernt
A.
@asgothian sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
Das dürfte daran liegen das innerhalb des ioBrokers der Host als 'raspberrypi' bezeichnet wird, während der Systemname auf Betriebssystemebene 'stormbroker' ist.
Dann sind die hosts nicht konsistent.
iob host thissollte das richtig stellen.
Da war etwas anderes im Wege
Jein, die Meldung mit dem Fixer kommt weiterhin, blockt aber die Ausführung von 'iob diag' nicht mehr.
-
@asgothian sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
Das dürfte daran liegen das innerhalb des ioBrokers der Host als 'raspberrypi' bezeichnet wird, während der Systemname auf Betriebssystemebene 'stormbroker' ist.
Dann sind die hosts nicht konsistent.
iob host thissollte das richtig stellen.
Da war etwas anderes im Wege
Jein, die Meldung mit dem Fixer kommt weiterhin, blockt aber die Ausführung von 'iob diag' nicht mehr.
@thomas-braun sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
@asgothian sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
Das dürfte daran liegen das innerhalb des ioBrokers der Host als 'raspberrypi' bezeichnet wird, während der Systemname auf Betriebssystemebene 'stormbroker' ist.
Dann sind die hosts nicht konsistent.
iob host thissollte das richtig stellen.
Sollte das in der Summary auftauchen ? Ich denke ich bin nicht der einzige der darauf stösst - ist passiert beim neu aufsetzen des Systems.
Da war etwas anderes im Wege
Jein, die Meldung mit dem Fixer kommt weiterhin, blockt aber die Ausführung von 'iob diag' nicht mehr.
Das ist irritierend - insbesondere wenn der Fixer gerade durchgelaufen ist und der Meinung ist es ist alles in Ordnung.
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@thomas-braun sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
@asgothian sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
Das dürfte daran liegen das innerhalb des ioBrokers der Host als 'raspberrypi' bezeichnet wird, während der Systemname auf Betriebssystemebene 'stormbroker' ist.
Dann sind die hosts nicht konsistent.
iob host thissollte das richtig stellen.
Sollte das in der Summary auftauchen ? Ich denke ich bin nicht der einzige der darauf stösst - ist passiert beim neu aufsetzen des Systems.
Da war etwas anderes im Wege
Jein, die Meldung mit dem Fixer kommt weiterhin, blockt aber die Ausführung von 'iob diag' nicht mehr.
Das ist irritierend - insbesondere wenn der Fixer gerade durchgelaufen ist und der Meinung ist es ist alles in Ordnung.
A.
@asgothian sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
Sollte das in der Summary auftauchen ? Ich denke ich bin nicht der einzige der darauf stösst - ist passiert beim neu aufsetzen des Systems.
Im Zuge dessen sollte man bei abweichenden hostnames halt
iob host thisausführen. Ich glaube backitup macht das aber eigentlich von sich aus schon.
Das ist irritierend - insbesondere wenn der Fixer gerade durchgelaufen ist und der Meinung ist es ist alles in Ordnung.
Das stimmt. Den eigentlichen Verursacher für den Hinweis auf den Fixer muss ich noch ausschalten.
-
@asgothian sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
Sollte das in der Summary auftauchen ? Ich denke ich bin nicht der einzige der darauf stösst - ist passiert beim neu aufsetzen des Systems.
Im Zuge dessen sollte man bei abweichenden hostnames halt
iob host thisausführen. Ich glaube backitup macht das aber eigentlich von sich aus schon.
Das ist irritierend - insbesondere wenn der Fixer gerade durchgelaufen ist und der Meinung ist es ist alles in Ordnung.
Das stimmt. Den eigentlichen Verursacher für den Hinweis auf den Fixer muss ich noch ausschalten.
@thomas-braun sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
ausführen. Ich glaube backitup macht das aber eigentlich von sich aus schon.
Hat er bei mir nicht - oder nicht erfolgreich.
Und mir sind die abweichenden Hostnamen erst aufgefallen als ich der Meldung nachgegangen bin. Ich könnte mir vorstellen dass
- das auch anderen so geht das sie mit nicht passenden Hostnamen arbeiten
- das nicht auffällt, weil es nur bei wenigen Operationen entscheidend ist.
A.
-
@asgothian sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
Sollte das in der Summary auftauchen ? Ich denke ich bin nicht der einzige der darauf stösst - ist passiert beim neu aufsetzen des Systems.
Im Zuge dessen sollte man bei abweichenden hostnames halt
iob host thisausführen. Ich glaube backitup macht das aber eigentlich von sich aus schon.
Das ist irritierend - insbesondere wenn der Fixer gerade durchgelaufen ist und der Meinung ist es ist alles in Ordnung.
Das stimmt. Den eigentlichen Verursacher für den Hinweis auf den Fixer muss ich noch ausschalten.
Kannst du bitten den OT / iob diag Teil hier rausnehmen und an
https://forum.iobroker.net/topic/59549/iob-diag-skript
anhängen? Da passt es besser. -
@thomas-braun Zwei Auffälligkeiten hab ich noch:
ich bekomme beim Start diese beiden Meldungen:
The state system. host.stormbroker. versions. nodeNewestNext was not found! The state system. host.stormbroker. versions.npmNewestNext was not found!Das dürfte daran liegen das innerhalb des ioBrokers der Host als 'raspberrypi' bezeichnet wird, während der Systemname auf Betriebssystemebene 'stormbroker' ist.
Auf einem 2. System started das besagte Skript nicht - es kommt weiter die Fehlermeldung das erst der fixer laufen muss - obwohl lt. ioBroker oberfläche das System aktuell ist (deswegen auch die Uptime von 0h) :Da war etwas anderes im Wege - jetzt ging es - nach einiger Wartezeit. Kann an der langen Leitung liegen - der ioBroker ist 1800 km entfernt
A.
@asgothian sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
The state system. host.stormbroker. versions. nodeNewestNext was not found!
sind da ungewollte Spaces nach den Punkten?
-
erledigt!
hoffentlich vollständig -
@thomas-braun sagte in cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany:
ausführen. Ich glaube backitup macht das aber eigentlich von sich aus schon.
Hat er bei mir nicht - oder nicht erfolgreich.
Und mir sind die abweichenden Hostnamen erst aufgefallen als ich der Meldung nachgegangen bin. Ich könnte mir vorstellen dass
- das auch anderen so geht das sie mit nicht passenden Hostnamen arbeiten
- das nicht auffällt, weil es nur bei wenigen Operationen entscheidend ist.
A.
Könntest du mal beide Langfassungen posten?
Insbesondere die von dem System mit dem irritierenden Verweis auf den Fixer? -
Könntest du mal beide Langfassungen posten?
Insbesondere die von dem System mit dem irritierenden Verweis auf den Fixer?@thomas-braun Auch auf die Gefahr hin, dass das Thema bereits bekannt ist und ich nicht gefunden habe, möchte ich es trotzdem melden.
Hatte vor vier Wochen auch das Problem das 1-2 x am Tag alle Adapter gestoppt wurden und dann wieder gestartet. Es gibt keine Fehlermeldungen im Log oder in journalctl (RPI5).
Meine Ursache:
Ich habe 4 Daten in der Datenbank von iob. Die werden in Minuten Takt mit Werten ergänzt.
Vor der Aktualisierung frage ich die Größe ab und bei >10 MB wird die Datei geleert. Blöd wenn man das nur für 3 Dateien macht...Nach ca. 1 Jahr war die 4te Datei ca. 350MB groß und deswegen ist iob immer abgestürzt.Ist das bekannt dann bitte diesen Post ignorieren.
Gruß//Lucky
-
@thomas-braun Auch auf die Gefahr hin, dass das Thema bereits bekannt ist und ich nicht gefunden habe, möchte ich es trotzdem melden.
Hatte vor vier Wochen auch das Problem das 1-2 x am Tag alle Adapter gestoppt wurden und dann wieder gestartet. Es gibt keine Fehlermeldungen im Log oder in journalctl (RPI5).
Meine Ursache:
Ich habe 4 Daten in der Datenbank von iob. Die werden in Minuten Takt mit Werten ergänzt.
Vor der Aktualisierung frage ich die Größe ab und bei >10 MB wird die Datei geleert. Blöd wenn man das nur für 3 Dateien macht...Nach ca. 1 Jahr war die 4te Datei ca. 350MB groß und deswegen ist iob immer abgestürzt.Ist das bekannt dann bitte diesen Post ignorieren.
Gruß//Lucky
Von welche Dateien sprichst du?
-
Von welche Dateien sprichst du?
49
Online32.4k
Users81.3k
Topics1.3m
Posts