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 …

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äglilch 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. 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!

Aus BUSO wird LEO: Hydraulik-Chirurgie

Es war keine ganz einfache Operation gewesen. Aber die Herztransplantation der Anlage war erfolgreich verlaufen. Der alte Gaskessel war herausgeschnitten und durch eine funkelnagelneue Sole-Wasser-Wärmepumpe ersetzt worden, die nun mit kräftigen Herzschlägen die Adern der Heizungsanlage mit warmem Wasser flutete.

Durch den gleichzeitig durchgeführten chirurgischem Eingriff im Regler-System liefen nun alle elektrischen Signale der Sensoreingänge und Schaltausgänge im CMI zusammen, wo sie im Minutentakt aufgezeichnet wurden und so ein Quasi-EKG der Anlage lieferten.

CMI (Control & Monitoring Interface): Die Logging-Zentrale ...

Das CMI (links oben) zeichnete alle Regelungssignale auf …

Und mit genau diesem EKG war Irgendwer noch nicht wirklich zufrieden. Die erhöhte Vorlauftemperatur der Wärmepumpe würde die Leistungsfähigkeit des Patienten nachhaltig gefährden.

BUSO-Log-2017-11-06

Die hohe Vorlauftemperatur der Wärmepumpe (T.WP 1) bereitete Irgendwem noch etwas Kopfzerbrechen …

Irgendwie vertrug sich das neue Herz noch nicht ganz mit dem über Jahre und Jahrzehnte gewachsenen Organismus der bestehenden Anlagenhydraulik. Wieder und wieder hatte er das EKG studiert und jedes mal war er zum gleichen Schluss gekommen: Die Durchblutung des Kombispeichers war gestört, was wiederum eindeutig mit dessen Bauweise zusammenzuhängen schien.

BUSO-Kombispeicher

Der eingebaute Warmwasser-behälter schien die natürliche Konvektion im Kombispeicher empfindlich zu stören …

Gleichzeitig war dieses Organ stark belastet. Zwei Heizkreise wurden von ihm gespeist. Und als wäre das nicht genug gewesen, war es auch noch für die gesamte Warmwasserversorgung zuständig. Andererseits gab es da einen enormen Doppel-Pufferspeicher, der vor Langeweile Däumchen drehte.

BUSO-Hydraulikschema-vorher

Historisch gewachsene Anlagenhydraulik, in der der ehemalige Gaskessel durch eine Sole-Wasser-Wärmepumpe samt LEO_2-Wärmequelle ersetzt worden war …

Und während er das Hydraulikschema hin- und herwälzte, formierte sich die Lösung vor seinem geistigen Auge. Hier musste definitv ein Bypass gesetzt werden und dort eine Rückschlagklappe. Wenn man dann an dieser Stelle noch ein Ventil einbaute und diese beiden Anschlüsse ein wenig versetzte …

BUSO-Hydraulikschema-nachher

Und so sollte die Anlagenhydraulik nach dem chirurgischen Eingriff aussehen: Ein Bypass sollte die Durchblutung im oberen Bereich des Kombispeichers verbessern. Die Heizkreise sollten zur Entlastung an die Pufferspeicher gehängt werden. Und die Herzklappen V.Lad.PS und V.Lad.KS sollten zu einer abwechselnden Durchblutung von Puffer- und Kombispeicher führen …

Schon wurde der Operationssaal vorbereitet. Der Siedler und sein Kumpel sollten diesen Eingriff mit telemedizinischer Unterstützung vornehmen. Einen solche Operation hatte noch niemand vor ihnen versucht und würde ihnen sicherlich einen Vorschlag zum Nobelpreis einbringen!

Und tatsächlich! Als der Patient das zweite Mal aus dem Tiefschlaf erwachte, ging es ihm deutlich besser. Er sollte schon fast in häusliche Pflege entlassen werden, als bei einer Nachuntersuchung eine immer noch erhöhte Rücklauftemperatur der Wärmepumpe diagnostiziert wurde, die die Arbeitszahl in den Keller drückte.

BUSO-Log-2017-12-14

Besser, aber die Rücklauftemperatur der Wärmepumpe  (T.WP 2) war immer noch zu hoch …

