Ankündigung

**hyman** · 10.11.2020, 14:23

Hallo Ralf,

ob man eine Stoppuhr leicht implementieren könnte, kann ich so aus dem Stegreif auch nicht sagen -- ich werd's jedenfalls mangels Bedarf zeitnah nicht machen.

Ich sehe aber für Dein Problem (Ansteuerung eises Stellventils) bessere Lösungen (sortiert nach meiner persönlichen absteigenden Präferenz):

0..10V-Stellmotoren statt der Dreipunktausführung verwenden und mit einem Analogaktor (z. B. von MDT) ansteuern
Dreipunkt-Stellmotoren mit ABB ES/S oder HCC/S ansteuern
Dreipunkt-Stellmotoren mit Jalousieaktor und etwas zusätzlicher Logik ansteuern

In allen drei Fällen kümmern sich andere Komponenten -- nicht der X1 -- um die millisekundengenaue Ansteuerung des Stellmotors, Das halte ich für deutlich betriebssicherer als von aufeinanderfolgenden Bustelegrammen die Einhaltung bestimmter zeitlicher Abstände zu erwarten.

Grüße von Horst

**matthiaz** · 10.11.2020, 14:37

Zitat von hubidoo Beitrag anzeigen

kennt jemand eine Möglichkeit im Gira L1/X1 eine Stoppuhr mit Ausgabe in Millisekunden zu realisieren?

Ich Zweifel auch an, dass eine Millisekunden genaue Steuerung via KNX Telegramme überhaupt möglich ist! Bus ist bei ca. 40-50 Telegrammen/Sekunde am Limit angekommen. Also etwa 1 Telegramm alle 20ms, und selbst das ist optimistisch... Ich würde eher sagen, dass alle 1-2 Sekunden das maximale ist, was Du vom Bus als "zeitnah" und "genau" erwarten kannst.

**hubidoo** · 10.11.2020, 16:08

Zitat von hyman Beitrag anzeigen

Hallo Ralf,

ob man eine Stoppuhr leicht implementieren könnte, kann ich so aus dem Stegreif auch nicht sagen -- ich werd's jedenfalls mangels Bedarf zeitnah nicht machen.

Ich sehe aber für Dein Problem (Ansteuerung eises Stellventils) bessere Lösungen (sortiert nach meiner persönlichen absteigenden Präferenz):

0..10V-Stellmotoren statt der Dreipunktausführung verwenden und mit einem Analogaktor (z. B. von MDT) ansteuern
Dreipunkt-Stellmotoren mit ABB ES/S oder HCC/S ansteuern
Dreipunkt-Stellmotoren mit Jalousieaktor und etwas zusätzlicher Logik ansteuern

In allen drei Fällen kümmern sich andere Komponenten -- nicht der X1 -- um die millisekundengenaue Ansteuerung des Stellmotors, Das halte ich für deutlich betriebssicherer als von aufeinanderfolgenden Bustelegrammen die Einhaltung bestimmter zeitlicher Abstände zu erwarten.

Grüße von Horst

Hallo Horst,

die vier Honeywell-Mischer sind halt Bestand. Typ sind VMM20 für 230V, die hängen momentan an Gira Solid-State-Heizungsaktoren.
Die gäbe es auch als 24V AC/DC mit 0-10V Ansteuerung. Dann wäre das überhaupt kein Problem, da sie dann direkt an der Heizungssteuerung verbleiben könnten.
Da sie jetzt nun mal da sind und das ein Fakelzug wäre, die Verkabelung und die Mischer zu ändern, bleiben sie eben so.

Die Heizungssteuerung berechnet aktuell über die Außentemperatur die Vorlauftemperaturen für die einzlnen Heizkreise und über das Delta die Mischerstellung in 0-100% und schreibt das in jeweils eine Gruppenadresse.

