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

[udo1toni]

Wie gesagt, a) Deine Rule ist zu kompliziert Es reicht, einfach den aktuellen Wert von Verbrauch in Dein Summen-Item zu kopieren. Das ist auch per Blockly nur ein einzelner Block. b) Wenn die DAten nicht dargestellt weredn, besteht ein Problem mit der Persistence. Mehr kann ich dazu nicht sagen, da ich die genaue Konfiguration Deines Systems ja nicht kenne.

[starbright]

Naja, ich hab mich mit Blockly versucht. Deinen Einzeiler möchte ich mal sehen.

Man könnte meinen eine "send command value to item" funktioniert, wenn man value durch "123" und item durch "test" ersetzt -
jedenfalls nicht wenn ich test als item number:power angelegt hab.

würde man jetzt den Wert eines Items kopieren wollen muss man machen:
"send command" "get state of " "item x" to "item test" und nicht
"send command" "item x" to "item test" und nicht

Wenn man dann den 1+1 Operator nimmt, dann kann man zwar
"<send command< >"123"+"123"> to <item"test"> geht wiederum, da landen dann "246 W" in item test.
Wenn man jetzt aber eine 123 durch item"x" ersetzt - bleibt die 246 in test stehen.
Man kann aber nicht "123" durch "get state of item x" ersetzen, das get state dockt nicht an eine "1" im "1+1" Operator!!!

Deswegen hab ich mit diesen Variablen angefangen. Ist das ein Bug oder hab ich das Konzept wieder nicht kapiert.

Als pures script sollte man meinen geht:

Code: Alles auswählen

events.sendCommand('test', (itemRegistry.getItem('sm_consumption').getState() + itemRegistry.getItem('sm_consumption').getState())

[udo1toni]

Wir kamen von der Situation, dass Du ein Group Item hast, welches die Aggregatfunktion SUM nutzt. Dieses Group Item enthält also die gewünschte Summe.
In der Sitemap wird im Chart aber nicht der Inhalt des Group Items als Kurve ausgegeben. Stattdessen siehst Du einzelne Kurven für jeden Member der Group. Du möchtest aber gerne die Kurve für die Summe sehen.
Also muss die Summe in ein eigenes Item kopiert werden.
Rules DSL:

Code: Alles auswählen

rule "Group Item nach Item"
when
    Item MyGroupItem changed
then
    MyProxyItem.postUpdate(MyGroupItem.state)
end

Jedes Mal, wenn sich der Status des Group Items ändert, wird die Rule getriggert und überträgt den Status in das Item MyProxyItem. Unter der Voraussetzung, dass die Itemtypen passen, wird das so funktionieren.
Als Rule, die in der UI angelegt wurde (mit DSL Code):

Code: Alles auswählen

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: MyGroupItem
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/vnd.openhab.dsl.rule
      script: MyProxyItem.postUpdate(MyGroupItem.state)
    type: script.ScriptAction

In Blockly:

Code: Alles auswählen

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: MyGroupItem
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      blockSource: <xml xmlns="https://developers.google.com/blockly/xml"><block
        type="oh_event" id="~~P;,th~/Uh}L[?Ov:x)" x="226" y="259"><field
        name="eventType">postUpdate</field><value name="value"><shadow
        type="text" id="S?vo(xCQdsFnFD|:v0YS"><field
        name="TEXT">value</field></shadow><block type="oh_getitem_state"
        id="m%}Pb0usD$eyRGDssu/n"><value name="itemName"><shadow type="oh_item"
        id="nR@|.9;m]cD;:RLY.j_S"><field
        name="itemName">MyGroupItem</field></shadow></value></block></value><value
        name="itemName"><shadow type="oh_item" id="!r}rErJcvfFi#$I]*FqL"><field
        name="itemName">MyProxyItem</field></shadow></value></block></xml>
      type: application/javascript
      script: |
        events.postUpdate('MyProxyItem', itemRegistry.getItem('MyGroupItem').getState());
    type: script.ScriptAction

Der obere Teil ist letztlich nur die Darstellung der Blocks, die eine Zeile nach script: | ist das eigentliche Script.

Eine Zeile.

Wenn Du nur ein Group Item hast, welches keine Aggregatfunktino hat, sondern lediglich die Items gruppiert, welche summiert werden müssen, ist der Code nur wenig länger. Auch hier geht das über Blockly. Die einfache Variante (ich zeige hier nur die Scriptzeilen, wenn man sich die Rule zusammenklickt...):

Code: Alles auswählen

      script: >
        var MySum;
        MySum = Java.from(itemRegistry.getItem('MyGroupItem').members).reduce(function(x, y) {return x + y;});
        events.postUpdate('MyProxyItem', MySum);
    type: script.ScriptAction

Oder auf klassische Weite als DSL Rule:

Code: Alles auswählen

rule "Group Item nach Item"
when
    Member of MyGroupItem changed
then
    var MySum = 0.0
    MyGroupItem.members.forEach[i|
        MySum += (i.state as Number).floatValue
    ]
    MyProxyItem.postUpdate(MySum)
end

Dies ist eine andere Funktion als oben, das mit reduce geht auch über die DSL, ich iteriere hier halt über die Gruppenitems.
Weil hier die Variable gebraucht wird, nimmt der Code etwas mehr Platz ein, aber allzu komplex ist er noch nicht

[starbright]

Danke für die ausführliche Antwort.
Gibt ja viele Möglichkeiten das zu machen Nun ja, da die Gruppe es für mich nicht gebracht hat (für Sitemap) bin ich davon abgekommen. Sonst brauch ich für die gleiche Sache ja gleich zwei Items und dann werden auch zwei Datenbanken erzeugt.
Also:
Bei Füllen eines Items mit einer Regel habe ich kein Group-Item erstellt, sondern eine "normales". Denn es soll ja auch vom Typ number.power sein.
Das ist doch aber auch korrekt, oder?
Sonst hatte das Grouped Item ja keine Einheit. Also so verstehe ich das.

Hast du meinen letzten Post mal angesehen? Also das man den math: 1+1 Operator nicht nutzen kann ist doch schräg. Den Item direkt kann man anklemmen, aber er rechnet nicht damit - nimmt man get-state-of-item bekommt man zwar den richigen Wert, kann aber nicht an den 1+1 Operator andocken. Deswegen musste ich über Variablen gehen.

[udo1toni]

Ich arbeite halt nicht mit Blockly, ich bin es gewohnt, Code hinzuschreiben. Das Blöcke Schubsen ist für mich immer ein Stück weit Rätsel Raten.

Was die "Datenbanken" betrifft: Default erzeugt openHAB3 für jedes Item eine rrd-Datei. Allerdings kann rrd4j gar nicht mit allen Itemtypen umgehen, andererseits sind die Dateien nicht so wahnsinnig groß (also für 2023er Verhältnisse).
Legt man eine externe Datenbank an, so wird für jedes Item eine Tabelle angelegt. Will man bestimmte Items nicht persistieren lassen, so muss man eine passende *.persist Datei für den Service anlegen, also z.B. rrd4j.persist für die rrd4j Persistence. Dort kann man genau defnieren, welche Items persistiert werden sollen. Wichtig ist aber, dass rrd4j mindestens einen Wert pro Minute persistieren muss, weshalb für diese Persistence eine minütliche Time cron Strategy zwingend gesetzt werden muss. Da rrd eine statische Dateigröße hat, die sich niemals ändert, hat das Speichern ohne Wertänderung aber keinen negativen Effekt.

Was die Group zum summieren betrifft: Du kannst selbstverständlich machen, was Du willst und solange es sich nur um zwei Items handelt wird es auch keine Rolle spielen, ob ich ein Group Item zum Rechnen verwende oder in einer Rule beide Status auslese und addiere.
Aber stelle Dir bitte mal vor, Du hast im eine Doppelhaushälfte und dort in jedem Zimmer einen Temperatursenor. Du möchtest nun zusätzlich zu allen Raumtemperaturen auch noch die hausweite Durchschnittstemperatur wissen. Da die Haushälfte über zehn Räume verfügt, musst Du zehn Items innerhalb der Rule benennen, um sie miteinander zu addieren. Außerdem musst Du die Items von Hand zählen und durch die Anzahl teilen.
Und nun kaufst Du andere Hälfte auch noch und hast plötzlich 20 Räume (Junge, Du scheinst Geld zu haben... ) Und jetzt musst Du Deine Rule anpassen und um weitere zehn Items ergänzen. Außerdem musst Du den Divisor anpassen.
Meine Zeilen dazu:

Code: Alles auswählen

var nTemp = 0
gTemp.members.forEach[i|nTemp += (i.state as Number).floatValue]
Durchschnitt.postUpdate(nTemp/gTemp.members.size)

Es ist egal, wieviele Räume das Haus hat, zwei, zwanzig, fünfhundert... allenfalls braucht die Rule bei fünfhundert Räumen zwei Sekunden länger, als bei zwei Räumen.

Natürlich ist das Beispiel mit der Durchschnittstemperatur sehr konstruiert (also der Teil mit der Änderung der Anzahl der Items innerhalb der Gruppe), bei WLAN Steckdosen und dem gemessenen Stromverbrauch pro Steckdose sieht das aber schon anders aus, vielleicht kauft man da nach und nach immer mal wieder ein weiteres Gerät dazu. Über Gruppe und Rule legt man lediglich jeweils ein Item für die neue Steckdose an (vielleicht gar halbautomatisch mittels Autodiscovery) und packt es in die Gruppe, der Rest bleibt gleich.

[starbright]

Code schreiben finde ich eigentlich auch besser. Dazu braucht man aber immer irgendein Beispiel - das hab ich ja jetzt.
Inzwischen hab ich mein Nahziel erreicht - und daran habt ihr im Forum und du insbesondere einen großen Anteil. Danke!

[starbright]

Mein WR ist kaputt, neuer (gebrauchter) musste her - leider ist das WEB-IF da anders. Doppel -
also mit curl 'http://192.168.3.241/measurements.xml' --output test bekomme ich diese Daten (siehe unten). Das entspricht etwa dem vorigen

Wie bekomme ich da die "221.3" (AC Power in Watt) raus? Mit regexp stehe ich echt auf Kriegsfuß - kleine Sachen bekomme ich manchmal hin, aber hier??? Oder gibts für xml Extraktion was einfacheres?

Code: Alles auswählen

<?xml version='1.0' encoding='UTF-8'?><root><Device Name='StecaGrid 3600' Type='Inverter' Platform='Net11' HmiPlatform='HMI13' NominalPower='3600' UserPowerLimit='nan' CountryPowerLimit='nan' Serial='xxxxxx' OEMSerial='' BusAddress='1' NetBiosName='INV005197180009' WebPortal='Steca sunCloud' ManufacturerURL='www.steca.com' IpAddress='192.168.3.241' DateTime='2024-11-30T14:02:31' ><Measurements><Measurement Value='237.1' Unit='V' Type='AC_Voltage'/><Measurement Value='1.008' Unit='A' Type='AC_Current'/><Measurement Value='221.3' Unit='W' Type='AC_Power'/><Measurement Value='50.049' Unit='Hz' Type='AC_Frequency'/><Measurement Value='471.9' Unit='V' Type='DC_Voltage'/><Measurement Value='0.468' Unit='A' Type='DC_Current'/><Measurement Value='30.2' Unit='°C' Type='Temp'/><Measurement Unit='V' Type='LINK_Voltage'/><Measurement Unit='W' Type='GridPower'/><Measurement Unit='W' Type='GridConsumedPower'/><Measurement Unit='W' Type='GridInjectedPower'/><Measurement Unit='W' Type='OwnConsumedPower'/><Measurement Value='100.0' Unit='%' Type='Derating'/></Measurements></Device></root>

[Harka]

Moin,
schau mal hier https://community.openhab.org/t/solved- ... er/91370/8

[starbright]

Der Einstieg fehlte mir noch - hab es aber jetzt (etwas anders) hinbekommen:
Ich hab ein Thing mit einem html-bindung, die Basis-URL ist: http://192.168.3.241/measurements.xml
Dann lege ich einen Channel an, einen String channel (AC_Power).
Dann lege ich einen Link an, Create a new Item - und da kann man ein XPATH Profile anlegen. Da steht dann XPATH:

Code: Alles auswählen

string(//Measurement[@Type='AC_Voltage']/@Value)

Soweit so gut, aber wenn wie im Beispiel keine Zahl drin ist, kommt auch keine "0.0" raus. Mit "" kann man nicht rechnen.

Wenn ich statt string number wähle wird es nicht besser, dann kommt NaN raus....

Edit:
Nach vielem probieren gelöst mit:

Code: Alles auswählen

concat(string(//Measurement[@Type='AC_Voltage']/@Value),"0")

Ist ein bisschen dirty, denn wenn kein Dezimalpunkt vorkäme, hatte ich statt 1W plötzlich 10. Wenn es jemand besser hinbekommt, gerne Feedback.

[Harka]

Moin,
mit gefällt folgende Lösung mit einem Channel vom Typ Number recht gut ->

Code: Alles auswählen

  - id: aatestxml4
    channelTypeUID: http:number
    label: aatest_AC_Voltage
    configuration:
      mode: READONLY
      stateTransformation: XPATH://Measurement[@Type='AC_Voltage']/@Value∩JS:|input == '' ? 0 :
          parseFloat(input);