Eine Frage der Perspektive …

Die Heizung seiner Siedlerhütte mit LEO_2 machte Irgendwem schon lange kein Kopfzerbrechen mehr. War es früher vielleicht einmal spannend gewesen, wie lange der Eisspeicher ausreichen würde, hatte sich über die Jahre hinweg  herausgestellt, dass es wohl die Ausnahme war, dass sich im Winter größere Eismengen in seinem ‚Eisspeicher‘ bildeten.

Blubber-3-Klippe

Das hatte mehrere Gründe.

Zum einen waren – von einigen vereinzelten Kälteperioden abgesehen – die vergangenen pannonischen Winter sehr mild gewesen. Und wie es aussah, würde das wohl noch eine Zeit lang so bleiben

Zum anderen hatte Irgendwer Hydraulik und Regelungslogik ursprünglich so ausgelegt, dass sie jede nur verfügbare Kilowattstunde an Umweltenergie aus dem Kollektor, die nicht direkt verheizt wurde, in den Eisspeicher leitete, um so seinen Wärmevorrat zu vergrößern.

(3) Wärmepumpensystem LEO_2 Oktober

Hingegen hatte er die Kühlung im Sommer bisher nur als ein ‚Nebenprodukt‘ gesehen. Mit dem, was an Kälte im Eisspeicher halt noch übrig war, hatte er seine Siedlerhütte im Sommer ein wenig ‚passiv‘ gekühlt. Aber während das Heizen im Winter einfacher wurde, kam die passive Kühlung im Sommer zusehends an seine Grenzen.

„Zeit also, die Perspektive zu ändern! …“

… hatte sich Irgendwer schon vor einiger Zeit gedacht, und begonnen, darüber zu tüfteln, wie er mit seiner Kältepumpe mehr Kühlvorrat anhäufen und in den Sommer hinein retten konnte.

Eisformationen-im-Eisspeicher

Der Holzhammer-Ansatz der Eisspeicher Challenge wäre dafür zu grob gewesen, weil er damit die Effizienz (=hohe Arbeitszahl) bei der Heizung hätte opfern müssen. Da war schon mehr die feinere Klinge gefragt!

Eine kleine Änderung in der Hydraulik, die er dazu benötigte, hatte er gleich im Zuge seiner Heizraum-Renovierung umgesetzt.

IB2-I-Schaltung-Nimmt-Gestalt-an

Die weit größere Herausforderung war aber die Bewältigung mehrerer Mutantenprobleme in der Regelungslogik gewesen. Unglaublich, wieviele zusätzliche Betriebszustände man für die Anlage berücksichtigen musste, wenn man doch nur so einen klitzekleinen zusätzlichen Mischer eingebaut hatte.

perspektive-uvr16x2

Aber es war ja nicht das erste Mal, dass er seine UVR16x2-Regelungs-Trickkiste bemühen musste. Und so lief jetzt, mitten in der Heizsaison, die Logik zur ’sanften Konservierung‘ des Eisvorrates an.

Ob er alle Mutantenprobleme gefunden und gelöst hatte, würde er aber erst in paar Monaten mit endgültiger Sicherheit wissen 😉 …

Das Mutantenproblem

Irgendwer konnte sich nicht mehr genau erinnern, wie es zu diesem Namen gekommen war, der sich inzwischen tief in der Siedlersprache verwurzelt hatte.

Aber er konnte sich sehr gut vorstellen, dass dieses Problem bereits mit der Mutation des Affen zum Menschen und der damit verbundenen Verwendung von Werkzeugen entstanden war. Das Mutantenproblem begegnete ihm quer durch alle Lebensbereiche und Gesellschaftschichten inzwischen so häufig, dass er zum Schluss gekommen war, dass eine bestimmte Gen-Sequenz dafür verantwortlich sein musste…

Ein Mutantenproblem liegt dann vor, wenn von genau zwei Möglichkeiten genau die falsche gewählt wird.

EIN statt AUS, AUF statt ZU, LINKS statt RECHTS, IM statt GEGEN den Uhrzeigersinn, VORLAUF statt RÜCKLAUF, aber auch NORMAL statt INVERS.

Die Wahrscheinlichkeit, das Falsche zu machen, ist beim Mutantenproblem zwar ’nur‘ 50%, die Auswirkung ist aber fatal (‚doppelt falsch‘), weil man nämlich exakt das Gegenteil davon erreicht, was man eigentlich will.

Die Heizungstechnik ist ein Eldorado für Mutantenprobleme.

MP-Feuer

Am Anfang war das Feuer: Es brannte oder nicht, was in einem unmittelbaren untrennbaren Zusammenhang mit WARM und KALT stand – Irrtum ausgeschlossen. Da war die Welt noch in Ordnung:

  • Feuer brennt =  WARM

