Auf der Suche nach einer Möglichkeit den Eigenverbrauch zu erhöhen, fiel ein Batteriespeicher aufgrund der hohen Anschaffungskosten raus. Was tun?

Vor einigen Jahren wurde der Kachelofen mit Wassertasche vom Schornsteinfeger wegen Umweltauflagen still gelegt (sehr schade drum). Dadurch ist aber noch der Warmwasserspeicher im Heizungsraum vorhanden. Diese hatte nach der Stilllegung des Kachelofen keine weitere Wärmequelle als die Ölheizung. Solarthermie ist leider nicht vorhanden und auch für eine Neu-Installation zu aufwändig.

Wir dachten dann über einen Heizstab nach. Der Wasserspeicher hat die Möglichkeit einen Heizstab von oben einzuschrauben. Leider ist es aber sehr schwierig, Heizstäbe mit entsprechend langer heiz-freier Zone zu bekommen, da das Wasser im Wasserspeicher ja nicht randvoll gefüllt ist. Bei anderen Herstellern von Warmwasserspeichern kann man den Heizstab seitlich einschrauben. Und der Heizstab vom Hersteller des Wasserspeichers ist leider raus, da er zu lang ist und wir den Warmwasserspeicher hätten kippen müssen. Es musste also eine andere Lösung her.

Wärmekreislauf im Selbstbau

Ein guter Freund meines Vaters ist Heizungsbauer und hat eine Vorrichtung gebaut, die analog der Wassertasche des alten Kachelofen das Wasser mittels Umwälzpumpe, an einem Heizstab vorbei, in den Warmwasserspeicher pumpt. Die Pumpe war noch vom Kachelofen vorhanden und der Heizstab ist ein günstiger ~ 2KW Heizstab mit 1 1/2 Zoll Gewinde. Dieser steckt nun in einem Eisenrohr/T-Stück mit entsprechendem Gewinde und ist über Kupferleitungen an den Warmwasserspeicher angeschlossen. Zudem wurde dieser Kreislauf noch an das Ausdehnungsgefäß des normalen Heizkreislauf angeschlossen, damit wir uns ein zweites Ausdehnungsgefäß sparen konnten.

Im Bild erkennt man den Heizstab, der senkrecht in dem Eisenrohr steckt, die grüne Umwälzpumpe und die entsprechende Verrohrung. Später wurde die Konstruktion noch isoliert.

Jetzt soll der Heizstab aber nur eingeschaltet werden, wenn auch PV-Überschuss vorhanden ist. Kauflösungen wie z.B. „intelligente“ Heizstäbe von ELWA kosten > 500 €. Soviel wollten wir aber nicht ausgeben, da die Ausbeute und der Wirkungsgrad um Wasser mit elektrischer Energie mittels Heizstab zu erhitzen nicht sehr effizient ist und sich schlecht amortisiert. Eine kleine Wärmepumpe schied übrigens vorerst aus Kostengründen auch aus.

Die Daten…woher bekommen?

So, wie kommt man nun an die Daten wann die Anlage Überschuss produziert? Der SMA-Wechselrichter ist ohne „Sunny Boy“ nicht wirklich auskunftsfreudig (es war ja ein Low-Budget-Selbstbau-Anlage). Aber welche Daten werden denn benötigt?

• den Eigenverbrauch des Hauses und
• die aktuelle Leistung, die durch die Solaranlage geliefert wird

Die Werte für den Eigenverbrauch hatten wir schon relativ schnell nach Inbetriebnahme der Solaranlage durch Einbau eines Powerfox am digitalen Stromzähler erledigt. Dieser misst am Energiezähler die aktuell benötigte Leistung, sowie die elektrische Energie des Verbrauchs und der Einspeisung. Den Powerfox kann jeder einfach anbringen, da er nur mittels Magnet an der entsprechenden Stelle am Zähler befestigt wird. Hier sind keine Arbeiten im Stromkasten notwendig. Der Powerfox ist mit den meisten digitalen Stromzählern kompatibel. Ggf. in die Modell-Liste von Powerfox schauen. Ich selber nutze hier eine Selbstbaulösung, aber der Powerfox ist „adminfreundlicher“.

