Ankündigung

Einklappen
Keine Ankündigung bisher.

Dpt275.100 / gira x1

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

    Dpt275.100 / gira x1

    Hallo Forum,
    folgende Problematik:
    Der Kunde hat Heizungsaktoren von Hager, die den Sollwert in 8-Byte-Breite erwarten. Das ist der DPT 275.100.
    Nun soll das Gebäude per GIRA X1 gesteuert werden. Der X1 kennt diesen DPT nicht. Ein Anruf bei GIRA ergab, daß die sagten, ich soll neue Heizungsaktoren einbauen.

    Damit wollte ich erstmal nicht losgehen. Habt Ihr noch eine Idee?
    Gruß
    Christoph

    #2
    ...am besten welche von Gira
    Punk ist nicht tot, Punk macht jetzt KNX

    Kommentar


      #3
      Hager würde die wahrscheinlich die Domovea empfehlen, aber 8 Byte für eine Solltemperatur ist schon eine Leistung.
      Gruß Florian

      Kommentar


        #4
        Zitat von Beleuchtfix Beitrag anzeigen
        aber 8 Byte für eine Solltemperatur ist schon eine Leistung
        Naja, der DPT275.100 ist 4x2 Byte Float mit dem Text "Temperatur Sollwert Einstellung für 4 HLK Modi". Somit kommt das mit 8 Byte gut hin. Ich verstehe nur nicht, warum Hager nicht auch einen Sollwert für jeden Kanal einzeln erlaubt? Welchen Vorteil soll es denn haben, immer bei 4 Kanälen gleichzeitig den Sollwert zu setzen?

        Gruß, Waldemar
        OpenKNX www.openknx.de

        Kommentar


          #5
          Hi nochmal,
          habe nun in den Parametern entdeckt, daß man unter "Sollwerte" von "kombiniert" auf "einfach" umstellen kann. Dann sind's wie gehabt 2 Byte ;-). Also doch noch alles gut...
          Gruß
          Christoph

          Kommentar


            #6
            Danke, kam mir auch irgendwie komisch vor, dass das nicht gehen sollte.
            Zuletzt geändert von Beleuchtfix; 09.12.2021, 08:53.

            Kommentar


              #7
              Zitat von mumpf Beitrag anzeigen
              ... Welchen Vorteil soll es denn haben, immer bei 4 Kanälen gleichzeitig den Sollwert zu setzen?
              The advantage is data consistency: if new values are set in different Telegrams, there may, between the transmissions, for the receiver, be moments where there are inconsistent situations. This cannot happen with a single Telegram and it is easier for the receiver to do exception handling.

              Kommentar


                #8
                In general, I see this point of consistency (i.e. with DPT19.001) and completely agree with you. I just wondered, what inconsistencies might happen with tempetatures of different heating channels.

                ​​​​​​But I don't know the application, probably there might be cases for inconsistencies...

                Regards, Waldemar
                OpenKNX www.openknx.de

                Kommentar


                  #9
                  EXAMPLE It would meet the user expectation if the setpoint for comfort would be lower than the setpoint for standby. So, a good implementation may supervise that this does not happen.
                  Imagine that the Setp Comfort is 21,5 °C and the Setp Standby is 20 °C.
                  Now imagine that - for whatever reason - the Setp Comfort is set in a single F16 Telegram to 19 °C.
                  What should the controller do? Accept this, and do unlogic things? Or wait until it gets the Setp Standby? May never come ...
                  Combining them all 4 together solves part of this.
                  This kind of exception handling is paid a lot of attention to and these constructs help in this.

                  Temperatures for different channels, in the same room/zone, should get the same temperature setpoint, or controllers can work in a main/secondary constellation.

                  Kommentar


                    #10
                    Thank you for the excellent explanation!

                    Regards,
                    Waldemar
                    OpenKNX www.openknx.de

                    Kommentar

                    Lädt...
                    X