Dann kam die ‚Zentralheizung‘.

MP-Kessel

Das Feuer brannte im Kessel und Heizungswasser wurde WARM über den VORLAUF in den Heizkreis transportiert und kam KALT über den RÜCKLAUF zurück. Wenn VORLAUF und RÜCKLAUF vertauscht wurden, war das noch nicht wirklich schlimm, weil der Heizkörper am anderen Ende auch so irgendwie seinen Dienst tat.

Doch dann kam der Mischer. Mit ihm die Regelung der Vorlauftemperatur und die Explosion der potenziellen Mutantenprobleme:

(1) Hydraulik: AUF / ZU.

MP-Mischer

AUF bedeutet für den Mischer, dass die Verbindung zwischen Kessel und Heizkreis OFFEN, also der Vorlauf WARM ist:

  • Hydraulik: Mischer = AUF
  • Vorlauf = WARM

(2) Stellmotor Drehsinn: IM / GEGEN den Uhrzeigersinn.

MP-Stellmotor

Die hydraulischen Positionen AUF / ZU werden durch den Stellmotor des Mischers automatisch angefahren, indem der Motor den Drehschieber im Mischer nach RECHTS (IM Uhrzeigersinn = CW (Clockwise)) oder LINKS (GEGEN den Uhrzeigersinn = CCW (Counter Clockwise)) dreht. Also:

  • Stellmotor Drehrichtung  = CW
  • Hydraulik: Mischer = AUF
  • Vorlauf = WARM

(3) Stellmotor: elektrischer Anschluss

MP-Spannung

Der Stellmotor braucht Strom, wobei jede der beiden Drehrichtungen ihren eigenen elektrischen Anschluss (EIN / AUS) hat:

  • Stellmotor Anschluss CW = SPANNUNG EIN
  • Stellmotor Drehrichung = CW
  • Hydraulik: Mischer = AUF
  • Vorlauf = WARM.

(4) Regler Ausgang: EIN / AUS.

MP-Regler

Der Stellmotor ist elektrisch mit zwei Reglerausgängen verbunden (einer für AUF und einer für ZU). Der Regler versorgt einen Ausgang mit Spannung, indem er den Ausgang auf EIN schaltet. Manche Reglerausgänge haben aber zwei Möglichkeiten, das Kabel anzukemmen: NO (= Normal Open = SCHLIESSER) und NC (Normal Closed = ÖFFNER). Also, für den Fall NO:

  • Reglerausgang A1 = EIN  (A2 = AUS)
  • Ausgang A1 NO = SPANNUNG EIN
  • Stellmotor Anschluss CW = SPANNUNG EIN
  • Stellmotor Drehrichung = CW
  • Hydraulik: Mischer = AUF
  • Vorlauf = WARM.

(5) Regelungslogik: NORMAL / INVERS.

MP-Reglerlogik

Der Regler schaltet die Ausgänge gemäß der im Regler programmierten Logik, wobei es (zumindest bei der UVR16x2) für die Mischersteuerung die Möglichkeit gibt, über den ‚Modus‘ die Regelungslogik noch einmal umzudrehen. Also:

  • Regelungslogik: Modus = NORMAL
  • Reglerausgang A1 = EIN  (A2 = AUS)
  • Ausgang A1 NO = SPANNUNG EIN
  • Stellmotor Anschluss CW = SPANNUNG EIN
  • Stellmotor Drehrichung = CW
  • Hydraulik: Mischer = AUF
  • Vorlauf = WARM.

Damit gibt es nur für dieses klitzekleine Beispiel eine besorgniserregende Anzahl von Möglichkeiten, in ein Mutantenproblem zu laufen. Man stelle sich nur vor, der WARME VORLAUF ist LINKS (statt RECHTS) vom KALTEN RÜCKLAUF. Oder: die Leitungen vom Kessel kommen von OBEN statt von UNTEN zum Mischer. Wie muss dann der Mischer eingebaut werden? Und wie muss dann die Drehrichtung des Stellmotors sein?

So wird die Wahrscheinlichkeit verschwindend klein, auf Anhieb wirklich alles richtig zu machen. Das dürfte wohl der wahre Grund dafür sein, warum man am Ende der Mutanenproblem-Kaskade ohne großem Aufwand in der Regelungslogik noch einmal von NORMAL auf INVERS umschalten kann 😉 .

Wer aber glaubt, das war jetzt schon alles – weit gefehlt!

Denn dann kam die Wärmepumpe!

MP-Waermepumpe

Und mit ihr zerbröselte der Glauben, dass VORLAUF immer gleich WARM bedeutet. Denn Wärmepumpen haben auch einen Solekreis, der sich genau umgekehrt zum Heizkreis verhält. Und: Wärmepumpensysteme können auch kühlen, was den HEIZKREIS zeitweise in einen KÜHLKREIS verwandeln kann, sodass:

  • Hydraulik: Mischer = AUF
  • Vorlauf = KALT (!)