Die Messung der Leistung der Solaranlage kam dann etwas später durch den Einbau eines Shelly 3EM mit drei Stromzangen im Stromkasten dazu. Die Stromzangen werden einfach um die drei Phasen gelegt, die vom Wechselrichter kommen. Der 3EM kommt auf die Hutschiene im Stromkasten und benötigt noch Versorgungsspannung. Für den Einbau ggf. besser einen Elektriker zu Rate ziehen!

Damit hatte mein Vater schon vor der Idee mit dem Heizstab alle wichtigen Informationen der Solaranlage und des Hausverbrauches zur Verfügung. Allerdings über zwei unterschiedliche Apps und ohne zentrale Einheit wie ein Smart-Home-Server.

Zurück zum Heizstab. Alle Infos, um den Heizstab bei PV-Überschuss anzuschalten waren also schon vorhanden. Um nun aus diesen Infos den eigentlich Überschuss zu berechnen und den Heizstab zu schalten, kam ich nicht mehr drumherum, einen kleinen Server mit entsprechender Software aufzusetzen.

Die Steuerung

Das Erste was mir als Software in den Sinn kam war openWB. Ich habe eine openWB-Wallbox und nutze sie schon zum Überschussladen des E-Autos und hatte mich auch schon mal in das von mir nicht genutzte SmartHome-Menü der openWB verirrt. Die Software selber kann auch ohne Wallbox-Funktionalitäten auf einem RaspberryPI betrieben werden. Ich hatte noch einen Pi 3 hier liegen und die Software war schnell installiert. Der Powerfox und der Shelly 2EM (sowie andere Produkte von Shelly) werden bereits von openWB unterstützt. Die Integration funktioniert einfach mit Eingabe der Shelly-IP bzw. der Powerfox-Cloud-Daten über die Weboberfläche der OpenWB.

Danach zeigt die Startseite der openWB die gemessenen Werte an. Im Screenshot aktuell sehr wenig Sonne und relativ viel Hausverbrauch.

Verschiedene Smart-Home-Geräte (unter die auch der zukünftige Heizstab fällt) können nun in der openWB konfiguriert werden und mit Aktionen hinterlegt werden. Der Heizstab selber ist natürlich nicht „Smart“. Ein- und ausgeschaltet werden soll er über einen Shelly Plug S. Den Shelly sieht man auch auf dem ersten Bild oben links. Daran angeschlossen ist der Heizstab und die Umwälzpumpe. Auch dieser Shelly wird von openWB als Smart-Home-Gerät unterstützt.

Was jetzt noch bleibt, sind verschiedene Einstellung am Smart-Home-Gerät:

• Schwellenwerte (in Watt) zum Ein- und Ausschalten,
• Nachlaufzeiten (in Sekunden) damit der Stab nicht ständig an- und ausgeht wenn Wolken aufziehen,
• Zeiträume und Gesamtdauer pro Tag in denen überhaupt geschaltet wird (zur Sicherheit falls die openWB den Shelly Plug aus irgendwelchen Gründen nicht ausschaltet)
• und einige andere Einstellungen.

Das ist natürlich abhängig vom Heizstab, dem Warmwasserspeicher und der gesamten PV-Anlage. Hier muss ein bisschen ausprobiert werden welche Werte für die jeweilige Anlage am besten passen.

Zur Sicherheit wird der Shelly Plug an Pumpe und Heizstab auch noch täglich mit Sonnenuntergang durch die Shelly-App ausgeschaltet und der Heizstab besitzt noch ein eigenes Thermostat, wodurch er sich selber ab einer einstellbaren Temperatur ausschaltet. Mit diesen Mitteln und den Einstellungen in der openWB sollte ein überhitzen bzw. zu langes laufen des Heizstabes ausgeschlossen sein.

Die Apparatur läuft seit dem Herbst 2024. Die Tage, an denen Sonne war und der Schwellwert für den PV-Überschuss in der openWB erreicht wurde, schaltete den Heizstab und die Umwälzpumpe über den Shell Plug einwandfrei ein und aus. Den Status des Heizstabes (An/Aus) sowie die aktuell benötigte Leistung und die pro Tag in den Heizstab geflossene Energie zeigt die openWB auch auf der Startseite an.