Aktuell sind für jeden Mischer zwei Binäreingänge zugeordnet für die jeweilige Anfangs- und Endposition.
Die Stoppuhr würde für die Referenzfahrt benötigt, um die Fahrzeit von links nach rechts und umgedreht zu erfassen.
Die Laufzeit / 100 entspricht dann 1%. Damit kann dann mit der Ist-Position, der Laufrichtung und der Zielposition die Zeit berechnet werden, die dann den entsprechenden Ausgang am Heizungsaktor eingeschaltet sein muss.

Ich habe das jetzt übergangsweise auf einem beaglebone mit KNX-Cape, der in einem Hutschienengehäuse sowieso in der Verteilung sitzt, umgesetzt, bis ich eine Lösung für den L1 gefunden habe.
Vermutlich werde ich mich mit der L1 SDK beschäftigen, um das besser zu lösen.
Da wird dann unten eine Stoppuhr und eine Mischersteuerung für 0-100% raus purtzeln.

Viele Grüße
Ralf

**hubidoo** · 10.11.2020, 16:45

Zitat von matthiaz Beitrag anzeigen

Ich Zweifel auch an, dass eine Millisekunden genaue Steuerung via KNX Telegramme überhaupt möglich ist! Bus ist bei ca. 40-50 Telegrammen/Sekunde am Limit angekommen. Also etwa 1 Telegramm alle 20ms, und selbst das ist optimistisch... Ich würde eher sagen, dass alle 1-2 Sekunden das maximale ist, was Du vom Bus als "zeitnah" und "genau" erwarten kannst.

Das brauche ich nur zur Berechnung der Laufzeitzuordnung je Delta in Prozent.
Da es bis zu 0,1% runter gehen kann wenn Delta K sehr klein ist, macht das Sinn, im Millisekundenbereich zu arbeiten.
Vom Ergebnis her spielt es keine Rolle, wenn es zu einem Versatz der Telegramme kommt, die kommen auf der Zeitleiste einfach weiter rechts an, das gilt dann für ein- und ausschalten. Es würde noch nicht einmal etwas ausmachen, wenn statt 1% der Mischer um 1,1% fährt, da die eigentliche Steuerung das wieder ausgleicht und über eine Endschalterfahrt der Versatz neutralisiert wird.

**hyman** · 11.11.2020, 18:10

Zitat von hubidoo Beitrag anzeigen

Die Stoppuhr würde für die Referenzfahrt benötigt, um die Fahrzeit von links nach rechts und umgedreht zu erfassen.

Haben die Dinger so viel Verschleiß, dass Du das dauernd neu ermitteln musst? Sonst kannst Du ja einmal die Fahrzeit messen und gut ist.

Die Frage ist dann immer noch, wie Du zwei Telegramme (Ein -- kurz warten -- Aus) in definiertem zeitlichem Abstand abschicken möchtest (könnte mit dem Formelberechnungsbaustein gehen). Und mit welcher Genauigkeit dieser zeitliche Abstand dann auch eingehalten wird.

Zitat von hubidoo Beitrag anzeigen

Vom Ergebnis her spielt es keine Rolle, wenn es zu einem Versatz der Telegramme kommt, die kommen auf der Zeitleiste einfach weiter rechts an, das gilt dann für ein- und ausschalten. Es würde noch nicht einmal etwas ausmachen, wenn statt 1% der Mischer um 1,1% fährt, da die eigentliche Steuerung das wieder ausgleicht und über eine Endschalterfahrt der Versatz neutralisiert wird.

Die Aussage halte ich für sportlich. Da der Bus ein shared-medium ist, kann es zu Kollisionen und Retries kommen. Da der Bus langsam ist, können so Deine Zeiten um zig Millisekunden verfälscht werden. Wenn die Mischer also nicht extrem langsam fahren, sammeln sich da schnell ungeahnte Ungenauigkeiten auf. Mit einer fertige Stellgröße (0..100%) aus einem Regler braucht man jedenfalls sehr häufige Referenzfahrten. Oder man riskiert, dass die Endstellung gar nicht mehr erreicht wird, wenn die Stellgröße 0% (oder 100%) wird.