Ihr müsst jetzt stark sein! Die Welt ist voller Mutantenprobleme und keiner ist davor gefeit!

Das Farbenkastl

Es war wieder soweit.

Irgendwer hatte den großen Schalter umlegt – und endlich wurden wieder Daten geloggt. Die Datenkrake blickte jedoch vorerst auf ein Knäuel von verknoteten Tentakeln!

Wie Anno 2016 gab es einen Bruch im Raum-Zeit-Kontinuum: Irgendwessen Regelungsbastelei hatte sich der Aufbau der mittels Winsol exportierten Logdateien grundlegend geändert. Es gibt jetzt komplett neue Sensoren und erstmals geloggte Werte. Die bekannten Werte stehen in anderen Spalten im Logfile. Das Logfile hat mehr Spalten. Die Kompressorleistung wird endlich als positiver Wert gemessen. Zähler wurden genullt während des Umbaus. Mehrmals.

Glücklicherweise hatte die Datenkrake weitgehend vorgesorgt! Als sich Ende 2016 eine neue Logfilestruktur ankündigte, wurde in einem klassischen Über-die-Feiertage-Marathon-IT-Projekt die ‚Softwarearchitektur‘ geändert.

(Symbolbild.)

Seit damals gibt es als Vorgruppe zur mächtigen SQL-Server-Krake eine Access-Krake: Diese Proto-Krake enthält die Dokumentation aller Messwerte inklusive der Information, seit wann es diesen Wert bzw. diesen Sensor gibt, an welcher Stelle in der Logdatei der Messwert steht, und wann er ggf. wieder ausgeschieden wurde. Aus dieser Kraken-DNA bastelt ein Powershell-Tentakel dann die eigentlichen SQL-Server-Datenbank-Objekte. So wie Forscher eventuell einmal ein Mammut klonen werden aus Fossilien, kann die komplette Datenbank aus den alten Logfiles neu aufgebaut werden – egal wie durcheinander gewürfelt die Spalten werden.

Ebenfalls festgehalten in der DNA sind die für die eigentliche Auswertung benötigten Funktionen. Lebenssinn der Datenkrake ist ja die Zusammenführung der Logdateien diverser Logger und die Berechnung von Kennwerten, die über einfache Mittelwerte und Zählerstände etc. hinausgehen. So berechnete die Krake die Arbeitszahl der Wärmepumpe ursprünglich aus den manuell vom Display der Wärmepumpe abgelesenen Werten. Schrittweise wurden aber die verwendeten Zähler automatisiert, d.h. die Krake muss Ihre Tentakel zum richtigen Zeitpunkt in eine andere Tabelle ausstrecken. Außerdem muss immer berücksichtigt werden, dass bestimmte Mittelwerte nur Sinn machen, wenn Kritierien erfüllt sind: Die Krake berechnet zum Vergleich auch eine Arbeitszahl aus einer selbst erstellten Fitkurve für die Wärmepumpenleistung in Abhängigkeit von Quellen- und Senkentemperatur. Zu diesem Mittelwert dürfen nur Zeitinervalle beitragen, in denen die Wärmepumpe auch gelaufen ist.

Solchen Anforderungen stellen also kein Problem für die Krake dar! Die Siedler fürchten sich immer schon ein wenig davor, dass die Datenkrake tatsächlich Bewusstsein erlangt und das Leben in der Siedlerhütte zu einem Science-Fiction-Alptraum wird. Glücklicherweise schützt die Siedler hier ein ungelöstes Problem. Bis zur tiefsten Ebene des Kraken-Genmaterials ist die Automatisierung nämlich noch nicht vorgedrungen. Wie sollte das auch aussehen – eine Mini-Drohne oder ein Roboter, der versucht, Irgendwessen Sensor-Verkabelungsmutationen live mitzudokumentieren?

Hier kommt nun endlich das titelgebende Farbenkastl ins Spiel. Ja, so ist es mit den Namen strategischer wichtiger Entwicklungen: Der erste Code-Name, der in einem internen IT Strategy Meeting achtlos in dem Raum geworfen wird, bleibt für alle Ewigkeit. Überraschend war auch für die Siedler, wo dieser Name eigentlich herkommt. Umgangssprachlich steht ‚Farbenkastl‘ im Land der Siedler meist für ewas bunt Geschecktes, Geschmackloses – z.B. im Zusammenhang mit Kleidung oder Inneneinrichtung oder der politischen Parteienlandschaft. Ursprünglich wurde der Begriff offenbar verwendet, um sich über den überaus komplizierten ‚Farb-Code‘ der militärischen Uniformen zur Zeit der k.u.k Monarchie lustig zu machen.

