iob diag - Skript

[Shadowhunter23]

@thomas-braun

Ja aber ich lösche sie jetzt zuerst und versuche es nochmals.

[Thomas Braun]

@shadowhunter23

Versionsnummer ist
2024-12-09 Raspbian+zigbee diag+masking

[Shadowhunter23]

@thomas-braun

Lag an mir:

USB-Devices by-id:
USB-Sticks -  Avoid direct links to /dev/tty* in your adapter setups, please always prefer the links 'by-id':

No Devices found 'by-id'

*** ZigBee Settings ***

HINT:
Your zigbee.0 COM-Port is NOT matching 'by-id'. Please check your setting:
tcp

HINT:
Your zigbee.1 COM-Port is NOT matching 'by-id'. Please check your setting:
tcp

HINT:
Your zigbee.2 COM-Port is NOT matching 'by-id'. Please check your setting:
tcp

HINT:
Your zigbee.3 COM-Port is NOT matching 'by-id'. Please check your setting:
tcp
Zigbee Network Settings on your coordinator/in nvbackup are:

zigbee.X
Extended Pan ID:
*** MASKED ***
Pan ID:
*** MASKED ***
Channel:
*** MASKED ***
Network Key:
*** MASKED ***

To unmask the settings run 'iob diag --unmask'

Mit --unmask sehe ich dann die komplette Ausgabe.

edit
Die Leerzeichen/Absätze sind auch weg bei --unmask.

[Thomas Braun]

@shadowhunter23 sagte in iob diag - Skript:

Mit --unmask sehe ich dann die komplette Ausgabe.

Also alle 5 Instanzen in kompakten Blöcken, ohne komische Leerzeichen?
So soll es sein.

Dann schau ich auch mal wie ich das für die 'by-id'-Links hinbekommen kann, für den Fall, das jemand da ein halbes Dutzend zigbee-Stöckchen betreibt.

[Shadowhunter23]

@thomas-braun sagte in iob diag - Skript:

Also alle 5 Instanzen in kompakten Blöcken, ohne komische Leerzeichen?

Ja 5 von 5!

edit doch alle fünf!!

[Thomas Braun]

@shadowhunter23 sagte in iob diag - Skript:

Nein nur 4 von 5, zigbee.4 wird nicht angezeigt.

Und die vierte gibt es auch? Kann eigentlich nicht sein, weil ich da in einer Schleife durch das Verzeichnis gehe...

[Shadowhunter23]

@thomas-braun

Sorry Thomas ist wohl zu spät für mich! Es passt alles.

[Thomas Braun]

@shadowhunter23 sagte in iob diag - Skript:

Es passt alles.

Super!

[Shadowhunter23]

@thomas-braun
Ich denke aber das ich eine Ausnahme bin mit meinen 5 Zigbee Instanzen. Ich hab mich aber bewusst dazu entschieden das so zu machen und bisher keinerlei Nachteile dadurch gehabt.
Für dich gilt dann ab jetzt: Haben ich besser als brauchen.

[Thomas Braun]

@shadowhunter23

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!

[Thomas Braun]

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

@thomas-braun OK, ich dachte das wäre inzwischen der Fall. Wobei ich die ja sowieso nutzen muss - RPI

[Thomas Braun]

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

@thomas-braun Klar - welcher Link ? der gleiche wie vorher ?

[Thomas Braun]

@asgothian

Kein Link, direkter Aufruf von

iob diag

[Asgothian]

@thomas-braun geht bei mir. Lt. Versionsangabe auch die Version von gestern

[Thomas Braun]

@asgothian

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.

[Asgothian]

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

[Thomas Braun]

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

sollte 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]

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

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