Ankündigung

Einklappen
Keine Ankündigung bisher.

KNX Jalousien-Aktor - Nur mit Hex-Wert?

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

    KNX Jalousien-Aktor - Nur mit Hex-Wert?

    Liebe alle,

    nachdem ich mich nun schon eine ganze Weile so durchschlagen konnte muss ich nun doch mal professionellen Rat einholen. Ich habe im August eine neue Wohnung bezogen und in diesem Zusammenhang in ein KNX-System investiert, das mir ein befreundeter Elektriker installiert hat. Es wurden Aktoren von JUNG verwendet.

    Da ich in meiner alten Wohnung schon etwas mit OpenHab rumgewurstelt habe (Hue, Sonos, etc.) hatte ich recht schnell Erfolge was die Steuerung von Licht, Heizung und Rolladen angeht - aber wie so oft, der Teufel liegt im Detail.

    Und zwar würde ich gerne die Rolladen-Position prozentual einstellen, und hier hatte ich bisher kein Glück. Nachdem ich Google diesbezüglich gefühlt durchgelesen habe und alles nicht geholfen hat, bat ich den Elektriker nochmal bei mir vorbeizukommen und zu überprüfen, ob er die Rolladen über ETS ansteuern kann. Konnte er, er hat dann aber festgestellt dass dies nur über HEX-Werte möglich sei - hat er also den Wert "000" losgeschickt fuhr der Rolladen ganz hoch, "128" ungefähr zur Mitte und "255" ganz runter. Kein Problem dachte ich, dann kann ich das eben nicht direkt über ein einfaches Item lösen sondern muss mir eine entsprechende Regel basteln.

    Testweise habe ich dann folgende Items definiert ...

    Code:
    String Wohnzimmer_Rolladen_Wohnbereich_Position "Rolladen Position" (gWohnzimmer) { knx="1/1/6", autoupdate="false" }
    Switch Wohnzimmer_Rolladen_Wohnbereich_Position_Schalter "Rolladen Hoch/Mitte"
    ... und dazu die passende Regel:

    Code:
    rule RolladenTest
    when
        Item Wohnzimmer_Rolladen_Wohnbereich_Position_Schalter received update
    then
        if (Wohnzimmer_Rolladen_Wohnbereich_Position_Schalter.state == ON) {
            logDebug("TestRule", "Rolladen mitte")
            Wohnzimmer_Rolladen_Wohnbereich_Position.sendCommand("128")
        }
        else if (Wohnzimmer_Rolladen_Wohnbereich_Position_Schalter.state == OFF) {
            logDebug("TestRule", "Rolladen oben")
            Wohnzimmer_Rolladen_Wohnbereich_Position.sendCommand("000")
        }
    end
    Die IP-Schnitstelle im Schaltkasten scheint auch ein Signal zu erhalten (die entsprechende LED leuchtet kurz auf), der Aktor und dementsprechend auch die Jalousie sind aber gänzlich unbeeindruckt. Ich vermute dass ich den falschen Format habe, allerdings sieht der m.M.n. Log gar nicht so schlecht aus:

    Code:
    16:34:55.707 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.1.181:3671: sending connection state request, attempt 1
    16:34:59.210 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'Wohnzimmer_Rolladen_Wohnbereich_Position_Schalter' received command ON
    16:34:59.223 [INFO ] [marthome.event.ItemStateChangedEvent] - Wohnzimmer_Rolladen_Wohnbereich_Position_Schalter changed from OFF to ON
    16:34:59.250 [DEBUG] [ipse.smarthome.model.script.TestRule] - Rolladen mitte
    16:34:59.266 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'Wohnzimmer_Rolladen_Wohnbereich_Position' received command 128
    16:34:59.272 [INFO ] [tuwien.auto.calimero                ] - calimero.link.192.168.1.181:3671: send message to 1/1/6, wait for confirmation
    16:34:59.274 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.192.168.1.181:3671: cEMI L-Data.req from 0.0.0 to 1/1/6, low priority hop count 6 repeat tpdu 00 80 31 32 38 00 00 00 00 00 00 00 00 00 00 00
    16:34:59.275 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.1.181:3671: sending cEMI frame seq 136, wait for cEMI.con, attempt 1 (channel 161) 06 10 04 20 00 23 04 a1 88 00 11 00 bc e0 00 00 09 06 0f 00 80 31 32 38 00 00 00 00 00 00 00 00 00 00 00
    16:34:59.313 [DEBUG] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.1.181:3671: received cEMI L-Data.con with req 247
    16:34:59.317 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.192.168.1.181:3671: confirmation of 1/1/6
    16:34:59.321 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.192.168.1.181:3671: send to 1/1/6 succeeded
    16:34:59.324 [DEBUG] [tuwien.auto.calimero                ] - process 192.168.1.181:3671: group write to 1/1/6 succeeded
    16:35:05.491 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.192.168.1.181:3671: indication from 1.1.2
    16:35:14.322 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.192.168.1.181:3671: indication from 1.1.6
    16:35:35.454 [DEBUG] [tuwien.auto.calimero                ] - calimero.link.192.168.1.181:3671: indication from 1.1.2
    Hier der Vollständigkeit halber noch ein Auszug der entsprechenden Gruppenadressen:

    Bildschirmfoto 2017-09-24 um 16.32.57.png

    Wäre super wenn jemand eine Idee hätte, wie ich das ganze zum Laufen bekomme. Vielen Dank schon mal!

    #2
    Hallo,

    Dein Rolladenaktor benötigt den Datentyp 5.001, 8Bit vorzeichenlos, Prozent (0..100%). Stellt man den im ETS-Gruppenmonitor ein, wird der Wertebereich 0..100 % automatisch auf 0..255 roh umgerechnet. Stellt man fälschlich einen anderen Datentyp ein, dann hat man natürlich auch eine andere (oder gar keine) Umrechnung. Dann kann sich das schon so verhalten, wie von Dir beschrieben.

    Was ich nicht weiß, wie OpenHAB mit Prozentwerten umgeht. Ich denke aber schon, dass die beim Senden auf den Bus passend umgewandelt werden können, wird ja häufig gebraucht. Keine Ahnung, was man dazu genau tun muss, weil ich kein OpenHAB einsetze. Dein Log zeigt, dass da kein Prozentwert (5..001), sondern eine Zeichenkette (16.000 oder 16.001) an die Gruppenadresse 1/1/6 geschickt wird. Vielleicht einfach mal die Anführungszeichen weg lassen, damit's eine Zahl wird?

    Hast Du Deinen ursprünglichen Ansatz
    ... direkt über ein einfaches Item ...
    schon praktisch ausprobiert? Wenn ja, was ist da passiert?

    Grüße von Horst

    Kommentar


      #3
      Ein knx Rollladenaktor sollte mit einem Rollershutter Item gekoppelt werden. Aufgrund Deiner Daten sollte es so aussehen:
      Code:
      Rollershutter shutterEssen "Rollladen Essen [%d%%]" {knx="1/1/4,1/1/5,1/1/6"}
      Einzubinden ist das Item dann in der UI als
      Code:
      Switch item=shutterEssen
      was dazu führt, dass ein Item mit AUF/STOP/AB Knöpfen gerendert wird. Da es sich um ein Rollershutter Item handelt, wird als default ein Rollladen Icon gezeichnet, entsprechend der Position.
      Wenn Du das Item über eine Rule steuern willst, reicht ein
      Code:
      shutterEssen.sendCommand(100) //Schließt den Laden
      shutterEssen.sendCommand(0)   //Öffnet den Laden
      Allerdings sieht es nach dem ETS Screenshot ja danach aus, als ob es sich um eine Jalousie mit Lamellen handelt.
      Da kommt dann tatsächlich ein (kleines) Problem, da openHAB kein natives Item für Jalousien kennt, soll heißen, Du brauchst tatsächlich ein 2. Item für den Lamellenwinkel.

      Weiterhin ist es dringend anzuraten, Rückmelde-GA pro Aktorkanal anzulegen und mit dem openHAB Item zu verbinden, damit openHAB den Aktorstatus direkt bei Programmstart und auch bei manueller Bedienung (über die Wandtaster) zuverlässig korrekt anzeigt. Dabei sind die allgemein gültigen Regeln für Rückmelde-GA zu befolgen, also, dass es exakt ein Gerät am Bus gibt, welches auf Read Requests antwortet (der Aktor, mit gesetztem L-Flag) und dass es für jeden rückzumeldenden Kanal eine eigene GA gibt, wenn es also 3 Läden (an drei Aktorkanälen) gibt, gibt es auch 3 Rückmelde-GA, auch wenn diese Läden immer die gleiche Stellung haben sollen. Wenn Du die Position z.B. über 1/1/99 rückmeldest, sieht das Item dann so aus:
      Code:
      Rollershutter shutterEssen "Rollladen Essen [%d%%]" {knx="1/1/4,1/1/5,1/1/6+<1/1/99"}
      was bedeutet, dass die Position auf 1/1/6 gesendet und zusätzlich auf 1/1/99 empfangen wird. Bei Programmstart wird (wegen des <) auf der 1/1/99 ein Read Request gesendet, damit openHAB den aktuellen Status kennt.

      Kommentar


        #4
        Ach so, fast vergessen...

        Wenn man ein String Item definiert, dann wird openHAB auch Strings als Input erwarten und Strings auf den Bus senden. Wenn man eine Zahl anzeigen und als Zahl verwenden will, nutzt man mindestens ein Number Item, oder alternativ Dimmer oder Rollershutter Item. Wenn man ein Number Item verwendet, sollte man sicherheitshalber den gewünschten bzw. erwarteten DPT mit angeben:
        Code:
        Number myNumberItem "Meine Nummer [%.1f]" {knx="5.001:1/1/1"}

        Kommentar


          #5
          Ich nutze den DPT Wert schon beim Rollershutter.

          PHP-Code:
          Rollershutter Rollo_1 "OG 1 [%s %%]" (OG_Kinderzimmer2) {knx="0/0/50,0/0/51,5.001:0/0/56+<5.001:0/0/57"
          --
          Gruß
          Lothar

          Kommentar


            #6
            Genau. Ist in diesem Fall aber eigentlich nicht nötig, da der DPT für die Position ja schon bekannt ist. Das wäre nur dann wichtig, wenn man eine der beiden anderen GA weg ließe. Schaden tut's aber auch nichts

            Kommentar

            Lädt...
            X