Ankündigung

Einklappen
Keine Ankündigung bisher.

basic.stateswitch wechselt visualisierten Zustand obwohl Aktor gesperrt

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

    basic.stateswitch wechselt visualisierten Zustand obwohl Aktor gesperrt

    Hallo,
    ich habe eine schaltbare Steckdose in smartvisu über das basic.stateswitch-Widget visulisiert:
    Code:
    {{ basic.stateswitch('', 'eg.buero.verbraucher.steckdose.schalten', 'icon', [0,1], ['it_pc.svg','it_pc.svg']) }}
    Das zugehörige Item ist folgendermaßen angelegt:
    Code:
    eg:
        buero:
            verbraucher:
                steckdose:
                    schalten:
                        type: bool  
                        visu_acl: rw
                        knx_dpt: 1
                        knx_listen: 3/1/110
                        knx_send: 3/0/110
                        knx_init: 3/1/110​
    Im Normalzustand bildet das Widget immer den Status des Schaltaktors ab. Alles ok.
    Sperre ich allerdings den Aktor, wird auf 3/0/110 vom Aktor keine Anwort zurückgesendet!
    So wird deutlich, dass der visualisierte Zustand nicht aus 3/1/110 kommt, sondern mit dem "Sollwert" 3/0/110 in der Visu wechselt! Auch der Wert aus/ein auf 3/0/110 toggelt als ob 3/0/110 direkt rückgekoppelt wird.

    Wie muss ich das Item anlegen damit immer der Status des Aktors (3/1/110) angezeigt wird?
    Die Lösung ist bestimmt nicht kompliziert!

    Vielen Dank für die Hilfe!

    #2
    Das item ist richtig angelegt. Das Problem ist, dass der smarthomeNG-Treiber von smartVISU das item nicht nur an smarthomeNG sendet, sondern auch gleich den internen Wertespeicher von smartVISU aktualisiert. Das kannst Du ändern, indem Du in ./drivers/smarthomeNG.js die Zeile 58 auskommentierst:
    Code:
        write: function (item, val) {
            io.send({'cmd': 'item', 'id': item, 'val': val});
          // widget.update(item, val);
        },
    ​
    Dann sollte der Treiber darauf warten, dass das item seitens smarthomeNG aktualisiert wird.

    Für Rückmeldung, ob das klappt, wäre ich dankbar.

    Gruß
    Wolfram

    Kommentar


      #3
      Ich hab das selbe Problem und hab deinen Vorschlag gerade ausprobiert. Funktioniert auch teilweise.
      Zusätzliche musste ich
      Code:
      eval: value if not sh..Sperre() else None
      in das SmarthomeNG-Item einfügen.
      Das Item in SmarthomeNG hat sonst den falschen Zustand und meldet den falschen Zustand zurück.

      Gruß Stefan

      Kommentar


        #4
        Moin Stefan,

        Danke für die Rückmeldung. „Funktioniert teilweise“ ist natürlich nicht der Anspruch für ein nächstes Release. Kannst Du eingrenzen, unter welchen Bedingungen es nicht funktioniert? Oder ist die eval-Zeile schon die vollständige Lösung?

        Gruß
        Wolfram

        Kommentar


          #5
          Wäre es nicht besser das Widget zu erweitern um bei gesperrtem Widget den Switch auch als gesperrt darzustellen?

          Kommentar


            #6
            Hallo Wolfram,

            Zitat von wvhn Beitrag anzeigen
            Kannst Du eingrenzen, unter welchen Bedingungen es nicht funktioniert?
            Sorry hier etwas detaillierter:
            Nur mit deiner Änderung:
            Code:
            [io.smarthomeng] receiving data:  {"cmd": "item", "items": [["Licht", true]]}
            [io.smarthomeng] sending data:  {"cmd":"item","id":"Licht","val":"1"}
            In SmarthomeNG ist das Item trotz Sperre True.

            Zitat von wvhn Beitrag anzeigen
            Oder ist die eval-Zeile schon die vollständige Lösung?​
            Wenn das Eval in SmarthomeNG eingefügt ist:
            Code:
            [io.smarthomeng] sending data:  {"cmd":"item","id":"Licht","val":"1"}​​
            Das Item bleibt auf False und sendet damit keine Antwort.

            Die Änderung wäre meiner Meinung nach nicht verkehrt. Außer dadurch wird irgendwas anderes kaputt gemacht.

            Der Vorschlag von bmx wäre natürlich die Goldlösung.

            Kommentar


              #7
              Danke für den Tip!
              Wundert mich ehrlich gesagt, dass ich der Erste bin, dem das auffiel.
              Ich habe den fix getestet, aber bei mir wechselt das Widget jedoch trotzdem den Status. Scheint keine Wirkung zu haben.
              Ich vermute auch, dass das Problem tiefer liegen könnte, als nur in der smartvisu.
              Ich bin zwar noch nicht ganz durchgestiegen, wie die verschiedenen Schichten bis zum Bus zusammenspielen, aber knxd-webif wird auch der Sollstatus als aktueller "Wert" abgebildet. Würde das das Unterbinden des Widget-Updates die Lösung sein, hätten wir eine Inkonsistenz zwischen dem Wert in knxd und der Darstellung in der Visu. Das könnte nicht absehbare Auswirkungen haben. (z.B. in einer smhNG-Logik)

              Aber Saubersten wäre wirklich das aktive Áuswerten des sperren-KOs und wenn gesperrt, das Unterbinden von
              Code:
               io.send({'cmd': 'item', 'id': item, 'val': val});
              OnTop die Visu des gesperrten Zustands über das "basic.stateswitch"-Widget wäre natürlich deluxe!

              Kommentar


                #8
                Der Fix sorgt dafür, dass smartVISU nur noch das anzeigt, was es von shNG über den Websocket gemeldet bekommt. Das ist glaube ich kein Fehler. Ich kann das auch als Option in der Konfiguration anlegen.

                Die tiefer gehende Frage ist, wie shNG die items behandelt. Wenn ich per Visu oder im Admin Interface auf ein item schreibe, nimmt dieses den Wert sofort an, oder wartet es auf Rückmeldung vom Bus (wenn sich die Adressen für knx_send und knx_listen unterscheiden)? Eigentlich sollte das Warten auf die Rückmeldung der Normalfall sein, wenn wir erwarten, dass die items immer die Zustände der Aktoren repräsentieren.

                Die Deluxe-Version könnt Ihr heute schon erzeugen, indem Ihr ein item für den Sperrzustand bereit stellt und den Stateswitch mit einem status.collapse versteckt, wenn die Sperrung aktiv ist.

                Gruß
                Wolfram

                Kommentar


                  #9
                  Danke für die Idee mit dem collapse.
                  Hier mein Codeschnipsel:
                  Code:
                  {{ status.collapse('locked', 'Sperre', '1') }}
                  <span data-bind="locked">
                  {{ basic.stateswitch('', 'Licht', 'icon', '', 'light_light.svg') }}
                  </span>
                  
                  {{ status.collapse('unlocked', 'Sperre', '0') }}
                  <span data-bind="unlocked">
                  {{ basic.symbol('', 'Licht', '', 'light_light.svg', '0', '', 'icon0') }}​
                  {{ basic.symbol('', 'Licht', '', 'light_light.svg', '1', '', 'icon1') }}​
                  </span>​
                  Für mich wäre das so OK.

                  Gruß Stefan

                  Kommentar


                    #10
                    Vielen Dank Wolfram für den Tip mit dem collapse!
                    Werde das dann auch so lösen.
                    Wobei das Beispiel von stopef schon viel Text für eine "einfache" Funktion ist.
                    Wenn ich jetzt denke, dass ich das für jedes Item so anlegen sollte, dann bläht das die ganze Sache schon ein wenig auf!

                    Wie oben bereits beschrieben, der angezeigte Wert unter "Wert" im WebIf von knxd ändert sich mit dem Sollwert von knx_send! Ich geh mal davon aus, dass dies der echte, aktuelle interne Wert von smhNG ist. Dieser wird dann wahrscheinlich auch in Logiken weiterverarbeitet?
                    Ohne es zu testen: Wenn ich z.B. in Smartvisu dann einen Sollwert auf True setze, der auf dem Aktor aber gesperrt ist, triggert die Logik mit True, obwohl der Istwert sich nicht ändert....Jetzt könnte man sich natürlich darüber streiten, ob dann die Logik auf den Sollwert in diesem Fall sinvoll ist. :-)

                    Nur zum Verständnis: Ich habe versucht das Update auf meinem PI unter /var/www/html/diver/io_smarthomeng.js durch Auskommentieren zu verhindern. Hat aber nicht gewirkt. Neustart hatte ich natürlich gemacht. Bin ich in der falschen Datei gewesen?
                    Zuletzt geändert von simon2k; 06.12.2022, 00:36.

                    Kommentar


                      #11
                      Die Datei ist die richtige. Neustart musst Du für smartVISU nicht machen, aber den smartVISU-Cache löschen und die Seite neu laden.
                      Der Fix hilft allerdings nicht, wenn in shNG nicht verhindert wird, dass ein gesperrtes item dort einen neuen Wert annimmt. Das erledigt der eval-Ausdruck von stoepf. smartVISU sendet ja weiterhin einen Schaltbefehl, aktualisiert die Anzeige aber erst mit Antwort des Backends und nicht mehr über den internen Kurzschluss.

                      Gruß
                      Wolfram
                      Zuletzt geändert von wvhn; 04.12.2022, 12:16.

                      Kommentar


                        #12
                        Der smartVISU Fix ist jetzt als Option im Develop. Als Default ist die Aktualisierung durch das Backend voreingestellt.

                        Gruß
                        Wolfram

                        Kommentar

                        Lädt...
                        X