VCCU Failover - Status update

Otto123 · 12 Juni 2019, 10:36:13

@frank: Wenn der Sensor angelegt ist (nicht gepairt) dann werden doch alle Nachrichten in ihm "verarbeitet". Die VCCU würde doch nur die Hilferufe aussortieren.

@kadettilac89 Wir wollen nicht darauf rumreiten ob der Sensor jetzt gepairt ist oder nicht. Für die Anzeige ist das nicht/kaum relevant. Wichtiger ist eigentlich zu wissen: was genau beeinflusst denn die VCCU, was ändert sich im System durch eine VCCU.

Leider ist auch nur im Wiki relativ lose beschrieben was sie tut und beeinflusst. Dabei ist mir jetzt der Satz aufgefallen:
Ein HMLAN/USB ist etwas enger verbunden als CUL IOs. Keine Ahnung was das bedeutet.

Ich bin gespannt was rauskommt bei deinem Test mit zwei CULs.

kadettilac89 · 12 Juni 2019, 10:45:34

Zitat von: Otto123 am 12 Juni 2019, 10:36:13
Ich bin gespannt was rauskommt bei deinem Test mit zwei CULs.

Ich teste es demnächst mal und poste. Vielleicht ist es ja so, dass der CUL etwas anders reagiert (bezogen auf Satz: in HMLAN/USB ist etwas enger verbunden als CUL IOs).

Hollo · 12 Juni 2019, 13:03:49

Zitat von: kadettilac89 am 12 Juni 2019, 10:17:00
Failover, ...sind jetzt Begrifflichkeiten. Was ich habe bzw. möchte ich ein Cold Standby. Ich stecke keine Hardware um. Ich habe 2 Server, einer läuft, einer nicht. Im Fehlerfall nach einem Monitoringalert starte ich Server2 remote der auch einen CUL hat. Statt VCCU könnte ich auch einen CH340 Chip nehmen, der hätte an jedem Server selbe ID. Jedoch will ich eindeutige ID haben (FT232).

Es gibt immer unterschiedliche Lösungsansätze und meist liegt der eingeschlagene oder favorisierte Weg auch weniger am Wollen, sondern mehr an äußeren Umständen wie vorhandenen Gerätschaften und/oder dem zur Verfügung stehenden Budget.
Daher ist das auch überhaupt keine Kritik; es sollen ja viel mehr Anregungen und Vor-/Nachteile aufgezeigt werden.

Ich habe die letzten 10 Jahre immer ein quasi identisches System für meinen Linux-Server parat gehabt; hätte so Teile oder alles tauschen können.
Gebraucht habe ich es nie, aber so habe ich mir damals viele Gedanken über die verschiedenen Möglichkeiten gemacht.

Daher (und wegen der Erfahrungen mit einigen USB-Devices) favorisiere ich mittlerweile (W)LAN-Devices.
Damit hat man halt die Möglichkeit, das System "davor" mit wenig Aufwand redundant zu machen; so wie Dein System plus der VM.

kadettilac89 · 12 Juni 2019, 13:22:33

Zitat von: Hollo am 12 Juni 2019, 13:03:49
Daher ist das auch überhaupt keine Kritik; es sollen ja viel mehr Anregungen und Vor-/Nachteile aufgezeigt werden.

Ist schon OK. Server, Virtualisierung, Netzwerk, Failover, Security ... mache ich beruflich. Da ist sowas auch mal Spielerei um Themen selber mal auszuprobieren statt nur in Büchern zu lesen. Für Fhem ist es sicher mit Kanonen auf Spatzen oder so, aber es laufen noch anderen Container mit drauf die ich redundant haben will. Habe auch Wlan und andere Protokolle, aber für Heizung ist HM gesetzt wegen Profilen und autarkem arbeiten ...

kadettilac89 · 15 Juni 2019, 09:37:54

Zitat von: kadettilac89 am 12 Juni 2019, 10:45:34
Ich teste es demnächst mal und poste. Vielleicht ist es ja so, dass der CUL etwas anders reagiert (bezogen auf Satz: in HMLAN/USB ist etwas enger verbunden als CUL IOs).

So,

- wenn ich 2 Cul an FHEM habe und einen abstecke bleibt der Status in der VCCU "CUL1: OK, CUL2: OK" obwohl einer der CUL auf disconnected geht. Mit beiden CUL getestet ...
* Event "CUL disconnect" ist im Eventlog
* Wenn ich auf "update" klicke wird der Status korrigiert
* Wenn ich FHEM restarte wird der Status korrigiert
- Pakete werden aber über den noch aktiven CUL geschickt. VCCU Konzept funktioniert

Für mich ist es wichtig, dass es mit einem aktiven CUL funktioniert, ob nun der Status in VCCU richtig oder falsch angezeigt wird ist für mich nicht von Bedeutung.

Die Statusanzeige wird nur beim Abstecken im laufenden Betrieb nicht aktualisiert. Das ist sowieso für mein Vorhaben kein Anwendungsfall.

martinp876 · 16 Juni 2019, 11:25:38

Der Status der vccu bei CUL ist nicht aktuell - bei HMlan schon. werde ich korrigieren.
Bei HMLAN ist es einfacher, da ein HMLAN die VCCU informiert. Bei der ccu habe ich keinen Zugriff auf den Code. Lässt sich aber machen.

Operationell ist das m.E. kein Problem. das wird nicht über den Status der VCCU geprüft, sondern direkt vom IO. Also im Detail:
- will ein Device senden wird geprüft, ob ein Senden schon aktiv ist.
+ Das IO device wird nicht geändert, wenn aktuell der Kommandstack abgearbeitet wird. Dies stellt die notwendige Timing kalkulation sicher
+ ist für dies Device aktuell kein senden am Laufen wird geprüft ob das IO in Betrieb ist und genutzt werden kann. Es wird also das passende (hoffentlich) IO gewählt.
+ Nachteil (dem Timing geschuldet) ist, dass das Senden scheitert, wenn das IO im Laufe des Sendens "verstirbt"

Den Update der CUL-states in den vccu state habe ich gescheut weil es möglicherweise zu erhöhter CPU Last führt.

kadettilac89 · 16 Juni 2019, 13:23:24

Zitat von: martinp876 am 16 Juni 2019, 11:25:38
Den Update der CUL-states in den vccu state habe ich gescheut weil es möglicherweise zu erhöhter CPU Last führt.

Hi Martinp876, wie es schein bin ich der erste dem es auffällt, und für mein Setup ist es nicht wichtig den Status zu haben. Bevor ich was umbaue schaue ich mir die Doku an und teste .. dadurch ist der Einstiegspost entstanden.

Wenn es zu CPU-Last oder anderen unerwünschten Effekten kommen kann, wäre eine Alternative das ganze in der Commandref und ggf. im Wiki als Einschränkung zu dokumentieren. Wer will kann sich per Notify ein Update einbauen.

Deine Erläuterung reicht mir weil es das Verhalten erklärt. Ich brauche keine Korrektur

Danke dir