Grundsätzlich funktioniert das also. Wirklich viel PV-Überschuss gab es aber leider nicht, so das wir das nächste Frühjahr abwarten müssen.

Wunder wird der kleine Heizstab im Warmwasserspeicher nicht vollbringen, aber auch im Sommer wird warmes Wasser benötigt und es sollte dann Wärme produziert werden, die mehr als 8 Cent wert ist. Die Ausgaben hielten sich auch sehr in Grenzen. Eigentlich war es nur der Heizstab für < 100 € und der Shelly Plug für 23 €. Der Rest war schon vorhanden (Powerfox und Shelly 3EM) bzw. lag irgendwo herum (Raspi, Umwälzpumpe). Das Installations-Material kostete ein Feierabendbier.

Ich werde mal berichten wie das Ganze im Sommer funktioniert.

Gruß
Chris

In den Einstellungen des Sensors gibt es daher nun die Möglichkeit das entsprechend zu konfigurieren zu können.

Zudem hatte ich noch in geistiger Umnachtung, den Namen/IP des Rechners, den Port und den Endpunkt zum Aufruf der eigenen API hart mit einer internen URL von mir verdrahtet. Immerhin hatte ich mir einen Kommentar im Quellcode geschrieben, dass das noch geändert werden muss. Hat nix geholfen, ist aber jetzt auch korrigiert.

Hier die aktuelle bin-Datei in der Version 1006:

http://www.bubux.de/heimautomatisierung/ota/gaszaehler_aktuell.bin

Für die Installation, weitere Erklärungen etc. gilt noch die Beschreibung aus dem ursprünglichen Artikel. Zudem der Artikel zum Auswerten der Impulse in Grafana.

Gruß Chris

Das Zählen der Impulse habe ich bei mir mit einer kleinen PHP-Seite umgesetzt, die bei jedem Aufruf einen neuen Eintrag in eine Datenbank schreibt. Der Mikrocontroller ruft bei mir dazu die Seite „GasMeterImpuls.php“ auf, die auf einem Webserver liegt. Das PHP-Script macht dabei nicht anderes, als bei jedem Aufruf eine neue Zeile mit Zeitstempel und einer „1“ für den Impuls in eine Tabelle einer MariaDB zu speichern.

<?php
//********************************************
//Impuls vom Gaszaehler in Datenbank schreiben
//********************************************

$servername = "";
$username = "";
$password = "";
$dbname = "";

$conn = new mysqli($servername, $username, $password, $dbname);

if ($conn->connect_error) {
        die("Connection failed: " . $conn->connect_error);
}

$sql="INSERT INTO gaszaehler (timestamp,zaehlerstand) VALUES (CURRENT_TIMESTAMP,1)";

if ($conn->query($sql) === TRUE) {
        //echo "Neuer Eintrag erzeugt";
} else {
        echo "Fehler: " . $sql . "<br>" . $conn->error;
}

$conn->close();
?>

Die Tabelle in der MariaDB ist sehr einfach und besteht nur aus zwei Spalten. Einmal eine Spalte mit einem Zeitstempel und eine weitere Spalte für den Impuls. Der Spaltenname „zaehlerstand“ ist evtl. etwas irreführend. Hier werden nur die einzelnen Impulse und kein Gesamtzählerstand gespeichert!

Hier das Create-Table für die Tabelle:

CREATE TABLE `gaszaehler` (
  `timestamp` datetime NOT NULL,
  `zaehlerstand` int(11) NOT NULL
) ENGINE=InnoDB

Heute würde ich anstelle der MariaDB eher eine auf Zeitreihen spezialisierte InfluxDB nehmen. InfluxDB arbeitet auch besser mit Grafana zusammen. Die Nutzung der MariaDB ist bei mir aber „historisch“ bedingt ;-).

Die Daten aus der MariaDB stelle ich dann mit Grafana graphisch dar. Diagramm-Typ ist hier ein „Bar Chart“.

Im Grafana verwende ich dazu für die Bar-Charts die drei folgenden SQL-Statements, die über Summen-Funktionen aus den einzelnen Impulsen die entsprechenden Tages-, Monats- und Jahreswerte berechnen:

SELECT
  timestamp as "time",
  sum(zaehlerstand)/100 as 'jährlicher Gasverbrauch'
FROM gaszaehler
GROUP BY year(timestamp)
ORDER BY year(timestamp) ASC;

SELECT 
  timestamp as "time",
  sum(zaehlerstand)/100 as 'monatlicher Gasverbrauch'
FROM gaszaehler
WHERE year(timestamp) >= YEAR(CURRENT_DATE - INTERVAL 7 MONTH)
GROUP BY month(timestamp), year(timestamp)
ORDER BY month(timestamp)

SELECT 
  timestamp as "time",
  sum(zaehlerstand)/100 as 'täglicher Gasverbrauch'
FROM gaszaehler
WHERE timestamp >= DATE_SUB(NOW(),INTERVAL 7 DAY)
GROUP BY day(timestamp),month(timestamp), year(timestamp)
ORDER BY year(timestamp),month(timestamp),day(timestamp) asc

Die Beschriftung der X-Achse erfolgt über einen „Override“ im Grafana, da die Beschriftung der X-Achse sonst eher unschön wird. Hier im Bild ist ein solcher Override z.B: für den täglichen Verbrauch dargestellt.

Anzeigen lasse ich mir die Diagramme von Grafana dann in der TabletUI von FHEM mittels iframe. Ja, ich nutze immer noch FHEM obwohl das sooo Old School ist und ich im Home Assistant doch alles per klicki klacki machen kann. Will ich aber nicht…

Mit TabletUI von FHEM schaut dann die Oberfläche mit den eingebundenen Diagrammen aus Grafana auch ganz nett aus.

Viel Spaß mit den Auswertungen.

Gruß Chris

Ja, es gibt bereits allerhand Lösungen mit ESP Home, ESP Easy & Co. aber das gefällt mir alles nicht so besonders und bedingt immer eine zentrale Lösung wie FHEM, HA, Grafana etc. in der die Ergebnisse anzeigt und auswertet werden. Meine Lösung stellt die Daten aber, wie auch bei der Zisternenfüllstandsmessung, ohne zentrale Komponente direkt auf einer Webseite dar und bietet eine Anbindung an einen Heimautomatiserungs-Server. Dazu aber gleich mehr.

Installation

Zum flashen der bin-Datei auf den Mikrocontroller kann das Programm „ESPEasy Flasher“ genutzt werden. Dieses ist auf Github unter https://github.com/BattloXX/ESPEasyFlasher/releases/tag/1.1 zu finden. Nach dem Download einfach die ZIP-Datei entpacken, die bin-Datei des Gaszählers in den gleichen Ordner kopieren, Mikrocontroller anschließen und FlashESP8266.exe starten. Nach Auswahl des richtigen COM-Ports und der Firmware startet der Flash-Prozess mit Klick auf „Flash“.

Der Reed-Kontakt muss an GND und D4 angeschlossen werden. Ich spare mir für die zwei Litzen eine Fritzing-Zeichnung. Einen Pull-Down Widerstand habe ich aktuell nicht eingebaut. Bisher war die Messung des Schaltimpuls wenn der Magnet seine Runden machte immer erfolgreich. Falls es ohne Widerstand doch Probleme gibt kann ich ggf. noch eine Zeichnung nachreichen. Als Reed verwende ich immer noch das gleiche Bauteil wie in der vorherigen Lösung am Odroid (mk 471 b z.B. von Reichelt).

Hier die bin-Datei zum direkten Download:

http://www.bubux.de/heimautomatisierung/ota/gaszaehler_aktuell.bin

Ersteinrichtung und Anschluss des Reed-Kontaktes

