Kleine Änderungen am Setup zum Jahresstart

Nachdem die Anlage in der ersten Version 2023 installiert wurde entschied ich mich im April 2024 die Anlage um 2 weitere Module zu erweitern. Platz auf der Garage ist genügend vorhanden, der Wechselrichter verfügt über die notwendigen Eingänge und ist gemäß der aktuellen Vorgaben in seiner Einspeiseleistung begrenzt. Also verfügt die Anlage aktuell über 4 Module mit je ca. 400 Watt welche unterschiedlich ausgerichtet sind. 2 Module zeigen komplett nach Süden, eines nach Osten und eines nach Westen. So kann ich vermutlich nicht die maximale Ausbeute in der Leistung erzielen, habe jedoch durch die wandernde Sonneneinstrahlung den ganzen Tag eine Einstrahlung was in meinem Fall lukrativer als die Spitzenleistung ist.

Ertrag der Balkonsolaranlage 2024 – Zahlen bitte

Wie auch im vergangenen Jahr beginnen wir erstmal mit den nackten Zahlen:

Das Balkonkraftwerk hat also in Summe 1.198,28 kWh produziert was einem monatliche Durchschnitt von 99,86 kWh entspricht. Hierbei gab ich 218,17 kWh an den Netzbetreiber zurück da ich diesen selbst im Haus nicht nutzen konnte.

Kombiniert komme ich über das Jahr 2024 auf eine Eigennutzungsquote von 86,75% und konnte 25,52% des gesamten Strombedarfes meines Hauses über das Balkonkraftwerk erzeugen.

Schaut man sich die Eigennutzungsquote einmal über das Jahr verteilt an so ist das zu erwartende Muster zu Erkennen. In den Monaten in welchen wenig Sonne scheint ist die Eigennutzung bei ca. 100%, geht im Sommer dann aber bis auf 73% runter.

persönliche Bewertung der Zahlen

Durch die installierte Balkonsolaranlage konnte ich im gesamten Jahr 2024 1.198,28 kWh produzieren und generierte somit 25,52% meines gesamten Strombedarfes. Dafür dass viele der Meinung sind ein Balkonkraftwerk würde nichts bringen empfinde ich es schon als sehr gut 1/4 des gesamten Strombedarfes darüber zu generieren. Ich bin erstmal zufrieden.

Rein finanziell lohnt sich das Balkonkraftwerk noch nicht denn die Investitionskosten übersteigen den bisher eingesparten Betrag noch deutlich. Das ist, aus meiner Sicht, aber ja nur eine Momentaufnahme denn die Investitionen sind getätigt und nun gilt es den Ertrag einzusammeln.

Beim Schreiben interessiert mich nun doch der Kassensturz – also schaue ich mal kurz rein

Bisher habe ich 833,99 EUR in das Balkonkraftwerk investiert, der bisherige Ertrag beträgt 366,22 EUR. Damit liege ich noch mit 467,77 EUR im Minus. Setze ich den Ertrag aus 2024 mal für die Zukunft an wäre das Balkonkraftwerk also irgendwann Mitte 2026 finanziert und ich wäre in der „Gewinnzone“. Fühlt sich gut an …

Der Beitrag Ertrag der Balkonsolaranlage 2024 erschien zuerst auf Das ist die Welt von Thomas.

Disclaimer: Nur eine theoretische Lösung

Alles was hier beschrieben ist, ist eine rein theoretische Darstellung der technischen Möglichkeiten. Auch ich habe selbiges natürlich nur theoretisch in einer Laborumgebung verprobt und würde diese niemals produktiv einsetzen. Auch weise ich ganz klar darauf hin, dass die eigene Anwendung (sofern dies jemand plant) auf eigenes Risiko erfolgt.

Worum geht es beim Thema Nulleinspeisung eigentlich?

Ein Balkonkraftwerk zuhause ist durch den Wechselrichtiger in der Höhe der Einspeisung limitiert. Unabhängig davon wie Leistungsstark die angeschlossenen Solarpanele sind lässt der Wechselrichter nur eine gewisse Leistung ins Hausnetz einfließen. Stand April 2024 sind maximal 600 Watt Balkonkraftwerke erlaubt. Wenn man den Medien glauben darf, sind bald 800 Watt erlaubt. Energie, welche nicht im eigenen Haus verbraucht wird, wird ohne Rückvergütung ins allgemeine Stromnetz eingespeist.

Warum nun eine dynamische Limitierung?

Im Grund ist es ganz einfach. Wenn die Sonne so richtig schön scheint generieren meine 4 Module deutlich mehr als die erlaubten 600 oder 800 Watt. Mir persönlich ist es erstmal egal, ob ich Energie ins allgemeine Stromnetz einspeise, nur möchte ich mein Heimnetz nicht unnötig belasten.

Schön wäre es aber doch, dass der gesamte zur Verfügung stehende Strom genutzt werden könnte, wenn er gebraucht wird, oder? Schalte ich z.B. einen Verbrauche wie einen Fön ein so möchte ich gerne, dass die Limitierung temporär gesenkt und mehr Strom zur Verfügung gestellt wird. Schalte ich den Fön wieder aus soll die Limitierung wieder greifen.

Im dargestellten Screenshot steht die blaue Linie für den aktuellen Bezug vom Netzbetreiber (über die Shelly Pro 3 EM* gemessen). Die grüne Linie steht für die Energie, welche vom Wechselrichter in das Haus eingespeist wird.

Wir sehen, dass der Wechselrichter ständig ca. 600 Watt einspeist wovon ca. 100 – 150 Watt an den Netzbetreiber fliesen. Plötzlich steigt der Stromverbrauch und vom Netzbetreiber werden knapp 2.000 Watt bezogen. Das Script bemerkt dies und entfernt die Drosselung des Wechselrichters welcher nun ca. 1.100 Watt einspeist und den Netzbezug deutlich reduziert. Als der Stromverbrauch wieder sinkt aktiviert das Script die Drosselung des Wechselrichters wieder und wir sind wieder bei den 600 Watt.

Code steht in Github bereit

Mein Script ist ein Fork der Nulleinspeisung von Selbstbau-PV.de und steht öffentlich in Github bereit.

Die Veränderungen zum Ursprungscode sind relativ überschaubar, für das oben beschriebene Setup jedoch zwingend notwendig. Folgende Bereiche wurden angepasst:

Noch einmal: Wer möchte, kann sich das Script gerne ansehen oder auch weiter entwickeln. Pullrequestes sind jederzeit gerne gesehen. Sämtlicher Code dient lediglich zur Veranschaulichung und Demonstration, von einem produktiven Einsatz wird abgeraten.

Balkonkraftwerk Einspeisung dynamisch limitieren – wie ist Deine Meinung?

Natürlich würde mich Deine Meinung zum Thema Balkonkraftwerk Einspeisung dynamisch limitieren interessieren. Wie handhabst Du das ganze, arbeitest Du ggf. sogar mit einem Akku in deinem Balkonkraftwerk? Ich freue mich auf Deine Rückmeldung.

Der Beitrag Balkonkraftwerk Einspeisung dynamisch limitieren mit openDtu und Shelly Pro 3 EM erschien zuerst auf Das ist die Welt von Thomas.

Was war passiert?

Wie viele Geschichten zuhause begann auch diese irgendwo zwischen Toilette und erstem Kaffee. Ich schaute auf mein Handy und überflog mein openHab Dashboard. Etwas erstaunt war ich als ich auf die Zahl des aktuellen Stromverbrauches schaute – über 6 kWh vor 7 Uhr morgens – das ist sehr sehr ungewöhnlich. Im Normalfall liegen wir hier unter 2 kWh, wie kommt es zu einer Abweichung von 4 kWh zu dieser frühen Zeit?

Ich schaute mit den Tagesverlauf als Graph an und sah eine recht klare und gerade Linie welche seit Tagesbeginn nach oben ging. Schnell mal einen anderen Tag angesehen – hier sieht das deutlich entspannter aus. Da stimmt doch was nicht …

Ursachenforschung und Fehlerlokalisierung

Zugegeben, ich bin hier vielleicht ein wenig Strange, aber ich wollte die Ursache direkt finden. Also ging ich mit dem Handy in den Hand die einzelnen Unterverteilungen durch und schaltete Sicherung für Sicherung ab. Als ich den unteren Schuppen vom Netz nahm sank der Strombezug direkt ab, sobald die Sicherung wieder eingeschaltet wurde stieg der Stromverbrauch direkt wieder extrem an.

Ich hatte direkt eine Vorahnung, denn die letzten Tage war es durchgehend weit unter 0 Grad dann kam gestern Regen dazu. Im Schuppen selbst steht eine Tauchpumpe, welche mittels Schwimmerschalter zur Dachentwässerung genutzt wird. Das Wasser wird über einen Schlauch weg gepumpt. Die Vermutung lag also nah: Hier ist was eingefroren und die Pumpe läuft in Dauerschleife.