Verflixt! Wo kam denn das schon wieder her! Aus dem Hydraulikschema war kein Hinweis darauf zu erkennen …

So musste die Anlage Rohr für Rohr und Ventil für Ventil untersucht und mögliche Abweichungen zum Hydraulikschema ausfindig gemacht werden. Und tatsächlich, nach einer Abenteuerreise durch den staubigen Heizungskeller und einem Tauchgang in der ‚Kiste‘ fand sich unter einem dicken Wulst aus Isoliermaterial der Übeltäter: Ein Vier-Wege-Mischer!

BUSO-4-Wege-Mischer

Unter der Isolierung befand sich – auf den ersten Blick nicht zu erkennen – der Missetäter: ein 4-Wege-Mischer …

Den hatte wohl in grauer Vorzeit jemand zur Rücklaufanhebung eingebaut, die aber heute in Verbindung mit einer Wärmepumpe vollständig kontraproduktiv war …

BUSO-3-4-Wege-Mischer

Statt des im Hydraulikschema vermuteten 3-Wege-Mischers fand sich tatsächlich ein 4-Wege-Mischer in der Anlage. Dieser bewirkt im Misch-Zustand die Anhebung der Rücklauftemperatur!

Dieses kleine Gebrechen mit großer Wirkung konnte aber in diesem Fall ambulant behoben werden. Kurze Zeit später verließ der Patient bei bester Gesundheit mit einer runderneuerten Hydraulik das Spital.

BUSO-Log-2018-03-14

Und das Hydraulik-EKG entsprach nun auch endlich Irgendwessen Ansprüchen…

Gönnen wir dem CMI sein eigenes Netz!

oder:

Wie Irgendwessen Problem gelöst wurde, weil das elkement gerne schnüffelt, was die ‚Dinge‘ so machen im Internet of Things.

Irgendwer stand vor einer besonderen Herausforderung: Der Chefingenieur und Regler-Freak hatte das ideale Plätzchen gefunden: Genügend Platz und Ruhe, um UVR16x2, CMI & Co für seine Projekte aufbauen, verkabeln und testen zu können. Fast ideal, wenn man es genau nahm. Denn die Siedler hatten diesem Plätzchen kein LAN gegönnt. Das CMI  – das Control and Monitoring Interface, also das ‚Ethernet-Gateway‘ des Reglers – konnte nicht angeschlossen werden. Damit wäre Irgendwer zurück in die Steinzeit des SD-Karten-Hin-und-Hertragens geworfen worden.

Aber ‚glücklicherweise‘ legten gerade einige ganz besonders fiese Kameras und Videorekorder das halbe Internet lahm – und das elkement erinnerte sich dadurch an eine bereits einmal hier publizierte Anleitung zum Thema: Wie kann man als normaler Windows-Benutzer ohne Hackererfahrung herausfinden, welche Botschaften diese (bösen?) Dinge in die Welt senden und empfangen?

Hier wurde ein von Profis oft belächeltes Feature von Windows genutzt – die so genannte Internetverbindungsfreigabe: Ein normaler Windows-PC kann damit in einen Router verwandelt werden: Der PC verbindet sich wie immer per WLAN ins lokale Siedlernetzwerk – und damit ins Internet. Das ‚Ding‘ wird mit den LAN-Anschluss des PC verbunden und kann die ‚freigebene‘ Internetverbindung nutzen. Nachdem der PC jetzt höchspersönlich alle Netzwerkpakete des Dinges weiterreicht, kann der investigative Benutzer diese auch mit Sniffer-Software auf diesem PC untersuchen.

Aber eigentlich kann man diese Funktion ja einfach so verwenden, wie sie vielleicht gedacht war: Einem WLAN-unfähigen Ding wird eine Brücke ins Internet gebaut.

Aus Klimaschutzgründen wurde natürlich ein ausrangiertes Testnotebook verwendet, dem so ein zweites Leben als wichtiger Router ermöglicht wurde.

Die folgende Grafik zeigt die ‚Netzwerkarchitektur‘:

Netzwerk zum Testen eines CMI mit Regler UVR16x2 in seinem eigenen Subnetz

