Binding für Gerät mit Webserver (Steca-Wechselrichter)

[starbright]

ok, dachte "labelValueId" enthält den Jahreswert mit formatierten 2865 kWh.

Macht er ja auch, aber nur den des aktuellen Jahres.Bis 31.12. geht das so, dann vermutlich wieder bei 0.
Wie gesagt, es gibt ein json, da steht die GesamtLeistung drin, aber nur in MWh.

Data scheint ja Teil eines größeren JSON zu sein. Das sollte sich gut auslesen und mit einer Schleife aufaddieren lassen.

Ich hab keine Ahnung wie das gehen kann.

[udo1toni]

Harka hat geschrieben: ↑Gestern 18:25

Data scheint ja Teil eines größeren JSON zu sein. Das sollte sich gut auslesen und mit einer Schleife aufaddieren lassen.

Ich hab keine Ahnung wie das gehen kann.

Direkt über einen Channel geht es nicht. Du kannst aber das komplette JSON als String Channel weiterreichen und innerhalb einer Rule auswerten. Dort könnte man dann das Wertearray in eine Liste überführen und diese Liste anschließend aufaddieren. Man benötigt dazu also eine Rule.

[Harka]

Weil ich nicht die ganze chart.js kenne habe mal was auf Basis der hier vorhandenen Infos mit Unterstützung von Blockly gebastelt. Dies schnappt sich die den Text zwischen "data": [...] und liefert die Summe zurück.

Code: Alles auswählen

JS:| var i; var oData = input.split('"data": [').slice(-1)[0].split(']')[0]; var iSumme = 0; var i_list = oData.split(','); for (var i_index in i_list) { i = i_list[i_index];iSumme = iSumme + parseFloat(i);}iSumme;

Fehlt noch eine Fehlerabsicherung und selbst würde ich auch eher 1mal am Tag eine Rule laufen lassen.

[starbright]

Ok, ich hab jetzt dem Wechselrichter einen weiteren Channel hinzugefügt, diesmal einen String channel. Das funktioniert soweit, der Link zeigt das json an.
Dann habe ich eine Item Solar_Total_Rule (number:energy) erzeugt und eine Rule die ihn beschreiben soll

Code: Alles auswählen

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: Solar_Total_String
    type: core.ItemStateUpdateTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/javascript
      script: |
        var i; 
        var oData = input.split('"data": [').slice(-1)[0].split(']')[0];
        var iSumme = 0;
        var i_list = oData.split(',');
        for (var i_index in i_list) { 
          i = i_list[i_index];
          iSumme = iSumme + parseFloat(i);
        };
        iSumme= 10;
        events.sendCommand('Solar_Total_Rule', iSumme);
    type: script.ScriptAction

Die Rule wird getriggert, dass kann ich sehen. Aber das Item Solar_Total_Rule bleibt bei NULL. Hab ich den das Script da richtig eingefügt. Ich hab mich an dem von Harka orientiert und an einem was bei mir schon läuft...
Zum Debuggen hab ich die iSumme mal festgetackert für den Fall das parsen klappt nicht. Aber schon da klemmts.

[Harka]

jup, da kommt ein wenig durcheinander.
input ist ein Transformations-"Ding", wofür mein Lösungsvorschlag ja gedacht war. In einer Rule brauchst Du event.itemState und kannst z.B. mit der Zeile am Anfang das nachreichen

Code: Alles auswählen

var input = event.itemState.toString();

events.sendCommand('item', wert) ist glaube ein eine andere Sprache (DSL ?). In Javascript wäre der Weg

Code: Alles auswählen

items.getItem('Solar_Total_Rule').sendCommand(iSumme);

[starbright]

Ein Problem war der Trigger der Rule. Das "events.sendCommand('Solar_Total_Rule', iSumme);" funktionierte an sich. Also die Zahl die in iSumme steht kommt ins Item. Aber die Berechnung ist falsch - zumindest kommt eine Zahl raus die ich nicht nachvollziehen kann. Nicht ganz klar ist mir, wo der Input her kommt, als der String der geparst wird. Wo steht denn das der aus dem "Solar_Total_String" kommt?

In einem anderen Script das ich nutze, kommt der Input so:
A = itemRegistry.getItem('Wechselrichter_Solar_Total').getState();
Aber mit dem langen String geht es nicht so scheinbar.

Aber wenn du sagt dein String ist für eine Transformation - ich bestehe nicht auf einer Rule. Und tatsächlich tut dein Einzeiler
Ich wiederhole das mal (für mich und vielleicht andere):
Zum http Binding thing mit einer URL einen Number Channel anlegen. Der bekommt dann deine Status-Transformation Zeile.
Dann noch über Advanced die Status-URL-Erweitung (gen.yield.year.chart.js) einfügen. Dann einen Link vom Typ Number:Energy erzeugen. Fertig. Ganz lieben Dank - das hätte ich nie hinbekommen.

[Harka]

Moin,
schön das es funktioniert.
Bei itemRegistry.getItem hat es gerade Klick gemacht. Du nutzt das alte JavaScript(Nashorn) wo von ich Dir eher abraten würde. Wird nicht weiterentwickelt, der Code ist Bä und es war für mich einer der Gründe ins Blockly-Lager zu wechseln. Bastele damit bitte keine neuen Regeln. Solange das Binding weiter existiert kannst Du die bestehenden aber weiter nutzen.
Das neue JavaScript(ECMAScript 2022+) ist besser an openHAB angepasst und gut dokumentiert. Da beides parallel laufen kann funktioniert die Transformation dennoch.

