Neues YouTube-Video: Visualisierung im Devices-Adapter

[Asgothian]

@BananaJoe sagte:

@Asgothian sagte:

Ein Wichtiger Punkt noch zu den per Lan angebundenen Koordinatoren - diese haben oft intern ein NVRam, in dem sich ab Werk bereits eine ExtPanID befindet - es kann also zu problemen kommen wenn man nach meiner Anleitung den Wechsel von Koordinator A auf Koordinator B durchfürt. Um das stabil zu können muss der Koordinator die Option bieten das NVRam zu löschen. Der Cod.M tut das, bei den Sonoff und SLZB bin ich da unsicher.

Wäre das hier das passende beim Sonoff?

Ja

[klassisch]

Habe jetzt die FW des Coordinators auf
Konfiguration nun
• type:ZStack3x0
• version:2-1.2.7.1.
• revision:20250321
upgedatet.
Jetzt sind aber wieder alle Namen gelöscht. Ist das normal?

[Asgothian]

@klassisch Eigentlich nicht. Wie hast du die Namen geändert ? Über das Zigbee UI oder im Objektbaum ? Auch - was steht in deiner localOverrides.json (liegt unter /opt/iobroker/iobroker-data/zigbee_0

A.

[klassisch]

Vielen Dank! Geändert habe ich im Objektbaum.
In den Overrides steht großteils die gelöschten Namen bzw. die types und nicht die von mir gegebenen Namen.

Was ist best practice, damit es persistent wird?

Edit: Ich sehe, daß die Overrides geändert werden, wenn ich die Namen in den Adapterkacheln ändere.
Aber nicht, wenn ich im Objektbaum ändere, was aber für mich besser funktioniert, weil die Reihenfolge mit der zuvor erzeugten Liste übereinstimmt.

[Asgothian]

@klassisch sagte:

Edit: Ich sehe, daß die Overrides geändert werden, wenn ich die Namen in den Adapterkacheln ändere.
Aber nicht, wenn ich im Objektbaum ändere, was aber für mich besser funktioniert, weil die Reihenfolge mit der zuvor erzeugten Liste übereinstimmt.

Das wird in der 3.5 erst wieder gehen - ich hab da an einzelnen Stellen Probleme wegen der Auto-Benennung aus den Converters.

Ist bekannt, und in Arbeit. Technisch einfach - die Logik klemmt etwas

A.

[klassisch]

Das heißt, ich muß jetzt in den Kacheln ändern?
Objektbaum und overrides erledigt dann der Adapter?

[Asgothian]

@klassisch sagte:

Das heißt, ich muß jetzt in den Kacheln ändern?
Objektbaum und overrides erledigt dann der Adapter?

Ja.

[klassisch]

Ich habe jetzt mit Python die LocalOverrides aus meinen xls Daten generiert. Scheint so weit zu gehen.

[Asgothian]

Ich hoffe du hast es ausgetauscht währender Adapter aus war.

[klassisch]

Ja, anschließend den Adapter neu gestartet. Der Adapter hat dann alles eingelesen und etwaige Änderungen, die ich danach in den Kacheln vorgenommen habe, wieder schön in die Overrides eingepflegt. So gesehen sieht das aus meiner Laiensicht gut aus.

Was wohl auch funktioniert hätte:

• Ändern im Objektbaum -> Die Änderungen werden in den Kacheln angezeigt
• Kacheln öffnen -> "Edit" Bearbeitung öffnen
• im Kacheleditor speichern. Dann ändert der Adapter auch die Overrides

[pmayer]

Sorry... ich weiß immer noch nicht worum es geht.

[Asgothian]

@pmayer Alles gut.

Es geht darum das die serielle Verbindung über TCP/IP empfindlich darauf reagiert wenn es im TCP/IP zu Paketverlust oder 'out of order' Paketen kommt.

Dabei kam die Frage auf wie gross der Puffer ist, über den die in den TCP/IP Paketen beinhalteten Daten seriell an den Chip weiter geleitet werden, und ob man diese Grösse konfigurieren kann.

A.

[pmayer]

Ah. Danke!

Das reagiert sehr empfindlich. Deswegen empfehlen wir nicht den Betrieb über WLAN.
Es gibt für ZigBee kein Protokoll zwischen Coordinator und zigbee-adapter. Da wird plain die serielle Verbindung auf TCP übersetzt.

Mir schwebt schon seit längerem vor, da ein Protokoll zu implementieren. Es gab auch schon Anstengungen vor ein paar Jahren im Home Assistant Universum....
Wäre was für die Zukunft. Dann könnte man ZigBee auch über WLAN machen.

[Asgothian]

Das passt zu meinen Erfahrungen. Ich habe an anderen Stellen negative Erfahrungen mit serieller Kommunikation via TCP/IP machen müssen - das hat im industirellen Umfeld am Ende nie sauber funktioniert weswegen die Firma bei der ich Arbeite davon Abstand genommen hat. 99.9% Stabilität reicht im industirellen Umfeld einfach nicht aus.

Aus meiner Sicht macht es leider wenig Sinn da ein Zwischen-protokoll zu etablieren nur um den Betrieb via WLan zu ermöglichen. Der Aufwand dafür ist signifikant, und ich gehe nicht davon aus das die Möglichkeit den Koordinator via WLan zu nutzen dazu führt das die Kunden einen höheren Preis akzeptieren. Ich habe regelmässig in Diskussionen feststellen müssen das lieber die billigste Hardware aus China bestellt wird als das man sich um Details wie vernünftigen Support, etc. Gedanken macht. Da kommt dann gerne die Aussage das wird doch sowieso alles in China hergestellt, warum soll ich dann die teurere Variante kaufen.

Das Risiko welches ich bei einem Zwischenprotokoll sehe ist das es letztendlich ja einen vollen seriellen Kommunikationszyklus zwischen Koordinator und Adapter abbilden muss. Da sind aber Grössen, Zeitverhalten und Latenzen schon interessant. Wobei ich halt auch skeptisch bin ob man damit wirklich alle Instabilitäten heraus bekommt.

A.

[pmayer]

Bin ich bei dir. Aber genaugenommen muss nur ein Layer dazwischen. Finde das in Python von Home Assistant gerade nicht. Aber es gibt schon Grundlagen.

Tasmota macht das über MQTT... da wandert aber die komplette Hostapplikation auf den ESP. Unser CZC wird dort auch schon untertstützt.
Damit hat man das Problem, falls man es denn hat, auch gelöst aber eben weniger ZigBee Hardware, die unterstützt wird.

Und ja... dass Leute sagen: "Geht doch schon viel günstiger" sehe ich oft genug im WLED Umfeld.
Bin ich auch hier (https://forum.iobroker.net/topic/84526/wled-grundlagen-von-smarterkram-olli-erklärt-von-mir) drauf eingengangen.