Keine Metapher könnte passender sein für dieses imperiale Tool! Als Vorstufe zur Vorstufe der Krakendatenbank wird ein Farbenkastl erstellt … in Microsoft Excel! Nur so kann das Elkement seine kreative Ader ausleben und die diversen Kategorien von mutierenden Sensoren einmal optisch ansprechend einfärben, zwecks leichterer Erstellung des nächsten Skripterls (Skript-chens).

Das erste Farbenkastl 2016 sah noch vergleichsweise langweilig aus:

Beim Screenshot-ten des Farbenkastls Reloaded 2018 stoßen wir aber schon an die Grenzen des Zoomens in Excel!

Und nun warten wie immer in diesen Fällen auf die überraschende Nominierung für einen Kunstpreis! In der Zwischenzeit erfreuen sich die Siedler wieder an den regelmäßig vorgeführten Kunststückchen der Krake!

(Symbol-Video. An der automatischen Änderung der PVC-Verrohrung mittels Krake und 3D-Druck arbeiten wir noch!)

Alte Heizung – Neue Regelung: Phase 2 – Programmierung

Die Rahmenbedingungen waren abgesteckt. Nun galt es, der bestehenden Heizungsanlage eine neue Intelligenz einzuhauchen, also zuallererst einmal alle Sensorsignale richtig zu verstehen.

Sensor

Irgendwem erschien es manchmal so, als wäre es eine Frage der Ehre für jeden Heizungshersteller, seinen eigenen Sensortyp zu verwenden. Umsomehr wusste er es zu schätzen, dass er auch diesen Exoten (NTC 5kOhm) in der Auswahlliste für mögliche UVR16x2-Sensoren wiederfand.

Sensor-Eingang-NTC

Aber auch das Ansteuern der Anlage, stellte ihn vor keine großen Schwierigkeiten:

Da noch keine hochgezüchteten elektronisch geregelten Pumpen eingebaut waren, war es neben einem simplen EIN/AUS auch möglich, TRIAC-Ausgänge der UVR16x2 für die Drehzahlregelung zu verwenden.

Auch die eingebauten automatischen Ventile und Heizungsmischer hörten – wie es sich gehört – auf Ein/Aus Signale mit 230V.

Einbindung-Mischer-Bestand

Einbindung und Ansteuerung des bestehenden Heizungsmischers

Und obwohl schon etwas betagt, hatte der Heizkessel einen potentialfreien externen Anforderungskontakt, über den er von der UVR16x2 direkt ein- und ausgeschaltet werden konnte.

Einzig der elektrische Heizstab, der im Warmwasserspeicher eingebaut war, erforderte ein zusätzliches Schütz, das über 230V von der UVR angesteuert werden konnte und das Schalten der hohen elektrischen Leistung übernahm.

Etwas kniffliger wurde es schon mit der Regelungslogik. Denn neben der Steuerung der nicht ganz alltäglichen Hydraulik sollten auch die Schwächen der alten Regelung ausgebügelt werden. Und um spezielle Anforderungen zu erfüllen, musste Irgendwer manchmal schon recht tief in seine Trickkiste greifen …

Regelungslogik

Die grafische Darstellung der Verknüpfung von Funktionsbausteinen im Programmiertool TAPPS war überaus hilfreich, um den Überblick über die Regelungslogik nicht zu verlieren…

Parallel zur Programmierung hielt Irgendwer alle relevanten Einzelheiten vom Hydraulikschema, über die Belegung der Ein-/Ausgänge, die Verdrahtung der Komponenten bis zur Regelungslogik in einem Handbuch fest. Denn der Besitzer sollte ja am Ende in der Lage sein, seine neue Regelung vollständig selbst zu verkabeln und in Betrieb zu nehmen.

Handbuch

Unverzichtbar: Das individuelle Siedler-Handbuch …

Damit wären wohl viele zufrieden gewesen. Nicht aber Irgendwer, der genau wusste, dass der wichtigste Teil erst nach der Inbetriebnahme wartete, nämlich die Optimierung der Regelung und die Anpassung an das tatsächliche Anlagenverhalten.

Daher war es aus seiner Sicht unverzichtbar, zu jeder Zeit – für ihn auch aus der Ferne – einen Überblick über die Anlage zu behalten und ein bestimmtes Regelungsverhalten auch im Nachhinein analysieren zu können.

Daher baute er mit Hilfe des TA-Designer ein Onlineschema, das den aktuellen Anlagenzustand auf eine Blick darstellte…

TA-Designer

Erstellen des Onlineschemas im TA-Designer

… und selektierte kritische Messwerte und Regelparameter, die er in die  Datenaufzeichnung aufnahm.