Man könnte allenfalls die Regelabweichung in ein Tastverhältnis fürs Zu- oder Auffahren umsetzen, dann braucht man gar keine Referenzfahrten und die genauen Laufzeiten sind auch nicht so wichtig (weil sie nur die Regelsteilheit beeinflussen). Dann baut man aber den Regler selber, mit allem Aufwand der da dran hängt.

Oder man macht es gleich richtig mit Komponenten, die dafür vorgesehen sind -- siehe mein Post oben.

**hubidoo** · 11.11.2020, 23:16

Zitat von hyman Beitrag anzeigen

Haben die Dinger so viel Verschleiß, dass Du das dauernd neu ermitteln musst? Sonst kannst Du ja einmal die Fahrzeit messen und gut ist.

Nein, sollten sie nicht haben. Honeywell VMM20 sind eigentlich schon sehr haltbar.
Ich würde ab und an alle paar Monate die Referenzfahrt anwerfen. Aktuell habe ich bei vier Mischern Laufzeiten zwischen 96 und 99 Sekunden gemessen mit meinem PoC-Referenzfahrt-Shellskript. Die Werte unterscheiden sich zwar von Mischer zu Mischer, sind aber jeweils stabil in mehreren Fahrten. Zwischen Rechts- und Linksfahrt gibt es bei zweien ein Delta von einer Sekunde.

Die Frage ist dann immer noch, wie Du zwei Telegramme (Ein -- kurz warten -- Aus) in definiertem zeitlichem Abstand abschicken möchtest (könnte mit dem Formelberechnungsbaustein gehen). Und mit welcher Genauigkeit dieser zeitliche Abstand dann auch eingehalten wird.

Dazu müsste ich einen erweiterten Timer haben, der mit dem Fließkomma-Wert zurecht kommt. Aktuell klappt das im PoC weiter unten ganz gut.

Die Aussage halte ich für sportlich. Da der Bus ein shared-medium ist, kann es zu Kollisionen und Retries kommen. Da der Bus langsam ist, können so Deine Zeiten um zig Millisekunden verfälscht werden. Wenn die Mischer also nicht extrem langsam fahren, sammeln sich da schnell ungeahnte Ungenauigkeiten auf. Mit einer fertige Stellgröße (0..100%) aus einem Regler braucht man jedenfalls sehr häufige Referenzfahrten. Oder man riskiert, dass die Endstellung gar nicht mehr erreicht wird, wenn die Stellgröße 0% (oder 100%) wird.

Die Laufzeiten für einen Drehwinkel von 90 Grad betragen bei vier Mischern 96-99 Sekunden. Die Korrektur könnte man über die Binäreingänge regeln, wenn die Werte 0 oder 100% sind, dann sollen sie fahren bis die jeweilige Endschalter-Position erreicht ist. Das kommt nach meiner Beobachtung aktuell zwei Mal am Tag vor. Wenn es wärmer wird am Tag und dann keine Anforderung ansteht und wenn er später wieder einschaltet, also immer dann, wenn die entsprechende Pumpe aus- und wieder einschaltet. Aktuell fehlt das noch im PoC.

Man könnte allenfalls die Regelabweichung in ein Tastverhältnis fürs Zu- oder Auffahren umsetzen, dann braucht man gar keine Referenzfahrten und die genauen Laufzeiten sind auch nicht so wichtig (weil sie nur die Regelsteilheit beeinflussen). Dann baut man aber den Regler selber, mit allem Aufwand der da dran hängt.

Oder man macht es gleich richtig mit Komponenten, die dafür vorgesehen sind -- siehe mein Post oben.