[starbright]

Danke für den Hinweis. Ich hänge wegen schwacher Hardware noch an openHAB 3.4. Weiß nicht ob das auch zu beachten ist.
Jetzt kann ich mit dem Zähler (Einspeisen/Bezug) und Wechselrichter wieder den aktuellen Verbrauch ausrechnen, mach ich mit einer Rule: Verbrauch = Bezug + Solar - Einspeisung +/- Offset:

Code: Alles auswählen

        var A, B, C, D, E;
        A = itemRegistry.getItem('sm_cnt_purchase').getState();
        B = itemRegistry.getItem('Wechselrichter_Solar_Years').getState();
        C = itemRegistry.getItem('sm_cnt_deliver').getState();
        D = A + B - C + 4051.203; 
        E = D.toFixed(3);
        events.sendCommand('sm_calc_consumption_total', E);

Wie stelle ich es an, dass der Offset (derzeit fix codiert) entweder zum Tages- oder Monats-Wechsel neu gesetzt wird, so dass der D=Verbrauch zu diesem Zeitpunkt "0" wird?
Dann hat man Counter der den aktuellen Tages- bzw Monatsverbrauch anzeigt. Aber wie kann ich den Offset bestimmen?
Kann man einer Rule mehrer Trigger geben Zum Beispiel einen der um 0:00 zuschlägt) und davon unterschiedliche Aktionen ableiten und die Variable gehalten werden? Oder wie kann man das tun?

[Harka]

Danke für den Hinweis. Ich hänge wegen schwacher Hardware noch an openHAB 3.4. Weiß nicht ob das auch zu beachten ist.

Das Updaten wird durch Abwarten auch nicht einfacher und meiner Erinnerung nach sind die Anforderungen mit OH4 nicht nennenswert gestiegen. Nur das Backup vorher nicht vergessen! openHAB ist noch um einiges benutzerfreundlicher geworden.

Wie stelle ich es an, dass der Offset (derzeit fix codiert) entweder zum Tages- oder Monats-Wechsel neu gesetzt wird, so dass der D=Verbrauch zu diesem Zeitpunkt "0" wird?
Dann hat man Counter der den aktuellen Tages- bzw Monatsverbrauch anzeigt. Aber wie kann ich den Offset bestimmen?

Muss gestehen, dass ich bei der Aufgabe Deiner Rule gerade auf dem Schlauch stehe (langer Tag). Du kannst aber Werte mittels Rule z.b. in einem manuell angelegtem Item (Add Point) oder in Custom-Metadaten abspeichern. Was Dir hier möglicherweise auch weiterhilf ist die Persistence. OH speichert standartmäßig alle Werte minütlich in einer rrd4j-Datenbank

Kann man einer Rule mehrer Trigger geben Zum Beispiel einen der um 0:00 zuschlägt) und davon unterschiedliche Aktionen ableiten und die Variable gehalten werden? Oder wie kann man das tun?

Ja, mehrere Trigger sind möglich und in in der Rule mit if-then auswertbar. Der Sinn hängt von der Aufgabe ab.

[udo1toni]

Wie stelle ich es an, dass der Offset (derzeit fix codiert) entweder zum Tages- oder Monats-Wechsel neu gesetzt wird, so dass der D=Verbrauch zu diesem Zeitpunkt "0" wird?

Was genau rechnest Du denn aus? Welche Werte stehen genau zur Verfügung?
Konkret (auch, weil ich auf den sieben Seiten die Infos nicht zusammenkratzen möchte):
Welcher Wert ist im Item Wechselrichter_Solar_Years hinterlegt, welcher Wert in sm_cnt_purchase, welcher Wert in sm_cnt_deliver, was bedeutet die 4051.203 (woraus ergibt sich dieser Offset)?
Wenn ich es richtig interpretiere, sind sm_cnt_deliver und sm_cnt_purchase jeweils die Zähler für die beiden Richtungen, aber über welchen Zeitraum wird hier gezählt? Wenn diese Zähler "zwischendurch" zurückgesetzt werden, dann ergäbe sich daraus vermutlich eine Verschiebung, wegen der dann der Offset nötig wäre.
Sinnvoll sind immer Gesamtzählerstände, also ein Total_In und eine Total_Out, die beide (streng) monoton wachsend sind. Beide Zählerstände werden persistiert. Dann kann man - auch nachträglich - jederzeit die Differenz zwischen zwei Zeitpunkten bestimmen und damit die erbrachte bzw. genutzte Arbeit, und aus den beiden Differenzen kann auch das jeweilige Saldo für den betrachteten Zeitraum bestimmt werden.

Wenn solche Zähler im Wechselrichter nicht vorhanden sind, musst Du diese in openHAB nachbilden. Dazu gab es auch schon entsprechende Ansätze, der Form "Messwert aktuell größer als Messwert alt -> Differenz auf den Zählerstand aufaddieren. Messwert aktuell kleiner als Messwert alt -> Zähler wurde genullt, also Messwert aktuell auf den Zählerstand aufaddieren" Der aktuelle Zählerstand wird persistiert und mit restoreOnStartup automatisch nachgeladen. Die Messwerte werden ebenfalls persistiert, aber nach dem aufsummieren auf den virtuellen Zähler nicht mehr zur Berechnung herangezogen. Stattdessen werden nur noch die errechneten Gesamtzählerstände verwendet.