Ankündigung

Einklappen
Keine Ankündigung bisher.

OpenKNX-Logikmodul release

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Hi,

    es müsste auch nicht die ganze Projektdatei sein, normalerweise reicht es, wenn Du das Gerät, auf dem die Logik läuft, aus den Projekt in ein neues Projekt kopierst (Wichtig: Mit allen GA, wirst Du beim Kopieren gefragt) und dann nur das neue Projekt mit der einen Applikation schickst. Ob wir die Hardware wirklich brauchen, weiß ich noch nicht - vielleicht. Ich würde erstmal dem Projekt eine Chance geben wollen. Aber noch eher vorher einer Telko.

    Gruß, Waldemar
    OpenKNX www.openknx.de

    Kommentar


      Mal eine Frage, wenn ich das Logikmodul in einem extra Gerät haben möchte, welches wäre dies dann am besten? Oder ist diese Idee völliger Blödsinn?

      Kommentar


        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

        Kommentar


          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.
          Gruß Bernhard

          Kommentar


            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

            Kommentar


              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.​
              Gruß Bernhard

              Kommentar


                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.
                OpenKNX www.openknx.de | Kaenx-Creator | Dali-GW

                Kommentar


                  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

                  Kommentar


                    Nur um ganz exakt zu sein (und um Missverständnisse zu vermeiden):
                    Zitat von henfri Beitrag anzeigen
                    nur dass 1-64 halt 6 bit sind
                    Genau, es sind 6 Bit im Wertebereich 0-63, die als Szenen 1-64 genutzt werden.
                    Zitat von henfri Beitrag anzeigen
                    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
                    OpenKNX www.openknx.de

                    Kommentar


                      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
                      OpenKNX www.openknx.de

                      Kommentar


                        Zitat von mumpf Beitrag anzeigen
                        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.

                        Kommentar


                          Zitat von jayem0 Beitrag anzeigen
                          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...
                          OpenKNX www.openknx.de

                          Kommentar


                            Zitat von mumpf Beitrag anzeigen
                            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).

                            Kommentar


                              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.

                              Zitat von mumpf Beitrag anzeigen
                              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

                              Kommentar


                                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!

                                Kommentar

                                Lädt...
                                X