openhabforum.de

Hallo zusammen,

nachdem ich nun den Regler meiner Gasheizungsanlange per BSB-LAN und MQTT auslesen kann, bin ich auf ein Konfigurationsproblem gestoßen: Ich möchte einen Wert vor dem Persistieren umrechnen!

Der Wert wird wie folgt im JSON-Format an den MQTT Broker geliefert:
{
"BSB-LAN":{
"device":0,
"parameter":8380,
"name":"Gesamte Gasenergie für Heizen und Trinkwasser",
"value":"963548",
"desc":"",
"unit":"kWh",
"error":0
}
}
Es geht hier um den Wert "963548".

Bei der Konfiguration des Channels in openHAB habe ich folgendes gemacht:
MQTT State Topic
BSB-LAN/0/35/8380/status

Unit Of Measurement
<leer>

Incoming Value Transformations
JSONPATH:$.BSB-LAN.value

Outgoing Value Format
%s

Über das im weitern Verlauf verlinkte Item wird "963548" persistiert. Dieser Wert entspricht jedoch nicht, wie lt. JSON-String zu vermuten wäre, einem Wert in "kWh". Es ist irgendeine andere Einheit oder anders zu interpretieren.
Nach ein paar Messreihen habe ich nun einen Faktor gefunden, mit dem ich diesen Wert multiplizieren kann, um dauraus den gewünschten kWh-Wert zu erhalten. Dieser entspricht dann annähernd dem, was ich vom Gaszähler ablesen und mit dem Umrechnungsfaktor des Gaslieferanten errechnen kann.
Was muss ich jetzt tun, um meinen empirisch ermittelten Wert auf "963548" anzuwenden?

Danke für die Hilfe im Voraus!

Moin,
Du kannst gleich noch eine weitere Transformation hinzufügen, welche die Umrechnung vornimmt. Beispiel Javascript (installiert?) oder DSL Diese fügst Du als zusätzliche Zeile ein oder hängst sie mit dem ∩ an Die 100 natürlich durch Deinen Faktor ersetzen.

Es gibt mehrere weitere Möglichkeiten ...

Vielen Dank für Deine Antwort!

Leider ist meine Lernukurve noch sehr steil, und ich komme da noch nicht ganz mit, weil das etwas völlig Neues für mich ist. Ich brauche also noch etwas Unterstützung:
1. Ich habe die Automation Java Scripting installiert. Passt das?
2. Was müsste ich für DSL installieren?
3. Egal, was ich dann von beiden nehme, wird OH am JS: bzw. DSL: erkennen, was zu tun ist und den eigenlichen Befehl z.B. JS:|parseFloat(input)*100 ausführen!? Ich muss also keine Datei oder sowas anlegen?
4. Das Zeichen '∩' habe ich heute schon mal gesehen! Wo finde ich das auf der Tastatur?
5. '100' ist klar aber 'input'? Ist das ein Standard, den man wissen muss? Ist das irgendwo zum Nachlesen Dokumentiert?

Ich antworte mal stellvertretend...

1. Wenn Du JavaScript Scripting nutzen willst, ja.
2. Gar nichts. Noch ist die DSL Teil des openHAB Core, weil die DSL die erste Automationssprache in openHAB war.
   Irgendwann wird die DSL nicht mehr Bestandteil des Core sein und genau wie alle anderen Automations-Addons unter den Automation Bindings gelistet werden.
3. Korrekt. Es ist so, dass Du wahlweise ein Script in einer Datei anlegen, oder den Code inline ausführen lassen kannst. Bei so einer simplen Umrechnung ist inline sicherlich sinnvoll. An anderer Stelle kann das Script aber auch komplexer werden, oder Du brauchst den identischen Code an verschiedenen Stellen (egal ob nun in einem Channel, im Link zwischen Channel und Item oder auch einer Rule), dann ist es eventuell sinnvoller, den Code in einer separaten Datei zu speichern. openHAB unterstützt beides.
4. Das Zeichen ∩ befindet sich gar nicht auf der Tastatur Du kannst es aus dem Hilfstext unterhalb des Eingabefeldes für die Transformation kopieren, oder alternativ auch über die Zeichentabelle von Windows. Aber Achtung!, Es gibt mehrere Symbole, die sich auf den ersten Blick sehr ähneln. Das genutzte Zeichen ist in der deutschen Version der Zeichentabelle leider falsch beschriftet als "Durchschnitt" (Unicode 2229), tatsächlich handelt es sich um das mathematische Symbol für "Schnittmenge" (engl. "Intersection").
5. Die Zeile beschreibt ja ein Script. Es handelt sich dabei um "beliebig komplexe" Scripte, entsprechend braucht man eine Variable, welche für den Übergabewert steht, diese Variable heißt input.
   Streng genommen würde man das Ergebnis auch in eine Variable speichern, aber das kostet am Ende nur viel zusätzlichen Platz, entsprechend betrachtet man die Codezeile als Term, der ein Ergebnis hat, und dieses Ergebnis wird direkt als Output verwendet.

Wichtig zu wissen: Die Transformations arbeiten ausschließlich mit Strings. Dabei wandelt openHAB Zahlen vor der Übergabe in die Transformation automatisch in Text um und umgekehrt (falls der Output eine Zahl sein muss). Innerhalb des Codes muss man sich aber selbst darum kümmern, aus dem String in der Variablen input den Zahlenwert zu gewinnen (hier mittels Float.parseFloat(input)). Am Ausgang wandelt die Transformation das Ergebnis auch wieder in einen String, darum muss man sich nicht selbst kümmern, weil die Kommunikation über ein Objekt läuft, und jedes Objekt in openHAB kennt die Methode .toString, welche die Konvertierung dann automatisch durchführt.
Tipp am Rande: Setze die Unit korrekt (wobei ich mir nicht sicher bin, ob die Unit vor oder nach der Transformation angehängt wird, könnte also sein, dass die Codezeile dann etwas komplexer wird). Sobald ein Item vom Typ Number:<QuantityType> ist, also z.B. Number:Energy, kann openHAB den beinhalteten Wert immer korrekt darstellen und Du musst lediglich angeben, welche Einheit verwendet werden soll, z.B. auch MWh (also Megawattstunden) oder Ws (Wattsekunden) bzw. J (Joule) oder meiner Erinnerung nach auch kcal. Bei der Verschiebung des Dezimalzeichens ist es ja einfach, aber z.B. ein Temperatursensor kann seine Messwerte auch in °F oder K liefern, openHAB kann den Wert dennoch in °C anzeigen, dazu braucht es keine Transformation.
Ganz verrückt wird es, wenn man mit Einheiten rechnet, auch das beherrscht openHAB, Du könntest also aus Spannung und Strom selbst die Leistung errechnen, aus Leistung mal Zeit die Energiemenge, aus der Energiemenge und dem Abnahmepreis den zu zahlenden Betrag (!!!) und das notfalls sogar mit aktuellem Währungskurs (könnte ja sein, dass Du ein Häuschen in England hast und wissen willst, wie viel Dich die Heizung im Monat kostet).
Die Units of Measurement sind inzwischen ein so fester Bestandteil von openHAB, dass es durchaus seltsame Anzeigen geben kann, wenn man diese Funktionen nicht nutzt.

Ergänzung:
die Frage nach der Dokumentation - https://www.openhab.org/docs/configurat ... tions.html
Datei anlegen geht auch -> unter Einstellungen-Transformations. Beispiel für Javascript mit dem Namen Multiply Das Rechnen mit Einheiten wird bei der Verwendung von Transformationen im Profil oder der State_description von Bedeutung. Dafür bin ich aber im Allgemeinen zu faul