Ich glaube, den Aufwand muss man gar nicht betreiben nach meinen Beobachtungen mit dem PoC.
Ja, da gebe ich dir grundsätzlich Recht mit den richtigen Komponenten, aber a) sind die Teile vorhanden, b) kostet die 24V Version mit 0-10V Ansteuerung 4x 2-300 Euro und c) haben die 24V Versionen nur 10Nm, statt 20Nm in der 230V-Version und sind an DN25 3-Wege-Mischer im oberen Grenzbereich, während die 230V Versionen bis DN60 können, daher gehe ich von einer längeren Haltbarkeit der Getriebe aus.
d) die Laufzeit der 24V Proportionalantriebe ist doppelt so lang über die 90 Grad.

Mein quick-and-dirty PoC vom Beaglebone sieht aktuell so aus (GAs sind nicht real), damit man vielleicht besser versteht, was ich genau vorhabe am L1:

Referenzfahrt via cron:
/usr/local/bin/knx-mischer4-referenzfahrt.sh

Code:

#!/bin/bash

GRPWR=/usr/lib/knxd/groupswrite
GRPR=/usr/lib/knxd/groupread
GRPCR=/usr/lib/knxd/groupcacheread

DEVNAME=mischer4
HOST=ip:127.0.0.1
GRPADDRLEFT="1/2/1"
GRPADDRRIGHT="1/2/2"
GRPADDRLEFTEND="1/3/1"
GRPADDRRIGHTEND="1/3/2"

RUNTIME=120
LOCKFILE=/var/lock/${DEVNAME}.lck
CONFDIR=/etc/knx/references
CONFFILE=${CONFDIR}/${DEVNAME}/calibration.value
PERCENT="\x25"
test -d ${CONFDIR}/${DEVNAME} || mkdir -p ${CONFDIR}/${DEVNAME}

status(){
  date
  printf "Tests:\n"
  printf "Status Linksfahrt (kälter): $(${GRPCR} ${HOST} ${GRPADDRLEFT})\n"
  printf "Status Rechtsfahrt (wärmer): $(${GRPCR} ${HOST} ${GRPADDRRIGHT})\n"
  printf "Linker Anschlag: $(${GRPCR} ${HOST} ${GRPADDRLEFTEND})\n"
  printf "Rechter Anschlag: $(${GRPCR} ${HOST} ${GRPADDRRIGHTEND})\n"
  printf "______________________________________________________\n"
}

drive_to_right_position(){
  RET="00"
  ${GRPWR} ${HOST} ${GRPADDRRIGHT} 1 2>&1>/dev/null
  while [ ${RET} -ne "01" ]; do
    RET="$(${GRPCR} ${HOST} ${GRPADDRRIGHTEND} | awk '{print $4}')"
  done
  printf "Rechter Anschlag erreicht\n"
  ${GRPWR} ${HOST} ${GRPADDRRIGHT} 0 2>&1>/dev/null
}

drive_to_left_position(){
  RET="00"
  ${GRPWR} ${HOST} ${GRPADDRLEFT} 1 2>&1>/dev/null
  while [ ${RET} -ne "01" ]; do
    RET="$(${GRPCR} ${HOST} ${GRPADDRLEFTEND} | awk '{print $4}')"
  done
  printf "Linker Anschlag erreicht\n"
  ${GRPWR} ${HOST} ${GRPADDRLEFT} 0 2>&1>/dev/null
}

#status
echo "$(date)" >$LOCKFILE
printf "Starte Referenzfahrt \"${DEVNAME}\"...\n"
drive_to_left_position
STARTR="$(date +%s)"
drive_to_right_position
ENDR="$(date +%s)"
RUNTIMER="$((${ENDR}-${STARTR}))"
printf "Laufzeit nach rechts: ${RUNTIMER} sek\n"
STARTL="$(date +%s)"
drive_to_left_position
ENDL="$(date +%s)"
RUNTIMEL="$((${ENDL}-${STARTL}))"
printf "Laufzeit nach links: ${RUNTIMEL} sek\n"
rm -f ${LOCKFILE}
RUNTIMESUM="$((${RUNTIMER}+${RUNTIMEL}))"
AVERAGE="$(echo "scale=2; ${RUNTIMESUM} / 2" | bc)"
PERCENTRT="$(echo "scale=3; ${AVERAGE} / 100" | bc)"
echo ${PERCENTRT} > ${CONFFILE}
printf "Ergebnis Referenzfahrt: 1${PERCENT} entspricht einer Laufzeit-Ansteuerung von ${PERCENTRT} Sekunden\n"

