OpenKNX-Logikmodul release

[mumpf]

Hi Hendrik,

die Idee, ein ganzes Logikmodul als Haupt- oder Failover-Modul zu definieren, ist zwar eine komplett andere als mein Ansatz auf Kanalebene, aber durchaus nicht schlecht. Allerdings glaube ich, dass sie noch schwerer zu lösen ist als mal ein paar Failover-Kanäle zu definieren.

Erstmal die Fehlannahme:

der Mechanismus für den Transfer existiert doch schon. Mal angenommen, die LMs haben die gleiche Version, dann kann ich sogar Logiken hier über das Forum synchronisieren :-)

Ja, aber nur über die ETS. Es gibt keinerlei Synchronisationsfunktionen für die Parameter in der Firmware. Und das wäre ohne ein UI, dass einen auf Fehler hinweist, auch nicht wartbar.

Wenn ganze Logikmodule als Failover-Module arbeiten würden, würde ich die Synchronisation dem User überlassen. Entweder über den ConfigTransfer, um einzelne Kanäle anzupassen, oder über eine Gerätekopie in der ETS.

Aber es geht gar nicht darum, ein paar Parameter über den Bus zu bekommen, das ist die rein technische Sicht. Es geht darum, was man von einem Failover erwartet.

Naiv würde jeder sagen: Der eine fällt aus, der andere soll einfach weitermachen, genau an dem Punkt des Ausfalls. Aber genau das wird nicht funktionieren.

Das Failover-Modul dürfte ja nicht senden, solange das Hauptmodul noch läuft. Wenn es aber nicht sendet, würden alle internen KO-Verknüpfungen nicht funktionieren. Die senden eben auch nicht. Eine Lösung wäre, alle Verknüpfungen über den Bus zu machen, aber dann erhöht man wieder die Buslast.

Was ist mit internen Zuständen (z.B. Zählern), die ihre Werte über den Busspannungsausfall hinweg speichern? Jetzt hat sich das ausgefallene Haupmodul nur aufgehängt und man startet es neu - und plötzlich schreibt es alte Zählerwerte auf den Bus, weil es logischerweise während des Hängers nicht zählen konnte.
Wenn man weiter nachdenkt, findet man sicherlich beliebig viele Komplikationen, die so ein Vorgehen nach sich zieht.

Deswegen sehe ich keine Chance, ein generisches Failover für ein ganzel Logikmodul anzubieten. Ich könnte unterstützende Funktionen einbauen, wie z.B. die Möglichkeit, das Senden der KO-Werte zu unterdrücken, bis es von Außen erlaubt wird (oder umgekehrt, als globale Sende-Sperre).
Aber das Failover-Konzept und die Gedanken, dass die implementierten Logiken im Failover-Fall auch weiterhin funktionieren, müsste der User schon selber machen.

Der Fall, dass man einfach die Parametrisierung von einem Modul auf ein anderes kopiert und dann der Eine den Ausfall des Anderen vollständig auffangen kann, wird eher selten sein.

Gruß, Waldemar

[mumpf]

Jede Zeitschaltuhr, also jeder Kanal für sich.

Gruß, Waldemar

[Sisamiwe]

Hallo,

ich habe eine Rückfrage zur Applikationsbeschreibung des Logikmoduls. Konkret geht es um:

Bei Neustart letzte Schaltzeit nachholen

Nach einem Neustart des Moduls kann die letzte Schaltzeit erneut ausgeführt werden. Sobald das Datum und die Uhrzeit erstmals über den Bus gesetzt worden sind, wird nach der spätesten Schaltzeit gesucht, die noch vor dem aktuellen Datum/Uhrzeit liegt. Dieser Schaltzeitpunkt wird dann ausgeführt.

Wird hier die letzte Schaltzeit JEDER definierten Zeitschaltuhr (also jedes Logikkanales) erneut ausgeführt oder die letzte ALLER in dem Logikmodul definierten Zeitschaltuhren?

Danke für die Klarstellung!

[henfri]

Hallo,

ich hab hier vorhin "Failover" gelesen und dann musste ich zum Essen kommen... Aber mein Hirn arbeitete daran.

Es wäre ja wirklich störend, wenn ein LM ausfällt. Ja, man kann es auf mehrere LM verteilen, aber das mindert das Problem nur um 1/N.