Vielen, vielen Dank!
Ich habe alles soweit verstanden und umgesetzt. Der openHAB Log Viewer sagt jetzt Item 'MQTT_BSBLAN_Gasenergie' changed from 971343 kWh to 3593.52979376 kWh. Da ich nicht weiß, welche Grundlast ich in meinem Stromnetz habe, kann ich die Änderungen dieses Wertes nicht am Stromzähler überprüfen. Aber ca. 0,11 kWh pro Minute, was ich aus den MQTT-Werten ablesen kann, sind wohl passend.
Ich habe den Faktor übrigens per ∩-Zeichen direkt hinter JSONPATH:$.BSB-LAN.value platziert und sowohl im Channel als auch im Item `'kWh' als Einheit angegeben.
Noch eine abschließende Frage, wenn ich jetzt in der Ausgabe eine Nachkommastelle haben wollte: Wo müsste ich dann z.B. %.1f hinpacken? Ich habe es im Channel und dort bei Outgoing Value Format mit "%.1f" (mit und ohne Gänsefüßchen) versucht, aber das hat leider nicht funktioniert: Der Wert wird ohne Nachkommastelle gerundet angezeigt.

Die Anzeige rundest Du in dem Du dem Item über "ADD METADATA" eine stateDescription mit dem entsprechendem Pattern (z.B. %.1f %unit%) gibst. Im Prinzip kannst Du auch gleich in Transformation runden um das Protokoll etwas zu "verschönern" - das gilt aber als die schlechtere Lösung.
Ungetestet: Nur aus Neugier, wie hängt das zusammen:
Gasenergie <-> Grundlast Stromnetz

Vielen Dank für die schnelle Antwort! Der Tipp hat mal wieder auf Anhieb funktioniert!

Bei der Gelegenheit habe ich auch endlich die Zusammenhänge innerhalb eines Channels richtig(?) wahrgenommen und verstanden:
1. Im Thing auf den Channel und dann auf Configure Channel klicken, ermöglicht das, was man so denkt.
2. Im Thing auf den Channel, dann auf das dem Channel untergeordnete Element klicken, öffnet nicht das Item, sondern nur so eine Art Übersicht, in der ich eins von ggf. mehrern Profilen auswählen kann. Auch das werde ich dann versuchen zu verstehen, wenns erforderlich wird.
3. In dieser Überischt dann auf das Item klicken, führt ins Item selbst und ermöglicht die Änderung von z.B. Metadata, wo ich den o.g. Formatstirng eintragen konnte.
4. Wenn ich dort dann auf Edit klicke, kann ich noch mehr am Item ändern. Aber die Zweiteilung (3. und 4.) für Änderungen am Item habe ich (noch) nicht verstanden.

Das ist das, was einen am Anfang als Anfänger, oder wenn man nur sehr selten intensiv mit openHAB arbeitet, verwirrt - zumindest mich. Und wenn ich nach Dokumentation suche, suche ich eingendlich eine Schritt-für-Schritt-Anleitung, wie ich es hier mal versucht habe zu beschreiben. Möglichst noch mit Kommentaren, wozu das so ist, wie es ist; ich wills ja verstehen. Und dann noch mit Bildern ...

Nur aus Neugier, wie hängt das zusammen:
Gasenergie <-> Grundlast Stromnetz

Nun, die Gasenergie ist ja das, was die Gasheizung so an Gas verbraucht und abgerechnet wird. Darüberhinaus verbraucht die Gasheizung ja auch noch Strom ... ähhh .... Mist! Da habe ich wohl den Überblick verloren! Danke für den Schlag auf den Hinterkopf!

Ja, die Darstellung der Items ist etwas unglücklich (speziell für Neulinge).
Generell: Things stellen die eigentliche Schnittstelle zwischen physischer Welt und Software her. Jedes Thing hat eine oder auch mehrere Eigenschaften, z.B. bei einem Dimmer die Helligkeit.
Damit alle Geräte, die in openHAB verfügbar sind problemlos miteinander kommunizieren können, braucht es eine einheitliche Schnittstelle, das sind die Items.
Einfach gesagt repräsentiert ein Item einen Aspekt, z.B. die Helligkeit des Dimmers von weiter oben. An dieser Stelle ist es aber völlig egal, ob dieser Dimmer ein mqtt Gerät, Matter, zwave, knx oder ein beliebiges anderes System verwendet, das Item ist immer das gleiche bzw. gleichartige, also ein Dimmer Item. Dadurch wird openHAB interoperabel, so weitgehend, dass man einen defekten Dimmer eines Typs ohne Probleme durhc einen Dimmer eines anderen Typs ersetzen kann - solange die Ansteuerung über openHAB erfolgt, reicht es, den Link zwischen Thing (das ist dann ein neues...) und Item (das ist das alte) neu zu setzen, danach sollte sich der neue Dimmer genauso verhalten, wie der alte Dimmer.

Items hatten ursprünglich mal nur wenige Eigenschaften, Name, Label (auf Wunsch dynamisch), Icon und Gruppenzugehörigkeit sowie der Link auf den Label,
Inzwischen sind (sehr viele) zusätzliche Eigenschaften hinzugekommen, und die meisten davon sind in Untermenüs versteckt.
Dass einzelne Aspekte eines Items auch gleichzeitig mehrere Datensätze zu einem Thema enthalten kann, z.B. die Tags oder die Group Member, macht die Sache nicht einfacher.