OpenKNX-Logikmodul release

[traxanos]

Die Aussage gilt auch für alle andere KNX Produkte und hat nichts mit OpenKNX zu tun. Du musst halt schauen was für eine Version du gerade in der ETS verwendest. Dazu kannst du dir die Eigenschaften des Gerätes öffnen und dann auf Information und Applikationsprogramm klicken.

[buster1536]

Das bedeutet das Gerätefirmware und KNX-Applikation nicht zusammen passt. Das kann zwei Gründe haben. Ggf hast du verschiedene Versionen oder aber verschiedene Typen (Big oder Normal) gemischt

Kannst du mir einen lösenden Tipp bitte geben, wie ich das jetzt lösen/herausbekommen kann? Ich war der Annahme, dass ich den Reg1 Bausatz genauso programmieren kann wie gewöhnliche Produkte.

[traxanos]

Das bedeutet das Gerätefirmware und KNX-Applikation nicht zusammen passt. Das kann zwei Gründe haben. Ggf hast du verschiedene Versionen oder aber verschiedene Typen (Big oder Normal) gemischt

[buster1536]

Hallo zusammen,
ich habe heute den OpenKNX REG1 versucht mit dem letzten 3.3.1 Release des Logikmoduls zu programmieren und bekomme leider die Fehlermeldung das die Produktdaten inkompatibel sind.

In der Doku habe ich leider nichts dazu gefunden - habe ich etwas falsch gemacht bzw. kann mir jemand bitte einen lösenden Tipp geben?

Danke euch!

[traxanos]

Wenn man weiter nachdenkt, findet man sicherlich beliebig viele Komplikationen, die so ein Vorgehen nach sich zieht.

Ja, mir fallen noch nen haufen weiterer Probleme ein.

Die Frage ist wirklich was möchte man mit dem Feature erreichen. EIn HW Ausfall halte ich generel für unwahrscheinlich, da diese nicht so komplex sind. Da sehe ich Softwarfehler eher als Problem. Aber hilft ein einfacher Failover nur bedingt. Beispiel kommt ein Telegram rein das zu einem Softwarefehler/Crash führt, betirfft dass ja in der Regel beide Geräte und würde vermutlich beide Geräte abschießen.

Willst du echtes HA haben, musst du viel mehr machen. Da muss die Hardware für ausgelegt sein und auch die Software und eigentlich sogar das Protokoll. Du musst theoretisch den Geräte aufgaben gebem zum lösen, um zu schauen ob diese noch korrekt arbeiten. Du musst Zuständesyncron halten (was du über so einen langsamen Bus vergessen kannst) uvm.

[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