openhabforum.de

Hallo liebe OH Spezialisten,

ich bin auf dem Gebiet leider ein vollständiger Rookie, darum bitte ich um euren Support. (mit ChatGPT haut das leider nicht hin).

Ich nutze aktuell im Zusammenhang mit meiner PV-Anlage eine einfache Regel:
- Ein Heizstab wird bei PV Leistung >4kW über einen Shelly aktiviert.
- Fällt die Leistung unter 2 kW wird der Shelly deaktiviert.

Das funktioniert auch soweit bestens.
Ich möchte die Funktion jedoch gerne erweitern:
Der Schalter soll nicht sofort bei einem Abfall unter 2 kW ausschalten.
Hier möchte ich gerne einen Timer laufen lassen für zB 5min - nach Ablauf dieser Zeit - sollte dann immer noch der Wert unter 2 kW liegen - soll ausgeschaltet werden.

Könnte mir ein Profi unter die Arme greifen und den Code dafür anpassen?
Sollte es zu aufwändig sein, dann wäre zumindest das Feedback hilfreich.

DANKE in jedem Fall!

Hier die aktuelle Regel:

Code: Alles auswählen

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: Fronius_Symo_Inverter_AC_Power
    type: core.ItemStateUpdateTrigger
conditions:
  - inputs: {}
    id: "3"
    configuration:
      itemName: Fronius_Symo_Inverter_AC_Power
      state: "2"
      operator: <=
    type: core.ItemStateCondition
  - inputs: {}
    id: "4"
    configuration:
      itemName: shellypro1_Betrieb
      state: ON
      operator: =
    type: core.ItemStateCondition
actions:
  - inputs: {}
    id: "2"
    configuration:
      command: OFF
      itemName: shellypro1_Betrieb
    type: core.ItemCommandAction

LG Rene

Hey René,

Ich habe vor kurzem eine ähnliche Schaltung integriert. Ggf. Noch ein paar Gedankengänge dazu. Ich habe die Leistung der PV Anlage in einem separaten Item auf 15 Minuten gemittelt. Dies soll einen schnellen Abfall oder einen Peak abfangen. Die Regel für die Schaltung habe ich dann auf einen Time-Trigger gestellt, welche alle 10 Minuten prüft. Dadurch brauche ich dann NICHT einen separaten Timer benutzen, sondern ich bewerte alle 10 Minuten auf Basis des gemittelten PV Ertrags, wieviel ich von dem Heizstab dazuschalte. Die Regel selbst habe ich dann mit einem Blockly Editor gebaut.

Bei meiner Variante umgehst du, dass du einen aktiven Timer brauchst. ggf. Hilft dir dies bei deinem Problem.

Beste Grüße,
Tim

... Super vielen Dank! Wieder was dazu gelernt.
... die Regel steht schonmal, morgen wird getestet!