Konfiguration Datenlogging

Konfiguration des Datenloggings in TAPPS

Jetzt musste er nur noch warten, bis der Siedler seine neue UVR16x2 beschafft, über das CMI erfolgreich mit dem Internet verbunden, und ihm Fernwartungszugang gestattet hatte.

CMI-Fernwartung

Fernwartung über CMI und das Webportal der Technischen Alternative

Dann folgten noch einige Standard-Fernwartungs-Handgriffe: Firmware von CMI und Regler aktualisieren, Funktionsdaten und Onlineschema aufspielen, Abruf der Messdatenaufzeichnung über Winsol konfigurieren.

Und damit war alles bereit für die Inbetriebnahme …

Frage an die Datenkrake: Was ist wo in Winsol?

Kürzlich erreichte die Siedler ein Hilferuf eines anderen UVR-Tüftlers – ausgelöst durch brisante Berichte von der Krakenwanderung:

Wie schafft es die Datenkrake, dass unterschiedliche Windows-Benutzer die gleichen Log-Dateien in Winsol verwenden und die gleiche setup.xml-Datei?

Die ganz kurze Antwort: Indem unterschiedliche Windows-Benutzer in Ihren Winsol-Grundeinstellungen den gleichen Logfile-Ordner eintragen. Dann schreibt jeder Benutzer die Logfiles in den gleichen Ordner und verwendet auch die gleiche setup.xml-Datei.

Nach den Infos zur letzten CMI-Firmware-Upgrade (2.09 – 20.April 2018) ist das jetzt auch eine unterstützte Vorgansgweise:

Unterstützt exklusiven Schreibzugriff auf Kundenordner:
Wird von mehreren Computern (Programminstanzen) auf denselben Kunden im gemeinsamen Datenpfad zugegriffen, wird ein gleichzeitiges Bearbeiten verhindert. An allen beteiligten Computern muss dazu dieselbe Version von Winsol verwendet werden.

Folgendes ist eventuell noch zu beachten:

Frühere Winsol-Versionen haben die Logfiles im Windows-Programme-Ordner abgelegt bzw. haben das zumindest versucht. Nachdem Microsoft das aus Sicherheitsgründen nicht mehr erlaubt, gab’s eine u.U. vewirrende Umleitung in einen ‚versteckten‘ Ordner im Profil des jeweiligen Benutzers (VirtualStore). Näheres zu den Speicherorten in dieser Geschichte. Installiert man eine neuere Winsol-Version neu, liegt der Standardordner jetzt auch ‚wirklich‘ und sichtbar im Benutzerprofil; aktualisiert man eine ältere Winsol-Version, wird eventuell noch der VirtualStore verwendet. Je nachdem, wie man ‚in den Logfile-Ordner schaut‘, sieht man dann die Logfiles im Profil oder im Programme-Ordner. In letzterem Fall sieht es also so aus, als ob alle Benutzer in den gleichen Ordner schreiben würden:

Standard-Ordner in älteren Winsol-Versionen (Winsol 2.07, aktualisiert von früheren Versionen, Windows 10 32bit). Direkt im Windows Explorer sieht man keine Logfiles im Ordner Program Files – im Gegensatz zum Winsol-Dialog. Erklärung: Der tatsächlich verwendete Ordner ist
C:\Users\[Benutzer]\AppData\Local\VirtualStore\Program Files\Technische Alternative\Winsol
(Weitere Details hier.)

Wenn man immer sofort nach der Winsol-Installation einen Nicht-Standard-Ordner außerhalb des Benutzerprofils und außerhalb anderer spezieller Systemordner einstellt, braucht man sich damit nicht zu beschäftigen.

Zusätzlich zum Logfile-Ordner gibt es noch einen weiteren Ordner mit den persönlichen  Winsol-Einstellungen – der war ‚immer schon‘ im Windows-Benutzerprofil zu finden: Hier wird das Cookie für den Zugriff auf das CMI-Webportal abgelegt und in der (benutzerspezifischen) Winsol.xml-Datei wird der Pfad zu den Logdateien eingestellt. Dieses Cookie muss einmalig kopiert werden oder jeder Windows-Benutzer muss sich einmal mit dem / seinem Portalbenutzer anmelden.

Ordner mit den persönlichen Winsol-Einstellungen in C:\Users\[Benutzer]\AppData\Roaming\Technische Alternative\Winsol – dieser Speicherort kann / braucht nicht geändert zu werden.

Verwaltet man mehrere ‚Winsol-Profile‘ / Kunden, dann werden deren Logdateien im Ordner Infosol abgelegt. Für welche Kunden Logfiles automatisch (winsol -a) abgeholt werden, wird auch in der Winsol.xml festgelegt –  die betreffenden Kunden werden in einem XML-Tag alle namentlich erwähnt:

Inhalt der Winsol.xml-Datei. Der Tag Autostart enthält die Liste der abzuholenden Kunden, als Werte der Attribute K1, K2 etc.

Will man nun tatsächlich hier dauernd rumklicken – d.h. bestimmte Kunden beim automatischen Abholen mit winsol -a einmal dazunehmen und dann wieder ausschließen – dann müsste man entweder:

  • winsol.xml zwischen den verschiedenen Windows-Benutzern synchroniseren oder
  • Die ‚Abhollliste‘ irgendwo zentral speichern und alle winsol.xml-Dateien mit Scripts anpassen.

 

Alte Heizung – Neue Regelung: Phase 1 – Konzept

Es soll ja Heizungen geben, die klaglos funktionieren.

happy

Bei vielen lernt man aber über die Zeit ‚kleine Mätzchen‘ kennen und lieben, die man als ’normal‘ akzeptiert, die man mit ‚gewissen Handgriffen‘ aber relativ problemlos beheben kann.

Aber dann gibt es Anlagen, deren Verhalten immer wieder überrascht, und die ohne permanente Aufsicht keinen zufriedenstellenden Komfort liefern können.

so sad

So wusste auch jener Siedler eine lange Leidensgeschichte zu erzählen, als er sich an Irgendwen wandte. Was hatte er nicht schon alles versucht, um nach jenem Einbau der thermischen Solaranlage eine akzeptable Anlagenperformance zu erreichen. Erfolglos. Diverse Untersuchungen und Schlussfolgerungen hatten nur ergeben, dass

‚… die Hydraulik soweit in Ordnung und das Problem wohl in der Regelung zu suchen sei …‘.

Aber für diese nicht mehr ganz zeitgemäße Regelung, die aus mehreren Modulen mit beschränkten analogen Einstellmöglichkeiten bestand, erschien eine systematische Analyse und Optimierung aussichtslos.

Regelung-Bestand

Das hatten selbst die herbeigerufenen Techniker des Herstellers eindrucksvoll bewiesen.

Also war der einzige Vorschlag, den Irgendwer machen konnte, den Ersatz dieses Urgesteins durch eine frei programmierbare Universalregelung UVR16x2 zu prüfen.

UVR16x2

Da dieser Siedler bereit uns willens war, bei Irgendwessen Fernanalyse tatkräftig zu unterstützen und bei der Umsetzung der Lösung auch selbst Hand anzulegen, war man sich schnell über eine weitere Vorgehensweise einig.

Bestandsaufnahme. Neben zwei nicht mehr ganz aktuellen Hydraulikschemen, fanden sich diverse Handbücher und Datenblätter, die in einem gemeinsamen Online-Ordner gesammelt wurden. Ein Erfahrungsbericht und eine Foto-Safari durch den Heizraum komplettierten die Aufnahme des Ist-Zustandes.

Hydraulik-Bestand

Ja, und dann gab es natürlich noch die ‚Wunschliste‘, die sich in diesem Fall schon zu einem kleinen Konzept ausgewachsen hatte, in dem sich der Siedler schon ausführlich seine eigenen Gedanken über eine mögliche Optimierung der Anlage gemacht hatte.

Analyse. Jetzt lag der Ball einmal bei Irgendwem, der sich durch die Informationen wühlte und daraus ein aktuelles Hydraulikschema kondensierte, in das alle Regelungskomponenten – vom Temperatursensor über Pumpen und Umschaltventile bis zum Sicherheitsthermostat – eingezeichnet wurden.

Hydraulik-Neu

Das ging nicht ganz ohne die Mithilfe des Siedlers, der in der einen oder anderen Heizraum-Expedition auch noch die letzten Details der Anlagenkomponenten in den hintersten Winkeln ablichtete.

Umschaltventil

Fragen und Details wurden über E-Mails abgestimmt – was auch zum Tüfteln und zum ‚in Ruhe Nachlesen‘ eine große Hilfe war.

Konzept. Aus den Analyseergebnissen und der Wunschliste des Siedlers konzipierte Irgendwer einen Lösungsvorschlag basierend auf der UVR16x2 und einem CMI.

Innerhalb der Grenzen der Hydraulik war die gewünschte Regelungslogik mit der UVR umsetzbar. Und es konnten praktisch alle bestehenden Komponenten eingebunden werden.

Einbindung-Ventil

Zusätzlich sollte aber endlich auch das Rätselraten über das tatsächliche Anlagenverhalten der Vergangenheit angehören. Der Momantanzustand sollte in einem Online-Schema dargestellt und sämtliche Sensorwerte und Schaltzusände aufgezeichnet werden.