und das eigentliche Proportional-Skript ebenfalls via cron alle 15 Sekunden mit Versatz zu den anderen Mischern:
/usr/local/bin/knx-mischer4-percent-drive.sh

Code:

#!/bin/bash

GRPWR=/usr/lib/knxd/groupswrite
GRPR=/usr/lib/knxd/groupread
GRPCR=/usr/lib/knxd/groupcacheread

DEVNAME=mischer4
HOST=ip:127.0.0.1
GRPADDRLEFT="1/2/1"
GRPADDRRIGHT="1/2/2"
GRPADDRLEFTEND="1/3/1"
GRPADDRRIGHTEND="1/3/2"
GRPADDRSOLL="1/4/1"

RUNTIME=120
LOCKFILE=/var/lock/${DEVNAME}.lck
CONFDIR=/etc/knx/references
CONFFILE=${CONFDIR}/${DEVNAME}/calibration.value
ISTFILE=/tmp/${DEVNAME}.absolute-position
PERCENT="\x25"

test -e ${LOCKFILE} && exit 0

test -e ${ISTFILE} || echo "UNKNOWN" > ${ISTFILE}

drive_to_left_position(){
  RET="00"
  ${GRPWR} ${HOST} ${GRPADDRLEFT} 1 2>&1>/dev/null
  while [ ${RET} -ne "01" ]; do
    RET="$(${GRPCR} ${HOST} ${GRPADDRLEFTEND} | awk '{print $4}')"
  done
  #printf "Linker Anschlag erreicht\n"
  ${GRPWR} ${HOST} ${GRPADDRLEFT} 0 2>&1>/dev/null
}

status(){
  SOLLHEX="$(knx-eis5-decode.sh $(${GRPCR} ${HOST} ${GRPADDRSOLL} | awk '{print $4" "$5}'))"
  SOLL="$(echo "scale=2; ${SOLLHEX} * 10" | bc)"
  #printf "Soll-Wert ${DEVNAME}: ${SOLL}\n"
  IST="$(cat ${ISTFILE})"
  if [ "${IST}" = "UNKNOWN" ]
    then
      printf "IST-Position: unbekannt\n"
      drive_to_left_position
      IST="0"
      echo "${IST}" > ${ISTFILE}
  fi
  #printf "Ist-Wert ${DEVNAME}: ${IST}\n"
  if [ "${IST}" = "${SOLL}" ]
    then
      #printf "Wert unverändert\n"
      exit 0
  fi
  if [ $(echo "if (${SOLL} > ${IST}) 1 else 0" | bc) -eq 1 ]
    then
      date >${LOCKFILE}
      #printf "Soll-Position ist größer Ist-Position\n"
      DELTA="$(echo "scale=2; ${SOLL} - ${IST}" | bc)"
      REFTIME="$(cat ${CONFFILE})"
      RUNTIME="$(echo "scale=3; ${DELTA} * ${REFTIME}" | bc)"
      printf "$(date +%Y-%m-%d" "%H:%M:%S): ${RUNTIME}sek ${DEVNAME} nach rechts um ${DELTA}${PERCENT} auf ${SOLL}${PERCENT}\n"
      ${GRPWR} ${HOST} ${GRPADDRRIGHT} 1 2>&1>/dev/null
      sleep ${RUNTIME}
      ${GRPWR} ${HOST} ${GRPADDRRIGHT} 0 2>&1>/dev/null
      echo "${SOLL}" > ${ISTFILE}
      rm -f ${LOCKFILE}
  else
    date >${LOCKFILE}
    #printf "Soll-Position ist kleiner Ist-Position\n"
    DELTA="$(echo "scale=2; ${IST} - ${SOLL}" | bc)"
    REFTIME="$(cat ${CONFFILE})"
    RUNTIME="$(echo "scale=3; ${DELTA} * ${REFTIME}" | bc)"
    printf "$(date +%Y-%m-%d" "%H:%M:%S): ${RUNTIME}sek ${DEVNAME} nach links um ${DELTA}${PERCENT} auf ${SOLL}${PERCENT}\n"
    ${GRPWR} ${HOST} ${GRPADDRLEFT} 1 2>&1>/dev/null
    sleep ${RUNTIME}
    ${GRPWR} ${HOST} ${GRPADDRLEFT} 0 2>&1>/dev/null
    echo "${SOLL}" > ${ISTFILE}
    rm -f ${LOCKFILE}
  fi
}

