Also mal platt gesagt: das alles sind Standardfunktionen von openHAB. Aber openHAB biete keine fertigen Module, die man nur noch mit den Geräten verbinden muss, um solche Regelaufgaben zu erfüllen. Die Arbeit mit openHAB gliedert sich ganz grob in drei Abschnitte:
- Hardware in openHAB verfügbar machen. Das bedeutet: pro Geräte "Sorte" das passende Addon installieren und für die Geräte die Schnittstelle konfigurieren, also z.B. für die Fronius das Fronius Addon installieren und eine Bridge mit dem Hostnamen sowie ein Thing mit der systemID (gewöhnlich 1, aber falls Du mehrere Inverter hast halt für jeden Inverter eine eigene SystemID) einrichten.
Anschließend brauchst Du für alle Daten, die Du verwenden willst (und natürlich unter der Voraussetzung, dass das Binding sie zur Verfügung stellt) ein eigenes Item, welches mit dem passenden Channel verlinkt wird. Bei Geräten die gesteuert werden sollen (z.B. der Laderegler für den Zoe) brauchst Du natürlich noch Items, welche die Befehle an die Hardware weitergeben.
- Falls gewünscht, eine UI erstellen.
- Die Regeln definieren, nach denen die Regelung erfolgen soll.
Punkt 1 und 2 sind reine Konfiguration. Das kann wahlweise mit Text oder per UI erfolgen. Wenn Du gerade erst anfängst, rate ich Dir dringend zu openHAB3, auch wenn das noch nicht als stable Version angeboten wird. Wenn nichts dazwischen kommt, ist es im Dezember stable. Du möchtest Dich nicht mehr mit dem alten Zeug belasten...
Punkt 3 fällt sicherlich unter den Begriff "programmieren", allerdings ist das auch nicht sooo wild. Es gibt mehrere Möglichkeiten, grob: Die NG Rules Engine, die alte Rules DSL und die Option, in Python (oder auch anderen Sprachen) Regeln zu erstellen.
Ich bin seit openHAB 1.0 mit dabei und schwöre auf die alte Rules DSL, es gibt aber viele Leute, die sich damit schwer tun.
Grundsätzlich ist openHAB eventbasiert, das heißt, jedes Ereignis kann Aktionen auslösen. Beispielsweise ändert sich die gelieferte Strommenge der PV Anlage, damit ändert sich auch der Status des Items, mit welchem die Strommenge angezeigt wird. Nun kann also eine Rule gestartet werden, weil sich die gelieferte Strommenge geändert hat. Die Rule kann dann anhand von Vergleichen und Berechnungen entscheiden, ob z.B. der Ladestrom für den Zoe angepasst werden muss und das eben auch automatisch erledigen. Sieht dann z.B. so aus:
Code: Alles auswählen
rule "Zoe laden"
when
Item PVPower changed
then
if(PVPower.state as Number).floatValue > 5000)
ChargeZoe.sendCommand(30)
end
Das ist jetzt natürlich nur ein unvollständiges Beispiel
Das Item PVPower ändert seinen Status. Daraufhin wird die Rule ausgeführt.
In der Rule wird geprüft, ob der Wert (als Zahl betrachtet) größer als 5000 ist. Ist das der Fall, so wird der Befehl zum Laden auf 30 gesetzt. Das wäre in meiner Vorstellung die Ladestrombegrenzung. Die Rule ist so natürlic hsinnlos, es müssten auch noch weitere Stufen definiert werden, es müsste vermutlich auch noch ein Timeout eingebaut werden, um zu verhindern, dass der Ladestrom ständig hin und her geht (das wäre vermutlich nicht gut für die Steuerung bzw. die Akkus) aber es sollte erkennbar sein, wie das Ganze abläuft.
openHAB5.0.1 stable in einem Debian-Container (trixie, OpenJDK 21 headless runtime) (Proxmox 9.0.6, LXC)
