Hinweis für die Profis: Viele der folgenden Erklärungen sind für den interessierten Laien gedacht und basieren auf Fragen, die ich per PN und eMail von verschiedenen Leuten erhalten habe, die sich mit der Trovis-Anbindung beschäftigt haben.

Ich bitte daher, die ganzen Vereinfachungen zu entschuldigen - sie dienen dem Gesamtverständnis. Sollte sich irgendwo trotzdem ein grober Schnitzer eingeschlichen haben, bitte kurz Bescheid geben - danke!

Über die Jahre hat sich eine Vielzahl von Computerschnittstellen etabliert. Im Zusammenhang mit Trovis-Reglern fallen in diesem Zusammenhang meist folgende Namen: RS232 (=RS232-C), RS485, RS232-TTL (=UART).

Schnittstellen unterscheiden sich hinsichtlich der verwendeten Kabel und Signale (z.B. Spannungspegel). Die folgende Übersicht soll das kurz verdeutlichen:

• RS232-C aus den 1960ern - bidirektional; mindestens 3, früher 9..25 Adern, Signalpegel +/- 15V, Kabellänge bis 15m,
• RS422 aus den 1970ern - bidirektional; 4 Drähte mit +/- 6V und Kabellängen bis >1km,
• RS485 aus den 1990ern - unidirektional; 2 Drähte mit -7/+12V und Kabellängen bis >1km,
• RS232-TTL aus den 2000ern - bidirektional; 3 Drähte, Digitalpegel 0V/5V oder 0v/3.3V und eine Kabellänge bis 50m.

Wichtig ist, dass man die Trovis an den richtigen Pins der Buchse mit einem Adapter ankabelt, der den erwarteten Signalpegel und das erwartete Signalverhalten hat. Deshalb wird ein RS485-Adapter in der Regel auch nicht an an den RS232-Pins der Trovis-Buchse funktionieren.

In den meisten hier aufgeführten Projekten wird ein UART (RS232-TTL) Adapter für die Anbindung der Trovis verwendet, der mit den RS232-Pins an der seitlichen Buchse verbunden wird. Obwohl es sich auf manchen Reglern um 232-C zu handeln scheint, reichen offensichtlich auch TTL-Spannungen für die Kommunikation. Viele Dokumente von Samson und KT-Elektronik machen hierzu widersprüchliche Angaben, z.B. hier auf S. 8 oder hier im Bild (zwei Dokumente von vielen, die ich für das Projekt gewälzt habe). Die Praxis zeigt jedenfalls, dass diese Konstellation funktioniert.

Bei seriellen Schnittstellen wie RS232 kommt hinzu, dass sie in verschiedenen Betriebsmodi gefahren werden können. Diese müssen auf beiden Seiten übereinstimmen - z.B. 19.600 8N1 (19600 bit/s, 8 bit, keine Parität, 1 Stopbit). Daher bei der Konfiguration des Adapters auf diese Werte achten - die Trovis macht immer 8N1, wahlweise mit 9.600 oder 19.200 baud (einstellbar am Regler unter PA6).

Für Interessierte - weiterführende Infos z.B. hier - gleichzeitig Bildquelle für oben.

Der mit der Trovis verbundene Computer (PC, Raspi, virtuelle Maschine auf einem NAS etc) unterhält sich mit der Trovis über eine 'physikalische' Schnittstelle (USB, Netzwerk - das, wo der Stecker reinkommt).

Die Schnittstelle wird über einen Gerätetreiber in das Betriebssystem eingebunden (Linux, Windows, Raspian) - der Treiber ist also quasi die 'Bedienungsanleitung' für das Betriebssystem, welches dann standardisierte Softwareschnittstellen für Anwendungsprogramme zur Verfügung stellen kann. Wäre das nicht so, müsste für die Hardware der ganzen verschiedenen Hersteller jeweils Individualprogrammierung betrieben werden.

Wichtig: Schnittstellen haben üblicherweise einen eindeutigen Namen (COM1 oder COM2 unter Windows, /dev/ttyUSB1 oder /dev/ttyserial1 unter Linux etc). Über diesen Namen werden sie von den Anwendungsprogrammen wie z.B. der Heimautomation angesprochen. Deshalb ist es wichtig, bei Verwendung von USB oder serieller Kommunikation die Software auf die richtige Schnittstelle einzustellen.

Nicht immer kann oder soll direkt über eine echte 'physikalische Schnittstelle' kommuniziert werden. Heutige Computer verfügen z.B. nur noch selten über eine echte serielle Schnittstelle COM1: oder COM2:.

Es gibt aber Software, die das typische Verhalten einer solchen Schnittstelle gegenüber dem Betriebssystem simuliert - also Anfragen dafür entgegennimmt, um dann die Kommunikation an eine andere Stelle umzuleiten (z.B. in das Netzwerk auf eine bestimmte IP, oder auf einen USB-Port). Das Ergebnis bezeichnet man als 'virtuelle Schnittstelle'. Somit muss man Software, die ausschließlich seriell kommunizieren kann/will/muss, nicht extra umschreiben.

Im Zusammenhang mit den verlinkten Trovis-Projekten kommt dabei folgende Software zur Anwendung:

^{(danke an @sancho679)}

socat ist eine komplexere Implementierung des 1995 erschienenen netcat-Befehls und gehört bei vielen UNIX-/Linux-Systemen quasi zur 'Grundausstattung'. Es verbindet zwei Endpunkte mit Datenströmen und kann die Kommunikation sogar zusätzlich abzweigen (z.B. um sie parallel zu beobachten - so ähnlich, wie auch Netzwerk-Sniffer wie Wireshark arbeiten). Obwohl socat eigentlich für die Kommandozeile gedacht ist, lässt es sich als Dienst im Hintergrund permanent machen ('daemon').

Im smarthomeNG-Projekt wird gezeigt, wie man mit socat eine virtuelle Schnittstelle /dev/trovis erstellt, über die ein Modbus-Server oder -Client dann kommunizieren kann. /dev/trovis ist dabei aus Sicht der Anwendung eine serielle Schnittstelle - in Wirklichkeit wird aber jegliche Kommunikation darüber an eine Netzwerk-IP weitergeleitet, und jegliche von dort eingehende Kommunikation geht über die simulierte 'serielle Schnittstelle' zurück an die Anwendung.

Was dort konkret kommuniziert wird (z.B. Daten gemäß Modbus-Protokoll, siehe unten) ist socat aber egal - es kennt nur seine Endpunkte und stellt die Datenströme dazwischen sicher. Möchte man also Modbus-Geräte darüber anbinden, muss man das Protokoll selbst bzw. mit Hilfe einer Bibliothek (z.B. pymodbus) selbst implementieren.

^{(danke an @volki21)}

Im Gegensatz zu socat ist mbusd ein echtes 'Modbus Gateway TCP/RTU' (siehe unten). Es ist ein Projekt von Victor Antonovich (3cky) und auf Github im Quellcode verfügbar.

mbusd verbindet sich auf der einen Seite permanent mit dem Modbus RTU-Gerät. Auf der anderen Seite kann es dann beliebig über Modbus-TCP angesprochen werden und übernimmt die Übersetzung TCP/RTU. Hierfür kann im System eine dauerhafte virtuelle Schnittstelle (z.B. /dev/trovis-mbusd) hinterlegt werden.

Der Clou: Man kann mbusd an einen bestimmten Netzwerkport binden. Beliebige Geräte können dann aus dem Netzwerk (also auch aus dem WLAN) über diesen Port auf mbusd and somit auf per RTU verbundene Trovis zugreifen. Dies ist daher der Weg, den man nutzt, um per Handy-App (55-Mobile, 55Pro - beide sprechen nur Modbus-TCP) auf die Trovis zuzugreifen.

Es wird dann sozusagen 'über Bande' an die Trovis gespielt:

Handy-App mit Modbus/TCP --> WLAN --> IP:Port Rechner mit mbusd --> mbusd wandelt in RTU um --> LAN --> RS232-Adapter --> Trovis

Trovis (RTU) --> RS232 Adapter --> mbusd wandelt in Modbus TCP um, IP:Port --> LAN --> WLAN --> Handy-App