status

Das kommt aktuell heraus:

Code:

2020-11-11 22:15:32: .490sek mischer4 nach links um .50% auf 76.70%
2020-11-11 22:16:47: .980sek mischer4 nach links um 1.00% auf 75.70%
2020-11-11 22:19:03: .784sek mischer4 nach links um .80% auf 74.90%
2020-11-11 22:20:32: 1.078sek mischer4 nach links um 1.10% auf 73.80%
2020-11-11 22:21:32: 1.372sek mischer4 nach links um 1.40% auf 72.40%
2020-11-11 22:22:47: 1.274sek mischer4 nach links um 1.30% auf 71.10%
2020-11-11 22:23:17: 1.078sek mischer4 nach links um 1.10% auf 70.00%
2020-11-11 22:24:04: 1.078sek mischer4 nach links um 1.10% auf 68.90%
2020-11-11 22:24:33: 1.078sek mischer4 nach links um 1.10% auf 67.80%
2020-11-11 22:25:17: 1.078sek mischer4 nach links um 1.10% auf 66.70%
2020-11-11 22:26:03: 1.078sek mischer4 nach links um 1.10% auf 65.60%
2020-11-11 22:26:32: 1.078sek mischer4 nach links um 1.10% auf 64.50%
2020-11-11 22:28:03: 1.078sek mischer4 nach links um 1.10% auf 63.40%
2020-11-11 22:29:33: 1.078sek mischer4 nach links um 1.10% auf 62.30%
2020-11-11 22:31:17: 1.078sek mischer4 nach links um 1.10% auf 61.20%
2020-11-11 22:34:48: 1.078sek mischer4 nach links um 1.10% auf 60.10%
2020-11-11 22:39:18: 1.078sek mischer4 nach links um 1.10% auf 59.00%

Für mich sieht das geschmeidig aus, da nicht so oft eingegriffen wird, wie ich erst dachte. Das sieht daher so aus, als sind die Laufzeitunterschiede entweder vernachlässigbar oder sie sind nicht so groß.

Für die Stoppuhr ist mir noch ein Anwendungsfall eingefallen.
Meine beiden Brunnenpumpen hängen an einem 300-Liter Druckbehälter, der quer in dem einen Brunnen auf Eisenbahnschienen liegt.
Über Luftaustrag muss ich aktuell ca. alle sechs Monate den Behälter neu mit Druckluft füllen. Das mache ich momentan bei Bedarf noch manuell über ein Magnetventil.
Über die Pumpenlaufzeit könnte man erfassen, wie weit der Behälter mit Brunnenwasser gefüllt ist und bei Unterschreitung der Zeit t, statt die Pumpen abwechselnd zu schalten, einfach das Druckluft-Magnetventil für die nächsten n Durchläufe schalten.

**hyman** · 13.11.2020, 16:14

Du kannst Deine 3-Punkt-Stellantriebe behalten und mit geeigneten Aktoren:

Zitat von hyman Beitrag anzeigen

ABB ES/S oder HCC/S

ansteuern.

