Ankündigung

Einklappen
Keine Ankündigung bisher.

Status abfragen per Logik

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

    #16
    Danke erstmal für die ganzen tollen Antworten.
    Das ganze über bspw. das Logikmodul von MDT abzubilden erschließt sich mir jetzt...

    @mumpf:
    Es geht hier um Gira Taster, die einen integrierten Temperatursensor haben.
    Bspw. der Gira 517303

    Was hier jemand zufällig, ob dieser beim Read dann auch unterschiedliche Werte sendet ?

    Kommentar


      #17
      Zitat von geforce28 Beitrag anzeigen
      Was hier jemand zufällig, ob dieser beim Read dann auch unterschiedliche Werte sendet ?
      Am besten ausprobieren, einfach den ReadRequest aus der ETS ausführen.
      Gruß Bernhard

      Kommentar


        #18
        Der Taster kann doch aber einfach zyklisch senden, wenn der das alle 15-Minuten oder halbe Stunde macht, ist das doch ausreichend für eine ERR und dass das dann den Bus sehr belastet, müsstest schon einige hundert davon im Projekt haben. Eine Logik zu bauen und die den pollt für eine Temperatursteuerung ergibt da keinen Mehrwert / Entlastung des Busses.

        Andere Logiken die mit dem Wert arbeiten sollen und warum auch immer mal sich resetten oder der ganze Bus resettet wird, machen halt bei Bedarf für sich selbst einen Readrequest für das passende KO. das lässt sich über die Flags an den KO der empfangenden Geräte regeln. Und wenn man das ganze clever anstellt, dann müssen das auch nicht endlos viele Telegramme bei der Initialisierung sein.

        Zitat von geforce28 Beitrag anzeigen
        Was hier jemand zufällig, ob dieser beim Read dann auch unterschiedliche Werte sendet ?
        Der wird immer den Wert senden der im KO des Tasters anliegt. Es kann aber passieren das wenn der Taster selbst nie etwas sendet er dann auch nichts zum senden am KO hat oder halt das was er zuletzt mal gesendet hatte. Es wäre auszuprobieren ob er dann auch immer adhoc in sich selbst nach einem aktualisierten Wert schaut.
        ----------------------------------------------------------------------------------
        "Der Hauptgrund für Stress ist der tägliche Kontakt mit Idioten."
        Albert Einstein

        Kommentar


          #19
          Naja ich habe schon so 20 Stk davon...
          Das ist okay für den Bus, wenn die alle losballern ?

          Kommentar


            #20
            Das ist kein Problem, die senden ja auch nicht alle gleichzeitig, da Du immer nur ein Gerät gleichzeitig programmieren kannst, wird also der Startzyklus nie identisch sein und das Startverhalten bei Busreset lässt sich auch so einstellen, das die Taster mit einigen Sekunden Versatz starten.

            Problematisch sind keine Klimasensoren.

            Erst wenn Du sowas wie Stromzähler hast und da dann aus einem Gerät mal eben 100 Telegramme bei Wertänderung und zusätzlich zyklisch alle 30 Sekunden gesendet werden.
            Oder viele bunte Farbverläufe in einer hohen Folge absoluter Dimmbefehle gesendet werden mit entsprechenden Statusrückmeldungen, dann wird es eng auf dem Bus. Aber nicht bei ein paar Temperaturwerten für eine Heizung.
            ----------------------------------------------------------------------------------
            "Der Hauptgrund für Stress ist der tägliche Kontakt mit Idioten."
            Albert Einstein

            Kommentar


              #21
              Du musst die ja nicht gleichzeitig senden lassen.
              Gruß, Waldemar
              OpenKNX www.openknx.de

              Kommentar


                #22
                Göran, noch ein paar Detail-Infos für Dich.

                Zitat von gbglace Beitrag anzeigen
                Der wird immer den Wert senden der im KO des Tasters anliegt.
                Das ist immer der Fall. Auf einen ReadRequest hin wird immer der Wert geliefert, der aktuell im KO steht. Das muss aber nicht unbedingt der zuletzt gesendete Wert sein.

                Zitat von gbglace Beitrag anzeigen
                Es wäre auszuprobieren ob er dann auch immer adhoc in sich selbst nach einem aktualisierten Wert schaut.
                ​Und das ist nie der Fall: Damit ein KO immer "rechtzeitig" antwortet, wird nie "adhoc" aktualisiert, sondern (wie oben schon geschrieben) immer der aktuelle Wert geschickt.

                Der Trick liegt beim Beschreiben des KO. Die Firmware kann nämlich durchaus in KO schreiben, ohne dass die Werte gleich auf den Bus gesendet werden. Eine "gut" programmierte Temperatursensor-Firmware würde nach jedem internen Temperatur-Update (z.B. alle 5 Sekunden) diesen Wert in das KO schreiben, aber nur alle 15 Minuten (bei Zykluszeit 15 Min) wirklich veranlassen, den Wert auf den Bus zu senden.
                Die meisten Firmwares halten aber den internen Temperaturwert im Speicher und schreiben ihn nur alle 15 Minuten auf das KO und senden das gleich weiter auf den Bus. Das ist IMO dann eine "schlechte" Firmware.

                Bei den "guten" bekommt man dann beim "Polling" immer einen aktuellen Wert, bei den Schlechten wird der alte Wert einfach nur wiederholt (weil ja kein neuer Wert im KO steht).

                Gruß, Waldemar
                OpenKNX www.openknx.de

                Kommentar


                  #23
                  Und sind die bei mir verbauten Giras jetzt „gute“ oder „schlechte“?

                  Kommentar


                    #24
                    Zitat von geforce28 Beitrag anzeigen
                    Und sind die bei mir verbauten Giras jetzt „gute“ oder „schlechte“?
                    Hä? Das musst Du doch wissen, Du hast doch die Geräte und kannst es einfach ausprobieren!

                    Gruß, Waldemar
                    OpenKNX www.openknx.de

                    Kommentar

                    Lädt...
                    X