Ankündigung

Einklappen
Keine Ankündigung bisher.

Blockly-Skript für Fensterstatus funktioniert nicht

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

    Blockly-Skript für Fensterstatus funktioniert nicht

    Hallo zusammen,

    ich habe mich kürzlich endlich dazu durchgerungen den Sprung von OH2 nach OH3 zu wagen. Ich habe bereits meine Things und Items in der neuen Umgebung aufgebaut und auch die Verbindung zu KNX funktioniert einwandfrei. Jetzt habe ich damit begonnen, meine alten Rules in OH3 neu aufzubauen. Hierbei versuche ich mich an den neuen Möglichkeiten, unter anderem Blockly.

    Ich arbeite gerade an einer recht simplen Regel, die den Item-Status an ein anderes Item übergeben soll. Es geht dabei um den Status meiner Fenster. Wenn die Group "gFensterkontakteEG" den Status OPEN einnimmt, soll der Status an das Contact-Item "ContactKNX_EG_AlleFenster" übergeben werden. Das letztere Item ist mit KNX verknüpft und dient dazu, ein Lämpchen an einer MDT-Statusanzeige in grün oder rot aufleuchten zu lassen.

    In OH2 lief die Regel bisher problemlos und ich habe versucht, diese in Blockly nachzubauen. Leider habe ich das Blockly-Skript noch nicht zum Laufen gebracht und erhalte in den Logs folgende Fehlermeldung:
    Code:
    Command 'OPEN' cannot be parsed.
    Hier zunächst der Code, den ich bisher in OH2 verwendet habe:
    Code:
    // Mindestens ein Fenster im EG ist offen oder alle sind geschlossen
    rule "Fensterstatus EG"
    when
    Item gFensterkontakteEG changed
    then
    if (gFensterkontakteEG.state==OPEN) {
    ContactKNX_EG_AlleFenster.sendCommand(OPEN)
    logInfo("Fenster_offen_LED.rules", "Mindestens ein Fenster im EG ist offen.")
    }
    else if (gFensterkontakteEG.state==CLOSED) {
    ContactKNX_EG_AlleFenster.sendCommand(CLOSED)
    logInfo("Fenster_offen_LED.rules", "Alle Fenster im EG sind geschlossen.")
    }
    end
    Und das ist der Code, der durch Blockly erzeugt wurde als ich versucht habe, die Regel dort nachzubauen:
    Code:
    if (itemRegistry.getItem('gFensterkontakteEG').getSta te() == 'OPEN') {
    events.sendCommand('ContactKNX_EG_AlleFenster', 'OPEN');
    } else if (itemRegistry.getItem('gFensterkontakteEG').getSta te() == 'CLOSED') {
    events.sendCommand('ContactKNX_EG_AlleFenster', 'CLOSED');
    }
    Auslöser: "When gFensterkontakteEG changed"

    Hat jemand eine Idee, was ich falsch gemacht habe?

    Viele Grüße
    Timo


    Zuletzt geändert von kruegertee; 01.10.2021, 14:16.

    #2
    Das Problem ist, dass OPEN und CLOSED tatsächlich keine gültigen Befehle sind. Genau genommen kennt ein Contact Item überhaupt keine Befehle. Es wundert mich insofern sehr, dass die Rule jemals funktioniert hat.

    Es gibt mehrere Möglichkeiten, mit dem Problem umzugehen, wobei wir allerdings schon weiter vorne ansetzen müssen.

    ContactKNX_EG_AlleFenster ist nämlich vermutlich mit einem contact Channel verknüpft. Nun ist es aber so, dass knx hier gar nicht den Status hält. Stattdessen tritt openHAB als "Besitzer" des Status auf. Also muss der Channel als contact-control definiert werden. Ist das der Fall, kannst Du durch Setzen des Status (postUpdate) den Status an knx senden(!)

    Eigentlich muss es sich auch gar nicht um ein Contact Item handeln, denn es geht darum, in knx eine LED ein- oder auszuschalten. Also könnte man genauso gut ein Switch Item verwenden, welches dann natürlich die Befehle ON und OFF kennt. Aber auch dieses wäre, wenn man dem logischen Aufbau folgt, als switch-control Channel zu verbinden und entsprechend müsstest Du den Status mit postUpdate setzen.

    Kommentar


      #3
      Hallo udo1toni,

      vielen Dank für die Rückmeldung und die Unterstützung! Jetzt wo Du es sagst, dämmert es mir auch. Ein Contact ist ja keine Lampe, daher ist es wirklich merkwürdig, dass sendCommand scheinbar funktioniert hat. Der Channel war bereits als contact-control definiert und mit dem postUpdate funktioniert nun auch die Übergabe des Status an das KNX-Item und die Lampe wechselt die Farbe. Dafür schon mal vielen Dank!

      Allerdings funktioniert das ganze noch nicht ganz zuverlässig. Ich habe die Fensterkontakt-Items in eine Group gepackt und gehe davon aus, dass da noch etwas nicht stimmt. Denn die Group gFensterkontakteEG wechselt nicht den Status bei einem bestimmten Kontakt obwohl dieser für sich den Status wechselt. Ich nehme an, dass es an der Aggregation Function liegt. Derzeit habe ich "One OPEN then OPEN else CLOSED" eingestellt und muss wohl mal mit den anderen Einstellungen experimentieren...

      Viele Grüße
      Timo

      Kommentar


        #4
        Ja, Du musst All CLOSED then CLOSED else OPEN verwenden.

        Worin nun genau der Unterschied liegt, kann ich Dir nicht sagen, aber ich vermute mal, dass es dann abhängig davon ist, ob das letzte bewegte Fenster nach der Bewegung offen oder geschlossen ist. Kann aber auch sein, dass tatsächlich nur dann OPEN gesendet wird, wenn genau ein Fenster offen ist.

        Da Du ohnehin eine Rule verwendest, kannst Du auch einfach wie folgt prüfen:
        Code:
        if(gFensterkontakteEG.members.filter[i|i.state == OPEN].size > 0) // mindestens ein Fenster offen
        Auf die gleiche Weise kannst Du auch bequem die genaue Anzahl geöffneter Fenster herausfinden
        Dieser Filter ist unabhängig von der Aggregation, das funktioniert auch, wenn eine Gruppe überhaupt keine Aggregation hat.
        Zuletzt geändert von udo1toni; 29.09.2021, 22:40.

        Kommentar


          #5
          Irgendwie ist da noch der Wurm drin...

          Der Abgleich mit KNX läuft mittlerweile wunderbar. Aber meine Gruppe ändert ihren Zustand nicht zuverlässig. Ich habe in der Gruppe im EG drei Fensterkontakte eingebunden. Zwei der drei Fensterkontakte funktionieren wunderbar und wenn ein Fenster auf oder zu ist oder beide wechselt die Gruppe zuverlässig den Status auf OPEN oder CLOSED. Nur der dritte Fensterkontakt wird von der Gruppe "ignoriert" (Technikraum Fenster). Wenn dieser OPEN oder CLOSED meldet, ignoriert die Gruppe das. Der Kontakt selber funktioniert einwandfrei und zeigt stets den korrekten Status an. Aber wie gesagt reagiert die Gruppe nicht darauf.

          Das sieht dann z. B. so aus:
          Status_Closed.JPG

          Hier noch ein Screen von den Einstellungen der Gruppe:
          Gruppe.JPG

          Nach etlichen Minuten ändert die Gruppe dann doch korrekt ihren Status und reagiert somit auf den Status des Technikraum Fensterkontakts. Doch dann findet kein Abgleich mehr mit dem KNX-Item statt und die Lampe wechselt nicht mehr die Farbe. Aber davon abgesehen ist das ja kein Zustand, dass sich der Status erst viel später ändert. Bei den anderen beiden Kontakten reagiert die Gruppe unmittelbar und auch die KNX-LED wechselt sofort die Farbe. In den Logs gibt es keine Fehlermeldungen, da sieht alles gut aus.

          Kannst Du Dir erklären, woran das liegen könnte?

          Kommentar


            #6
            Problem gelöst!

            Hier noch eine kurze Lösungsbeschreibung, falls andere auch mal vor diesem Problem stehen:

            Nachdem nur das eine Item nicht funktionierte, habe ich es entfernt und wollte es wieder neu erstellen. Dabei ist mir aufgefallen, dass trotzdem noch der Channel vom Thing bzgl. des Contact-States verlinkt war (obwohl ich das Kontakt-Item bereits gelöscht hatte). Ich habe dann festgestellt, dass ich den Channel des Fensterkontakts zweimal verbunden hatte. Einmal mit dem Kontakt-Item und einmal direkt mit dem Gruppenitem. Logisch, dass das Gruppenitem verwirrt war und mit den OPEN/CLOSED-Meldungen des Kontakts nicht viel anfangen konnte. Als ich den Channel vom Group-Item löste, war alles wunderbar.

            Hintergrund: Bevor ich verstand, wie Group-Items im neuen OH funktionieren hatte ich das Item zur Überwachung aller Fenster im EG erst als "normalen" Point angelegt und die Channel der Kontakte direkt mit dem Item verbunden. Dann hatte ich das Item nachträglich in ein Group-Item umgewandelt und dabei vergessen, wirklich alle Channel wieder zu lösen.

            Kommentar


              #7
              Kaum macht man‘s richtig, schon funktioniert‘s…

              Prima, dass Du den Fehler selbst gefunden hast, denn nach so etwas sucht man im Zweifel ewig…

              Die Group Items haben sich im übrigen seit OH1 nicht geändert… Group Items wurden noch nie direkt mit Channels (oder davor mit Bindings) gekoppelt.
              Zusätzliche Funktionen bei Items sind aber reichlich vorhanden, seien es die Profiles, Tags, Units of Measurement oder (mit OH3) das Semantic Model…

              Kommentar

              Lädt...
              X