Das ganze funktioniert natürlich nur, wenn auch der Rechner mit mbusd läuft - ist aber eine super Lösung, die Samson App's ins Spiel zu bringen. Und quasi so ganz nebenbei stellt mbusd auch noch (wie socat) eine virtuelle serielle Schnittstelle für auf dem Rechner installierte Software zur Verfügung.

Installation

Auch die Linux-Fraktion hat festgestellt - es nützt alles nichts, die wichtigste Software für die Trovis (TrovisView, Firmware-Updater) läuft unter Windows. Hier kommt das kommerzielle Programm VCom des Herstellers USRIOT in's Spiel. Die gute Nachricht: Das Programm ist kostenlos.

VCom sucht nach verfügbaren USRIOT Apdatern im Netzwerk und erstellt für diese eine virtuelle Schnittstelle COMx.

Das Verfahren samt Downloadlink ist bereits weiter vorn hier im Wiki beschrieben.

In diesem Screenshot werden die beiden Adapter für die Trovis und meine Helios KWL (anderes Projekt) im Netzwerk gefunden:

Der einzige Nachteil: Man weiß nie, was da eigentlich auch nach 'draußen' kommuniziert wird. Deshalb läuft VCom bei mir auf einer VM, die von/nach draußen durch die Firewall komplett geblockt wird - dasselbe gilt übrigens für die Adapter.

Ein Protokoll ist sozusagen die gemeinsame 'Sprache', in der sich zwei Geräte unterhalten. Wie bei der menschlichen Sprache sind dabei Worte, Satzbau, Betonungen und Pausen festgelegt - sonst versteht man sich nicht.

Es gibt viele verschiedene genormte Protokolle, die oft auch für bestimmte Schnittstellen / Verkabelungen / Anwendungsgebiete ausgelegt sind - z.B. CAN-Bus (Autos), Profibus (Industrie-Automatisierung), KNX (Hausautomation), M-Bus (Wärmemengenzähler, auch auf der Trovis) usw usw.

Die meisten der Trovis-557x-Modelle (bis auf die 5575/Pewo PCR06/...) sprechen Modbus, ein sehr schlankes Protokoll, das es bereits seit Ende der 1970er Jahre gibt.

Da Modbus eine reine Protokolldefinition ist, ist er unabhängig von der darunter liegenden Hardware ('Physical Network Layer'). Üblicherweise wird er aufgrund seiner Schlankheit bei seriellen Schnittstellen wie RS232, RS422 oder RS485 eingesetzt (siehe oben - Schnittstelle I).

Oft kommen Anfragen wie: "Mein Wechselrichter / Stromzähler / WP-Controller / WMZ / Heizungsregler hat eine Standard Modbus-Schnittstelle. Welcher Adapter wird empfohlen, um das Gerät XYZ anzubinden?"

Solche Fragen können ohne weitere Informationen nicht beantwortet werden, denn so etwas wie 'Standard Modbus'-Geräte gibt es im Grunde nicht. Das Modbus-Protokoll definiert nur:

• dass es adressierbare Geräte gibt (8 oder 16 Bit-Adressierung, also 1..256 oder 1..65.536 gleichzeitig mögliche Geräte),
• dass es in diesen Geräten nummerierte Speicherplätze gibt, in denen Werte (16-bit Register) oder Statusinformationen / Schalter (Einzelbits = Coils = 0/1, an/aus, ja/nein) abgelegt sind,
• ob und wie man diese Speicherplätze lesen und beschreiben kann (Funktionscodes 1-15),
• wie die Datenpakete für das Lesen und Schreiben sowie die zugehörigen Antworten inhaltlich aufzubauen sind.

Das war es auch schon - für eine funktionierende Geräteanbindung braucht es aber noch viel mehr (siehe nächster Abschnitt).

Wichtig: Gemäß Punkt 1 werden Modbus-Geräte über eindeutige Adressen angesprochen.
Die höchste verwendbare Adresse an der Trovis ist theoretisch die 255 (8 Bit-Adresierung). Diese hat sie auch erstmal nach einem Neustart, bis die eingestellte Adresse verwendet wird.
In der Praxis funktionieren keine Adressen >247 im Dauerbetrieb (so wird z.B. 255 als sogenannte 'Broadcast'-Adresse verwendet, auf die alle Geräte hören). Deshalb läuft meine Trovis mit der Stationsadresse 247, einstellbar über PA6.