Logiksynchronisation müsste ja die Semantik der implementierten Logik erfassen und den Failover-Fall erkennen

Ich weiß nicht, wass der erste Part bedeutet (also: Ich denke schon, aber dann verstehe ich nicht, warum das nötig sei), aber der Mechanismus für den Transfer existiert doch schon. Mal angenommen, die LMs haben die gleiche Version, dann kann ich sogar Logiken hier über das Forum synchronisieren :-)

Wie wäre es also, wenn man jedem LM eine Priorität gibt. Eins ist Prio 0, eines 1, 2, 3 usw. Jedes sendet ein Heartbeat mit seiner ID auf eine GA. Wenn der Heartbeat kleiner der eigenen Prio ausbleibt, springt man ein.

Die Konfiguration der Logiken ist bei Prio 1,2,3 usw. gesperrt, da sie Slave (darf man ja nicht mehr sagen, aber ich bin zu faul die richtige Alternative zu suchen) sind.
Der Master sendet auf Kommando oder nach jeder Parametrisierung seine Konfigurations-Strings auf eine GA und die Slaves senden diese.

Ist bestimmt kompliziert zu implementieren. Aber müsste gehen, oder?

Gruß,
Hendrik

[jayem0]

Oh... da vergleichst Du aber wirklich Äpfel mit Birnen .

Da hast du Recht!

Ich habe einfach zu wenig Zeit ... dein Logikmodul gepaart mit dem OpenKNX IP Gateway inkl. Webserver mit Logikeditor (vllt. sogar mit Datenlogger via Influx) - hätte ich mein Leben zeitlich im Griff () würde ich das aufsetzen (also die Software).

[mumpf]

Aber die Synchronisierung der Config über mehrere Logikmodule per BUS (also analog zum Fingerabdrucksensor)

Oh... da vergleichst Du aber wirklich Äpfel mit Birnen . Fingerabdrücke zu synchronisieren, das ist nur der Austausch einiger weniger Daten, die gesamte Verarbeitung bleibt ja auf den Geräten. Logiksynchronisation müsste ja die Semantik der implementierten Logik erfassen und den Failover-Fall erkennen. Das ist wesentlich komplexer und - falls überhaupt abbildbar - dann nicht in der ETS.

Aber mit der nächsten Version wird es Möglichkeiten geben, gewisse Failover-Szenarien selber zu realisieren, ohne den Bus vollzumüllen. Es wird für alle zustandsbasierten Logiken gehen, also nicht für triggerbasierte Logiken wie z.B. Szenen oder zyklisches senden/Telegrammwiederholungen.

Was zum Beispiel gehen wird:

• Du hast ein einem Raum aus 4 Logikkanälen ein 8-fach OR gebaut, um festzustellen, ob im Raum noch irgendein Licht an ist.
• Du überträgst die 4 Kanäle exakt so wie sie sind per ConfigTransfer auf ein weiteres Logikmodul, dass den Failover machen soll.
• Du verbindest alle GA exakt gleich bei beiden Logikmodulen
• Beim Failover-Modul machst Du nun noch 3 Dinge am Gesamtausgang vom OR:
  1. Du setzt die EIN- und AUSschaltverzögerung auf 2/10 Sekunden
  2. Du sagst, dass der Ausgang nur senden soll, wenn der Wert vom KO sich geändert hat (diese Einstellung wird neu kommen)
  3. Du fügst dem Ausgangs-KO das S-Flag hinzu

Was passiert: Beide Logikmodule arbeiten exakt parallel. Das Hauptmodul ermittelt den Wert und sendet es normal über seine GA auf dem Bus. Da die GA auch mit dem Ausgang vom Failover-Modul verbunden ist und der auch das S-Flag gesetzt hat, empfängt der Ausgang vom Failover diesen Wert. Da man dem Failover-Modul gesagt hat, es soll erst nach 2/10 Sekunden senden und auch nur, wenn sich der KO-Wert geändert hat, wird es normalerweise nichts senden, da der Wert vorher über den Bus ins Ausgangs-KO geschrieben wurde. Falls das Hauptmodul versagt, wird das Failover-Modul den Wert nach 200ms senden.