Nach dem flashen startet der Sensor und baut ein eigenes WLAN-Netz mit dem Namen „WLAN-Gaszaehler“ auf (Access Point – AP). Mit diesem muss man sich z.B. mit einem Smartphone verbinden. Bis es gefunden wird kann es einen Moment dauern – nicht ungeduldig werden. Nach dem Verbinden kann das Smartphone meckern weil kein Internet „hinter“ diesem AP-WLAN verfügbar ist. Manchmal wechselt das Gerät dann wieder schnell zum „normalen“ WLAN. Ist man aber schließlich im AP-WLAN des NodeMCUs eingebucht, ruft man in einem Webbrower die Adresse 192.168.4.1 auf. Es sollte eine Konfigurationsseite zur Eingabe der SSID und des WLAN-Passwortes erscheinen. Hier dann die Daten des eigenen WLANs eingeben und speichern. Der NodeMCU muss anschließend neu gestartet werden (Reset oder vom Strom trennen) und sollte sich beim neuen Start mit den eingegebenen Zugangsdaten in das WLAN einbuchen. Welche IP der NodeMCU bekommen hat, kann man in seinem Router nachschauen. Ab jetzt jetzt ist der Sensor unter der entsprechenden IP im Heimnetz erreichbar. Ist der Sensor nicht in das eingene WLAN eingebucht muss nochmal geprüft werden ob eventuell wieder ein AP aufgemacht wurde.

Startseite und weitere Konfiguration

Auf der Startseite des Sensors werden der bisher gemessene Gesamtverbrauch im Kubikmeter (m³) und Kilowattstunden (kWh) angezeigt und eine Kachel die zu einer Seite mit Auswertungen führt. Die Berechnung des Verbrauchs in kWh erfolgt erst nach mindestens einem Impuls. Zudem werden einige technische Daten angezeigt die mit Klick auf den blauen Balken „Technische Daten“ ausklappen. Unter „Sonstiges“ klappt der Link zu der Konfigurationsseite und einem Button zum Restart des Sensors auf. Bei Impuls blinkt die eingebaute LED des NodeMCUs kurz auf.

In der Konfiguration unter „Sensordaten“ kann der auf der Startseite oben angezeigte Name definiert werden. Der Startwert muss vom Gaszähler abgelesen werden wobei hier die Angabe mit zwei Nachkommastellen erforderlich ist. An der dritten Nachkommastelle des Zählers ist in der Regel der Magnet befestigt dessen Impulse mit dem Reed erfasst werden.

Mithilfe der Werte „Brennwert“ und „Zustandszahl“ wird der Verbrauch in kWh berechnet. Diese Werte sind abhängig vom Gaslieferanten und in der Regel auf der Gasrechnung zu finden. Auch hier sind jeweils zwei Stellen hinter dem Komma einzugeben. Die Werte für Brennwert und Zustandszahl können sich mit der Zeit ändern und können in der Konfiguration entsprechend angepasst werden.

Der Wert Impulszähler sollte zu Beginn auf „0“ gesetzt werden. Hier werden alle gemessenen Impulse hochgezählt, so das bei einem Neustart des Mikrocontrollers, nicht wieder der Startwert angepasst werden muss. Bei Bedarf kann dieser Wert aber auch im Betrieb geändert werden.

Wie auch bei der Messung des Zisternenfüllstandes sind auch hier die aktuellen Werte auch per JSON abrufbar:

Auch können die Daten an einen MQTT-Broker gesendet und/oder an eine eigene API welche die Daten per HTTP-Post entgegen nimmt übermittelt werden.

Auswertung auf bubux.de

Falls eine Datenübermittlung an die bubux-WebAPI aktiviert wurde, erscheint auf der Startseite eine Kachel mit einem Graphensymbol. Bei Klick auf diese Kachel öffnet sich eine weitere Webseite welche die übermittelten Daten darstellt. Eine Kachel für den Tagesverbrauch, eine Kachel für den Monatsverbrauch und eine graphische Darstellung der letzten 7 Wochentage. Diese Seite ist noch im Aufbau. Hier werden mindestens noch ein Graph für den Monatlichen- und den Jahresverbrauch dazu kommen. Die dafür gespeicherten Daten sind die lokale IP-Adresse des Sensors (damit der Klick auf den Link für den Rückweg zur lokalen Sensorseite funktioniert), die MAC-Adresse des Sensors zur Zuordnung der Daten sowie die Impulse. Beim Aufruf der Seite werden Brennwert, Zustandszahl und aktueller Zählerstand übermittelt. Diese Daten werden aber nicht gespeichert.

So, bleibt mir nur noch viel Spaß zu wünschen mit dem neuen Sensor. Kommentare sind gerne willkommen.

Eine Möglichkeit zum Logging der Daten mittels MariaDB und Darstellung mittels Grafana habe ich in einem weiteren Artikel beschrieben.

