Ankündigung

Einklappen
Keine Ankündigung bisher.

Wieder mal Raffstore

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

    Wieder mal Raffstore

    Hänge wieder mal...

    Warum funktioniert das nicht?

    Gruß Wolfgang


    Code:
    // Things
    Bridge knx:ip:bridge [
    type="TUNNEL",
    ipAddress="192.168.xx.30",
    portNumber=3671,
    localIp="192.168.xx.25",
    readingPause=50,
    responseTimeout=10,
    readRetriesLimit=3,
    autoReconnectPeriod=60,
    localSourceAddr="1.1.241"
    ]
    
    {
    Thing device MDT_1_1_10 "Jal.aktor Flur-1.1.10" [
    address="1.1.10",
    readInterval=0
    ]
    {
    rollershutter OG_Buero_JalTuer_ud "RS Buero OG Tuer UD" <rollershutter> (OG_Buero, gJal) { channel="knx:device:bridge:MDT_1_1_10:chCud", autoupdate="false" }
    rollershutter OG_Buero_JalTuer_la "RS Buero OG Tuer LA" <rollershutter> (OG_Buero, gJal) { channel="knx:device:bridge:MDT_1_1_10:chCla" } }
    }
    
    // Items
    Type rollershutter : chCud "Kanal C UP/DOWN" [ upDown="1/1/0", stopMove="1/1/1", position="1/1/3+<1/1/5" ] // Jal. Buero OG Tuer
    Type rollershutter : chCla "Kanal C Winkel" [ upDown="1/1/1", position="1/1/4+<1/1/6" ]

    #2
    Things und Items vertauscht? Die Things haben die GA und die Items die Channels.

    Kommentar


      #3
      Du darfst die Definitionen nicht einfach irgendwie hinschreiben...
      Things in einer Datei knx.things (Endung exakt so, alles vor dem Punkt ist beliebig), im Ordner ./things/
      Code:
      Bridge knx:ip:bridge [
          type="TUNNEL",
          ipAddress="192.168.xx.30",
          portNumber=3671,
          localIp="192.168.xx.25",
          readingPause=50,
          responseTimeout=10,
          readRetriesLimit=3,
          autoReconnectPeriod=60,
          localSourceAddr="1.1.241"
       ] {
          Thing device MDT_1_1_10 "Jal.aktor Flur-1.1.10" [
              address="1.1.10",
              readInterval=0
          ] {
              Type rollershutter : chCud "Kanal C UP/DOWN" [ upDown="1/1/0", stopMove="1/1/1", position="1/1/3+<1/1/5" ] // Jal. Buero OG Tuer
              Type rollershutter : chCla "Kanal C Winkel" [ upDown="1/1/1", position="1/1/4+<1/1/6" ]
          }
      }
      Items in einer Datei knx.items (Endung exakt so, alles vor dem Punkt ist beliebig), im Ordner ./items/
      Code:
      Rollershutter OG_Buero_JalTuer_ud "RS Buero OG Tuer UD" <rollershutter> (OG_Buero, gJal) { channel="knx:device:bridge:MDT_1_1_10:chCud", autoupdate="false" }
      Rollershutter OG_Buero_JalTuer_la "RS Buero OG Tuer LA" <rollershutter> (OG_Buero, gJal) { channel="knx:device:bridge:MDT_1_1_10:chCla", autoupdate="false" }
      Die meisten Parameter der Bridge sind optional, default Werte müssen nicht notiert werden, localSourceAddre ist keine (!) der physikalischen Adressen des Interface, sondern eine (zwingend) unbenutzte physikalische Adresse. Man kann in ETS ein Dummy Device anlegen, dem man die physikalische Adresse zuweist, das Device darf aber nicht in Hardware existieren (Man könnte das Device auch openHAB nennen, dann wird das im Gruppenmonitor automatisch korrekt angezeigt)
      Zuletzt geändert von udo1toni; 30.09.2020, 19:11.

      Kommentar


        #4
        Hallo udo12toni,

        ist alles soweit klar,

        ich habe die Things und die Items nur zur Übersicht hier für meinen Beitrag zusammenkopiert. Die Things und die Items stehen natürlich in den entsprechenden Dateien. Das mit der localSourceAddresse ist auch keine Adresse des Interface, sondern die jeweilige phys. des Aktors. Die Switches funktionieren so ja auch problemlos. Vielleicht was das Zufall. Der Tipp mit dem Dummy Device ist vielleicht nicht schlecht. Muß ich ausprobieren ...

        Der Effekt ist nur, wenn ich die Items in der Datei scharfschalte, verschwinden alle Things und Items in der PaperUI und in Control. So ein Verhalten, als ob ein Schreibfehler bei den entsprechenden Items vorliegt. Ich finde nur nicht wo. Das ist hier die Frage...

        Ich habe jetzt die Items für die Rollershutter mit PaperUi angelegt und das funktioniert. Also sind die Things in diesem Fall korrekt. Nur wie gesagt, wenn ich die Items manuell in der Datei (siehe oben) anlege, klappts nicht. Vielleicht habe ich mich Eingangs zu undeutlich ausgedrückt ...

        Wolfgang

        Kommentar


          #5
          Wie gesagt, Du hast oben die verschiedenen Teile durcheinander gemischt. Ich kann mir irgendwie nicht vorstellen, wie das beim Einfügen passiert sein soll. Und es würde erklären, warum nichts funktioniert. Auch wird das Schlüsselwort Rollershutter in der *.items Datei mit großem Anfangsbuchstaben geschrieben, in der Channel Definition, die zwingend Bestandteil der Things Definition ist, muss aber das Schlüsselwort Type angegeben werden und das Schlüsselwort rollershutter wird klein geschrieben.

          Was die localSourceAddr betrifft: NEIN! Die localSourceAddr darf überhaupt nicht in knx vorhanden sein, weder in der Schnittstelle noch in einem Device. Diese Adresse ist exklusiv für openHAB und hat nichts mit irgendeiner Hardware zu tun. Lediglich die Reservierung der Adresse mittels eines nicht real vorhandenen Dummy Devices ist ok.
          Anders verhält es sich bei der address, die gehört sehr wohl zum jeweiligen Device, welches durch das Thing repräsentiert wird. Allerdings kann man sie auch weg lassen, wie auch die Parameter fetch, readInterval und pingInterval. Die address wird gemeinsam mit pingInterval verwendet, um das Device ONLINE oder OFFLINE anzuzeigen, die Anzeige hat aber keinerlei Auswirkungen auf irgendetwas (abgesehen natürlich von den entsprechenden Events). Weiterhin kann man bei gesetzter address mit dem Parameter fetch=true zusätzliche Informationen über das Device erhalten falls das Device das unterstützt. Für die Funktion spielt aber auch das keine Rolle.

          readInterval wiederum sollte nur in begründeten Ausnahmen gesetzt werden. Default ist die Einstellung readInterval=0, womit die Funktion abgeschaltet ist.
          Zuletzt geändert von udo1toni; 01.10.2020, 12:55.

          Kommentar


            #6
            Erst mal danke für die Hilfe.

            Problemlösung war die fehlerhafte Kleinschreibung von "Rollershutter" in der *.items Datei.

            Gleich anschließend die nächste Frage. Wie löscht man Items aus der internen Datenbank? Wenn ich bei den Things die Kanäle lösche und den Browser aktualisiere, sind diese Kanäle wieder da. In Control habe ich dann die Kanäle aus der DB und die Kanäle aus der Things Datei....

            Was bewirkt das "<" Zeichen bei der Angabe der Gruppenadressen?


            Kommentar


              #7
              Du musst zunächst alle Links der Items zu den Channels entfernen. Anschließend sollte es möglich sein, die Items aus der Itemliste zu löschen.

              Das < bedeutet, dass openHAB beim Systemstart versucht, von dieser GA den aktuellen Zustand zu lesen. Hat das Erfolg, so leitet det Channel diesen Status an den openHAB Bus weiter, so dass ein verlinktes Item diesen Status annimmt.

              Kommentar


                #8
                Items aus der Itemliste löschen ging nicht. Ich habe jetzt in der .things Datei das Thing komplett gelöscht und neu angelegt. Jetzt ist alles ok -> sehr seltsam ...
                Irgendwie erschließt sich mir die Logik des Systems nicht ..., d.h. es werden noch viele Fragen kommen

                Aber schon mal vielen Dank!

                Kommentar


                  #9
                  Da muss man ein wenig ausholen. Die erste Version von openHAB (openHAB1) bot ausschließlich Textkonfiguration. Als es an die Realisierung von openHAB2 ging, war ein großer Wunsch, openHAB per Browser konfigurieren zu können, und am besten dreiviertel automatisch. Deshalb wurde Paper UI entwickelt.
                  Allerdings wollte man unbedingt auch kompatibel zu openHAB1 bleiben, also durfte man auch weiterhin mit Text konfigurieren. Das Format der Textdatei war aber total unpraktisch, um es mit Paper UI zu verheiraten, also entschlossen sich die Entwickler, beide Konfigurationen parallel zu nutzen. Im Nachhinein war das vermutlich eine ungünstige Entscheidung, da quasi jeder, der neu dazu kommt, Probleme beim Verständnis hat.
                  Mit openHAB3 wird das aber ein Ende haben, dann gibt es keine zwei unterschiedlichen Konfigurationssysteme mehr, sondern nur noch eine Wahrheit, die dann wahlweise über UI oder über Text konfiguriert werden kann (und man kann jederzeit hin und her wechseln).

                  Für den Moment ist nur wichtig, wu wissen, dass Items und Things, die per Text angelegt werden, zwar in Paper UI angezeigt werden, aber nicht editierbar sind, während Items und Things, die in Paper UI erstellt wurden, in der Textkonfiguration nicht auftauchen.
                  Man kann aber von beiden Konfigurationen auf alle Elemente der anderen Quelle zugreifen, also z.B. ein Thing als Text anlegen, welches zu einer Bridge gehört, die in der UI angelegt wurde (umgekehrt genauso), oder auch ein Item per Text anlegen, welches dann mit einem Channel verknüpft ist, die in Paper UI erzeugt wurde (oder umgekehrt...)
                  Das macht es allerdings nicht eben übersichtlicher, so dass man schon sehr gute Gründe dafür haben sollte, das so zu machen...

                  Kommentar


                    #10
                    Also sollte man vielleicht nur noch die "PaperUI" verwenden. Ich bin deshalb auf der Textvariante unterwegs, weil ich das System verstehen wollte. Wenn man allerdings alles was in den Textdateien steht auch über der Web-Oberfläche machen kann, ist das wahrscheinlich wesentlich sicherer und natürlich schneller, oder gibts da irgendwelche Einschränkungen?


                    Zuletzt geändert von wolfgang12; 02.10.2020, 16:27.

                    Kommentar


                      #11
                      Sicherer im Sinne von "weniger Fehler bei der Konfiguration möglich". aber auch nur, weil man in der UI an vielen Stellen nur eine Auswahlmöglichkeit hat, während man in der Textdatei genau wissen muss, was man wo wie eintragen muss. Sobald man Freitext hat, gibt es genauso Probleme.
                      Schneller? Sicher nicht. Es sei denn, wir reden von Autodiscovery, das ist natürlich etwas anderes.
                      Es ist mitnichten so, dass es keinerlei Einschränkungen über Paper UI gibt. Es gibt keine Möglichkeit, Tags zu setzen (die braucht man bei bestimmten Bindings).
                      Über Paper UI kann man keine Sitemaps erstellen. Auch Scripte, Transformations usw. sind dort nicht zugänglich.
                      Rules kann man nur über die NG Rules Engine laufen lassen, die (zumindest was den über Paper UI ereichbaren Teil angeht) gegenüber der normalen DSL doch arg eingeschränkt ist.

                      Paper UI wird es in OH3 nicht mehr geben, OH3 bringt eine neue UI mit, die komplett anders funktioniert. Das hängt damit zusammen, dass der Entwickler von Paper UI eine Entwicklungsumgebung genutzt hat, mit der sich keiner der Entwickler auskennt (und er selbst ist nicht mehr mit an Bord), so dass man eh alles neu entwickeln musste. Insofern ist Paper UI eine Sackgasse, einzig der Umstand, dass es komplett über REST API an openHAB angebunden ist, bringt einen entscheidenden Vorteil, nämlich, dass die Konfiguration einfach übernommen werden kann.
                      Es wird aber entweder ein Tool geben, um die Textkonfiguration automatisch zu übernehmen, oder ein Tutorial, wie das mit geringem Aufwand manuell passieren kann.
                      Zuletzt geändert von udo1toni; 03.10.2020, 14:57.

                      Kommentar


                        #12
                        Ich habe gerade mal schnell geschaut: Ich benutze so knapp 500 Items, organisiert in knapp 70 Gruppen, u.a. um mit Einzeilern Daten in Influx zu speichern oder einen kompletten Raum oder ein Gewerk in der Basic UI anzuzeigen.

                        Ich könnte mir absolut nicht vorstellen, das alles in einer GUI zusammenzuklicken und nie im Leben wäre es schneller, als das mit copy & paste und sinnvollem search & replace in VSC zu machen.

                        Einer der Gründe für mich OpenHAB zu benutzen ist, das ich nicht alles über eine GUI machen muss. Tatsächlich benutze ich PaperUI praktisch gar nicht, außer zum warten/installieren von Bindings. Ich finde auch gerade den Bereich GUI und Visu bei OpenHAB sehr schwach - das mache ich alles mit einem X1.

                        Kommentar

                        Lädt...
                        X