Ankündigung

Einklappen
Keine Ankündigung bisher.

Weitere sinnvolle Defaults?

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

    Weitere sinnvolle Defaults?

    Hallo,

    wir hatten ja gerade das Thema Visu=yes, was jetzt default ist.
    In der Diskussion hatte ich angeregt:
    vielleicht kann man hier noch eine Nummer größer denken:
    Ich fänd es praktisch Defaults und Defaults global für alle Children festlegen könnte.

    Sprich:

    Code:
    smarthome.conf:
    [item_defaults]
    visu=yes
    enforce_update=yes
    cache=yes
    sqlite=yes

    Und dann:
    Code:
    items.conf/MeineUnwichtigenItems.conf:
    [MeineUnwichtigenItems]
    cache=no 
    sqlite=no
    [[abba]]
    (hier wäre jetzt sqlite&co standardmäßig aus).

    Der Gedanke ist, dass Children oft ähnlich sind.
    Da spart man sich Copy&Paste (nicht so wichtig) aber vor allem ist es wartbarer, da man Änderungen nicht zig-mal machen muss.
    Das würde ich hier gerne noch einmal zur Diskussion stellen.
    Was haltet ihr hiervon?

    Ein aktuelles Beispiel:
    Eigentlich möchte ich meist:
    knx_listen=knx_send=knx_init
    Wäre super, das als Default zu haben.

    Gruß,
    Hendrik

    #2
    Ich kann mich dafür nicht so richtig erwärmen, mir fallen nur wenige Tags ein, wo ich das wirklich nutzen könnte. Einzig Visu=yes wäre vielleicht interessant.

    Allerdings finde ich die Scripte eher unleserlicher dadurch, Fehler schwerer zu lokalisieren. Durch das Excel-Macro zum Erstellen der Items geht das ja auch so recht fix.

    knx_listen=knx_send=knx_init meide ich wie der Teufel das Weihwasser

    Gruss
    Jochen.

    Kommentar


      #3
      Hallo,

      ich habe gerade noch so ein Beispiel:
      Wenn ich einen knx_dpt angebe, erübrigt sich doch type eigentlich, oder?
      Code:
      knx_listen=knx_send=knx_init meide ich wie der Teufel das Weihwasser
      Warum?

      Gruß,
      Hendrik

      Kommentar


        #4
        type ist Kern, knx_dpt ist Plugin. Höchstens eine Warning wert wenn abweichend.

        Rest auch so lassen. Frist keine Ressourcen und ist übersichtlicher.

        Kommentar


          #5
          Ein default hätte ich aber noch:

          Das Log gehört auf einer Linux Maschine (egal ob Pi oder x86) nach /var/log .

          Edit:
          Und ja man kann es mit symlinks sehr einfach ... so wie ich jetzt.
          Umgezogen? Ja! ... Fertig? Nein!
          Baustelle 2.0 !

          Kommentar


            #6
            Zitat von JuMi2006 Beitrag anzeigen
            Ein default hätte ich aber noch:

            Das Log gehört auf einer Linux Maschine (egal ob Pi oder x86) nach /var/log
            +1 (bzw. man könnte mal überlegen, um auch z.B. der Cache nach /var/shm gehen sollte und ggfl. bei einem Rechnerneustart weggeschrieben wird)

            Kommentar


              #7
              Hallo,


              Zitat von Robert Beitrag anzeigen
              type ist Kern, knx_dpt ist Plugin. Höchstens eine Warning wert wenn abweichend.
              Ich weiß.
              Ist aber doch dennoch ziemlich redundant, oder? Warum nicht einfach den type abhängig vom knx_dpt (wenn vorhanden)?


              Zitat von Robert Beitrag anzeigen
              +1 (bzw. man könnte mal überlegen, um auch z.B. der Cache nach /var/shm gehen sollte und ggfl. bei einem Rechnerneustart weggeschrieben wird)
              Und wo wir dabei sind:
              Warum gibt es überhaupt die sub-Struktur in /usr/local/smarthome?

              Warum liegt sh.py nicht im Dateibaum wie alle anderen Programme, also die Konfig in /etc/smarthome/...


              Gruß,
              Hendrik

              Kommentar


                #8
                Zitat von henfri Beitrag anzeigen
                Warum gibt es überhaupt die sub-Struktur in /usr/local/smarthome?

                Warum liegt sh.py nicht im Dateibaum wie alle anderen Programme, also die Konfig in /etc/smarthome/...
                hängt wohl mit der Entwicklung zusammen... denke es war so einfacher.. wenn auch nicht unbedingt besser. Anders hätte man noch einen Installer bauen müssen, oder der User kopiert dann immer wieder alles durch die gegend. Das einfach hochladen der entwickelten Änderungen ist dann eben auch schwieriger, da man es erst wieder in seinen Entwicklungsbaum einpflegen muss.

                Kommentar


                  #9
                  ne, /etc/local/smarthome finde ich schon gut. Die Vorstellung, /etc /items /logics /plugins womöglich verstreut über das ganze System zu haben (plugins nach /usr/local, bin naxch /usr/bin, /etc nach /etc/smarthome - und wo kommen Logiken hin) neeee.

                  Aber die Sachen die eh nicht in einer klassischen Sicherung sind (also /var/...) könnten an entsprechende Orte.

                  Kommentar


                    #10
                    Das regelt soweit ich weiss die LSB (linux standard base). Unterhalb /usr/local gibt es alles, was man braucht etc/ var/ usw. Das sollte erstmal reichen.

                    Später kann man dann normal ins System verteilen.
                    Derzeit zwischen Kistenauspacken und Garten anlegen.
                    Baublog im Profil.

                    Kommentar


                      #11
                      Zitat von greentux Beitrag anzeigen
                      Das regelt soweit ich weiss die LSB (linux standard base).
                      Filesystem Hierarchy Standard ? Wikipedia

                      Ein Grund mehr, zumindest /var/cache, /var/tmp, /var/local und insbesondere /var/log zu beachten.

                      Kommentar


                        #12
                        Ja ist ja ein Subset davon Robert...


                        /usr/localdistributionsunabhängige lokale Hierarchie. Hier kann und soll die lokale Systemadministration Programme und Daten ablegen, die von der entsprechenden Distribution des jeweiligen Systems unabhängig installiert worden sind, wie etwa selbstkompilierte oder unabhängig von der Distribution heruntergeladene Programme und Dateien. Den Installationsmechanismen der betreffenden Distribution ist es ausdrücklich untersagt, diese Verzeichnisstruktur zu berühren. Die Gestaltung der internen Struktur von /usr/local obliegt der lokalen Systemadministration und ist vom FHS nicht vorgegeben.
                        Wir sind doch noch bei distributionsunabhängig? Falls nicht, dann wird das Erstellen der Pakete die Verzeichnisse dann je Distri festlegen.
                        Derzeit zwischen Kistenauspacken und Garten anlegen.
                        Baublog im Profil.

                        Kommentar


                          #13
                          Hallo,

                          durch Nikos Items seines RTRs bin ich gerade hierauf gestoßen:
                          knx_init

                          If you set this attribute, SmartHome.py sends a read request to specified group address at startup and set the value of the item to the response. It implies 'knx_listen'.
                          "implies" hatte ich bisher immer als "benötigt auch" interpretiert.

                          Ist das falsch?

                          Ich sehe nämlich in der Konfiguration https://knx-user-forum.de/320939-post14.html ein Item, das nur knx_init hat.

                          Ist knx_init=1/2/3 also gleichzeitig auch knx_listen=1/2/3?

                          Gruß,
                          Hendrik

                          Kommentar


                            #14
                            Hallo Hendrik,

                            ja und ja.

                            Soll ich den Titel vllt. in "Dieses und jenes" abändern ;-)

                            Würde mittlerweile besser passen. Oder ist das nur ein Test ob ich den Thread auch lese?

                            Bis bald

                            Marcus

                            Kommentar


                              #15
                              Solange Du ihn ab und zu liest ist uns der Titel egal .
                              Umgezogen? Ja! ... Fertig? Nein!
                              Baustelle 2.0 !

                              Kommentar

                              Lädt...
                              X