Gruß Chris

Offensichtlich waren aber die dunklen Wintermonate bei einigen Leuten Ansporn, um ihre Heimautomatisierung und Sensorik zu überarbeiten. Es gab viele Einträge im Blog und ich bekam viele Anfragen per Mail bzgl. des Time Of Flight-Sensor VL53L0X als möglicher Ersatz des Ultraschallsensors HC-SR04. Ich hatte ja auch bei der Version 1028 nach fleißigen Testern und Rückmeldungen gefragt. Vielen Dank euch dafür! Das hat mich auch motiviert mal wieder was an dieser Front zu tun.

Auch wenn mein Ultraschallsensor für seine 2,50€ seit 3 Jahren tadellos seine Arbeit in der Zisterne verrichtet und ich bisher keine Notwendigkeit sehe diesen zu ersetzen, habe ich mir einen weiteren Sensor zu Testzwecken beschafft und in die Software implementiert. Ergebnis ist die Version 1029 der Software.

Neben dem ToF VL53L0X kann nun auch der VL53L1X angeschlossen und genutzt werden. Zu den Unterschieden der beiden Sensoren findet man einiges im Internet. Welcher Sensor nun im jeweiligen Anwendungsfall die bessere Wahl ist, muss jeder selber herausfinden bzw. freue ich mich auch wieder auf Rückmeldungen im Blog oder per Mail bzgl. eurer Erfahrungen.

Zu den beiden ToF-Sensoren nur ganz kurz folgende Zeichnung bzgl. der Öffnungskegel in Abhängigkeit zum Messabstand. Dazu aber noch weiter unten ein bisschen mehr Details da es anscheinend bei den möglichen Abständen etc. nicht verallgemeinert werden kann, welcher Sensor die bessere Wahl ist. Ich habe dazu auch (bisher) keine Tests gemacht!

Der Anschluss des VL53L1X erfolgt analog des VL53L0X. Die notwendigen PINs zum Anschluss sind u.a. in der Applikation angegeben. Hier aber nochmal schnell das Anschlussschema für die beiden ToF-Sensoren.

Die Version 1029 unterstützt weiterhin den Ultraschallsensor sowie die Displays und den Temperatursensor. Für das komplette Anschluss-Schema schaut bitte in den älteren Blog-Eintrag hier.

Die beiden ToF-Sensoren unterstützen seitens der API noch verschiedene Einstellungen die ich in der ersten Version 1028 nicht implementiert hatte und für den VL53L0X nur die Nutzung der Default-Einstellungen möglich war. In der neuen Version habe ich im ersten Anlauf zumindest ein paar wenige Einstellungsmöglichkeiten implementiert.

Dazu gehört für beide ToF-Sensoren die Möglichkeit den Abstandsmodus anzupassen. Hier holt man auch aus dem VL53L0X noch mehr heraus als im Datenblatt angegeben ist und muss bei größeren Abständen nicht zwingend auf den VL53L1X wechseln. Zudem habe ich beim VL53LoX noch die mögliche Anpassung des Timings implementiert. Hier kann zwischen dem Default-Wert auch noch High-Accuracy (hohe Genauigkeit) und High-Speed gewählt werden. Auch hier gibt es anscheinend kein Patentrezept um gute Messwerte zu erreichen und ausprobieren scheint die Devise.

Da ich diese Werte im „Setup“ setze, ist nach Änderung in der WebUI ein Neustart des Sensors notwendig damit die neu eingstellten Werte greifen. Beim VL53L1X muss man den ESP auch ggf. mal vom Strom trennen. Der scheint da etwas zickig was ich auch schon erfahren musste als es nur seltsame Werte bei der Messung gab.

Die weiteren Einstellmöglichkeiten des VL53L1X muss ich mir noch genauer anschauen und implementiere sie dann ggf. in einem nächsten Update. Hier gibt es z.B. noch die Möglichkeit zur Anpassung des Timings (ähnlich dem VL53L0X was ich dort bereits implementiert habe), die Anpassung der Größe des Empfangs-Arrays (SPAD) sowie der Anpassung der Region of Interest (ROI) und Definition eines Offsets. Mit diesen Parametern kann man u.a. „spielen“, falls der Sensor hinter eine Glasscheibe verbannt werden soll.