Blockly war ein guter Rat, das ist halbwegs einfach verständlich inkl. YouTube Lernvideo (https://youtu.be/0l2H9Cxbyfo?si=VPJ0Hihj12fHL_5K)

LG Rene

Moin,

Habe an andere Stelle eigentlich exakt das selbige eingesetzt:

Code: Alles auswählen

var Timer tHeizpatrone = null                                                   // Timer tHeizpatrone

rule "Überwachung Shelly"

when
    Item Fronius_Symo_Inverter_AC_Power changed
then
    if(!(newState instanceof Number))                                           // falls Status keine Zahl
        return;                                                                 // Abbruch
    if((newState as Number).intValue < 2000 && tHeizpatrone === null) {         // falls kleiner 2000 und kein Timer gestartet
        tHeizpatrone = createTimer(now.plusMinutes(5), [|                       // Erstelle Timer 5 Minuten
            shellypro1_Betrieb.sendCommand(OFF)                                 // Shelly deaktivieren
            tHeizpatrone = null
        ])
    } else if((newState as Number).intValue > 2000) {                           // falls größer 2000
        tHeizpatrone?.cancel                                                    // Timer abbrechen
        tHeizpatrone = null
    }
end

Wenn also der Wert unter 2000 fällt, wird der Timer gestartet, geht der Fronius innerhalb der Zeit wieder über 2000 wird der Timer gelöscht.

Sollte der Wert unter 2000 bleiben, wird der Shelly deaktiviert...

tim.l hat geschrieben: ↑28. Nov 2023 17:12 „Ich habe die Leistung der PV Anlage in einem separaten Item auf 15 Minuten gemittelt. Dies soll einen schnellen Abfall oder einen Peak abfangen.
Beste Grüße,
Tim“

Hallo Tim,
könntest du mir bitte noch verraten, wie du den Mittelwert gebildet hast, ich hab auf deiner Seite dazu leider auch nichts gefunden, generell online auch nicht so wirklich.

Für ne kurze Anleitung wäre ich sehr dankbar.
(Ohne Mittelwert funktionierts soweit 1A!)

Danke LG

Wenn das Item persistiert ist (also per Default jedes Item...) reicht es, in einer Rule per dasZuMittelndeItem.averageSince(now.minusMinutes(15)) den Mittelwert auszulesen.

Hallo udo1toni,
ich habe nun versucht - bin wirklich Rookie auf dem Gebiet - diesen Mittelwert zu bilden.
Folgendes habe ich gemacht:

rrd4j.persist Datei mit folgendem Inhalt angelegt:

Code: Alles auswählen

Strategies {
    everyMinute : "0 * * * * ?"
    default = everyChange
}

Items {
    Fronius_Symo_Inverter_AC_Power : strategy = everyMinute, restoreOnStartup
}

Danach neu gestartet und im Item hab ich jetzt die Analyse Funktion - es werden mir Daten angezeigt, somit sollte das richtig funktionieren.
Ich habe jetzt bedenken, ob die Geschichte meinen Rasp-Pi gut tut, da ich bedenken habe, dass damit der Speicher schneller beschädigt werden könnte, ist da etwas dran?

zudem hab ich ein neues ITEM angelegt, um den Mittelwert auszugeben = PVMittelwert
folgender Code:
la

Code: Alles auswählen

bel: PV Power Mittelwert
type: Number:Energy
category: energy
groupNames:
  - PV_Station
groupType: None
function: null
tags:
  - Measurement
  - Power

Und zudem folgende RULE erstellt:

Code: Alles auswählen

configuration: {}
triggers:
  - id: "1"
    configuration:
      cronExpression: 0 * 9-18 * * ? *
    type: timer.GenericCronTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/vnd.openhab.dsl.rule
      script: >
        var mittelwert =
        items["Fronius_Symo_Inverter_AC_Power"].averageSince(now.minusMinutes(15));

        logInfo("rules", "Mittelwert der letzten 15 Minuten: " + mittelwert);

        events.sendCommand("PVMittelwert", mittelwert.toString());
    type: script.ScriptAction

... leider wird mir kein Wert angezeigt = immer nur NULL
Kannst du mir sagen, wo der Fehler liegt?

Danke erstmal! LG

RR727 hat geschrieben: ↑5. Dez 2023 12:29 Ich habe jetzt bedenken, ob die Geschichte meinen Rasp-Pi gut tut, da ich bedenken habe, dass damit der Speicher schneller beschädigt werden könnte, ist da etwas dran?

Definitiv nicht von dem einen Item

und wenn Du das offizielle Image für den Pi verwendest (openHABian), dann sollte ZRAM aktiv sein, welches sämtliche Schreibzugriffe ohnehin ins RAM umleitet - eben um vorzeitiges Wearout der SD-Karte zu verhindern.

Fronius_Symo_Inverter_AC_Power ist vom Typ Number:Power? Dann ist schon die Annahme verkehrt, dass Du aus dem Mittelwert eine vernünftige Aussage über die Energiemenge treffen könntest

Deine Rule kann so nicht funktionieren, denn Du vermischst DSL und JavaScript.
Korrekt wäre die Rule so:

Code: Alles auswählen

configuration: {}
triggers:
  - id: "1"
    configuration:
      cronExpression: 0 * 9-18 * * ?
    type: timer.GenericCronTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/vnd.openhab.dsl.rule
      script: >
        var mittelwert = Fronius_Symo_Inverter_AC_Power.averageSince(now.minusMinutes(15))
        logInfo("mittelwert", "Mittelwert der letzten 15 Minuten: {}", mittelwert)
        PVMittelwert.postUpdate(mittelwert)
    type: script.ScriptAction

Wobei es noch ein paar Dinge zu beachten gibt...
Erstmal die offensichtlichen Unterschiede DSL<->JavaScript:
Grundsätzlich gibt es kein Semikolon am Ende eines Befehls. Die einzige Ausnahme zum Grundsatz: mit dem Befehl return; kann man die Rule frühzeitig abbrechen. return liefert gewöhnlich immer einen Rückgabewert, was aber im Zusammenhang mit Rules nicht funktioniert, da es keine aufrufende Funktion gibt, der ein Wert übergeben werden könnte. Deshalb muss dediziert null als Rückgabewert gesetzt werden, was mit dem Semikolon erreicht wird.
Items stehen direkt als Objekte zur Verfügung, man greift niemals indirekt auf Items zu (also Fronius_Symo_Inverter_AC_Power.state statt Items.getItem("Fronius_Symo_Inverter_AC_Power").getState)
.sendCommand() tut genau das: es sendet ein Kommando. Du möchtest den Status eines Items setzen, dazu wird .postUpdate() verwendet. Es mag auf den ersten Blick nicht auffallen, weil openHAB (default) für jedes .sendCommand() ein passendes .postUpdate() erzeugt, aber zum Einen kann man diese Funktion abschalten (autoupdate=false), zum Anderen kann das schief gehen und ist mindestens langsamer als das .postUpdate()
Zum Befehl logInfo(): Der erste der zwei Strings ist der letzte Teil des Loggernamens, der erste Teil lautet immer org.openhab.core.model.script., und der Loggername wird genutzt, um das Verhalten des Loggers zu steuern (ob die logInfo() Befehle beachtet werden oder nicht) rules ist kein guter Loggername (und der erste Teil des vollständigen Loggernamens ist ohnehin fix und verweist auf scripts)
Außerdem beherrscht logInfo Substitution, jedes Klammerpaar {} wird durch den Inhalt der nachfolgenden Variablen ersetzt (das ist wichtig, weil die Substitution auch Typumwandlung beherrscht, im Gegensatz zum verknüpfen von Strings (und im Gegensatz zum Schreiben in das Item braucht es hier zwingend das .toString, nur ist openHAB hier sehr gnädig und setzt .toString automatisch.
Wie gesagt, beim .postUpdate() (und auch bei .sendCommand()) braucht es kein .toString.
Es kann allerdings gut sein, dass die Umwandlung der Units Probleme macht, je nachdem, ob die Persistence die Unit mit ausliefert oder nicht. Im Zweifel kannst Du die Unit so loswerden:

Code: Alles auswählen

        var mittelwert = (Fronius_Symo_Inverter_AC_Power.averageSince(now.minusMinutes(15)) as Number).floatValue

udo1toni hat geschrieben: ↑5. Dez 2023 23:01
Definitiv nicht von dem einen Item und wenn Du das offizielle Image für den Pi verwendest (openHABian), dann sollte ZRAM aktiv sein, welches sämtliche Schreibzugriffe ohnehin ins RAM umleitet - eben um vorzeitiges Wearout der SD-Karte zu verhindern.

... vielen Dank für die ausführliche Antwort!
Endlich ein Wert!

- mit der Zusatzinfo hat es letztendlich funktioniert. Danke dafür!

Zu deiner Anmerkung "nicht von dem einen Item", da bin ich mir nicht sicher ob das stimmt.
Warum auch immer, aber seit herstellen der rrd4j Datei wird mir bei jedem Item, das ich im System habe, die Analysefunktion gezeigt.
Jetzt kann ich mir von jedem Item über Tage zurück die Ist Daten anzeigen lassen, darum meine bedenken.

Und ja, ich habe gestern upgedatet auf 4.0.4 - ich nutze normalerweise die ZRAM Funktion.
Muss ich mir Gedanken machen, wegen der vielen Daten, die jetzt als Analysefunktion zur Verfügung stehen, oder kann ich das dankend ignorieren?

Nochmal DANKE! Schönen Tag!
LG Rene

RR727 hat geschrieben: ↑6. Dez 2023 09:33 Warum auch immer, aber seit herstellen der rrd4j Datei wird mir bei jedem Item, das ich im System habe, die Analysefunktion gezeigt.
Jetzt kann ich mir von jedem Item über Tage zurück die Ist Daten anzeigen lassen, darum meine bedenken.

Dann muss da was gehörig schief gelaufen sein. Default Verhalten seit openHAB3 ist, dass rrd4j direkt installiert ist, ohne dass der Anwender dies ausgelöst hätte. Weiterhin wird jedes Item automatisch mit everyMinute, everyChange über rrd4j persistiert, solange man das über die rrd4j.persist nicht einschränkt.
Nun hast Du oben genau das getan, was also das genaue Gegenteil dessen bewirken sollte, was Du jetzt berichtest. Eventuell hattest Du bereits eine rrd4j.persist (mit ungünstigem Inhalt) und hast diese Datei nun mit einer Version überschrieben, die openHAB nicht lesen kann - das wäre das einzige Szenario, welches das von Dir beschriebene verhalten auslösen könnte - es sei denn, es gibt noch andere Probleme im System.

RR727 hat geschrieben: ↑6. Dez 2023 09:33 Muss ich mir Gedanken machen, wegen der vielen Daten, die jetzt als Analysefunktion zur Verfügung stehen, oder kann ich das dankend ignorieren?

Wenn Du nicht gerade tausende Items hast, sollte es keine Probleme geben. rrd4j hat fixe Dateigrößen, ZRAM verhindert Schreibzugriffe auf die SD-Karte.

openhabforum.de

Regel für Schalter mit Timerfunktion

Regel für Schalter mit Timerfunktion

Re: Regel für Schalter mit Timerfunktion

Re: Regel für Schalter mit Timerfunktion

Re: Regel für Schalter mit Timerfunktion

Re: Regel für Schalter mit Timerfunktion

Re: Regel für Schalter mit Timerfunktion

Re: Regel für Schalter mit Timerfunktion

Re: Regel für Schalter mit Timerfunktion

Re: Regel für Schalter mit Timerfunktion

Re: Regel für Schalter mit Timerfunktion