WIE die Daten technisch zu übertragen sind (also über welche Schnittstelle, mit welcher Geschwindigkeit und über was für ein Verkabelungssystem), definiert Modbus nicht:

• Seriell RS232 / 422 / 485 Zweidraht/Vierdraht, parallel Centronics, USB, LAN/WLAN,
• 9.600 / 19.200 / 115.200 baud,
• 6, 7 oder 8-bit-Übertragung,
• Parität, Anzahl Start-Stopbits, XON/XOFF (wie z.B. das bekannte 8N1) usw.

Das ist Herstellersache und somit für jedes Gerät herauszufinden. Ohne die richtige und korrekt eingestellte Schnittstelle wird eine Modbus-Anbindung nicht funktionieren.

WIE OFT Daten übertragen werden, legt Modbus ebenfalls nicht fest. Es handelt sich hier um klassisches 'Polling' - das heißt, ein Master schickt eine konkrete Anfrage an einen Client, und nur dann antwortet dieser Client mit den angefragten Daten. Von sich aus bzw. ohne konkrete Anfrage wird kein Gerät einfach so Daten preisgeben oder 'auf Verdacht' senden.

WAS in welchem Speicherplatz eines Gerätes steht, definiert Modbus ebenfalls nicht. Bei dem einen Gerät steht an der Speicherstelle #0815 die Außentemperatur, beim nächsten der aktuelle Puls eines Patienten, beim Dritten die Netzfrequenz des Stromnetzes, und beim vierten der ASCII-Code der ersten beiden Buchstabens der Hersteller-Gerätebezeichnung.

Daher ist es wichtig, sich Listen der Register und Coils der anzuschließenden Geräte zu besorgen, denn diese sind immer hersteller- und/oder gerätespezifisch.

Manche Daten müssen nach dem Auslesen oder vor dem Beschreiben sogar aufbereitet werden, denn Modbus-Register fassen nur 16 Bit und damit nur einen begrenzten Zahlenbereich (2^16 = 0..65.535). Bei einigen Implementierungen werden auch Register kombiniert - z.B. wird aus zwei 16Bit-Registern dann ein 32Bit-Register. In letzterem Fall muss man noch die Bytereihenfolge beachten, die der Hersteller in die Client-Firmware implementiert hat (siehe Little/Big Endian).

Ein Beispiel: Register #40815 - #40817 auf einer Trovis enthalten den aktuellen Zählerstand des ersten von bis zu sechs gleichzeitig möglichen, per MBus angeschlossenen Wärmemengenzählern. Bei der Implementierung muss ich folgendes wissen (die drei Register enhalten beispielsweise die Zahlen 62 / 891 / 275):