Nachdem das Konzept mit dem Siedler besprochen und verfeinert worden war, war die Phase 2 startklar: die Reglerprogrammierung. – Aber das ist eine andere Geschichte

Logging-Forschung: Beim Fenster raus und bei der Türe wieder rein

Die Datenkrake wird täglich herausgefordert: So viele Möglichkeiten gibt es, neue Tentakel in bisher unerforschte Gebiete auszustrecken!

Das CMI ist seit einiger Zeit selbst eine Datenkrake: In den Einstellungen können Ein- und Ausgänge am CAN-Bus oder für Modbus-TCP konfiguriert werden.

Logisch und physisch getrennt von Wärmepumpe und Hydraulik arbeitet der PV-Wechselrichter der Siedler (Fronius Symo 4.5-3-M). Die PV-Daten werden lokal auf einen USB-Stick geloggt; das minimale Loggingintervall beträgt 5 Minuten. An manchen dunklen Abenden werden die gesammelten Daten dann an die Krake verfüttert. Der Fronius-Datenlogger hat eine WLAN-/Internet-Verbindung und einen lokalen Webserver, aber direkt ‚online runterkopieren‘ von diesem Stick kann man die Daten nicht.

Aber es gibt eine Modbus-TCP-Schnittstelle: Damit können die aktuellen Daten von einem Computer im  lokalen Netzwerk abgefragt werden oder von einem anderen Dings im Internet of Things. Die Siedler wollten nun wissen, ob der Modbus-Client des CMI das USB-Logging ersetzen könnte. Oder könnte gar die künstliche Intelligenz der Regelung auf die aktuelle PV-Leistung reagieren? Der Wechselrichter hat eine Energiemanagement-Funktion, aber 1) er könnte nur sehr schlicht über ein Relay ‚kommunizieren‘ und 2) das natürlich nicht über WLAN.

Nötige Schritte und einige Erkenntnisse:

Modbus wird aktiviert am Datenlogger des Wechselrichters. Wir entscheiden uns für echte Kommazahlen und erlauben keine Änderungen über Modbus:

Modbus-Einstellungen am lokalen Webserver des Fronius-Symo-Wechselrichters. 502 ist der Modbus-Standardport. Die Alternative zu float wären Ganzzahlen mit Skalierungsfaktor SF (Faktor steht dann in anderem Register).

Check der Modbus-TCP-Dokumentation von Fronius: Benötigt werden die Register (‚Speicherplätze‘) der interessanten Werte, z.B. die aktuelle Outputleistung. Das ausführliche PDF ist aktuell hier zu finden (Letzter Check/Update des Links: 2019-01). Eventuell Logging-würdige Werte sind in verschiedenen Tabellen (‚Models‘) zu finden – z.B. Daten die dem Wechselrichter ‚als Ganzes‘ zugeordnet werden oder nur einem String von PV-Modulen.

Dokumentation S.30, Common Inverter Model. Zum Loggen der Wechselstrom-Leistung werden folgende Angaben benötigt: Adresse 40092, Registertyp 3 (read and hold), Datentyp float32 (Platz entspricht zwei 16bit-Register, daher ist die Endadresse 40093) und die Einheit Watt.

Wichtig dazu ist dieser Hinweis auf S.15:

D.h. auf einem Modbus-Client muss bei der Abfrage der Leistung 40091 angegeben werden.

Mit diesen Infos und der IP-Adresse des Wechselrichters in lokalen Netz wird ein entsprechender analoger Modbus-Eingang am CMI festgelegt:

Modbus-Analogeingang 1 liest die aktuelle PV-Leistung vom Wechselrichter. Der ‚Eingangswert‘ ergibt sich, wenn die Daten als Integerzahl interpretiert werden. ‚Aktueller Wert‘: Der Integer-Teil der ‚wahren‘ Gleitkommazahl.

Ja, wir haben uns das in einem Netzwerk-Trace angeschaut 😉 nachdem uns das Dropdown-Menü zur Byte-Reihenfolge etwas verwirrt hatte: Modbus-TCP sollte immer Big Endian verwenden laut Protokollspezifikation.

Faktoren und Datentypen: Am CAN-Bus werden nur Integer-Werte verarbeitet – evtl. mit einem Skalierungsfaktor als Zusatzinformation. Bei der Leistung in Watt gibt es da glücklicherweise keinen Handlungsbedarf. Würde man aber z.B. die 15A Strom mit einer Kommazahl loggen wollen, müsste man den Faktor auf 10 setzen um eine Kommastelle aus der Floatzahl ‚mitzunehmen‘. Vorher am Symo Integer + Skalierungsfaktor einzustellen ist nicht sinnvoll, da dieser Faktor in einem anderen Register des Wechselrichters steht … das das CMI natürlich nicht kennt.

