Ankündigung

Einklappen
Keine Ankündigung bisher.

Feature-Vorschlag Custom dpts in KNX-Plugin

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

    Feature-Vorschlag Custom dpts in KNX-Plugin

    Hallo liebes SmarthomeNG-Team,

    vielen Dank für Eure tolle Arbeit. Das Upgrade auf Version 1.2 hat einwandfrei geklappt. Alles läuft wie gewohnt ohne irgendwelche Anpassungen. Selbst mit dem eibd läuft alles ohne Probleme.

    Wenn es jetzt wieder öfter Releases gibt, bekomme ich aber ein Problem: meine händischen Änderungen an der dpts.py, die ich für mein Tebis TS System brauche, sind bei jedem Upgrade wieder weg. Abhilfe würden anpassbare datapoints schaffen, die man in eine separate Datei auslagert.

    Das funktioniert auch, wenn man in der dpts.py im Import-Bereich die Zeile
    Code:
    from . import customdpts
    einfügt und dann im decode-Bereich unten z.B. 3 Funktionen zum Dekodieren der custom-dpts ergänzt (letzte drei Zeilen).
    Code:
    decode = {
        '1': de1,
        '2': de2,
        '3': de3,
        ....
       [B] 'cust1': customdpts.decust1,
        'cust2': customdpts.decust2,
        'cust3': customdpts.decust3[/B]
    }
    Das Gleiche noch einmal im encode-Bereich ("customdpts.encust1"...).

    In der Datei customdpts.py werden die Funktionen in gleicher Weise definiert, wie in dpts.py.
    In der item.conf sieht eine Definition dann so aus:
    Code:
     [[[licht_haupt]]]
                type = num
                visu_acl = rw
                knx_dpt = cust1
                knx_listen = 1/0/21
                knx_send = 1/0/21
    Ich habe dies versuchsweise umgesetzt und es funktioniert. Dennoch würde ich meine Installation erst umstellen, wenn der Vorschlag für gut befunden und in das Release aufgenommen wird. Vielleicht gibt es ja noch mehr so Exoten, die so etwas brauchen.

    Die Dateien könnte ich hier im Thread zur Verfügung stellen. Für einen pull-Request habe ich noch zu wenig Ahnung von github.

    Danke und Gruß
    Wolfram

    #2
    Hallo Wolfram,

    sind diese Datenpunkttypen Herstellerspezifisch oder sind das Standardpunkte, die noch nicht offiziell definiert worden sind?
    Das wäre ja ein wenig wie ein Plugin fürs Plugin?
    Martin Msinn macht sich derzeit gerade Gedanken, wie man bereits definierte Plugins und Teile davon für andere Plugins nutzbar macht, Beispielswiese cherrypy vom Backend für andere Plugins. Vielleicht kann man da generell eine Schnittstelle schaffen...

    Gruß,
    Bernd

    Kommentar


      #3
      Moin Bernd,

      "Plugin fürs Plugin" ist treffend formuliert.

      Wir beide hatten die Besonderheiten der Tebis-Anlage vor langer Zeit schon einmal diskutiert: https://knx-user-forum.de/forum/supp...ebis-ts-anlage. Tebis TS codiert offenbar die Nummer des Eingangs der Tasterschnittstelle in den Wert hinein, den es an die GA schickt. Man kann das als herstellerspezifischen Datenpunkttyp bezeichnen. Tebis TS war ja nie vollständig EIB-kompatibel sondern sollte eine einfachere und günstigere Alternative sein, die ohne ETS auskommt.

      Du hattest mich gewarnt, dass mir die Änderungen wieder verloren gehen, wenn ein neues Release eingespielt wird. Da es jetzt erfreulicher Weise öfter neue Releases gibt, wird das jetzt zum "Problem".

      Danke und Gruß
      Wolfram

      Kommentar


        #4
        Hi Wolfram,
        eigentlich ist ein solches Konzept nicht wirklich nötig... Wenn du dir sh.py immer mit git holst, bekommst du automatisch die Info, dass es einen merge-Konflikt in der dpts.py gibt. Der automatische merge sollte das Problem in 99% der Fälle lösen, da ja eher selten DPTs geändert werden.
        Ich will nur darauf hinaus, dass es alle nötigen Werkzeuge schon gibt...
        Gruß Waldemar
        OpenKNX www.openknx.de

        Kommentar


          #5
          Hi Waldemar,

          wahrscheinlich kenne ich mich zu wenig mit github aus. Beim Upgrade auf das neue Release wurde der pull abgebrochen. Der Konflikt der Versionen von dpts.py wurde angezeigt und ich wurde aufgefordert, meine Änderungen zu committen. Das habe ich nicht gewagt und deshalb die dpts.py löschen müssen, um den pull durchführen zu können. Danach musste ich meine Patches wieder neu einspielen, weil im Release auch eine Änderung der dpts.py enthalten war.

          Ich finde sicher einen Workaround, aber wenn die anpassbaren Datenpunkte für andere Anwender auch hilfreich wären, dann würde ich mich über die Übernahme meines Vorschlags freuen.

          Danke und Gruß
          Wolfram

          Kommentar


            #6
            Das müsste ein git Profi bestätigen, aber es sollte mit
            Code:
            ​​​​​​git fetch
            git rebase
            funktionieren. Der pull ist dafür nicht gedacht.
            Gruß Waldemar
            OpenKNX www.openknx.de

            Kommentar


              #7
              Sorry, habe unsinn geschrieben.

              Du musst Deine Änderungen "committen", dann kannst Du einen pull machen. Dabei passiert ein automatischer merge, der meiner Meinung nach sowieso fast immer erfolgreich sein wird.

              Gruß, Waldemar
              OpenKNX www.openknx.de

              Kommentar

              Lädt...
              X