Nachteil dieser Lösung: Lesetelegramme werden doppelt beantwortet (aber immer mit dem gleichen Wert). Das kann man auch nicht vermeiden, indem man das L-Flag an einem der Module zurücknimmt, denn man weiß nicht, welches Modul zuerst ausfällt.

Wie schon oben gesagt, das ist nicht dazu geeignet, Failover-Logiken zu bauen, die Telegrammwiederholungen brauchen, aber für Zustandsbasierte Logiken bekommst Du das sehr gut damit hin. Nur als Anregung...

Gruß, Waldemar

P.S.: Das läuft schon bei mir im Test...

[jayem0]

Ich kann Dir nur empfehlen, mehrere Logikmodule einzusetzen (also in verschiedenen Geräten), damit Du nicht neue "Single Point of Failure" (SPOF) in Deiner Anlage schaffst.

Aber die Synchronisierung der Config über mehrere Logikmodule per BUS (also analog zum Fingerabdrucksensor) kann das Logikmodul nicht, oder?

So als Failover im Prinzip.

[mumpf]

Marino Ich kann Dir nur empfehlen, mehrere Logikmodule einzusetzen (also in verschiedenen Geräten), damit Du nicht neue "Single Point of Failure" (SPOF) in Deiner Anlage schaffst. Ich hab 20 davon am laufen, Tendenz steigend. Nur weil 99 Logiken da sind, heißt ja nicht, dass man immer 99 Logiken ausnutzen muss.

Es ist auch immer das selbe Logikmodul, also das selbe Coding in jedem Gerät. Das ist genau der Knackpunkt von unserem Modulkonzept.

Gruß, Waldemar

[mumpf]

Nur um ganz exakt zu sein (und um Missverständnisse zu vermeiden):

nur dass 1-64 halt 6 bit sind

Genau, es sind 6 Bit im Wertebereich 0-63, die als Szenen 1-64 genutzt werden.

Beim Speichern wird das 7. bit zur 1.

Hier ist jetzt die Frage, wie Du zählst. Wenn Du die ersten 6 Bit mit 0-5 zählst, dann ist das korrekt, Bit 6 ist frei und Bit 7 ist das Speichern-Bit. Aber an sich ist es das 8. Bit, nicht das 7. Bit. Das 7. Bit ist bei Szenen immer 0.

Gruß, Waldemar

[henfri]

Super, vielen Dank!
Hatte ich so ähnlich im Sinn, nur dass 1-64 halt 6 bit sind. Beim Speichern wird das 7. bit zur 1.

Gruß,
Hendrik

[thewhobox]

Noch zu ergänzen: Die 129 bis 192 sind keine Szenen, sondern die Szenen 1 bis 64 mit dem Unterschied, dass sie gespeichert werden sollen und nicht aufgerufen.

Wenn man dir Info nicht braucht (zb wenn man eh nur Szenen aufrufen will) sind die beiden DPST kompatibel.

[willisurf]

DPT18 hat auch 1Byte, nicht 2. Aus Sicht Logikmodul sind beide DPT kompatibel.
Wenn man es genau nimmt, sagt DPT 17.001, dass das Gerät Szenen empfangen kann. DPT 18.001, dass das Gerät auch Szenen speichern kann.

Anders gesagt, DPT 17.001 geht von 1 bis 64, DPT 18.001 von 1 bis 64 und von 129 bis 192.

[henfri]

Hallo,

mein Dali-GW und mein Taster nutzen DPT 18.001 zur Szenensteuerung.
Das Logikmodul benutzt DPT 17.001. Sind die Kompatibel (18.001 ist ja 2byte und wenn darauf ein 1byte Wert kommt, könnte das richtig interpretiert werden, so meine Hoffnung).

Gruß,
Hendrik

[willisurf]

Die Geräte sind die gleichen, egal ob mit VPM/Logik oder nur Logik. Bei der Software würde ich immer VPM/Logik nehmen, da ist nicht weniger Logik drin, als bei einer reinen Logikmodul Software.

[Marino]

Es stört nie, mehrere Geräte zu haben und nicht nur eines. Ich mag das REG1 von Ing-Dom gerne. Davon habe ich 2 und zudem noch einen Multisensor. Ich teile alles ein wenig auf. Völliger Blödsinn ist das also eigentlich nicht.


Viele Grüße
Nils