Raspberry Pi als Modbus-Server – ein Universalübersetzer für die UVR16x2

Seit Irgendwessen heroischem Umbau des Heizraums sind sie glücklich auf diesem hochprofessionellen Schaltbrett vereint – die diversen Geräte am CAN-Bus und der Raspberry Pi:

Dieser Anblick hat die Datenkrake inspiriert! Im Gegensatz zur fleißigen UVR16x2 langweilte sich der Raspberry Pi – alle paar Minuten die Daten der Wärmepumpe von deren CAN-Bus loggen war nicht Herausforderung genug.

Es war Zeit, einige langjährige Vision umzusetzen:

Wärmepumpen-Daten auch in der UVR. Hin und wieder wurden die Siedler gefragt, warum sie die Daten der Stiebel-Eltron WPF7 basic nicht einfach direkt in die UVR loggen -‚Ist ja alles CAN-Bus!‘. Nicht ganz: Wie andere Netzwerkprotokolle gibt es auch hier verschiedene Schichten und auf der obersten (Applikations-)Ebene spricht die UVR canopen  und die Wärmepumpe eine proprietäre Variante.

Außerdem sind selbst die Siedler als furchtlose Tüftler etwas vorsichtig damit, den internen CAN-Bus der Wärmepumpe zu verbinden mit dem anderen CAN-Bus auf dem mittlerweile ja Einiges los ist. Man macht ja so seine Erfahrungen mit Geräten, die sich durch theoretisch harmlose Netzwerkpakete anderer gestört fühlen.

Aber was wäre, denn der Raspberry Pi die über den CAN-Bus geloggten Daten selbst wieder ‚auflegen‘ könnte – über ein Protokoll, dass die UVR versteht?

Der Klassiker – Photovoltaik und Eigenverbrauch: Die Datenkrake ermittelt schon lange Kenndaten wie z.B. den PV-Direktverbrauch oder den Haushaltsstrom ohne Wärmepumpe – das war aber bis jetzt nur auf Tagesbasis möglich, da die diversen Logger unterschiedliche Logging-Zeitpunkte und -Intervalle verwenden. Die bisher gezeigten Tagesgänge waren einfach übereinander gelegte Kurven mit unterschiedlichen Zeitwerten.

Es wäre also schön aus aktuellen Daten von Wechselrichter, Zähler und UVR16x2 eigene Werte berechnen zu könne – im Minuteninterval.

Der Fronius-Symo-Wechselrichter unterstützt Modbus – die Siedler loggen die aktuelle PV-Leistung über diesen Weg ‚in das CMI‘ bzw. die UVR. Der Zähler der Siedler hat aber ’nur‘ eine Weboberfläche und bietet die Daten in strukturierter Form über JSON an. Das CMI unterstützt zwar JSON, aber nur ‚in die andere Richtung‘: Man kann Daten der neueren Geräte von Technische Alternative über JSON vom CMI abfragen.

Was wäre, wenn der Raspberry Pi die JSON-Daten so aufbereiten könnte, dass das CMI sie lesen kann?

Kommunikation auch in die andere Richtung. Für manche Berechnungen braucht der Raspberry Pi auch Input von der UVR – d.h. die UVR16x2 muss z.B. die aktuelle Kompressorenergie an den Pi ’senden‘. JSON am CMI ist dafür nur bedingt geeignet, da Daten nur maximal 1x pro Minute abgerufen werden dürften.

Leider ist die hier mühsam aufgebaute Spannung schon verpufft – im Titel steht schon die Lösung:

Der Rasperry Pi arbeitet als Modbus Server (bzw. ‚Slave‘)! Daten werden von anderen Loggern über deren Protokolle geholt, z.B,. über JSON vom Smart Meter oder über Modbus vom Wechselrichter. Diese Daten werden vom Pi auf eigenen Modbus-Registern zur Verfügung gestellt. Zusätzlich werden Werte berechnet – wie der PV-Direktverbrauch – und ebenfalls ’serviert‘.

Das CMI arbeitet als Client (bzw. ‚Master‘) und holt die Daten vom Rasperry Pi ab. Für das Datenlogging in das CMI-Logfile und die eventuelle Nutzung als Signal für Aktionen der UVR ist wieder das Fenster-raus-Türe-rein-Spielchen mit Roundtrip über den CAN-Bus erforderlich.

Damit arbeitet der Pi als ein universeller Protokollübersetzer zwischen den Loggern.

Auch bei der Kommunikation ‚in die andere Richtung‘ ist das CMI der Client. Die Kompressorleistung wird nicht auf einem Register des CMI serviert, sondern das CMI schreibt diese Daten in ein Register des Modbus-Server am Pi. Spätestens an der Stelle sollte man vielleicht auch ein wenig paranoid werden und sicherstellen, dass sich das alles nur in einem selbst kontrollierten Netzwerk abspielt. Bei Modbus gibt es nämlich Null Security.

Umgesetzt hat die Datenkrake das mit der Python-Programmbibliothek pymodbus: Der eigentliche Modbus-Server läuft in einem eigenen Thread; die Daten werden in einer unendlichen Schleife von den anderen Loggern geholt und bearbeitet – und dann werden die Register mit den Ergebnissen befüllt.

Am CMI werden Modbus-Eingänge erstellt für alle zu loggenden Werte – Zähler EM210, Wärmepumpe, berechnete Werte …

…und Ausgänge für die Werte, die in die andere Richtung ‚gesendet‘ werden:

Sind dann die entsprechenden CAN-Ausgänge am CMI und Netzwerkvariablen an der UVR eingerichtet …

… steht dem Mitfiebern über Winsol nichts mehr im Wege!

Aber man sollte auch kurz einmal innehalten und sich andächtig den Fluss der Messdaten der Wärmepumpe selbst vorstellen. Die geloggten Heißgastemperaturen z.B. …

… fließen über folgende Stationen:

  • Interner CAN-Bus der Wärmepumpe
  • CAN-Sniffer-Board des Raspberry Pi
  • Register des Modbus-Server des Raspberry Pi
  • Modbus-Eingang am CMI
  • CAN-Ausgang am CMI
  • CAN-Eingang an der UVR16x2
  • Loggingplatz am CMI für diesen CAN-Eingang

Für die lebenswichtigen, kritischen Steuerungssignale würden die Siedler diese Vorgangsweise nicht unbedingt empfehlen 🙂

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