Der Ethernetanschluss des Laptop-Routers wird von Windows mit der IP-Adresse 192.168.137.1 konfiguriert, sobald die Internetfreigabe aktiviert wurde. Dieser Computer wird zum DHCP-Server und weist dem dem ‚Ding‘ eine dynamische IP-Adresse aus demselben Netzwerk zu, z.B. 192.168.137.2. Der WLAN-Adapter erhält eine Adresse aus dem sonst verwendeten ‚Office‘-Netzwerk (oft: 192.168.0.x)

Für Details zu den Einstellungen am PC siehe den früheren Artikel über das Internet der Dinge. Unter Windows 10 muss/kann jetzt auch die Netzwerkverbindung nicht mehr ausgewählt werden, auf der das Ding sitzt. Kleiner Tipp, bestätigt durch die bewährte Methode ‚Googlen in Foren‘: Wenn unter Windows 10 die Internetverbindungsfreigabe nach einem Neustart nicht mehr funktioniert, muss sie nochmals in den Eigenschaften des WLAN-Adapters deaktiviert und wieder aktiviert werden.

Wie früher schon berichtet wurde, kann so eine Kaskade von Netzwerken auch sinnvoll sein, um ein sensibles Ding (wie den Logger BL-NET) vor einem besonders gesprächigen Ding (IP-TV) zu schützen.

Irgendwer konnte somit wahlweise über das Router-Notebook lokal auf das CMI zugreifen oder über das Internet, also sozusagen bei der Türe raus und beim Fenster wieder rein. Da man vom lokalen ‚Office‘-Netzwerk gar nicht direkt lokal auf das CMI kommt (sondern nur über die ‚Cloud‘), ist das auch halbwegs realistischer Test der späteren Fernwartung über das Internet.

Die Reglerprogrammierung ging damit eigentlich fast schneller als das Aufräumen des Spielplatzes Arbeitsplatzes danach:

irgendein-stilles-plaetzchen-unaufgeraeumt

Die UVR16x2. Und ihr soziales Umfeld.

Kaum zu glauben. Es ist jetzt auch schon wieder fast 2 Jahre her, seit die UVR16x2 der Technischen Alternative das Licht der Welt erblickt hatte und in seiner Urversion ausgeliefert worden war.

Auch wenn Irgendwer gewusst hatte, dass die ’neue UVR‘ zu diesem Zeitpunkt noch nicht ‚ganz fertig‘ gewesen war, hatten sich doch der Spieltrieb und der Forscherdrang hinterlistig gegen die Vernunft verbündet und nach einem kurzen Widerstreit die Oberhand gewonnen. Sodass die UVR16x2 bald darauf im Maschinenraum der Siedler – so wie ihre älteren Schwester UVR1611 – einen festen Platz auf einem hübschen Holzbrettchen gefunden hatte…

UVR16x2-am Brettchen

Die UVR16x2 am rechten Brettchen und ihre ältere Schwester die UVR1611 (links).

Irgendwen hatte von Beginn an die konsequente Philosophie der TA begeistert, die sich im herben Charm des Designs, der lieb gewonnenen Logik der Bedienoberfläche und der klassischen Stift-Bedienung des Touch Screens widerspiegelte. Er war fast enttäuscht, als er das erste Mal den Regler-Teil aus seinem Sockel zog und sich dieser problemlos(!) ohne minutenlangem Rütteln und Zerren (wie bei der 1611) entfernen ließ.

UVR16x2-Aus-dem-Gehäuse-nehmen

Unglaublich! Ohne Spezialwerkzeug mit bloßen Händen ließ sich die UVR16x2 vom Sockel abziehen und aus dem Gehäuse nehmen …

Ja, in einer modernen Welt muss man auch lernen, sich von lieb gewonnenen Gewohnheiten zu verabschieden. 😉

Am Anfang war die UVR16x2 – was will man von einem Teenager erwarten – noch etwas unreif und bockig gewesen. Und die Kommunikation mit ihrem sozialen Umfeld, wie etwa dem CMI, hatte sie konsequent verweigert. Daher konnte sie von Irgendwem nur mit unkritischen Mess- und Regelungsaufgaben betraut werden und war lange Zeit zu einem Schattendasein verurteilt.

Aber glücklicherweise war sie – ebenso wie ihr soziales Umfeld – lernfähig. Eine Reihe von ‚Firmware- und Software-Upgrades‘ waren notwendig, bis sie alle sozialen Umgangsformen beherrschte, die für die Steuerung von LEO_2 unverzichtbar waren:

TAPPS2

Das begann mit der Programmierung der UVR16x2 in TAPPS2. Es gab eine Reihe überarbeiteter und neuer, interessanter Funktionsbausteine, wie z.B. eine ‚Kennlinienfunktion‘ oder das unscheinbare ‚Sample&Hold‘, die sich beide für die Forschung der Siedler noch als echte Bereicherung herausstellen sollten. Aber es war vor allem die von der UVR1611 bekannte Konfiguration des Datenloggings, die Irgendwer für die UVR16x2 am Anfang vergeblich in TAPPS2  gesucht hatte.

Aber nachdem sich Irgendwer etwas in Geduld geübt hatte, war er für das anfängliche Fehlen inzwischen mit deutlich umfangreicheren Konfigurationsmöglichkeiten für das Datenlogging entschädigt worden. Viele Funktionsparameter waren nun als ‚Ausgangsvariable‘ der jeweiligen Funktionsbausteine und damit für das Logging verfügbar geworden.

UVR16x2-Datenlogging

Die ‚Ausgangsvariablen‘ und damit die verfügbaren Parameter für das Datenlogging waren für die UVR16x2 deutlich umfangreicher geworden. Die besten Voraussetzungen um die Anlage eingehend zu analysieren …

C.M.I.

Abgeschnitten vom CMI (und damit vom Internet) hatte die UVR16x2 auf ihrem Holzbrettchen lange Zeit ein einsames Dasein fristen müssen, hätte sie nicht Irgendwer zu regelmäßigen Firmware-Updates besucht. Diese mussten – wie in alten Zeiten – auf einer SD-Karte zwischen PC und UVR hin und her transportiert werden.

UVR16x2-SD-Karte

Firmware-Update mittels altertümlichem Datentransport …

Aber inzwischen hatte auch die Kommunikation mit dem CMI ein Niveau erreicht, das (fast) keine Wünsche mehr offen ließ: Irgendwer musste seine Kommandozentrale nicht mehr verlassen, um die UVR16x2 zu bedienen …

UVR16x2-CMI-Fernbedienung

Über das CMI -Webinterface ließ sich die UVR16x2 vollständig fernbedienen.

oder Updates von Firmware und Funktionsdaten einzuspielen …

UVR16x2-CMI-Datenverwaltung

In der ‚Datenverwaltung‘ des CMI-Webinterfaces war es nun möglich, Updates für Firmware und Funktionsdaten mittels ‚Drag & Drop‘ auf die UVR16x2 zu übertragen.

TA-Designer

Kein LEO_2 ohne Online-Schema. Aber auch die Erstellung eines solchen war zu den Anfängen von der UVR16x2 noch nicht möglich gewesen.

Aber die Zeit heilt ja bekanntlich alle Wunden. Inzwischen verstand der TA-Designer auch die Funktionsdaten der UVR16x2, womit Irgendwessen Anforderungen an die Gestaltung eines vernünftiges Onlineschemas mehr als erfüllt wurden.

UVR16x2-TA-Designer

Umfangreiche Möglichkeiten bei der Gestaltung eines Online-Schemas im TA-Designer.

Und ein kleines aber wichtiges Detail gefiel Irgendwem beim TA-Designer besonders gut: Er war sehr häufig ‚Erfolgreich‘!

UVR16x2-Erfolgreich

UVR1611, CMI und Logging (X-Akten, Teil 2)

Aus der Reihe Leser fragen; das war Teil 1: ‘Error!’ oder: Die Wahrheit ist irgendwo da draußen.

Dieses Mal erreichten uns folgende – zusammen hängende – Fragen ambitionierter Regelungs-Hacker aus dem IT-Bereich:

  1. Das Web-Interface zum CMI sieht etwas altbacken aus – gibt es da einen Webservice, den man anprogrammieren könnte?
  2. Ich habe mir den UVR1611 Data Logger Pro angesehen – was macht jetzt dieser BL-NET und wozu brauche ich den?
  3. Ihr Siedler sagt, ihr greift über das lokale Netzwerk auf das CMI zu – wie wertet ihr die Messdaten aus?

