Neues YouTube-Video: Visualisierung im Devices-Adapter

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