Ankündigung

Einklappen
Keine Ankündigung bisher.

- √ - wiregate-patch für knx_write von Datum/Uhrzeit DPT 10.001 und 11.001

Einklappen
Dieses Thema ist geschlossen.
X
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    [wiregate] - √ - wiregate-patch für knx_write von Datum/Uhrzeit DPT 10.001 und 11.001

    Hallo Wiregate-Freunde,

    EXPERIMENTAL!

    Hier ein Patch für den wiregated.pl (PL30), mit dem knx_write auch Datum/Uhrzeit (DPT 11.001 und 10.001) schreiben kann. Diese DPTs werden bisher ignoriert, obwohl knx_read sie lesen kann.

    Vorweg: KNOW WHAT YOU DO - wer seinen wiregated.pl patcht, sollte auch wissen, wie er wieder zurückkommt, wenn was schiefgeht.

    Das Format, in dem der gepatchte knx_write die Werte für Datum/Zeit erwartet, ist kompatibel zu knx_read, also "Mo 12:34:23" für Zeiten (Wochentag und Sekunden dürfen entfallen, ist aber ungetestet) und "2012-04-15" für Daten.

    Daher sollten folgende Dinge alle funktionieren (bei mir klappt's):

    Code:
    use POSIX qw(strftime);
    
    $datum1=knx_read('0/7/12',300,11.001);
    $datum2=strftime "%F", time();
    $datum3=`/bin/date +"%F"`;
    
    knx_write('0/1/2',$datum1,11.001);
    knx_write('0/1/2',$datum2,11.001);
    knx_write('0/1/2',$datum3,11.001);
    
    $zeit1=knx_read('0/7/13',300,10.001); # lesen zB von der Wetterstation
    $zeit2=strftime "%a %X", time(),0,2,0,0,70,0,0; # Sommerzeit (1 statt 2 für Winterzeit)
    $zeit3=`/bin/date +"%a %X"`; # Zeitzone des WG
    
    knx_write('0/1/3',$zeit1,10.001);
    knx_write('0/1/3',$zeit2,10.001);
    knx_write('0/1/3',$zeit3,10.001);
    ...und hier der wiregated.pl-Patch, anzuwenden auf /usr/sbin/wiregated.pl.

    Vor dem Patch: Backup machen.

    Nach dem Patch: /etc/init.d/wiregated restart

    Code:
    @@ -416,6 +416,26 @@
               when (/^16/)             { $bytes = pack ("CCa14", 0, $apci, $value); }
               when (/^17/)             { $bytes = pack ("CCC", 0, $apci, $value & 0x3F); }
               when (/^20/)             { $bytes = pack ("CCC", 0, $apci, $value); }
    +          when (/^10/) 
    +      { 
    +          my %wd=(Mo=>1, Di=>2, Mi=>3, Do=>4, Fr=>5, Sa=>6, So=>7);
    +          my $wdpat=join('|',keys %wd);
    +          my ($w,$h,$m,$s);
    +          return unless ($w,$h,$m,$s)=($value=~/^($wdpat)?\s*([0-2][0-9])\:([0-5][0-9])\:?([0-5][0-9])?\s*/si);
    +          return unless defined $h && defined $m;
    +          $w=$wd{$w} if defined $wd{$w};
    +          $h+=($w<<5) if $w; 
    +          $s=0 unless $s;
    +          $bytes=pack("CCCCC",0,$apci,$h,$m,$s);
    +      }
    +          when (/^11/) 
    +      { 
    +          my ($y,$m,$d);
    +          return unless ($y,$m,$d)=($value=~/^([1-2][0-9][0-9][0-9])\-([0-1][0-9])\-([0-3][0-9])\s*/si);
    +          return if $y<1990 || $y>=2090;
    +          $y%=100;
    +          $bytes=pack("CCCCC",0,$apci,$d,$m,$y);
    +      }
               when (/^\d\d/)           { return; } # other DPT XX 10,11,15 are unhandled
               when (/^[1,2,3]/)        { $bytes = pack ("CC", 0, $apci | ($value & 0x3f)); } #send 6bit small
               when (/^[4]/)            { $bytes = pack ("CCc", 0, $apci, ord($value)); }
    Have fun,
    Grüße,
    Fry

    PS. Die Geschichte ist natürlich auch kompatibel zur Ansage von Datum/Uhrzeit mit dem Plugin Ansagen.pl, das ich letzte Woche ins SVN gestellt habe.

    #2
    Sehr schön, aber:

    Können wir uns darauf einigen, dass Patches und Vorschläge - wie in Open Source üblich - zunächst Upstream an den Maintainer geschickt werden und dessen Meinung eingeholt bzw. diesem die Veröffentlichung überlassen wird, nicht zuletzt weil wir bereits an PL31 arbeiten (und sogar bereits an den übernächsten Releases).

    Merci

    Stefan

    Kommentar


      #3
      Hi Stefan,

      Da können wir uns leider nicht so ohne weiteres drauf einigen, denn da bin ich dediziert anderer Meinung. Gerne diskutieren wir das mal aus (aber bitte in freundlichem Ton, bitte nicht so wie im Bereich Communitygate).

      Zitat von StefanW Beitrag anzeigen
      Können wir uns darauf einigen, dass Patches und Vorschläge - wie in Open Source üblich - zunächst Upstream an den Maintainer geschickt werden
      1. Genau das, was du vorschlägst, ist im Open-Source-Umfeld gerade nicht üblich. Im Gegenteil, man entwickelt mit Mailinglisten als zentralem Tool in aller Öffentlichkeit. Was ins nächste offizielle Release kommt, ist natürlich Entscheidung des Maintainers. Nicht aber die Entwicklung von Patches und deren Veröffentlichung.

      Beispielzitat aus Wikipedia: "The Linux kernel mailing list (LKML) is the main electronic mailing list for Linux kernel development, where the majority of the announcements, discussions, debates, and flame wars over the kernel take place..... LKML is the central place where Linux developers around the world share patches, argue about implementation details, and discuss other issues. The official releases of Linux kernel are indicated by an email to LKML. New features are discussed and most code is posted to the list before any action is taken." (Hervorhebungen sind von mir)

      Übrigens ist genau das auch ein Grund, warum Open Source so erfolgreich ist. Im Idealfall haben jetzt vielleicht schon ein paar Leute den Patch ausprobiert, vielleicht postet demnächst jemand eine Verbesserung oder macht noch einen kleinen Bugfix, und das erspart Makki und dir jede Menge Testarbeit.

      2. Ganz praktisch: In deinem Profil steht "Bitte keine PNs.". Wie soll es also gehen, dir/euch was privat und upstream zu schicken?

      Zitat von StefanW Beitrag anzeigen
      und dessen Meinung eingeholt bzw. diesem die Veröffentlichung überlassen wird
      3. Politisch ausgedrückt: in der Open-Source-Szene ist Zensur ein no-go. Was wäre, wenn der Patch nicht aufgenommen würde, weil ihr vielleicht entscheidet, dass ihr diese Funktion nicht supporten wollt? Auch wenn manche genau dieses Feature vielleicht haben wollen?

      4. Auch mal was Egoistisches: Manche, darunter auch ich, haben sowas wie einen (kleinen) Autorenstolz - man will der Welt ja auch zeigen, dass man was beiträgt, und dafür eine gewisse Anerkennung der Mitmenschen bekommen. Das motiviert einen selbst und sicher auch Dritte, die es lesen. Da möchte man auch nicht in einem langen Abspann irgendwo im README eines /usr/src/ - Unterverzeichnisses erwähnt werden, sondern den Patch offen zeigen dürfen.

      Zitat von StefanW Beitrag anzeigen
      , nicht zuletzt weil wir bereits an PL31 arbeiten (und sogar bereits an den übernächsten Releases).
      5. Prima. Wann kommt er raus? Deine und Makkis reguläre Antwort, wann irgendwas fertig wird: "Es ist fertig, wenn es fertig ist." Aha. Das würde also bedeuten, ich als Autor würde meinen Patch nicht im Forum veröffentlichen, sondern privatissime an euch schicken und dann hoffen, es im nächsten Update - wann immer der kommt - aufgenommen zu finden. Und was ist, wenn der nächste Patchlevel ein Jahr braucht? Siehe auch Punkt 3.

      (Zwischenbemerkung: eure Kommunikationslinie ist eure Entscheidung! - aber die Konsequenz ist nunmal, dass nicht jeder warten möchte. Und das ist wiederum die Entscheidung anderer...)

      6. Forks (z.B. Communitygate) sind im Bereich Open Source regelmäßig möglich und auch erwünscht. Wenn in der offiziellen Linie ein Patch nicht aufgenommen wird, kann es sein, dass eine Sub-Community einen Fork des Entwicklungszweiges gründet, in dem der Patch drin ist (vgl Cathedral/Bazaar-Diskussion). Das ist im Linux-Bereich zigmal passiert, und es hat Linux überhaupt nicht geschadet, im Gegenteil: Russound-Multizonenverstärker, Fermax-Türstation, Dreambox-TV-Settopbox, Wiregate-Hausautomatisierungsserver, Fritzbox-DSL-Router, Samsung Galaxy II sind nur einige Produkte, die auf Linux basieren.

      7. Am Ende mal etwas versöhnlicher (ich hab mich erst über dein Posting ziemlich aufgeregt): Ich gehe davon aus, dass dein Wunsch letztlich daher stammt, dass ihr keine Supportanfragen von Leuten haben wollt, die sich mit "wilden" Patches ihren Daemon zerschossen haben und jetzt nicht wieder hinkriegen. Um genau das in diesem Fall zu verhindern, habe ich Disclaimer und Vorsichtshinweise in meinem Posting eingefügt.

      Wenn man mehr als das machen möchte, ginge auch die Einrichtung eines eigenen Developer-Subforums (gerne!), aber dann bitte nicht passwortgeschützt, sondern genauso frei wie dieses hier (aber vielleicht mit weiteren Sicherheitshinweisen und roter Hintergrundfarbe o.ä.)

      8. Noch hinzugefügt: Die Linux-Tools diff und patch arbeiten so gut, dass auch sich überkreuzende Weiterentwicklungen (z.B. wenn jemand meinen obigen Patch auf einen wiregated.pl des Patchlevels 31 loslässt) in aller Regel funktionieren. Da es sich nur um eine einzige Einfügung handelt, gehe ich davon aus, dass das der Fall sein wird. Es sei denn, Makki ändert an genau diesem Punkt im Source ebenfalls was. Dann wäre die Auswirkung, dass patch den Patch ablehnt. Die tatsächliche Wahrscheinlichkeit, sich das System zu zerschießen, ist sehr begrenzt.

      Zum Schluss: ich hoffe, du nimmst mir die offenen Worte nicht übel. Ich finde euer Angebot fantastisch, das ihr rund um Wiregate und 1-wire gebaut habt, werde gerne auch weitere Produkte bei euch kaufen und finde sie auch nicht zu teuer, sondern genau richtig gepreist (Wiregate 2 wird man sehen - nur nicht übermütig werden :-).

      Und ich bin genau wegen der Frage "offen oder geschlossen" zum Wiregate gekommen und lehne Alternativen wie EibPC und Homeserver aus genau diesem Grund ab.

      Ich arbeite gerade an einem selbstoptimierenden Multi-PID-Heizungsregler für den Winter, für den ich auch eine eigene Testumgebung für Wiregate-Plugins geschrieben habe (um die Regelung im Zeitraffer testen zu können, ohne tatsächlich heizen zu müssen). Das und vielleicht mehr werde ich noch beitragen (vielleicht sehe ich mir auch den russconnectd noch an), und es kommt auch eurem Produkt zugute.

      Viele Grüße,
      Fry

      Kommentar


        #4
        OMG. Macht doch was ihr wollt.

        Ich denke, ich werde mich hier eine Zeitlang nicht mehr äußern, offensichtlich drücke ich mich zur Zeit ungeschickt aus...

        Kommentar


          #5
          Ich schrieb oben

          "Zum Schluss: ich hoffe, du nimmst mir die offenen Worte nicht übel."

          Schade.

          VG, Fry

          Kommentar


            #6
            Ich nehme es nicht übel, aber ich wollte auch keine Mords-Diskussion lostreten, schaffe ich zeitmäßig nicht.

            Kommentar


              #7
              Dann ist der Fall für mich ok.
              Viel Erfolg auf der LB. Ich schaffe es leider nicht hinzukommen.
              VG, Fry

              Kommentar


                #8
                Alles gut

                Steht hiermit auf der Liste, der Weg ist so schon grundsätzlich Ok*, wir sind gerade vielleicht etwas mit schlauen Vorschlägen ohne Patch überstrapaziert

                Makki

                *) Der Zeitversand findet bewusst nur zur vollen Sekunde statt um eine Präzision von ca. max. 50ms zu gewährleisten, ich hasse ungenaue Uhren
                EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                -> Bitte KEINE PNs!

                Kommentar


                  #9
                  Kleine Verbesserung: Sinnvollerweise sollte die Zeile

                  Code:
                  my %wd=(Mo=>1, Di=>2, Mi=>3, Do=>4, Fr=>5, Sa=>6, So=>7);
                  besser so ergänzt werden:

                  Code:
                  my %wd=(Mo=>1, Di=>2, Mi=>3, Do=>4, Fr=>5, Sa=>6, So=>7,
                          Mon=>1, Tue=>2, Wed=>3, Thu=>4, Fri=>5, Sat=>6, Sun=>7);
                  Dann spielt es keine Rolle, ob $LANG auf deutsch oder englisch
                  eingestellt ist.

                  Grüße, Fry

                  Kommentar


                    #10
                    Hallo,

                    da ich gerade Probleme habe, die Zeit auf den Bus zu senden, bin ich hier gelandet. In meiner wiregate.pl (PL36) sieht es so aus, als wäre dieser Patch noch nicht drin. Kann mir dazu jemand was sagen?

                    Datum kann ich übrigens senden, nur beim Senden der Zeit mit
                    Code:
                    knx_write($GA_Zeit,$Betreff->{Std}.":".$Betreff->{Min}.":00",10.001);
                    wird nichts gesendet.

                    Viele Grüße

                    Micha

                    Kommentar


                      #11
                      Stop, sorry, es ist drin. Steht paar Zeilen vorher in der wiregate.pl.

                      Trotzdem funktioniert die Zeit bei mir nicht. Wo kann ich hier nach Fehlern suchen? In der eibd.log steht nichts wenn der Befehl vom Plugin ausgeführt wird.

                      Viele Grüße

                      Micha

                      Kommentar


                        #12
                        So, selbst gelöst :-)

                        Ich musste die Zeit zweistellig senden, sonst hats nicht funktioniert. "sprintf" hat mich gerettet.

                        Hier mein CODE-Schnipsel:

                        Code:
                        knx_write($GA_Zeit,sprintf("%02d:%02d:%02d",$Betreff->{Std},$Betreff->{Min},00));
                        Viele Grüße

                        Micha

                        Kommentar


                          #13
                          Das Zeitformat muss immer zwei Ziffern haben, also zum Beispiel 06:03:09 oder auch 06:03. Nicht aber 6:3:9

                          VG, Fry

                          Kommentar

                          Lädt...
                          X