Zählerstand = Zehntausenderstellen + Einerstellen + Nachkommastellen
Zählerstand = (#40815 x 10^4) + (#40816 x 10^0) + (#40817 x 10^-3)
Zählerstand = 62x10^4 + 891x10^0 + 275x10^-3
Zählerstand = 62.000 + 891 + 0,275
Zählerstand = 62.891,275

Man kann zwar alle drei Register einzeln auslesen, bekommt dann aber keinen plausiblen Gesamtwert, sofern die zugehörige Berechnungsformel nicht bekannt ist oder man nicht weiß, dass diese drei Register mathematisch ausgewertet und addiert werden müssen - z.B. weil der Hersteller dazu keine Informationen gegeben hat (das ist leider oft der Fall).

Oft fallen im Zusammenhang mit Modbus die Begriffe RTU und TCP. Beide Varianten werden häufig verwendet. Es handelt sich um den Modus, in dem das Modbus-Protokoll betrieben wird:

Ursprünglich (Ende 1970er) wurden bei Modbus die Daten im Klartext übertragen (Modbus/ASCII):
:|Zieladresse|Funktionscode|Nutzdaten_Klartext|Prüfsumme|Endsequenz
also z.B. :|GerätNr1|Abfrage|Register123|Prüf0815|CrLf

Um die Geschwindigkeit zu erhöhen, wurde die Kommunikation später binär durchgeführt (Modbus/RTU): Wartezeit|Zieladresse|Funktionscode|Nutzdaten_binär|Prüfsumme
also z.B. 100msPause|GerätNr1|Schreiben|Register123,Wert=17|Prüf0815

Mit der Verbreitung der Computernetze wurde 2007 Modbus/TCP geschaffen, wo über Netzwerkport 502 kommuniziert wird:
[TCP-Header]Lfd_Nr|Protokoll_ID|Paketlänge|Ziel|Nutzdaten_binär[TCP-Endsequenz]
also z.B. [TCP-Header]0001|0000|20Zeichen|GerätNr1|LeseRegister123[TCP-Endsequenz]

Man sieht sehr deutlich, dass sich RTU und TCP vom Aufbau her sehr stark unterscheiden - die Auswahl des richtigen Modus ist also wichtig und richtet sich nach dem abzufragenden Client.

Tip für die Fehlersuche bei unbekannten Geräten: Wie so oft bei TCP/IP, weichen manche Hersteller vom Standardport ab und wählen statt Port 502 einen beliebigen anderen - z.B. 1502.

Die Trovis 'spricht' RTU - daher ist es wichtig, dass der verwendete USB-/LAN-Adapter nicht nur die gleiche physikalische Schnittstelle wie die Trovis hat (RS232) und die richtigen Pins an der Trovis verbunden sind (Masse, RxD/TxD gekreuzt - siehe Schnittstellen I), sondern dass er auf der seriellen Seite auch 'RTU-fähig' ist.

Viele Adapter bringen heute bereits auf ihrer Netzwerkseite einen Modbus-TCP-Server mit, der auf der seriellen Seite trotzdem per RTU mit dem Client kommunizieren kann. Der Adapter spielt dann Übersetzer für TCP/RTU. Dies ist aber nicht bei allen Adaptern der Fall. Deshalb: Augen auf beim Adapterkauf.

Für Interessierte - gute und weitergehende Infos zu Modbus hier, hier, hier und hier.

Die Standardsoftware von Samson findet man hier. Achtung - nicht gleich den ersten Link anklicken, sondern nach unten zu "Regler und Automationssysteme" scrollen und den Tab "Trovis 5500" auswählen.

Die Mindestanforderungen für TrovisView sowie die unterstützten Adapter stehen hier. Der Hersteller der Adapter verkauft nach telefonischer Auskunft nicht an Privatpersonen - daher ist der Weg über die serielle Schnittstelle für 'Privatiers' der einzige, um den Regler per TrovisView sowie mit anderer Software auszulesen.

Verwirrend ist diese Information (Seite 4) - offensichtlich ist es doch möglich, die 5575 mit Updates zu versehen und die Werte des Reglers über TrovisView auszulesen. Nur eben nicht über Modbus - es scheint der Gerätebus hierfür verwendet zu werden.

Mittlerweile bietet Samson auch öffentlich Firmware-Updates an. Dazu auf die Seite des Reglers gehen - unter 'Downloads' findet sich sowohl das Update-Tool als auch die aktuelle Firmware. Die Einstellungen im Update-Tool entsprechen denen in TrovisView.

Hinweis: Einige User berichten von Problemen beim Update per ModbusTCP. Die Kommunikation wird erfolgreich aufgebaut, aber der Upload läuft nicht an. In diesem Fall hilft eine kurzzeitige Umschaltung Umschaltung auf ModbusRTU und Kommunikation über eine virtuelle Schnittstelle COMx:, z.B. mit VCom.

--> ToDo
55Home (Nur Android) https://play.google.com/store/apps/details?id=de.kt_elektronik.home
55Pro (iOS, Android) https://apps.apple.com/de/app/55mobile/id943003351, https://play.google.com/store/apps/details?id=kt.ffMobile

Unbenutzte Sensoreingänge können mit zusätzlichen Sensoren bestückt werden. Versuche haben gezeigt, dass die Trovis auch die Messwerte der nicht aktivierten Sensoren vorhält.

• Notwendiger Sicherheitshinweis: Der Einbau der Sensoren sollte durch eine Elektrofachkraft erfolgen. Vor den Arbeiten: Sicherung raus!

• Zuerst im Handbuch bei der eingestellten Hydraulik ("Anlage") prüfen, welche Fühler benutzt werden und demzufolge aktiviert sind (die Tabelle unter der Hydraulik weist auf die zugehörigen Parameter hin). Meist sind dies zumindest VF1 (Vorlauffühler), RüF1 (Rücklauffühler) und SF1 (Speicherfühler), ggf. aber auch mehr.
  
  Hier ein Beispiel für Anlage 2.1 auf einer 5573-1. In der Zeile AE sind die von Anlage 2.1 verwendbaren Sensoreingänge aufgeführt; die Tabelle darunter listet auf, wie sie für die Benutzung durch Anlage 2.1 aktiviert oder deaktiviert werden können.

• Anschließend unter CO5-F01...02 prüfen, welcher Sensortyp verbaut ist (Einstellungen mit dem Hanbuch vergleichen; meist PT100 (100Ω bei 0°C) oder PT1000 (1.000Ω bei 0°C). Es ist wichtig, dass die zusätzlich bestellten Sensoren exakt vom gleichen Typ sind.

• Im Handbuch findet man auch einen Schaltplan der Trovis, der die Draufsicht auf den Sockel darstellt - hier wieder ein Beispiel für die 5573-1. Auf der linken Seite finden sich die Sensoren, je nach Modell in 1 oder 2 Reihen.
  
  Auf der rechten Seite befinden sich die Schaltausgänge (Achtung, 230V!).
  
  Dazwischen ist ein Trennsteg aus Plastik, um die Kabel für Klein- und Netzspannung zu trennen - z.B. bei einem Kabelbruch oder -abriss würde sonst das Risiko bestehen, dass ein Sensoreingang auf der linken Seite plötzlich 230V erhält, was mit 99.999%iger Sicherheit zu einer Zerstörung des Reglers führen würde.

• Um an den Sockel zu kommen, die Frontschrauben der Trovis lösen und diese nach vorn aus dem Sockel ziehen (der Regler ist nur gesteckt).

• Der Anschluß eines Sensors erfolgt zwischen dem zugehörigen Pin links (siehe Schaltplan) und dem zentralen Massesteg in der Mitte.

• Am Ende den Regler wieder aufstecken und befestigen; die Sensoren stehen sofort zur Verfügung, eine Umkonfiguration ist nicht notwendig.

Das Register 40005 zunächst mit 1732H (= 5938 dezimal) und anschließend mit 0002H (= 2 dezimal) beschreiben – danach führt der Regler automatisch einen Reglerneustart aus.

Eine Liste der bekannten Register und Coils ist im Templates-Verzeichnis zu finden (Basis: 5576-0003). Die Liste hat dabei das Format eines 'Nested Dictionary' (nested dict - Dicts in einem Dict, also einer Liste von unsortierten Elementen). Dieses Format ist z.B. in Python direkt einlesbar. Die Liste wird von Zeit zu Zeit von mir ergänzt und erweitert.

Der Benutzer @ClearEyetemAA55 hat weiterhin eine Excel-Tabelle für die Einstellungen der Trovis zur Verfügung gestellt (im Tools-Verzeichnis zu finden - danke!!!).

Hinweis: Je nach Anbindung und verwendeter Programmierbibliothek bzw. Anbindung sind die in der Liste genannten Registernummern gültig, oder es gilt: Nummer +40.001. Die Gerätekennung ist also entweder unter Nummer '0' oder '40.001' verfügbar, die Anlage unter '1' oder '40.002' usw. Ich beabsichtige, in der nächsten Revision des Dokuments beide Registernummern zu nennen.

Ganz am Anfang des Projektes, als noch unklar war, wo die Reise hingeht, habe ich zwei kleine Programme geschrieben, die per "Try&Error" alle Speicherplätze des Trovis ausprobieren (sogenannte 'Sniffer'). Die ansprechbaren Register und Coils werden am Ende ausgegeben.

Diese in Python geschriebenen Programme sind hier im Projekt zu finden und können verwendet werden, um die in einem bestimmten Modell adressierbaren Speicherplätze herauszufinden.

Hinweis: Manche Speicherplätze liefern nur dann sinnvolle Werte zurück, wenn das System auch aktiv ist. So liefert z.B. im Sommermodus das Register für 'Vorlauf SOLL' den Wert 32.767 (=3.267,7°C = Vorhof zur Hölle). Andere Speicherplätze scheinen bei abgeschalteten Funktionen gar nicht mehr zur Verfügung zu stehen und liefern beim Auslesen einen Fehler.

--> ToDo: Weiter beobachten/beschreiben

Um die Trovis nicht nur auslesen, sondern auch beschreiben zu können, ist vorher die Schlüsselzahl (letzte Handbuchseite; meist 1732) in das Register 144 zu schreiben (Modem-Schreibfreigabe). Dadurch wird der Regler in den Zustand "GLT" (GebäudeLeitTechnik) versetzt. Nach 30 Minuten ohne Modbus-Anfragen geht der Regler automatisch wieder auf 'autark' (manuel: Gem. Handbuch durch Setzen des Coils ???, CO6-F07=1). --> ToDo

Hinweis: In einem der letzten Firmwareupdates kam die Funktion CO6-F20=1 hinzu: "diverse Modbusvorgaben wirken nicht auf die Sammelebene/GLT-Anzeige". --> ToDo: Was bedeutet das, was macht das, wie wirkt sich das aus?

Oft kommen Fragen zur Heizkurve und somit zum Regelverhalten der Trovis auf. Daher hier zwei (vereinfachte) Darstellungen zur sogenannten "Witterungsgeführten Regelung". (Anmerkung: Neben dieser gibt es auch den Betrieb mit einer komplett benutzerdefinierten 4-Punkt-Heizkennlinie sowie als Festwertegler, beide werden in der Praxis jedoch selten verwendet.)

In den meisten "klassischen" Reglern liegt der Fußpunkt der Heizkurve bei 20/20 (20° Außentemperatur = 20° Vorlauf). Dieser Fußpunkt kann durch den Parameter "Niveau" nach oben oder unten verschoben werden, so dass sich bei einem Startpunkt von 20° Außentemperatur eine höhere oder geringere Vorlauftemperatur der Heizung ergibt.

Hinzu kommt der Parameter "Steigung", der definiert, wie schnell die Vorlauftemperatur bei sinkender Außentemperatur vom Fußpunkt aus ansteigen soll. Dieses Schema ist so auch in den Trovis-Handbüchern dargestellt:

Die Trovis verfügt jedoch über einen weiteren Parameter, der nicht über PA1/2/3 in der Konfigurationsebene eingestellt wird, sondern direkt über die Drehschalter zugänglich ist: Sollwert Tag und Sollwert Nacht (auch "Raum-Solltemperatur" genannt - siehe ganz vorn im Handbuch). Dieser Parameter verschiebt sowohl den X- als auch den Y-Wert des werksmäßigen Fußpunkts von 20/20/20 (Außentemperatur/Vorlauftemperatur/Raumsoll). Hier eine schematische Darstellung:

Zum Raumsoll gibt es häufig Rückfragen - warum ist die tatsächliche Raumtemperatur so weit vom eingestellten Raumsoll entfernt?

Wichtig für das Verständnis ist, dass in den meisten Heizungen KEINE Temperatursensoren ("Raumfühler") in den Räumen verbaut sind (Eingänge RF1, RF2, FG1, FG2). Somit hat die Trovis keine Möglichkeit, zu messen, wie warm es in den Räumen wirklich ist - die Raumtemperatur ist ein rein rechnerischer 'imaginärer' Parameter zur Feinanpassung der Heizkennlinie.

Es empfiehlt sich somit, das Raumsoll einmalig einzustellen und danach nur noch Steigung und Niveau anzupassen, da sonst zu viele Parameter gleichzeitig eingestellt werden.

Der Benutzer @robhubi aus dem Haustechnikdialog-Forum hat mit sehr viel Geduld eine Näherungsformel für die gängigen Steigungen der Trovis-Heizkurve ermittelt:

VTsoll = 24+Niveau+2*Steigung*(RTsoll-20) - (0,1+0,9*Steigung) * (1,5*(AT-20) + 0,01 * (AT-20)^2 )

Vielen Dank für Deine Mühen und Geduld, robhubi!!!