Wenn man statt relativ stabilen Werten irgendwelche Zahlen zwischen ca. -32000 und + 32000 sieht 😉 merkt man, dass hier etwas schiefgegangen ist.

Diese Einstellung bedeutet noch nicht, dass das CMI die Modbus-Daten schon ‚hat‘ und mitloggt. Alles, was man bis jetzt davon ‚hat‘, ist die Anzeige des aktuellen Wertes in der CMI-Modbus-Einstellung. Zur Weiterverarbeitung inklusive dem Logging am CMI selbst muss wieder ein passender Ausgang definiert werden. Das CMI kann nur über CAN- oder DL-Bus loggen. Also brauchen wir einen…

… analogen CAN-Bus-Ausgang am CMI:

Das CMI hat die Standard-Knotennummer 56. Jedes andere Gerät am CAN-Bus kann damit diesen Wert auslesen durch Angabe der Knotennummer und der Nummer des Analogausgangs – 1.

Diese Geräte nutzen aktuell den CAN-Bus:

Darstellung der Geräte durch das CMI. Beim Klick auf (unterstützte) Geräte kommt man in das entsprechende Konfigurationsmenü.

Wenn man sich die Logging-Einstellungen am CMI ansieht, könnte man in Versuchung kommen, einfach das CMI selbst – CAN 56 – auszuwählen:

Am CMI konfiguriertes lokales CAN-Logging (Nutzung mit Winsol) – von UVR1611 (1), UVR16x2 (2) und dem Energiezähler CAN-EZ (41).

Erkenntnis: Das CMI kann aber seinen eigenen CAN-Ausgang nicht loggen. Man kann zwar CAN 56 als Logging-Quelle im Dropdown-Menü anklicken, aber das endet dann so:

CAN-Fehler am CMI – ausgelöst durch den Versuch, das CMI als Logging-Quelle einzutragen (so dass es gleichzeitig Logger und Quelle spielt).

Hier ist das ‚Durchschleifen‘ des Wertes durch die ‚loggingfähige‘ UVR nötig – womit endlich der Titel des Postings erklärt wäre!

An der UVR16x2 wird der CAN-Ausgang des CMI jetzt als CAN-Eingang (‚Netzwerkvariable‘) verbunden:

Definition des Netzwerkeingangs auf der UVR16x2. Quelle ist der CAN-Ausgang am CMI (Knoten 56, Ausgang 1).

Die Leistung in Watt wird als Integer übergeben. Hätte man am Modbuseingang einen Faktor 10 verwendet, müsste hier die Einheit auf ‚dimensionslos,1‘ gesetzt werden.

Aktueller Wert am CAN-Netzwerkeingang.

Die UVR16x2 kennt damit die PV-Leistung. Dieser Wert steht für Regelungszwecke zur Verfügung und Irgendwer kann beginnen, das Warmwasser-Zeitprogramm durch eine Digitalisierte Smarte 4.0 Big Data AI Bot Version abzulösen. Skynet entwickelt ein Bewusstsein!

Andererseits kann der Wert durch das CMI von der UVR geloggt werden – als Teil des immer schon genutzten CAN-Loggings:

Anzeige der geloggten Daten mit Winsol (Zugriff auf lokale Logfiles): PV-Leistung, Globalstrahlung auf die senkrechte Fläche des Kollektors, Kollektortemperatur, Außentemperatur.

… bzw. kann das ‚Portal-Logging‘ auf cmi.ta.co.at konfiguriert werden …

Konfiguration des Loggings direkt am Portal cmi.ta.co.at – als mögliche Loggingquellen stehen nur UVR1611 und UVR16x2 zur Verfügung. Die interessanten CAN-Ausgänge müssen in den rechten Bereich gezogen werden – dann kann dieser Parameter in einem Profil ausgewählt werden und das Diagramm des Werteverlaufs wird online angezeigt.

… und online mitverfolgt …

Anzeige Logging-Profil auf cmi.ta.co.at. In diesem Fall werden die Daten beim Logging vom CMI an das Portal gesendet und dort gespeichert.

Würde man alle Outputwerte des Fronius-Datamanagers auf diese Art loggen, hätte man außerdem schnell die Limits betreffend Netzwerkvariablen und Loggingplätzen erreicht. Wenn man unbedingt jede Minute die Spannung zwischen Phase 1 und 2 oder die Blindleistung wissen will, verwendet man besser einen eigenen Logger, z.B. Rasperry Pi. Hier ist ein perfekt dokumentiertes Projekt: Logging der Daten von Fronius Symo mit Python über Modbus TCP, plus Datenbank und Weboberfläche.

Nur Werte, die tatsächlich auch zum  Regeln benötigt werden, sollten beim Fenster rausgeworfen und bei der Türe wieder hereingebeten werden!