Den Download der neuesten Version gibt es hier:

http://www.bubux.de/heimautomatisierung/ota/zisterne_aktuell.bin

Gruß Chris

Mit dem freiwilligen Check des Heizungsfachhandwerks wird erstmals die gesamte Heizungsanlage sozusagen „auf Herz und Nieren“ untersucht. Das Alter der Heizung, eine mögliche Kesselüberdimensionierung, die Dämmung von Leitungen und die Funktionstüchtigkeit von Thermostatventilen spielen beispielsweise eine wichtige Rolle bei der Bewertung. Der Fachmann kann auf dieser Grundlage sinnvolle Modernisierungsmaßnahmen vorschlagen. Schon niedrig investive Maßnahmen steigern die Energieeffizienz der Heizungsanlage.

Will der Hausbesitzer allerdings die optimale Energieeffizienz im Haus erzielen, dann sollte die fortschrittliche Brennwerttechnik mit Erdgas oder Heizöl zum Einsatz kommen. In Verbindung mit Solarthermie, lassen sich somit bis zu 40 Prozent der Heizkosten einsparen. Aber auch Zentralheizungen, die mit Wärmepumpen, Holz oder Pellets betrieben werden, bieten wirtschaftliche Lösungen.

Die Inspektion erstreckt sich über:

• Abgasverlust
• Wärmeverluste über Kesseloberfläche
• Wärmeverluste über das Abgassystem der Heizung
• Brennwertnutzung
• Überdimensionierung des Heizungskessels
• Heizkesselregelung
• Hydraulischer Abgleich der Heizungsanlage
  
• Überdimensionierung der Heizpumpe
• Dämmung der Rohrleitung
• Regelungseinrichtungen der Heizkörper

Pro untersuchtem Bereich vergibt der Fachhandwerker eine bestimmte Anzahl von Punkten. Je höher diese Zahl, umso weiter ist die Heizung vom energetischen Idealzustand entfernt. Viele Punkte bedeuten also ein besonders großes Verbesserungs-potenzial. Die Kosten des Heizungs-Check`s für ein Einfamilienhaus belaufen sich je nach Region zwischen 100€ und 250€ und nimmt ca. 1,5 Stunden Zeit in Anspruch! Wenn im Nachgang aus dem Heizungsscheck ein Auftrag für den Installateur entsteht, kann in der Regel dieser Betrag in Abzug gebracht werden.

Entwickelt wurde der Test für Heizungsanlagen von der VdZ in Zusammenarbeit mit dem Zentralverband Sanitär Heizung Klima (ZVSHK) und dem Institut für Technische Gebäudeausrüstung Dresden. In ersten Feldtests wurden laut VdZ bereits die häufigsten Verursacher von unnötigen Energiekosten identifiziert: schlecht eingestellte Brenner, überdimensionierte Heizkessel, ungeregelte Heizungspumpen sowie zu alte Thermostate an den Heizkörpern.

Bei größeren Mehrfamilienhäusern oder gar Gewerbeeinheiten sind spezielle Kenntnisse erforderlich. Diese bieten daher Ingenieur- oder Planungsbüro`s oder Messdienstleister an. Da es sich hier in der Regel nicht um Standardanlagen handelt, sich die eingesetzte Technik nicht nur auf die Heizenergie beschränkt, greift der einfache Heizungs-Check hier nicht.

Neben den benannten Punkten der Inspektion, werden auch:

• Lüftungsanlagen
• Kälte- und Klimaanlagen
• Wärmerückgewinnungssysteme
• Trinkwassererwärmungsanlagen
• Druckerhöhungsanlagen
• Hausautomatisation
• etc.

bewertet und für den Kunden und die Immobilie zugeschnittene Konzepte erstellt. Daraus resultiert auch das sich der Preis für solche Ingenieurtechnische Leistungen zwischen 1.500€ und 30.000€ bewegen kann.

Anbei die Broschüre der Vereinigung der Deutschen Zentralheizungswirtschaft e.V.

          VdZ_HC_Leitfaden_090210

 follow me https://twitter.com/EU_EnergyCOACH