Also ab in den Schuppen und an das Fass, in welchem die Pumpe sitzt. Die Tauchpumpe läuft und das Fass ist spürbar warm. Na immerhin war die Pumpe bislang Wassergekühlt und scheint noch zu funktionieren. Pumpe vom Strom trennen und schon ist das Problem (zumindest das des hohen Stromverbrauches) erstmal gelöst.

SmartHome Daten richtig interpretieren

Auch wenn ich zugegeben muss dass dieser Fall eher Zufall war. Ich habe manuell auf das Dashboard gesehen und bin über die Abweichung gefallen. Dennoch ohne die Datensammlung und die entsprechende Visualisierung hätte ich weder gewusst was ein normaler Stromverbrauch ist, noch hätte ich die Möglichkeit gehabt diese Abweichung zu erkennen.

Es genügt also nicht eine Heimautomatisierung aufzubauen, die gesammelten Daten müssen sinnvoll aggregiert und ausgewertet werden.

Ich für meinen Teil bin auf jeden Fall erstmal zufrieden und konnte Nachweisen dass das SmartHome mehr als nur eine Spielerei ist
Im hier beschriebenen Fall haben mir die Daten nicht nur beim Stromsparen geholfen sondern vermutlich auch schlimmeres verhindert. Wer weiß wie lange die arme Tauchpumpe noch durchgehalten hätte…

Smarthome Daten automatisiert analysieren

Aktuell arbeite ich daran die gesammelten Daten der einzelnen Sensoren (z.B. Verbrauchswerte von Strom, Gas und Wasser) automatisiert auswerten zu lassen. Das Ziel dieser Übung ist es, starke Abweichungen automatisch zu erkennen und mich per Warnung auf selbige hinweisen zu können. Ich bin gespannt ob mich dieses Experiment zum gewünschten Ziel führt und werde darüber berichten.

Der Beitrag SmartHome Daten können echtes Geld sparen erschien zuerst auf Das ist die Welt von Thomas.

Ertragsübersicht – hier die nackten Werte

Fangen wir zuerst einmal mit der nackten Wahrheit, den genauen Werten in der Übersicht an:

In der Summe hat das Balkonkraftwerk in den 147 Tagen in welches in Betrieb war (seit dem 6. August) 262,52 kWh produziert. Hiervon konnte ich 239,06 kWh in meinem Haushalt selbst nutzen und „verschenkte“ 23,46 kWh welche ich ins Netz zurück gab.

Kombiniert komme ich über den gesamten Zeitraum auf eine Eigennutzungsquote von 94,14 %

meine persönliche Bewertung der Zahlen

Als ich die Solaranlage auf der Garage installierte war ich mir nicht sicher was ich genau davon erwarten soll. Eigentlich war es eher ein Versuch um zu schauen ob überhaupt etwas dabei rüber kommt. Vondaher bin ich selbst erstmal zufrieden, ohne Ausrichtung der Anlage 262 kWh erzeugt zu haben ist doch erstmal gut.

Auf der anderen Seite interessierte mich die Eigennutzungsquote um herauszufinden in wie weit sich ein Akku lohnen kann. Natürlich ist der Auswertungszeitraum etwas trügerisch denn von den sonnigen Monaten hatte ich nicht sonderlich viele. Dennoch ist eine Eigennutzungsquote von 94,14% definitiv besser als vermutet. Mit 4,69 kWh „verschenktem“ Strom würde sich aus aktueller Sicht ein Akku für ein solch kleines Balkonkraftwerk wohl niemals rechnen. Mal sehen wie das Ende 2024 aussieht wenn die Anlage einmal ein Jahr durchgelaufen ist.

Sehr zufrieden bin ich mit der Integration der Shelly-Komponenten in meine openHab Installation. Die Auswertung der Daten läuft sehr rund und gibt mir immer einen aktuellen Überblick darüber was die Solaranlage so leistet.

Der Beitrag Ertrag der Balkonsolaranlage in 2023 (August bis Dezember) erschien zuerst auf Das ist die Welt von Thomas.

openHab Zeitsteuerung über den Google Kalender?

OpenHab ist aus meiner Sicht ein echt einfaches System zur Heimautomatisierung. Wenn es allerdings um das Thema Zeitsteuerung geht ist hier wirklich Nachholbedarf. Es existiert keine einfache Möglichkeit um flexibel Geräte zu unterschiedlichen Zeiten mit eigenen Befehlen zu versorgen.

Durch den Einsatz des iCalendar Bindings und ein paar Zeilen Code ist es mir gelungen die Steuerung der Heizung über den Kalender umzusetzen.

Das Screenshot hier zeigt, wie der aktuelle Wochenplan aussieht. Im Gegensatz zu so manch andere Lösung die man im Internet so findet habe ich mich dafür entschieden nur Statusänderungen im Kalender zu hinterlegen und auf diese Events per Script zu reagieren.

Jeder Kalendereintrag steht also für eine gewünschte Änderung der Temperatur am Thermostat. Somit können flexibel alle Räume zu unterschiedlichen Zeiten nach meinen Wünschen gesteuert werden.

eigenen Kalender anlegen

Im ersten Schritt habe ich in meinem bestehenden Kalender einen neuen Kalender nur für die Steuerung meiner Heizung angelegt. Immerhin möchte ich die Einträge zur Steuerung nicht in meinem normalen Kalender sehen und getrennt verwalten. Dies funktioniert recht einfach über diesen Link.

Wir geben dem Kalender einen Namen, die gewünschte Zeitzone und speichern diesen. Für die Einbindung in das Binding benötigen wird nur die iCal Adresse. Hierfür gibt es im unteren Bereich eine „Privatadresse im iCal-Format“ welche über das entsprechende Kopieren-Icon in die Zwischenablage kopiert werden kann.

iCalendar Binding installieren und Kalender verbinden

Nachdem wir das iCalendar Binding in openHab installiert haben legen wir ein neues Item vom Typ „Kalender“ an. Dieses Binding dient den späteren Filtern als Gateway und stellt die Verbindung zwischen openHab und dem Kalender her.

Ins Feld ‚URL‘ tragen wir die URL ein, welche wir uns im vorherigen Schritt kopiert haben. Der Aktualisierungsintervall kann ruhig etwas länger sein, in meinem Fall sind es 30 Minuten. Dies bedeutet so viel wie dass das Plugin alle 30 Minuten nach neuen Terminen im Kalender schaut und diese herunterlädt.

Nach dem Speichern ist das Plugin auch schon fertig konfiguriert und die Kalendereinträge werden heruntergeladen.

Schön, doch was nun? Wir haben nun einen Google Kalender in welchen wir Termine einstellen können. Dazu ein Binding welches dafür sorgt, dass diese Termine nach openHab geladen werden. Damit nun die einzelnen Räume gesteuert werden müssen benötigen wir noch ein wenig Konfiguration für jeden einzelnen Raum …

openHab iCalendar Filter verwenden um Räume zu steuern

Um die Heizungssteuerung mit openHab umzusetzen habe ich mir im ersten Schritt Überlegt, wie ich meine Kalendereinträge gestalten möchte. Um es möglichst einfach zu halten habe ich mich dazu entschieden, je Verändungsevent einen Kalendereintrag zu erstellen. Wenn ich also z.B. im Büro die Heizung morgens um 6:30 Uhr auf 21 Grad stellen möchte und am Nachmittag um 17 Uhr wieder auf 17 Grad dann benötige ich hierfür 2 Kalendereinträge. Ich nutze hierbei den Titel des Kalendereintrages und hinterlege hier den Raum sowie die gewünschte Temperatur. Ein Eintrag mit dem Titel ‚Büro: 21‘ sorgt dafür, dass das Thermostat im Büro auf 21 Grad, ein Titel ‚Büro: 17‘ dass das Büro auf 17 Grad geändert wird.

Um die Kalendereinträge des eines Raumes in openHab verfügbar zu haben, habe ich mir je Raum ein Item vom Typ icalendar:eventfilter angelegt.

Der Filter selbst nutzt als Bridge das zuvor angelegte Item vom Typ „Kalender“. Die Anzahl Kalendereinträge habe ich mit 1 und den Aktualisierungsinterval mit 15 Minuten definiert. Der Filter selbst wurde als Textbasierter Filter auf Basis des Betreff / Title angelegt. Der Suchausdruck entspricht in meinem Fall dem Raumname, hier also ‚Büro‘ als Text.

Diese Konfiguration sorgt dafür, dass im neu angelegten Item 3 Channels angelegt werden. Diese Channels beinhalten die Daten des nächsten Kalendereintrages mit den Werte Startzeit, Endezeit und Titel.

Diese Channels lege ich mir als Points in meinem Model in den jeweiligen Raum. Das ist zwar nicht zwingend notwendig, erleichtert mir aber die Übersicht und die mögliche Fehlersuche.

Wichtig: An dieser Stelle unbedingt auf die Namensnotation achten. Das Script erwartet den Prefix ‚Calendar_Events__‘ gefolgt vom Raumname mit dem Suffix ‚_Titel‘ und ‚_Start‘.

Dieses Vorgehen muss nun für jeden Raum den ich steuern möchte dupliziert werden. Sprich für jeden Raum benötige ich einen eventfilter und die entsprechenden Points im Model damit das nachfolgende Script funktioniert.

Heizungssteuerung mit openHab – das Script

Nachdem die Vorarbeiten nun erledigt sind benötigt es noch ein kleines Script (Rule) welches die Werte der jeweiligen Räume abruft und die Änderungen an den Thermostaten durchführt. Ich habe mich hierbei für einen cronjob entschieden welcher jede Minute läuft und die Werte überprüft:

import java.time.format.DateTimeFormatter
import org.openhab.core.model.script.ScriptServiceUtil

rule "Heizungssteuerung - cron"
	when
		Time cron "5 * * * * ?"
	then
		val roomList = newArrayList('Buro', 'Wohnzimmer', 'Bad_EG', 'Kinderzimmer', 'Schlafzimmer', 'Kueche')
			
		roomList.forEach[ itemName |
			if (itemName != "") {
				var itemToManage = "Heizung__" + itemName + "_Set_Temperature"
				
				var calValue = "Calendar_Events__" + itemName + "_Titel"
				var calStart = "Calendar_Events__" + itemName + "_Start"
				
				var newValue = ScriptServiceUtil.getItemRegistry.getItem(calValue).getState.toString
				
				if (newValue != "UNDEF") {
					newValue = newValue.substring(newValue.indexOf(" ")).trim
					
					var currentValue = ScriptServiceUtil.getItemRegistry.getItem(itemToManage).getState.toString
					currentValue = currentValue.substring(0, currentValue.indexOf(" "))

					var currentStart = ScriptServiceUtil.getItemRegistry.getItem(calStart).getStateAs(DateTimeType).zonedDateTime.withZoneSameInstant((new DateTimeType).zonedDateTime.getZone).format(DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm"))

					if (currentStart.format(DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm")) == now.format(DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm"))) {
						logInfo("Heizungssteuerung", "neue Temperatur " + itemToManage + "= " + newValue)
						sendCommand(itemToManage, newValue)
					} 
				}
			}			
		]
end

Das Script läuft alle 5 Minuten. Hierbei durchläuft es in einer Schleife alle definierten Räume und prüft, ob eine neue Temperatur eingestellt werden soll. Wichtig ist hierbei die bereits erwähnte Namensnotation der Items. Im ersten Schritt wird geprüft, ob ein neuer Wert eingestellt werden soll. Falls dies der Fall ist prüfen wir ob die aktuelle Uhrzeit der gewünschten Uhrzeit entspricht. Falls auch dieses Kriterium zutrifft setzen wir den entsprechenden Wert am Heizkörperthermostat über den sendCommand Befehl.

Zeisteuerung in openHab mit dem Google Calendar – Fazit

Anfangs dreht ich mich ein wenig im Kreis bis ich die Funktionen der einzelnen Bindings im Detail verstanden hatte und mich langsam dem gewünschten Ziel näherte. Inzwischen läuft die Heizungssteuerung mit openHab über die Homematic IP Komponenten sehr verlässlich. Durch die Planung über meinen Kalender kann ich quasi nebenbei die Zeitpläne von überall aus bearbeiten und bin sehr flexibel geworden.

Der Beitrag Heizungssteuerung mit openHab und Google Kalender automatisieren erschien zuerst auf Das ist die Welt von Thomas.

Die Idee

Das Balkonkraftwerk befindet sich auf meiner Flachdachgarage neben dem Haus. Das Haus und die Garage sind über ein ausreichend dimensioniertes Kabel miteinander verbunden worüber die Garage heute den Strom bezieht. In der Garage wurde eine neue Dose installiert an welche das Balkonkraftwerk angeschlossen ist. Die Dose selbst läuft über eine ‚Shelly Plus 1 PM*‘ (mit einer 1 gekennzeichnet) welche die Verbrauchsdaten misst. Am Hauptsicherungskasten im Haus ist eine ‚Shelly 3EM*‘ installiert (mit einer 2 gekennzeichnet) welche die Verbrauchsdaten aller 3 Phasen misst. Diese Verbrauchsdaten werden bereits per MQTT an openHab gesendet (die Konfiguration hierzu ist in ‚Shelly Verbrauchsdaten über MQTT an openHab senden‚ beschrieben).

Um nun Dinge wie die Eigenverbrauchsquote des Balkonkraftwerkes oder den Strombezug vom Netzbetreiber zu berechnen benötigen wir einige Messpunkte anhand derer wir die notwendigen Daten halbwegs genau berechnen können.

Verbrauchsmessung Balkonkraftwerk Messpunkte definieren

Die Shellys senden Events per MQTT sobald sich ein Wert verändert. Das heisst, dass wir bei jeder kleinen Änderung einen neuen Wert über den „neuen aktuellen Wert erhalten“. Merken wir uns nun den „altwert“, also den Wert der letzten Nachricht sowie den Zeitpunkt der neuen Nachricht so können wir den Verbrauch in einer Zeitspanne berechnen. Hierzu nehmen wir einfach den alten Wert und multiplizieren diesen mit der Zeit welche zwischen beiden eingegangenen Nachrichten liegt.

Das klingt erstmal etwas „komplex“, funktioniert in der Realität aber ausgezeichnet. Für die eigentliche Berechnung der aktuellen Werte benötige ich nun also 9 Items. Dazu möchte ich gerne noch eine Übersicht über die aktuellen Tageswerte haben welche in weiteren 6 Items abgelegt werden.

Number		stromUpdateTimeStamp   		"letztes Stromupdate [%d]"
Number		stromBezugAltwert			"Strombezug altwert [%d]"
Number 		stromBezugWert			 	"Strombezug Wert [%d]"
Number 		stromEinspeisungAltwert		"Stromeinspeisung Altwert [%d]"
Number 		stromEinspeisungWert			"Stromeinspeisung Wert [%d]"

Number		stromErzeugungAltwert			"Stromerzeugung Altwert[%d]"
Number		stromErzeugungWert			"Stromerzeugung Wert[%d]"
Number		stromErzeugerUpdateTimeStamp		"letzte Update Erzeugung [%d]"

Number		stromErzeugungKwhToday			"Stromerzeugung [%d] kWh"
Number		stromBezugKwhToday			"Strombezug [%d] kWh"
Number		stromEinspeisungKwhToday		"Stromeinspeisung [%d] kWh"
Number		stromVerbrauchKwhToday			"Stromverbrauch [%d] kWh"
Number		stromEigennutzungProzent		"Eigennutzung [%d]"
Number		stromEigennutzungKwhToday		"Eigennutzung [%d] kWh"

Auswertung der MQTT-Events des Stromzählers

Als erstes widme ich mich den Events des Hauptstromzählers. Auf Basis des aktuellen Wertes kann ich entscheiden, ob ich gerade Strom vom Betreiber beziehe oder ob ich Strom ins Netz einspeise (positiver Wert = ich beziehe etwas vom Betreiber). Nachfolgend mein Script:

rule "Stromzaehler Wert Change"
	when
		Item MQTTThing_aktueller_Stromverbrauch changed
	then
		var Number aktuellerWert = MQTTThing_aktueller_Stromverbrauch.state
		val Number letztesUpdateValue = stromUpdateTimeStamp.state;
		var ZonedDateTime now = ZonedDateTime.now();
		var Number vStromBezugAltwert = stromBezugAltwert.state;
		var Number vStromBezugWert = stromBezugWert.state;
		var Number vStromEinspeisungAltwert = stromEinspeisungAltwert.state;
		var Number vStromEinspeisungWert = stromEinspeisungWert.state;
		
		if (vStromBezugWert === NULL || vStromBezugAltwert === NULL) {
			vStromBezugWert = 0;
			vStromBezugAltwert = 0;
			vStromEinspeisungAltwert = 0;
			vStromEinspeisungWert = 0;
		}
		
		var ZonedDateTime letztesUpdate;
		if (letztesUpdateValue === NULL) {
			letztesUpdate = ZonedDateTime.of(LocalDate.now(), LocalTime.MIN, ZoneId.systemDefault());
		} else {
			letztesUpdate = ZonedDateTime.ofInstant(java.time.Instant.ofEpochMilli(letztesUpdateValue.longValue), ZoneId.systemDefault());
		}

		var double zeitspanne = Double.valueOf(java.time.temporal.ChronoUnit.MILLIS.between(letztesUpdate, now)) / 1000;
		if (aktuellerWert > 0) {
			vStromBezugWert += vStromBezugAltwert * zeitspanne;
			stromBezugAltwert.postUpdate(aktuellerWert);
			stromEinspeisungAltwert.postUpdate(0);
		} else {
			aktuellerWert = aktuellerWert * -1;
			vStromEinspeisungWert += vStromEinspeisungAltwert * zeitspanne;
			stromBezugAltwert.postUpdate(0);
			stromEinspeisungAltwert.postUpdate(aktuellerWert);
		}
		
		stromBezugWert.postUpdate(vStromBezugWert)
		stromEinspeisungWert.postUpdate(vStromEinspeisungWert)
		stromUpdateTimeStamp.postUpdate(now.toInstant().toEpochMilli())
end

Ich berechne als erstes die Zeitspanne zwischen dem aktuellen und dem letzten Event. Anschließend prüfe ich, ob ich gerade Strom vom Betreiber beziehe oder ob mein Balkonkraftwerk Strom ins Netz einspeist. Entsprechend dieser Prüfung aktualisiere ich die jeweiligen Werte der Items, setze die Altwerte auf die aktuellen Werte und setze die Timestamp auf die aktuelle Zeit.

Auswertung der MQTT-Events des Balkonkraftwerks

Nachdem wir über den Stromzähler nun wissen ob wir gerade Strom einspeisen oder vom Netz beziehen fehlt uns noch die Information, wie viel Strom unser Balkonkraftwerk gerade erzeugt. Diesen Wert erhalten wir direkt von der Shelly an welche das Balkonkraftwerk angeschlossen ist. Auch hier erstmal mein Script:

rule "Stromerzeugung Wert Change"
    when
		Item MQTTThing_Balkonkraftwerk_Garage_Erzeugung changed
	then
		var Number aktuellerWert = MQTTThing_Balkonkraftwerk_Garage_Erzeugung.state
        	val Number letztesUpdateValue = stromErzeugerUpdateTimeStamp.state;
        	var ZonedDateTime now = ZonedDateTime.now();
		var Number vStromAltwert = stromErzeugungAltwert.state;
        	var Number vStromWert = stromErzeugungWert.state;	

			if (vStromWert === NULL || vStromAltwert === NULL) {
			vStromWert = 0;
			vStromAltwert = 0;
		}

        	var ZonedDateTime letztesUpdate;
        	if (letztesUpdateValue === NULL) {
			letztesUpdate = ZonedDateTime.of(LocalDate.now(), LocalTime.MIN, ZoneId.systemDefault());
		} else {
			letztesUpdate = ZonedDateTime.ofInstant(java.time.Instant.ofEpochMilli(letztesUpdateValue.longValue), ZoneId.systemDefault());
		}

        	var double zeitspanne = Double.valueOf(java.time.temporal.ChronoUnit.MILLIS.between(letztesUpdate, now)) / 1000;
        	vStromWert += vStromAltwert * zeitspanne;
       
		stromErzeugungAltwert.postUpdate(aktuellerWert);
		stromErzeugungWert.postUpdate(vStromWert);
        	stromErzeugerUpdateTimeStamp.postUpdate(now.toInstant().toEpochMilli());
end

Wer das erste Script verstanden hat, für den ist dieses Script selbsterklärend. Wir nehmen den alten Wert des Balkonkraftwerkes und multiplizieren diesen mit der Zeit zwischen dem letzten und dem aktuellen Event. Nun aktualisieren wir noch die entsprechenden Items und schon haben wir die gewünschten Werte.

Berechnung der Tageswerte

Ein wenig mehr habe ich über die Berechnung der Tageswerte gegrübelt. Ich möchte gerne für jeden Kalendertag die Gesamtwerte verfügbar haben. Diese müssen täglich um 0 Uhr zurück gesetzt werden, so dass die Zählung für den neuen Tag wieder korrekt ist. Um es mit der Berechnung nicht zu übertreiben habe ich mich dazu entschieden diese nur alle 15 Minuten durchzuführen. Hierdurch kam es jedoch bei dem täglichen Reset zu einem Problem so dass ich hier eine 2te Prüfung einbaute und nicht nur beim Tageswechsel sondern auch dann wenn der Bezug > 2 KwH in der erste Stunde des Tages (also zwischen 0 und 1 Uhr) ist.

Erneut, anbei erstmal mein Script:

rule "Stromerzeugung Tagswerte"
    when
		Time cron "0 */15 * * * *" // alle 15 Minuten genügt
	then
		// Check if next day
		val Number letztesUpdateValue = stromUpdateTimeStamp.state;
		var ZonedDateTime letztesUpdate;
		if (letztesUpdateValue === NULL) {
			letztesUpdate = ZonedDateTime.of(LocalDate.now(), LocalTime.MIN, ZoneId.systemDefault());
		} else {
			letztesUpdate = ZonedDateTime.ofInstant(java.time.Instant.ofEpochMilli(letztesUpdateValue.longValue), ZoneId.systemDefault());
		}
		
		var Number stromVerbrauchKwhTodayValue = stromVerbrauchKwhToday.state
		
		if ((((stromVerbrauchKwhTodayValue === NULL) || (stromVerbrauchKwhTodayValue > 2)) && (letztesUpdate.toLocalTime().getHour() == 0)) || letztesUpdate.toLocalDate().isBefore(LocalDate.now())) {
			logInfo("rules.stromerzeugung.tageswerte", "Tageswechsel  reset to 0");
			
			// Tageswechsel
			stromBezugAltwert.postUpdate(0);
			stromEinspeisungAltwert.postUpdate(0);
			stromBezugWert.postUpdate(0);
			stromEinspeisungWert.postUpdate(0);
		
			stromErzeugungAltwert.postUpdate(0);
			stromErzeugungWert.postUpdate(0);

			stromUpdateTimeStamp.postUpdate(ZonedDateTime.now().toInstant().toEpochMilli());
			stromErzeugerUpdateTimeStamp.postUpdate(ZonedDateTime.now().toInstant().toEpochMilli());
			
			stromVerbrauchKwhToday.postUpdate(0);
			stromErzeugungKwhToday.postUpdate(0);
			stromEinspeisungKwhToday.postUpdate(0);
			stromBezugKwhToday.postUpdate(0);			
			
			stromEigennutzungKwhToday.postUpdate(0);
			stromEigennutzungProzent.postUpdate(100);
		} else {
			var Number stromBezug = stromBezugWert.state
			var Number stromErzeugung = stromErzeugungWert.state;
			var Number stromEinspeisung = stromEinspeisungWert.state

			if (stromBezug === NULL || stromBezug == 0) {
				stromBezug = 0;
				stromErzeugung = 0;
				stromEinspeisung = 0;
			}
			stromVerbrauchKwhToday.postUpdate((stromBezug + stromErzeugung - stromEinspeisung) / 60 / 60 / 1000);
			stromErzeugungKwhToday.postUpdate((stromErzeugung) / 60 / 60 / 1000);
			stromEinspeisungKwhToday.postUpdate((stromEinspeisung) / 60 / 60 / 1000);
			stromBezugKwhToday.postUpdate((stromBezug) / 60 / 60 / 1000);
			stromEigennutzungKwhToday.postUpdate((stromErzeugung - stromEinspeisung) / 60 / 60 / 1000);
			
			if (stromEinspeisung == 0 || stromErzeugung == 0) {
				stromEigennutzungProzent.postUpdate(100);
			} else {
				stromEigennutzungProzent.postUpdate(100 - (stromEinspeisung / stromErzeugung * 100));
			}
		}
end

Eigentlich ist auch hier keine grosse Magie zu finden. Der Tagesverbrauch ergibt sich aus dem Bezug vom Stromanbieter + dem Eigenverbrauch. Der Eigenverbrauch selbst entspricht dem Wert der Erzeugung abzgl. dem Wert der Einspeisung. Diese Werte werden alle 15 Minuten berechnet und in den entsprechenden Items abgelegt.

Verbrauchsmessung Balkonkraftwerk Visualisierung

So nun haben wir also viele Items welche munter irgend welche Daten speichern und berechnen. Das ist für den ersten Schritt ja schonmal schön, besser wäre es aber doch wenn man diese nun auch noch sauber anzeigen könnte, oder? Zu diesem Zweck habe ich mir 2 neue Seiten angelegt:

aktuelle Werte des Balkonkraftwerkes

Als erstes möchte ich gerne auf einen Blick sehen, wie sich der Verbrauch in meinem Haus gerade jetzt darstellt. Zu diesem Zweck habe ich ein Dashboard erstellt, welches den aktuellen Strombezug, die aktuelle Erzeugung sowie die Tageswerte bis zum aktuellen Zeitpunkt darstellt:

Das dargestellte Beispiel ist von einem eher durchschnittlichen Tag mit einigen Wolken. Das Balkonkraftwerk hat bis 14 Uhr 2.22 kWh erzeugt wobei ich 89,32% dieser Erzeugung selbst genutzt habe. Daraus resultiert dass ich 0.24 kWh Strom „verschenkt“ habe. Selbiges ist auch in einigen Graphen dargestellt.

historische Analyse der Daten

Neben der Tagesaktuellen Liveansicht ist die historische Sicht auf die Erzeugungswerte des Balkonkraftwerkes natürlich mit die interessanteste Sicht. Auch hierzu habe ich mir ein kleines Dashboard gebaut welches mit auf einen Blick alle relevanten Werte eines Monates anzeigt.

Das angezeigte Dashboard zeigt hierbei eine Kombination aus 4 Werten an. Die Gesamte Tagesproduktion des Balkonkraftwerkes in blau, die eigengenutzte Energie in grün, die ins Netz eingespeiste Energie in Gelb und die vom Stromanbieter bezogene Energie in rot.

Die Werte des Eigenverbrauches und des Netzbezuges wurden hierbei gestapelt dargestellt um den gesamten Strombedarf eines Tages auf einen Blick zu sehen.

Ein weiteres schönes Feature des Diagramme ist, dass man einzelne Sichten per „Knopfdruck“ deaktivieren kann. Somit ist es möglich sich z.B. nur die durch das Balkonkraftwerk erzeugte Energie anzeigen zu lassen, oder aber eben die Werte der Einspeisung oder Eigennutzung. Zusätzlich lassen sich die Diagramme von Haus aus downloaden oder als Tabelle exportieren.

Hier einmal alle Diagramme für den August 2023 im Überblick. Hierbei bitte nicht wundern, die Auswertung beginnt in der Tat erst am 6. August …

Verbrauchsmessung Balkonkraftwerk – ich bin gespannt

Noch habe ich kein wirkliches Gefühl dafür, wie lange es dauern wird bis sich das angeschaffte Balkonkraftwerk amortisieren wird. Der August war nun wirklich kein sonderlich guter Monat, es hat viel Geregnet. Dazu waren wir ein paar Tage weg was die Eigennutzungsquote leicht nach unten trieb. Ich werde das nun weiter verfolgen und bin gespannt, wie sich das ganze über das nächste Jahr entwickelt. Immerhin konnte das Balkonkraftwerk im August schonmal 86 kWh erzeugen wovon ich 76 kWh selbst nutzen konnte. Die Eigennutzungsquote im August betrug somit 88,37%, für den Anfang schonmal gar nicht so übel …

Der Beitrag Verbrauchsmessung Balkonkraftwerk mit openHab erschien zuerst auf Das ist die Welt von Thomas.

verwendete Komponenten für die Datenerfassung

Um sowohl den Bezug des Stromes vom Netzanbieter als auch die Erzeugung des selbigen durch das Balkonkraftwerk zu messen entschied ich mich für den Einbau 2er Komponenten.

Der Shelly Pro 3EM wurde direkt im Sicherungskasten verbaut. Dieser misst den Gesamtenergieverbrauch des gesamten Hauses über alle 3 Phasen. Dazu wurde direkt an der Anschlussdose das Balkonkraftwerkes ein Shelly Plus 1PM installiert welcher den Energieverbrauch des Balkonkraftwerkes erfasst.

Das schöne an den Shelly-Komponenten ist, dass diese über das MQTT Protokoll verfügen. Durch dieses sind die Komponenten in der Lage eine Nachricht zu senden, sobald sich ein Wert verändert. Diese Nachrichten können nun wieder in openHab eingesammelt und in ein entsprechendes Item übertragen werden. Wir sind also in der Lage die aktuellen Livedaten sowohl Strombezuges des gesamten Hauses als auch der Stromerzeugung des Balkonkraftwerks nach openHab zu transportieren.

Was ist MQTT eigentlich?

MQTT ist ein offenes Netzwerkprotokoll zur Übertragung von Nachrichten. Das Protokoll wurde für die Maschine zu Maschine Kommunikation und findet den Einsatz meist im Bereich IOT (Internet of Things). Hierbei senden Devices Informationen an einen Broker. Der Broker leitet diese an die entsprechenden Abonnenten weiter. Weitere Informationen zu MQTT selbst findet man am besten direkt auf MQTT.org.

Einrichtung des MQTT-Brokers auf dem Raspberry PI

Die Einrichtung des MQTT-Brokers auf dem Raspberry-PI ist recht schnell und mit wenigen Befehlen erledigt. Zuerst aktualisieren wir einmal die Pakete auf dem PI, anschliessend installieren wir das Paket ‚mosquitto‚:

# Update durchführen
sudo apt update
sudo apt upgrade

# Mosquitto installieren
sudo apt install mosquitto

Der MQTT-Broker Mosquitto ist nun auf dem System installiert. Nun müssen wir noch einige kleine Konfigurationen vornehmen damit der Zugriff auf den Broker funktioniert. Ich habe mich dazu entschieden den Broker ohne Authentifzierung laufen zu lassen, das muss selbigem jedoch beigebracht werden.

# Konfigurationsdatei öffnen
sudo nano /etc/mosquitto/conf.d/local.conf

#Einfügen der folgenden Inhalte zur Datei
listener 1883
allow_anonymous true

Nun ist der Broker installiert und vorkonfiguriert. Der Zugriff erfolgt über den Port 1883 und es werden keine Benutzerdaten zur Authentifzierung benötigt. Wir können selbigen nun starten und dem System mitteilen, dass der Start des Services auch bei einem Reboot des Systemes automatisch wieder mitgestartet werden soll:

# mosquitto beim Systemstart automatisch starten lassen
sudo systemctl enable mosquitto

# starten des mosquitto brokers
sudo systemctl start mosquitto

MQTT in den Shelly Komponenten einrichten

Nachdem der MQTT-Broker nun läuft können die Shelly-Komponenten konfiguriert werden so dass diese bei jeder Änderung eine Message an den Broker senden. Dies funktioniert über die Oberfläche des Komponenten. Der Zugriff erfolgt entweder über die interne IP (ist im Router zu finden) oder die Shelly-Cloud. Meine Screenshots stammen aus der Shelly-Cloud, welche bei mir allerdings inzwischen deaktiviert wurde.

Schritt 1:
Die MQTT Konfiguration befindet sich im Settings-Bereich unter dem Punkt Network \ MQTT

Schritt 2:
MQTT selbst ist zu aktivieren. Damit openHab die Nachrichten auswerten kann sollte unbedingt die Optin ‚Generic status update over MQTT‘ aktiviert werden, ansonsten gibt es Probleme bei der Auswertung der Nachrichten.
Im Feld Host geben wir den Namen oder die IP unseres Rapsberry-PI zusammen mit dem konfigurierten Port 1883 an. Das FeldUsername und Passwort lassen wir einfach leer

Nachdem die Änderungen übernommen wurden senden die Shellys bereits Nachrichten an den MQTT Broker welche nun „nur noch“ ausgewertet werden müssen.

Nachrichteneingang mit dem MQTT-Explorer prüfen

Nachdem ich den Shellys den Versand der MQTT Nachrichten beigebracht habe entschied ich mich, erstmal zu prüfen ob die Nachrichten auch wirklich ankommen. Hierfür setze ich einen freien MQTT-Client Namens ‚MQTT-Explorer‚ ein. Nach dem Start des Tools hinterlege ich auch hier den Hostnamen des MQTT-Brokers und schon kann ich die eingehenden Nachrichten sehen.

Nachricht des Shelly Pro 3PM* aus dem Hauptverteiler. Markiert ist hierbei der Wert des aktuellen Netzbezuges.

Nachricht des Shelly Plus 1PM* des Balkonkraftwerkes. Markiert ist hier der aktuelle Wert des Stromes, welcher durch die Solarmodule erzeugt werden.

Die Kontrolle der Nachrichten gibt zum einen ein gutes Gefühl und stellt sicher, dass die Kommunikation sauber funktioniert. Des weiteren ist diese Kontrolle relevant um zu erfahren, welche Inhalte die MQTT-Nachricht hat. Wie zu sehen ist beinhaltet die Nachricht eine Vielzahl von Werten. Für meine Zwecke sind von beiden Nachricht jedoch nur 2 Werte relevant welche im nächsten Schritt in openHab integriert werden.

Einrichtung des MQTT-Clients in openHab

Etwas mehr als die Hälfte des Weges ist gemacht. Nun sollen die Nachrichten der Shellys noch in openHab ausgewertet werden. Hierzu benötigen wir als erstes einmal das MQTT-Binding in OpenHab. Nachdem selbiges installiert ist richten wir zuerst einmal einen MQTT-Client ein welcher die Verbindung zum MQTT-Broker herstellt. Als nächstes definieren wir ein MQTT-Topic (über ein Generic-MQTT-Thing) welches dazu dient, alle Nachrichten des MQTT-Brokers zu empfangen:

Schritt 1
Definition eines neues Items vom Typ ‚MQTT Broker‘ welches als Client fungiert. Im Feld Hostname tragen wir die IP-Adresse des installierten Mosquitto Servers ein. In meinem Fall läuft dieser auf dem gleichen PI wie auch openHab wodurch die Angabe von 127.0.0.1 völlig genügt. Weitere Angaben sind nicht notwendig (sofern der gleiche Port und der anonyme Zugriff wie hier beschrieben gewählt wurden)

Schritt 2
Nachdem das Thing für den MQTT-Client eingerichtet wurde definieren wir ein weiteres Item. Dieses ist vom Typ ‚Generic MQTT Thing‘ und nutzt als Bridge den im vorherigen Schritt angelegten Client.
Auch hier ist keine weitere Konfiguration notwendig.

Definition der benötigen Channels und Items in openHab

Nachdem beide Items angelegt sind sehen wir … nichts. Im Hintergrund passiert nun aber doch schon einiges, auch wenn wir es nicht sehen. Die Shellys senden bei jeder Änderung eine MQTT-Nachricht an den installierten Mosquitto-Broker. Das im Schritt 1 eingerichtet Item stellt die Verbindung zum Broker her. Das im Schritt 2 eingerichtet Topic nutzt den Client und empfängt alle Nachrichten. Diese werden noch nicht ausgewertet wodurch wir noch nichts sehen, also los.

Für meinen Anwendungsfall genügen mir 2 Werte. Zum einen möchte ich gerne wissen wie viel Strom ich gerade vom Netzbetreiber beziehe. Zum zweiten möchte ich wissen wie viel Strom mein Balkonkraftwerk generiert. Aus diesen beiden Werten lassen sich alle weiteren Werte berechnen (mehr dazu in einem anderen Beitrag).

Bevor die MQTT Nachrichten verarbeitet werden können wird ein weiteres Modul in openHab benötigt. Die eingehenden Nachrichten kommen im JSON-Format an. Damit dieses einfach verarbeitet werden kann installieren wir das ‚JsonPath Transformation‚ Plugin. Sobald dies geschehen ist können wir die benötigten Channels anlegen.

Als erstes benötigen wir 2 Channels auf dem eingerichteten MQTT-Topic. Diese Channels extrahieren die gewünschten Informationen aus den MQTT-Nachrichten und stellen diese für die weitere Verarbeitung bereit.

Nun können wir endlich die so lang ersehnten Items anlegen:

aktuelle Live Stromwerte in openHab

Ich muss zugeben, dass mich dieser Weg einiges an Zeit gekostet hat. Jetzt, wo ich weiß wie es funktioniert, ist es alles logisch. Zu Beginn jedoch sah ich den Wald vor lauter Bäumen nicht und musste ein wenig kämpfen bis ich alle losen Enden zusammen hatte. Jetzt bin ich endlich so weit dass die Shelly Verbrauchsdaten über MQTT an openHab gesendet und dort ausgewertet werden können.

Die obige Grafik zeigt den Verlauf eines Tages an wobei die blaue Linie dem Bezug vom Netz (also den eingekauften Strom) darstellt. Die grüne Linie zeigt an wie viel Strom das Balkonkraftwerk produziert hat.

Als nächstes werde ich mich der Berechnung der Tageswerte widmen. Das Ziel ist es eine genaue Übersicht darüber zu erhalten wie viel Strom ich vom Netzbetreiber beziehe, was mein Balkonkraftwerk an Strom generiert und wie der Wirkungsgrad des selbigen wirklich ist. Stichworte wie „Eigenverbrauchsquote“ oder auch die Amortisierungszeit sind hierbei Fragen die mich herumtreiben. Sobald ich hier etwas brauchbares zu vermelden habe werde ich diese Scripte natürlich ebenfalls veröffentlichen.

Der Beitrag Shelly Verbrauchsdaten über MQTT an openHab senden erschien zuerst auf Das ist die Welt von Thomas.

Das Grundsetup

Unsere Waschmaschine und auch unser Wäschetrockner stehen im Keller im Waschkeller. Wir befinden uns irgendwo im Haus (oder Garten) und hören selbige nicht. Wir bekommen also in der Regel nicht selbst mit, ob die Geräte fertig sind. Schön wäre es doch, wenn uns das Gerät selbst bescheid sagt, wenn es fertig ist, oder?

Hierfür analysiere ich den Stromverbrauch der jeweiligen Geräte. Ist das Gerät aktiv so ist der Stromverbrauch höher als im Ruhemodus. Also messen wir „einfach“ den Stromverbrauch und prüfen, ob dieser höher ist als der Ruhemodus. Befindet sich das Gerät längere Zeit im Ruhemodus so senden wir eine Benachrichtigung und schalten das Gerät aus.

Jetzt auf Amazon ansehen *

Jetzt auf Amazon ansehen *

Hierfür wurden beide Geräte über eine eigene smarte Steckdose mit Leistungsmessung* am Stromnetz angeschlossen. Hier habe ich mich für die Steckdosen von Homematic* entschieden. Dazu betreibe ich die Homematic CCU3 Zentrale* welche über das entsprechende Binding an meine auf dem Raspberry* betriebene OpenHAB Installation angebunden ist.

Pushsafer für Waschmaschine Statusupdate versenden – Scripte

Im ersten Schritt benötigen wir in OpenHAB unsere Steckdose als „Thing“. Diese habe ich mir in mein Modell des Hauswirtschaftsraumes gezogen und mit 3 Items angelegt:

• Current -> aktueller Stromverbrauch
• Energy Counter -> gesamter Stromverbrauch
• State -> Status (ein / aus)

Für die beschriebene Umsetzung wird der aktuelle Stromverbrauch sowie der Status benötigt. Hier aber zunächst mal das umgesetzte Script:

rule "HWR Waschmaschine - Energychange"
  when
    Item Strom__HWR__Waschmaschine_Current.state changed
  then
    val Number grenze = 50

    if((Strom__HWR__Waschmaschine_Current.state.state as DecimalType).intValue < grenze) {
      if (timerHwrWaschmaschine === null) {
        timerHwrWaschmaschine = createTimer(now.plusMinutes(2), [
          if((Strom__HWR__Waschmaschine_Current.state.state as DecimalType).intValue < grenze && Strom__HWR__Waschmaschine_State.state.toString == "ON") {
            logInfo("rules.automatic.hwr.wash", "Stromverbrauch länger als 2 Minuten unter Grenzwert - ausschalten")
            Strom__HWR__Waschmaschine_State.sendCommand(OFF)

            val actions = getActions("pushsafer", "pushsafer:pushsafer-account:gemeinsam")
            actions.sendPushsaferMessage("Homecontrol - HWR", "Waschmaschine ist aus")

            timerHwrWaschmaschine = null
          }
        ])
      }
    } else {
      timerHwrWaschmaschine?.cancel
      timerHwrWaschmaschine = null
    }
end

Das Rule ‚HWR Waschmaschine – Energychange‘ reagiert auf jede Änderung des Stromverbrauches des Items ‚Strom__HWR__Waschmaschine_Current‘ welches auf den aktuellen Stromverbrauch der Waschmaschine gemappt wurde. Bei jeder Änderung eines Wertes wird die Regel getriggert und führt den Code aus.

Im ersten Schritt lege ich eine Variable „grenze“ an welche den Schwellert definiert, ab wann das Gerät sich für mich im Ruhemodus befindet. Dieser Wert ist für jedes Gerät individuell und variiert. Bei meiner Waschmaschine liegt der Verbrauch im Ruhemodus unter 50 Watt. Diese Definition ist nicht zwingend notwendig, macht den Code aber einfach lesbarer.

Im nächsten Schritt prüfe ich, ob der aktuelle Stromverbrauch sich unterhalb der definierten Grenze liegt. Ist die der Fall so wird ein Timer gestartet welcher 2 Minuten lang läuft. Sind die 2 Minuten erreicht wird erneut geprüft ob der aktuelle Stromverbrauch weiterhin unterhalb der Grenze liegt und ob die Steckdose noch eingeschaltet ist. Ist dies der Fall senden wir die Pushsafer Notification über das entsprechend angelegte Binding und setzen den Timer wieder auf null.

Ist der aktuelle Stromverbrauch höher als die Grenze beenden wir eventuell laufende Timer und setzen selbige auf null.

Warum der Timer?

Die wenigsten Elektrogeräte haben über die Zeit hin immer den gleichen Stromverbrauch. In den ersten Versuchen habe ich die Waschmaschine regelmäßig während dem Betrieb ausgeschaltet da ich auf einen Timer verzichten wollte. Dummerweise ist es aber so, dass die Waschmaschine auch im normalen Betrieb irgendwann mal ansatzweise gar keinen Strom zieht. Kurz danach fährt der Stromverbrauch wieder hoch und die Maschine beginnt z.B. zu schleudern nachdem das Wasser abgepumpt wurde. Um diese Zeiten zu überbrücken wurde der Time umgesetzt. Wir warten also 2 Minuten lang bevor wir die Maschine abschalten. Springt der Stromverbrauch während dieser 2 Minuten wieder über die definierte Grenze so brechen wir den Timer ab. Nur wenn wir 2 Minuten den Stromverbrauch unterhalb der definierten Grenze haben ist die Arbeit für uns beendet und wir schalten die Maschine ab und senden die Benachrichtigung.

Pushsafer Notification für die Waschmaschine läuft verlässlich

Bei uns zuhause ist die hier beschriebene Lösung nun seit einiger Zeit im Einsatz. Sie läuft sehr verlässlich und informiert uns immer sobald die Arbeit beendet ist. Somit wissen wir wann wir die nächste Ladung Wäsche anstellen oder den Trockner befüllen können. Mit Sicherheit ist das hier keine Raketentechnik – sie erleichtert uns jedoch das Leben ein wenig

Wie sind eure Erfahrungen? Habt Ihr selbst auch eine solche Lösung umgesetzt, eine andere Lösung oder ist es euch total egal und Ihr wollt von euren Maschine nicht angeschrien werden?

Der Beitrag Pushsafer für Waschmaschine – sag mir bescheid wenn Du fertig bist erschien zuerst auf Das ist die Welt von Thomas.

Homematic Funkmodul für den Rapsberry PI

Ich hasse es, unnötige Geräte herumstehen zu haben welche dumm Energie verbrauchen. Aus diesem Grund entschied ich mich vor 5 Jahren dazu, die Homematic-Komponenten über das Homematic Funkmodell an den Rapsberry PI anzubinden. Hierbei wird ein kleines Modul an den Raspberry angeschlossen* welcher zusammen mit einem frei verfügbaren Softwarepaket Homegear als Homematic-Zentrale fungiert. Klingt erstmal toll, keine unnötige Hardwarekomponente irgendwo herumstehen sondern alles direkt auf einem Device zentralisiert.

Die damalige Installation war dank diverserer Anleitungen im Internet recht schnell erledigt und funktionierte nach anfänglichen Problemen dann doch recht stabil.

gelegentliche Neustarts des Homegear-Services notwendig

Ab und an war zu beobachten, dass Funktionen der Homematic-Komponenten nicht mehr über die Automatisierung zur Verfügung standen. Die Ursache hierfür war schnell gefunden, der Homegear-Service verabschiedete sich hin und wieder unangekündigt und stellte die Arbeit ein. Keine Konfigurationsänderung, kein neues Aufsetzen des gesamten Systems verhalten das Problem zu lösen. Nun gut, also wurde ein kleiner Service umgesetzt der alle paar Minuten die Funktion des Services prüfte. War der Service mal wieder „offline“ wurde dieser neu gestartet. Dummerweise musste ich anschliessend das Binding der Homegear-Zentrale in OpenHAB ebenfalls neu starten, was über die Rest-API jedoch auch fix erledigt war. Somit lief das Modul eigentlich ganz rund …

Update des Betriebssystems – Homegear kaputt

Im Mai 2023 bekam ich dann irgendwann vermehrt böse Blicke meiner geliebten Ehefrau zugeworfen – die Automatisierung läuft nicht mehr rund. Rolläden gehen nicht mehr hoch und runter, die Waschmaschine sagt uns nicht mehr dass diese fertig ist – da ist der Wurm drin. Kein Problem, denke ich mir, ich habe ja nur ein Update durchgeführt. Kurz die Services prüfen und gut ist. Dieses mal leider nicht …

Der Homegear-Service verweigerte die Zusammenarbeit mit den Homematic-Komponenten vollends. Auch ein Rollback der Software brachte keine „kurzfristige“ Lösung (ich habe mich gut 3 Stunden damit beschäftigt) und mein Log wurde mit Fehlermeldungen überschüttet:

openhab homematic Warning: !!!Not!!! sending packet, because init sequence is not complete

Egal was ich versuchte, die Verbindung war gestört und ich bekam diese nicht (kurzfristig) zum laufen. Kurzfristig ist für mich hier eines der entscheidende Worte – ich habe keine Zeit mich um so einen Quatsch zu kümmern. Somit muss eine Lösung her – und zwar schnell.

Homematic und OpenHAB – Update auf die CCU3 Zentrale

Jetzt auf Amazon ansehen *

Glücklicherweise ist das OpenHAB-Binding für die Homematic-Zentrale sowohl für Homegear als auch die CCU3 Zentrale* gedacht. Was ist als naheliegender als die etwas fehleranfällige Umsetzung über das Funkmodul gegen die Homematic eigene Zentrale zu ersetzen? Ok, der Anschaffungspreis könnte ein Punkt sein denn eigentlich ist diese Investition nicht notwendig, sofern das Modul läuft. Tut es aber nicht, also Zähne zusammenbeissen und her mit der Zentrale.

Die Zentrale selbst war echt fix eingerichtet. LAN-Kabel rein, mit dem Strom verbunden und los geht es. Die ersten Komponenten waren fix angelernt, auch wenn ich zugeben muss, dass die Oberfläche recht „altbacken“ rüber kommt. Intuitiv ist anders

3 Wochen ohne Probleme

Die neue Homematic CCU3 Zentrale* ist nun seit gut 3 Wochen hier in Betrieb und arbeitet sehr zuverlässig. Bisher musste ich mich nur um neue Komponenten anzulernen dort anmelden, ansonsten liegt selbige einfach nur im Regal herum und macht seine Arbeit. Die Steuerung der Komponenten erfolgt weiterhin über den Raspberry PI mit OpenHAB und ist gefühlt schneller und stabiler als zuvor. Inzwischen sind auch erste Homematic-IP Komponenten eingezogen, welche mit der „alten Lösung“ leider nicht sauber liefen. Ich werde weiter berichten

Der Beitrag Homematic und OpenHAB – Tschüss HM-MOD-PI, Hallo CCU3 erschien zuerst auf Das ist die Welt von Thomas.

Die technische Ausstattung

Unser Zuhause ist mit diversen Sensoren und Aktoren von den unterschiedlichsten Herstellern ausgestattet. Sowohl der hier notwendige Sonnensensor als auch die Steuerung der Rolläden wurde über Homematic-Komponenten umgesetzt. Der Bewegungsmelder HM-Sen-MDIR-O-2* ist für außen geeignet, läuft über Batterie und verfügt über einen Sonnensor. Dazu kommen noch die Schaltaktoren für die Steuerung der Rolläden* und das war es auch schon mit den Komponenten.

Jetzt auf Amazon ansehen *

Jetzt auf Amazon ansehen *

Die einzelnen Homematic-Komponenten sind über Homegear angebunden. Für die Verbindung zwischen dem Raspberry PI und den Komponenten setze ich auf das HM-MOD-RPI-PCB Modul*.

Grundkonfiguration in openHAB

Die nachfolgenden Scripte gehen davon aus, dass eine gewisse Grundkonfiguration vorliegt. Zum einen benötigten wir eine Gruppe in welcher alle zu steuernden Rolläden zusammengefasst sind. In meinem Fall trägt diese Gruppe den Namen ‚group_rolladen_wohnen‚. Dazu benötigen wir ein thing welches die die aktuelle Helligkeit des Sonnensensors verfügbar macht. In meinem Fall trägt dieses den Namen ‚HomematicBewegungsmelderEingangsbereich_Brightness‚.

automatische Rolladensteuerung mit openHAB – Konfigurationsoberfläche

Ich möchte mich im täglichen Gebrauch nicht in Scripten finden um Werte anzupassen sondern möchte selbige über eine brauchbare UI haben. Aus diesem Grund habe ich mir eine kleine UI gebaut welche die für mich notwendigen Parameter beinhaltet:

Zum einen kann ich die Steuerung über einen globalen Switch aktivieren / deaktivieren. Als nächstes möchte ich gerne, dass die Rolläden unter der Woche zu anderen Zeiten und anderen Helligkeitswerten geschaltet werden können als am Wochenende. Auch möchte ich gerne eine Option haben den Helligkeitssensor zu deaktivieren und die Schaltung nur per Zeitplan zu steuern. Hierfür habe ich mir die folgenden items über die Datei ‚rolladensteuerung.items‘ angelegt:

Switch		rolladenWohnEnabled				"Rolladensteuerung aktiv"			<switch>	(gRestoreOnStartup)

Switch		rolladenWohnSunEnabledWeek		"Helligkeitssteuerung aktiv"		<switch>	(gRestoreOnStartup)
DateTime	rolladenWohnWeekDown			"Zeit runter [%1$tH:%1$tM]"			<time>		(gRestoreOnStartup)
DateTime	rolladenWohnWeekUp				"Zeit hoch [%1$tH:%1$tM]"			<time>		(gRestoreOnStartup)
Number 		rolladenWohnSunThreshWeek 		"Helligkeitsgrenze [%d]"			<sun>		(gRestoreOnStartup)

Switch		rolladenWohnSunEnabledWeekend	"Helligkeitssteuerung aktiv"		<switch>	(gRestoreOnStartup)
DateTime	rolladenWohnWeekendDown			"Zeit runter [%1$tH:%1$tM]"			<time>		(gRestoreOnStartup)
DateTime	rolladenWohnWeekendUp			"Zeit hoch [%1$tH:%1$tM]"			<time>		(gRestoreOnStartup)
Number 		rolladenWohnSunThreshWeekend	"Helligkeitsgrenze [%d]"			<sun>		(gRestoreOnStartup)

String		rolladenWohnCurrentState		"Status"										(gRestoreOnStartup)

Alle Elemente aus der Konfiguration wurden der Gruppe ‚gRestoreOnStartup‘ zugeordnet. Diese Gruppe ist bereits im Artikel openHAB Werte speichern und laden – Persistenz einführen erklärt und sorgt dafür, dass die konfigurierten Werte auch nach einem Systemneustart noch vorliegen. Die eigentliche Settings-Page habe ich mir über die Paper-UI über die Oberfläche „zusammengeklickt“. Die entsprechende yaml-Definition sieht wie folgt aus:

config:
  label: Steuerung Wohnbereich
  sidebar: false
blocks:
  - component: oh-block
    config: {}
    slots:
      default:
        - component: oh-grid-row
          config: {}
          slots:
            default:
              - component: oh-grid-col
                config: {}
                slots:
                  default:
                    - component: oh-toggle-card
                      config:
                        item: rolladenWohnEnabled
                        title: Rolladensteuerung aktiv
  - component: oh-block
    config:
      title: Konfiguration für Wochentage (Montag bis Freitag)
    slots:
      default:
        - component: oh-grid-row
          config: {}
          slots:
            default:
              - component: oh-grid-col
                config: {}
                slots:
                  default:
                    - component: oh-toggle-card
                      config:
                        item: rolladenWohnSunEnabledWeek
                        title: Helligkeitssteuerung
              - component: oh-grid-col
                config: {}
                slots:
                  default:
                    - component: oh-input-card
                      config:
                        clearButton: true
                        inputmode: text
                        item: rolladenWohnSunThreshWeek
                        outline: true
                        sendButton: true
                        title: Helligkeitsgrenze
                        type: number
              - component: oh-grid-col
                config: {}
                slots:
                  default:
                    - component: oh-input-card
                      config:
                        clearButton: true
                        footer: =items.rolladenWohnWeekUp.displayState
                        inputmode: text
                        item: rolladenWohnWeekUp
                        outline: true
                        placeholder: hh:mm:ss
                        sendButton: true
                        title: Rolladen hoch
                        type: time
              - component: oh-grid-col
                config: {}
                slots:
                  default:
                    - component: oh-input-card
                      config:
                        clearButton: true
                        footer: =items.rolladenWohnWeekDown.displayState
                        inputmode: text
                        item: rolladenWohnWeekDown
                        outline: true
                        placeholder: hh:mm:ss
                        sendButton: true
                        title: Rolladen runter
                        type: time
  - component: oh-block
    config:
      title: Konfiguration für Wochenende (Samstag + Sonntag)
    slots:
      default:
        - component: oh-grid-row
          config: {}
          slots:
            default:
              - component: oh-grid-col
                config: {}
                slots:
                  default:
                    - component: oh-toggle-card
                      config:
                        item: rolladenWohnSunEnabledWeekend
                        title: Helligkeitssteuerung
              - component: oh-grid-col
                config: {}
                slots:
                  default:
                    - component: oh-input-card
                      config:
                        clearButton: true
                        inputmode: text
                        item: rolladenWohnSunThreshWeekend
                        outline: true
                        sendButton: true
                        title: Helligkeitsgrenze
                        type: number
              - component: oh-grid-col
                config: {}
                slots:
                  default:
                    - component: oh-input-card
                      config:
                        clearButton: true
                        footer: =items.rolladenWohnWeekendUp.displayState
                        inputmode: text
                        item: rolladenWohnWeekendUp
                        outline: true
                        placeholder: hh:mm:ss
                        sendButton: true
                        title: Rolladen hoch
                        type: time
              - component: oh-grid-col
                config: {}
                slots:
                  default:
                    - component: oh-input-card
                      config:
                        clearButton: true
                        footer: =items.rolladenWohnWeekendDown.displayState
                        inputmode: text
                        item: rolladenWohnWeekendDown
                        outline: true
                        placeholder: hh:mm:ss
                        sendButton: true
                        title: Rolladen runter
                        type: time
masonry: null
grid: []
canvas: []

Rule zur automatischen Rolladensteuerung

Nachdem nun die Konfiguration über die UI verwaltet werden kann fehlt noch die Regel welche die eigentliche Steuerung durchführt. Natürlich könnte man nun auf die unterschiedlichsten Events hören und die Regel loslaufen lassen. Ich habe mich allerdings dazu entschieden dass es völlig genügt, wenn die Regel alle 5 Minuten prüft, ob sich etwas geändert hat. Somit basiert meine Regel auf einem Trigger per cron.

Anbei erstmal die Regel welche in der Datei ‚rolladensteuerung.rules‘ abgelegt ist:

rule "Rolladensteuerung Wohnbereich"
when
	Time cron "0 */5 * * * *" // Prüfe alle 5 Minuten
then
	var usedGroup = group_rolladen_wohnen
	
	if (rolladenWohnEnabled.state == ON && !usedGroup.allMembers.isEmpty) {
		var isWeekend = (now.dayOfWeek.getValue() == 6) || (now.dayOfWeek.getValue() == 7)
		
		// get configuration values for current weekday
		var Boolean cfgUseSunLevel = false
		var Number cfgSunLevel = -1
		var cfgTimeUp = now
		var cfgTimeDown = now
		if (isWeekend) {
			cfgUseSunLevel = rolladenWohnSunEnabledWeekend.state == ON
			cfgSunLevel = rolladenWohnSunThreshWeekend.state
			cfgTimeUp = (rolladenWohnWeekendUp.state as DateTimeType).getZonedDateTime()
			cfgTimeDown = (rolladenWohnWeekendDown.state as DateTimeType).getZonedDateTime()
		} else  {
			cfgUseSunLevel = rolladenWohnSunEnabledWeek.state == ON
			cfgSunLevel = rolladenWohnSunThreshWeek.state
			cfgTimeUp = (rolladenWohnWeekUp.state as DateTimeType).getZonedDateTime()
			cfgTimeDown = (rolladenWohnWeekDown.state as DateTimeType).getZonedDateTime()
		}
		
		// check if should go down
		var Number aktuelleHelligkeit = HomematicBewegungsmelderEingangsbereich_Brightness.state
		if (cfgUseSunLevel && cfgSunLevel > -1 && aktuelleHelligkeit <= cfgSunLevel) {
			if (rolladenWohnCurrentState.state === null || rolladenWohnCurrentState.state != "DOWN") {
				rolladenWohnCurrentState.postUpdate("DOWN")
				logInfo("rules.automatic.rolladen", "Rolladensteuerung - Wohnbereich - runter - Helligkeitssensor")
				usedGroup.allMembers.filter( m | m.state != 100).forEach[ i | i.sendCommand(100) ]
			}
		} else if ((now.getHour == cfgTimeDown.getHour && now.getMinute >= cfgTimeDown.getMinute) || (now.getHour > cfgTimeDown.getHour)) {
			if (rolladenWohnCurrentState.state === null || rolladenWohnCurrentState.state != "DOWN") {
				rolladenWohnCurrentState.postUpdate("DOWN")
				logInfo("rules.automatic.rolladen", "Rolladensteuerung - Wohnbereich - runter")
				usedGroup.allMembers.filter( m | m.state != 100).forEach[ i | i.sendCommand(100) ]
			}
		} else if ((now.getHour == cfgTimeUp.getHour && now.getMinute >= cfgTimeUp.getMinute) || (now.getHour > cfgTimeUp.getHour && now.getHour <= cfgTimeDown.getHour)) {
			if (rolladenWohnCurrentState.state === null || rolladenWohnCurrentState.state != "UP") {
				rolladenWohnCurrentState.postUpdate("UP")
				logInfo("rules.automatic.rolladen", "Rolladensteuerung - Wohnbereich - hoch")
				usedGroup.allMembers.filter( m | m.state != 0).forEach[ i | i.sendCommand(0) ]
			}
		} 
	}
end

Die Regel scheint auf den ersten Blick vielleicht ein wenig abstrakt, hat sich aber in der Praxis bisher bewährt und funktioniert recht gut. Die hier vorgestellte Regel ist hier bei mir für 2 unterschiedliche Schaltzonen (Wohnen und Schlafen ) aktiv und arbeitet zuverlässig.

automatische Rolladensteuerung mit openHAB – Zusammenfassung

Prinzipiell ist die Anforderung der automatischen Steuerung der Rolläden mit openHAB recht einfach umzusetzen. Wie immer steckt der Teufel allerdings dann doch im Detail. Anfangs hatte ich z.B. auf den Status verzichtet was sich dann schnell rächte. Als meine Frau tagsüber den Rolladen herunterfuhr um auf dem TV etwas zu erkennen fuhr dieser 5 Minuten später wieder hoch. Fühlt sich erstmal komisch an, ist aber total logisch wenn man sich die Regel mal ohne die Speicherung des aktuellen Status vorstellt.

Inzwischen funktioniert die Steuerung wunderbar. Vielleicht hilft meine Dokumentation an dieser Stelle ja dem ein oder anderen Leser

Der Beitrag Automatische Rolladensteuerung mit openHAB, Zeitplan und Sonnensensor erschien zuerst auf Das ist die Welt von Thomas.