Einen extra Server, nur um so grundlegende Funktionen damit weniger betriebssicher zu machen, das käme mir nie in den Sinn...

**hubidoo** · 13.11.2020, 19:07

Zitat von hyman Beitrag anzeigen

Du kannst Deine 3-Punkt-Stellantriebe behalten und mit geeigneten Aktoren:

ansteuern.

Einen extra Server, nur um so grundlegende Funktionen damit weniger betriebssicher zu machen, das käme mir nie in den Sinn...

Das ist ein Argument, das stimmt, aber wie gesagt, ist das erst mal eine Fingerübung als Proof of Concept (=PoC) und soll in den L1, sobald die Logiken verfügbar sind.
Oder meinst du mit weniger betriebssicher bereits den einen L1, statt vier Mischeraktoren?

Man kann, abgesehen davon, Server auch clustern, was beim Homeserver & Co. nicht geht, es sei denn man abstrahiert die Hardware und virtualisiert das auf einem hochverfügbaren Hypervisor.

Die Betriebssicherheit ist generell ein Thema. IP Router haben einen Netzwerk-Port. Fällt der Switch aus, ist Feierabend für die Funktionen, die über das Backbone müssen. Der L1 ist aber auch ein single-point-of-failure, genau wie ein Homeserver, Facilityserver, X1, usw.
Ausfallsicher ist das alles nicht. Dennoch liegen da Logiken, ohne die nicht wirklich mehr was funktioniert.

Der "extra" beaglebone Server ist sowieso da, da er in einem Hutschienengehäuse für die ETS5 VM den KNX Dongle bereit stellt und EnOcean-/1wire-Gateway ist. Ob da noch ein knxd mitläuft und eine Spielwiese für quick-and-dirty-Dinger bereit stellt, juckt ihn nicht.
Der beaglebone sichert sein blockdevice als Image jede Nacht auf einen NFS export, zudem läuft da ein bareos Backup um einzelne Files zurück sichern zu können. Fällt der aus, habe ich zwei Ersatz-BBs in der Schublade. Rein in den Schrank, booten, image zurück spielen, fertig.

Die Aktoren sind interessant, wenn man die Logiken und Heizkreissteuerungen tatsächlich im KNX haben möchte und man nur einen Kreis hat.
Bei vier Heizkreisen oder mehr wird das aber zur Kostenfrage. Da bekomme ich zwei UVR16X2 dafür, die auch direkt PWM Hocheffizienspumpen ansteuern können und über die dadurch optimierte Spreizung die Brennwerteffizienz vom Kessel verbessern. Da man extra noch ein KNX PWM Modul brauchen würde, wird das HCC/S uninteressant. Aktuell bin ich am Tauschen sämtlicher Pumpen gegen Grundfos UPM3 mit PWM. Für Solarthermie ist sie schon getauscht, was mir eine Effizienz- Verbesserung und eine höhere Gesamtleistung gebracht hat, der Holzvergaser hat eine PWM, die Warmwasserstation ist geregelt, die Mischerpumpen treffen nächste Woche ein und die Pumpe vom Gaskessel werde ich wohl auch noch tauschen.

KNX ist für Heizungssteuerungen zu umständlich und letztendlich zu teuer in größeren Anlagen. Den Fackelzug mit den Mischern mache ich nur, weil ich an keiner UVR16x2 genügend Ein- und Ausgänge mehr zur Verfügung habe. Um auf einem Steuerungstyp zu bleiben, müsste ich jetzt einen UVR610 in die Verteilung bauen und eine CAN-Leitung vom Heizraum in den Verteilerraum legen oder ich lasse es, wie es ist und erfinde die Stoppuhr für den L1.
Aktuell hängen die Mischer an zwei Gira 6-fach Heizungsaktoren und einem 8-fach Binäreingang für die Endschalter.

Ankündigung

Gira L1/X1: Fehlende Funktion: Stoppuhr

Gira L1/X1: Fehlende Funktion: Stoppuhr

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar