openhabforum.de

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).

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: 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...

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.

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!

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.

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.

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

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

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?

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