Das Elkement erinnert sich an seine ersten Versuche, mit BL-NET, UVR1611 und später CMI Kontakt aufzunehmen. Für klassische IT-Freaks doch etwas gewöhnungsbedürftig!

Alvim-correa12

Zu 1) Es gibt keinen Webservice. Auf die Logging-Daten beider Logger – BL-NET und CMI kann mittels der TA-Software Winsol zugegriffen werden, d.h. es ist ein Windows-PC oder eine virtuelle Maschine erforderlich. Winsol lädt die Logfiles auf diesen PC. Diese Dateien sind nicht direkt lesbar und werden in Winsol angezeigt bzw. wahlweise auch aus Winsol in Textdateien (CSV) exportiert. Da das CMI eine SD-Karte als Speicher verwendet, braucht dieser – im Vergleich zu BL-NET – auch nur sehr selten ausgeleert werden.

Zu 2) Nach der Beschreibung des UVR1611 Logger Pro (mit dem wir selbst keine Erfahrung haben) wird der BL-NET hier nur als CAN-Ethernet-Gateway verwendet, aber nicht mehr als Logger. Durch das Loggen in eine andere Datenbank wird ebenfalls das Problem des schnell ausgenutzten BL-NET-Datenspeichers umgangen, außerdem lässt sich der Zugriff von extern sicherer konfigurieren.

Man findet bei der Suche nach UVR1611 Logger Pro Heizungs-Websites im Internet, die im Gegensatz zu unseren Stichproben zur CMI- oder BL-NET-Website wahrscheinlich auch absichtlich so konfiguriert wurden – wir aber trotzdem hier nicht verlinken wollen.

Aus dem verwendeten Port (40000 laut Config-Datei) lässt sich schließen, dass der Logger-PC, z.B. Raspberry Pi, das gleiche Protokoll verwendet wie WinSol in der Kommunikation mit BL-NET. Kurzes Sniffen des HTTP-Traffics zwischen einem Winsol-PC und CMI (Port 80) zeigt im Vergleich zum Winsol-BL-NET-Traffic, dass ein anderes Protokoll verwendet wird. Nach den Infos in dieser Diskussion (Stand Dezember 2014) wird das CMI-Protokoll derzeit vom Logger Pro noch nicht unterstützt.

Update im Herbst 2015: CMI wird jetzt vom Logger Pro unterstützt, ebenso UVR16x2.

Zu 3) Was machen wir Siedler? Wir importieren diese CSV-Dateien in unseren SQL-Server, konsolidieren die Daten dort, führen sie mit manuell gemessenen Daten zusammen und berechnen wichtige Kenndaten wie Arbeitszahlen. Alle in diesem Blog gezeigten Plots werden mit Excel als ‚Frontend‘ zu dieser SQL-Datenbank erstellt, aktuelle Daten sehen wir uns einfach in Winsol an. Außerdem arbeiten wir an einer Excel-Auswertung, die die wichtigsten Kennzahlen direkt aus den CSV-Dateien ermittelt.

Auf der Basis der exportierten Logfiles anderer Siedler können wir mittels Winsol Detektivarbeit zu betreiben – unabhängig von deren Logger (CMI oder BL-NET) oder deren Firewall-Einstellungen. Praktisch ist es aber, dass CMI mit der letzten Firmware nun auch das Logging ‚direkt vom Portal‘ unterstützt.

Winsol: Warmwasser-Durchfluss und Speichertemperaturen

Winsol: Durchfluss Warmwasser und Temperaturen (von Warmwasser und Hygienespeicher). Hier ist nicht einmal besondere Detektivarbeit nötig, um zu sehen, dass manche Lebensformen in dieser Siedlerhütte einen wahrhaft elementaren Warmwasser-Verbrauch haben. Beliebige Ausschnitte lassen sich durch ‚Zeichnen eines Rechtecks‘ heranzoomen.

Zusätzlich sind die aktuellen Messdaten auch in unserem Online-Schema über das Webportal cmi.ta.co.at verfügbar – allerdings nicht für anonyme Benutzer. Wir geben unser Schema gerne frei, bitte ggf. um den TA-Benutzernamen an das elektronische Postfach der Siedler unter punkt [ät] punktwissen.at.

Online-Schema CMI

Online-Schema, Anzeige durch das CMI