Wallbox Lademanagement über OH 3

Für welche Projekte verwendet Ihr OpenHAB? Was habt Ihr automatisiert? Stellt eure Projekte hier vor.

Moderatoren: Cyrelian, seppy

shorty5001
Beiträge: 19
Registriert: 11. Feb 2021 13:54
Answers: 0

Re: Wallbox Lademanagement über OH 3

Beitrag von shorty5001 »

Ich habe mich die letzten Wochen auch mal an einem Script versucht.
Leider ist die Scriptsprache für mich absolutes Neuland.
Könnt ihr mal drüber sehen, ob es Sinn ergibt?

Zur Erklärung:
Das Script ist Teil einer Rule für einen Schalten "PV-Laden".
Wenn dieser eingeschaltet wird erhält die Wallbox den Befehl das Laden sofort zu beginnen und dann das Script auszuführen.

PV_Laden_Amp_max ist ein errechneter Wert aus PV Produktion in Watt minus Hausverbrauch in Watt geteilt durch 232 Volt (damit habe ich die vielfach genutzte 90 bzw. 95 % Idee bereits eingepreist).

Code: Alles auswählen

var ampere = (PV_Laden_Amp_max.state as Number).floatValue    //Verfügbare Ladeleistung in Ampere wird ermittelt.
var Timer tCharge = Null

rule "PV_Laden"
when
	Item PV_Laden_Amp_max received update  
then
	if(ampere.intValue >= 6)  //Bei Überschreiten der 6A Schwelle = Fortlaufendes Anpassen der Stromstärke zum Laden in vollen Ampere zwischen 6 und 16
	{
		if(ampere.intValue = 6)
			{
				Wallbox_Max_Amp.sendCommand(6) 
			}
			else if(ampere.intValue > 16)
			{
				Wallbox_Max_Amp.sendCommand(16)  //Bei mehr als 16 Ampere verfügbarer Leistung erfolgt Limit auf 16
			}
			else
			{
				Wallbox_Max_Amp.sendCommand(ampere.intValue)  // Die jeweils verfügbare Ladeleistung wird eingestellt.
			}
			
	}	
		
	if(ampere.intValue < 6)		//Wenn verfügbare Ampere kleiner 6 - Timer starten
	{
		    if(tCharge === null)
				{
					tCharge = createTimer(now.plusMinutes(2), [ |               // Erzeuge Abschlattimer
						Wallbox_Forcestate.sendCommand(OFF)
						tCharge = null
					])
				}
				Wallbox_Max_Amp.sendCommand(6)
	}
	else if(ampere.intValue > 16)
	{
			Wallbox_Max_Amp.sendCommand(16)
			tCharge?.cancel         // laufenden Timer abbrechen
			tCharge = null          
	}
	else
	{
			Wallbox_Max_Amp.sendCommand(ampere.intValue)
			tCharge?.cancel         // laufenden Timer abbrechen
			tCharge = null         
	}
	
  
end

Benutzeravatar
udo1toni
Beiträge: 13986
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Wallbox Lademanagement über OH 3

Beitrag von udo1toni »

Also, das wichtigste hier im Forum wäre, Code, den Du postest, auch als Code zu markieren (ich habe das mal nachgeholt...)

Nun zu Deinem Code:

Gleich der erste Fehler passiert in der allerersten Zeile noch vor der Rule.

Du definierst unnötigerweise eine globale Variable und weist ihr einen Wert zu, den Du aus einem Item gewinnst. Das wird gleich aus mehreren Gründen schief gehen.
Grund eins: die Definition ist statisch, sie wird nur einmalig ausgeführt, und zwar, wenn die Datei geladen wird. Die Variable bekommt dabei den Wert zugewiesen, nicht etwa eine Funktion.
Grund zwei: Beim Laden der Rule ist die Chance bei etwa 95 %, dass der Status des Items NULL ist. NULL ist allerdings kein Bestandteil des Datentyps Number, es wird deshalb eine NullPointer Exception geben.

Und weiter geht es mit Zeile zwei ;)
Dort weist Du der Timer Variablen den Wert Null zu. Diesen Wert gibt es allerdings nicht. Entweder Du hast ein Item, das kann den Status NULL annehmen, oder Du hast eine Variable, die kann den Wert null zugewiesen bekommen.

Der Rest der Rule würde vermutlich funktionieren, aber die Herangehensweise ist unnötig kompliziert. Optimiert und korrigiert sähe die Rule bei mir so aus:

Code: Alles auswählen

var Timer tCharge = null                                // Timer Variable global definieren

rule "PV Laden"
when
    Item PV_Laden_Amp_max changed
then
    if(!(newState instanceof Number))                   // Falls kein gülter Zahlenwert
        return;                                         // breche Rule ab

    var Integer iAmpere = (newState as Number).intValue // Verfügbare Ladeleistung in Ampere ermitteln

    if(iAmpere >= 6) {                                  // falls iAmpere mindestens 6
        tCharge?.cancel                                 // breche Timer ab, falls vorhanden
        tCharge = null                                  // setze tCharge auf null
    } else if(tCharge === null)                         // falls iAmpere kleiner 6 UND kein Timer vorhanden
        tCharge = createTimer(now.plusMinutes(2), [ |   // Erzeuge Abschalttimer
            Wallbox_Forcestate.sendCommand(OFF)
            tCharge = null
        ])

    if(iAmpere > 16) iAmpere = 16                       // falls über 16, setze 16
    if(iAmpere <  6) iAmpere =  6                       // falls unter 6, setze  6
    Wallbox_Max_Amp.sendCommand(iAmpere)                // Ladeleistung an Wallbox senden
end
Der Name der Rule kann beliebige Zeichen aus dem UTF-8 Zeichensatz enthalten, also z.B. Leerzeichen oder auch Umlaute.
Er entspricht da einem Label. Naturgemäß darf aber jeder Name nur einmal benutzt werden, in der Hinsicht ist er eher mit einer UID vergleichbar :)

Der Trigger changed ist hier vollkommen ausreichend :) und mit diesem Trigger kommt eine implizite Variable, welche etwas Tipparbeit spart (newState enthält den aktuellen Status des Items, welches die Rule mit changed getriggert hat. Eine weitere implizite Variable wäre previousState, welche den Status vor dem changed Ereignis enthält. Die spielt hier aber keine Rolle, nur der Vollständigkeit halber...)

Der erste Schritt innerhalb des Rule Codes ist, zu prüfen, ob überhaupt eine gültige Zahl im Status vorliegt. Ist das nicht der Fall, bricht die Rule ab, denn sie kann keine qualifizierte Entscheidung treffen.

Falls die Rule nicht abgebrochen wird, wird im nächsten Schritt aus dem aktuellen Status der Ganzzahlwert ermittelt (dieser ist hinreichend für den restlichen Code).

Weiter geht es mit der Steuerung des Timers. Grund für die vertauschte Reihenfolge ist das Einsparen einer Variable :)
Liegt der Wert bei oder über 6, so kann ein eventuell laufender Timer abgebrochen und die Timer Variable genullt werden.
Liegt der Wert unter 6, so gilt es zu beachten, ob der Timer bereits läuft. Ist das der Fall, so darf der Timer nicht erzeugt werden, sonst werden mehrere Timer erzeugt, von denen nur der zuletzt angelegte Timer noch gestoppt werden kann (weil ja immer wieder die selbe Timer Variable verwendet wird.) Ist noch kein Timer vorhanden, wird er angelegt und gestartet. (Zu beachten: der Timer wird vom Scheduler verwaltet und hat nichts mit der Rule zu tun)

Zum Abschluss wird der ermittelte Wert mit Ober- und Untergrenze abgeglichen (wie gesagt, das muss nach dem Vergleich für den Timer geschehen, weil sonst die Untergrenze den Vergleich vermasselt...)
Der Wert, der nun sicher ein Integer Wert zwischen 6 und 16 ist, wird an die Wallbox gesendet. Fertig...
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

mcdandrew
Beiträge: 163
Registriert: 13. Dez 2018 17:42
Answers: 0

Re: Wallbox Lademanagement über OH 3

Beitrag von mcdandrew »

Kleine Anmerkung am Rande...

Ich hatte ja lange einen selbst geschriebenen Code genutzt um den Strom unserer PV Anlage optimal zu nutzen. (Code hatte ich hier mal gepostet)
Mittlerweile bin ich auf das Projekt EVCC umgestiegen....läuft bei mir auf dem Synology NAS als Docker Container.

Bin super zufrieden damit, wäre eventuell für manche eine Alternative.

shorty5001
Beiträge: 19
Registriert: 11. Feb 2021 13:54
Answers: 0

Re: Wallbox Lademanagement über OH 3

Beitrag von shorty5001 »

Danke - mal wieder - Udo1toni
Gleich in der ersten Zeile Murks… uiuiui, aber war schon fast klar. Bin nicht im Ansatz vom Fach.
Null ist nicht gleich null ist nicht gleich NULL.
Da muss man auch erstmal drauf kommen.
Verstehe ich das richtig, das „newState“ sich auf den Wert von PV_Laden_Amp_max bezieht?

Nochmal: Vielen Dank!

Benutzeravatar
udo1toni
Beiträge: 13986
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Wallbox Lademanagement über OH 3

Beitrag von udo1toni »

shorty5001 hat geschrieben: 28. Aug 2022 15:42 Null ist nicht gleich null ist nicht gleich NULL.
Da muss man auch erstmal drauf kommen.
Grundsätzlich ist openHAB überall Case Sensitive - Ja, es gibt ein paar Stellen, an denen es nicht so ist... das Einfachste ist aber, sich sklavisch an die ExAkte Schreibweise zu halten. In dem Zusammenhang auch wichtig: openHAB nutzt ausgiebig CamelCase, gewöhnlich fängt das Wort aber mit einem Kleinbuchstaben an. stateTopic, commandTopic usw. Bei Datentypen in DSL Rules bedeutet die Typisierung in Kleinbuchstaben, dass es sich um Primitives handelt (var int iVar = 10 -> Primitive; var Integer iVar = 10 -> Object. Der Unterschied: für das Primitive gibt es keine Methoden wie z.B. iVar.toString.
shorty5001 hat geschrieben: 28. Aug 2022 15:42 Verstehe ich das richtig, das „newState“ sich auf den Wert von PV_Laden_Amp_max bezieht?
Genau, weil die Rule durch Item PV_Laden_Amp_max changed getriggert wurde, befindet sich der Status vor dem Ereignis in previousState und der Status nach dem Ereignis (also der aktuelle Status) in newState.
Und bitte previousState nicht mit Item.previousState verwechseln, Ersteres ist eine implizite Variable, die zur Verfügung steht, weil die Rule durch das changed Ereignis getriggert wurde, Letzteres ist eine Methode, die nur zur Verfügung steht, wenn das Item persistiert wird.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

int5749
Beiträge: 1161
Registriert: 4. Nov 2019 22:08
Answers: 9

Re: Wallbox Lademanagement über OH 3

Beitrag von int5749 »

mcdandrew hat geschrieben: 27. Aug 2022 20:29 Kleine Anmerkung am Rande...

Ich hatte ja lange einen selbst geschriebenen Code genutzt um den Strom unserer PV Anlage optimal zu nutzen. (Code hatte ich hier mal gepostet)
Mittlerweile bin ich auf das Projekt EVCC umgestiegen....läuft bei mir auf dem Synology NAS als Docker Container.

Bin super zufrieden damit, wäre eventuell für manche eine Alternative.
Evtl. Noch zu erwähnen (da ich auch evcc nutze) das es dafür sogar ein openHAB Binding gibt ;-)
Kurzes Fazit nach nunmehr 13 Monaten Fiat 500e - ca.<40 km am Tag.
Spätes Frühjahr bis Anfang Herbst wird der kleine schwarze am Wochenende (ab Freitagmittag) meist perfekt über evcc gesteuert mit Sonne geladen und evcc schließt die Lücke des Herstellers und stoppt bei 85% Akkuladung den Ladevorgang. Das reicht dann Mo-Fr für meine Frau und sogar kleinere Wege nebenher,
Ab Herbst - Frühjahr wird dann über meine openHAB Rule von Sonntag auf Montag Nacht der 500er auf 90% geladen, dies reicht dann bis Mittwoch, dann geht es wieder an den Strom. Ich rede mir ein, das es ganz gut ist den Akku Nachts langsam zu laden und den LAdevorgang kurz vor Abfahrt beendet zu wissen. Da ich der Akku noch leicht vorgewärmt.
openHAB 4.1.0 Release mit openHABian in einem Debian Bookworm (LXC) unter Proxmox 8.1.3

Benutzeravatar
udo1toni
Beiträge: 13986
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Wallbox Lademanagement über OH 3

Beitrag von udo1toni »

int5749 hat geschrieben: 30. Aug 2022 23:20 Ich rede mir ein, dass es ganz gut ist den Akku Nachts langsam zu laden und den Ladevorgang kurz vor Abfahrt beendet zu wissen. Da ist der Akku noch leicht vorgewärmt.
Das empfehlen sogar die Hersteller :)
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

int5749
Beiträge: 1161
Registriert: 4. Nov 2019 22:08
Answers: 9

Re: Wallbox Lademanagement über OH 3

Beitrag von int5749 »

udo1toni hat geschrieben: 31. Aug 2022 01:16
int5749 hat geschrieben: 30. Aug 2022 23:20 Ich rede mir ein, dass es ganz gut ist den Akku Nachts langsam zu laden und den Ladevorgang kurz vor Abfahrt beendet zu wissen. Da ist der Akku noch leicht vorgewärmt.
Das empfehlen sogar die Hersteller :)
Dann bin ich ja auch einmal auf dem richtigen Pfad :)
openHAB 4.1.0 Release mit openHABian in einem Debian Bookworm (LXC) unter Proxmox 8.1.3

BOP
Beiträge: 197
Registriert: 23. Sep 2018 19:43
Answers: 1

Re: Wallbox Lademanagement über OH 3

Beitrag von BOP »

Ich kaper den Thread jetzt einfach mal ein wenig.
Ich betreibe zurzeit ioBroker, um den Ladestand des Fiats zu holen und per MQTT an openHAB zu übergeben. Mehr macht das Teil nicht.
Würde es Sinn ergeben, ioBroker gegen EVCC auszutauschen? Auch wenn man keine PV-Anlage betreibt?
Das Lademanagement würde ich ganz gerne in OH belassen. Das funktioniert nämlich sehr gut und zuverlässig. Es geht ausschließlich darum den Ladezustand abzurufen und ggf. den Ladestatus des Fahrzeugs.

In ioBroker muss man ja z.B. ein DeepUpdate ausführen, damit der Ladestand aktualisiert wird. Ich denke das ist mit EVCC nicht nötig?

int5749
Beiträge: 1161
Registriert: 4. Nov 2019 22:08
Answers: 9

Re: Wallbox Lademanagement über OH 3

Beitrag von int5749 »

BOP hat geschrieben: 7. Sep 2022 09:44 In ioBroker muss man ja z.B. ein DeepUpdate ausführen, damit der Ladestand aktualisiert wird. Ich denke das ist mit EVCC nicht nötig?
evcc macht genau dies auch ;-)

[off-topic on]
War damals in Kontakt mit den evcc Entwicklern und genau zu dem Zeitpunkt wurde parallel das AddOn für ioBroker erstellt, was ich mit tests unterstützt habe. Als der lief, war die Kommunikation zwischen den beiden open-source Projekten Formsache und evcc konnte den Fiat 500 unterstützen. (Hier immer noch einen Dank an beide Entwickler (Teams))
[off-topic off]

Problem wird eher sein, dass evcc ohne entsprechende PV bzw. min. einer intelligenten Steuerung (z.B. SMA Home Manager) nicht startet.
Leider waren/sind meine Kenntnisse ein openHAB Binding deutlich zu gering und bisher konnte ich keinen begeistern sich dieses (teilweise volatilen) Thema's anzunehmen :roll:
openHAB 4.1.0 Release mit openHABian in einem Debian Bookworm (LXC) unter Proxmox 8.1.3

Antworten