Viessmann API mit OH3 auf RPi

Für welche Projekte verwendet Ihr OpenHAB? Was habt Ihr automatisiert? Stellt eure Projekte hier vor.

Moderatoren: Cyrelian, seppy

Antworten
chrisfetz
Beiträge: 16
Registriert: 12. Mär 2021 14:00

Re: Viessmann API mit OH3 auf RPi

Beitrag von chrisfetz »

Hallo!

Das habe ich versucht zu sagen aber scheinbar nicht klar ausgedrückt.
Das Lesen der Daten lief bei mir erstmal gut los aber die USB Schnittstelle ist scheinbar wieder ausgestiegen. Hatte noch keine Zeit zum schauen.

Viele Grüße,
Christoph

nw378
Beiträge: 199
Registriert: 22. Sep 2018 10:38
Answers: 4

Re: Viessmann API mit OH3 auf RPi

Beitrag von nw378 »

chrisfetz hat geschrieben: 23. Nov 2022 07:18 Hallo!

Das habe ich versucht zu sagen aber scheinbar nicht klar ausgedrückt.
Das Lesen der Daten lief bei mir erstmal gut los aber die USB Schnittstelle ist scheinbar wieder ausgestiegen. Hatte noch keine Zeit zum schauen.

Viele Grüße,
Christoph
Hast Du mehrere USB Geräte angeschlossen? Manchmal wird die USB Schnittstelle vertauscht. Dagegen hilft es, dem USB Port mit dem Optolink einen festen Namen zuzuweisen:


Mittels

Code: Alles auswählen

dmesg | grep ttyUSB
die angeschlossenen Geräte suchen,
mit

Code: Alles auswählen

udevadm info --name=/dev/ttyUSB0 --attribute-walk
die eindeutigen Attribute herausgepickt und diese mit

Code: Alles auswählen

sudo nano /etc/udev/rules.d/10-usb-serial.rules
"verankert", in meinem Fall ein Emlog Lesekopf für den Stromzähler und der Optolink für die Heizung:

Code: Alles auswählen

SUBSYSTEM=="tty", ATTRS{idProduct}=="6015", ATTRS{idVendor}=="0403", SYMLINK+="ttyUSB_emlog"
SUBSYSTEM=="tty", ATTRS{idProduct}=="ea60", ATTRS{idVendor}=="10c4", SYMLINK+="ttyUSB_vito"
openHAB 4.1.0 @ RPi 4 / SSD - InfluxDB2 und Grafana @ Synology Docker - KNX

chrisfetz
Beiträge: 16
Registriert: 12. Mär 2021 14:00

Re: Viessmann API mit OH3 auf RPi

Beitrag von chrisfetz »

Ah, falscher Verdacht: als ich noch mit vMon gespielt habe, hat sich der Adapter immer wieder mit einem Treiber-Fehler verabschiedet, ich hatte wieder das vermutet.
Eine udev-Regel gab es schon aber die war wohl nicht korrekt. Jetzt hab ich mal einen neuen Anlauf mit einer anderen Regel genommen.
Den Treier-Fehler hab ich nach dem Abschied von vMon jedenfalls nicht mehr gesehen. Keine Ahnung, ob das Zufall ist oder ein Fehler im vMon.

Viele Grüße,
Christoph

chrisfetz
Beiträge: 16
Registriert: 12. Mär 2021 14:00

Re: Viessmann API mit OH3 auf RPi

Beitrag von chrisfetz »

Servus,

hm, das mit udev sagt sich so einfach. Ich leide wohl an diesem Problem:
https://blog.oddbit.com/post/2022-02-13 ... dev-rules/

Ein bisschen merkwürdig ist noch:
mit dieser Regel:
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="vitoir0", GROUP="dialout"

Funktioniert es nach diesen Komandos:
sudo service udev restart
sudo udevadm trigger
immer erstmal korrekt.

Irgendwann später sieht /dev/vitoir0 dann so aus:
SmartAdmin@raspberrypi:~/openv/vcontrold $ ls -l /dev/vitoir0
lrwxrwxrwx 1 root root 15 29. Nov 21:47 /dev/vitoir0 -> bus/usb/001/120

und dann meldet vcontrold das:
[506827] Tue Nov 29 20:25:08 2022 : error tcgetattr /dev/vitoir0:Inappropriate ioctl for device
nach einem neuen
sudo udevadm trigger
passt wieder alles.

Der Vorschlag aus der Webseite oben gefällt mir nicht. Ich kannte es zuletzt noch von Apple, dass der ipod nur an einem einzigen USB-Anschluss funktioniert hat (und das ist immer mal wieder ein anderer), das kann doch heute nicht Stand der Technik sein?!

Code: Alles auswählen

SmartAdmin@raspberrypi:~ $ udevadm info --name=/dev/ttyUSB0 --attribute-walk

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0
/ttyUSB0/tty/ttyUSB0':
    KERNEL=="ttyUSB0"
    SUBSYSTEM=="tty"
    DRIVER==""
    ATTR{power/control}=="auto"
    ATTR{power/runtime_active_time}=="0"
    ATTR{power/runtime_status}=="unsupported"
    ATTR{power/runtime_suspended_time}=="0"

  looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-
1.3:1.0/ttyUSB0':
    KERNELS=="ttyUSB0"
    SUBSYSTEMS=="usb-serial"
    DRIVERS=="ch341-uart"
    ATTRS{port_number}=="0"
    ATTRS{power/control}=="auto"
    ATTRS{power/runtime_active_time}=="0"
    ATTRS{power/runtime_status}=="unsupported"
    ATTRS{power/runtime_suspended_time}=="0"
    
     looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-
1.3:1.0':
    KERNELS=="1-1.3:1.0"
    SUBSYSTEMS=="usb"
    DRIVERS=="ch341"
    ATTRS{authorized}=="1"
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{bInterfaceClass}=="ff"
    ATTRS{bInterfaceNumber}=="00"
    ATTRS{bInterfaceProtocol}=="02"
    ATTRS{bInterfaceSubClass}=="01"
    ATTRS{bNumEndpoints}=="03"
    ATTRS{supports_autosuspend}=="1"

  looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3':
    KERNELS=="1-1.3"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{authorized}=="1"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bDeviceClass}=="ff"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bMaxPacketSize0}=="8"
    ATTRS{bMaxPower}=="98mA"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bcdDevice}=="0262"
    ATTRS{bmAttributes}=="80"
    ATTRS{busnum}=="1"
    ATTRS{configuration}==""
    ATTRS{devnum}=="120"
    ATTRS{devpath}=="1.3"
    ATTRS{devspec}=="(null)"
    ATTRS{idProduct}=="7523"
    ATTRS{idVendor}=="1a86"
    ATTRS{ltm_capable}=="no"
    ATTRS{maxchild}=="0"
    ATTRS{power/active_duration}=="2622016"
    ATTRS{power/autosuspend}=="2"
    ATTRS{power/autosuspend_delay_ms}=="2000"
    ATTRS{power/connected_duration}=="2622012"
    ATTRS{power/control}=="on"
    ATTRS{power/level}=="on"
    ATTRS{power/persist}=="1"
    ATTRS{power/runtime_active_time}=="2621833"
    ATTRS{power/runtime_status}=="active"
    ATTRS{power/runtime_suspended_time}=="0"
    ATTRS{product}=="USB2.0-Serial"
    ATTRS{quirks}=="0x0"
 ATTRS{removable}=="removable"
    ATTRS{rx_lanes}=="1"
    ATTRS{speed}=="12"
    ATTRS{tx_lanes}=="1"
    ATTRS{urbnum}=="729"
    ATTRS{version}==" 1.10"

  looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1':
    KERNELS=="1-1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{authorized}=="1"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bDeviceClass}=="09"
    ATTRS{bDeviceProtocol}=="02"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{bMaxPower}=="2mA"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bcdDevice}=="0200"
    ATTRS{bmAttributes}=="e0"
    ATTRS{busnum}=="1"
    ATTRS{configuration}==""
    ATTRS{devnum}=="2"
    ATTRS{devpath}=="1"
    ATTRS{idProduct}=="9514"
    ATTRS{idVendor}=="0424"
    ATTRS{ltm_capable}=="no"
    ATTRS{maxchild}=="5"
    ATTRS{power/active_duration}=="1645182588"
    ATTRS{power/autosuspend}=="0"
    ATTRS{power/autosuspend_delay_ms}=="0"
    ATTRS{power/connected_duration}=="1645182588"
    ATTRS{power/control}=="auto"
    ATTRS{power/level}=="auto"
    ATTRS{power/runtime_active_time}=="1645182187"
    ATTRS{power/runtime_status}=="active"
    ATTRS{power/runtime_suspended_time}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{removable}=="unknown"
    ATTRS{rx_lanes}=="1"
    ATTRS{speed}=="480"
    ATTRS{tx_lanes}=="1"
    ATTRS{urbnum}=="1683"
    ATTRS{version}==" 2.00"

  looking at parent device '/devices/platform/soc/3f980000.usb/usb1':
    KERNELS=="usb1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{authorized}=="1"
    ATTRS{authorized_default}=="1"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bDeviceClass}=="09"
    ATTRS{bDeviceProtocol}=="01"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{bMaxPower}=="0mA"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bcdDevice}=="0515"
    ATTRS{bmAttributes}=="e0"
    ATTRS{busnum}=="1"
    ATTRS{configuration}==""
    ATTRS{devnum}=="1"
    ATTRS{devpath}=="0"
    ATTRS{idProduct}=="0002"
    ATTRS{idVendor}=="1d6b"
    ATTRS{interface_authorized_default}=="1"
    ATTRS{ltm_capable}=="no"
    ATTRS{manufacturer}=="Linux 5.15.76-v8+ dwc_otg_hcd"
    ATTRS{maxchild}=="1"
    ATTRS{power/active_duration}=="1645182728"
    ATTRS{power/autosuspend}=="0"
    ATTRS{power/autosuspend_delay_ms}=="0"
    ATTRS{power/connected_duration}=="1645182732"
    ATTRS{power/control}=="auto"
    ATTRS{power/level}=="auto"
    ATTRS{power/runtime_active_time}=="1645182729"
    ATTRS{power/runtime_status}=="active"
    ATTRS{power/runtime_suspended_time}=="0"
    ATTRS{product}=="DWC OTG Controller"
    ATTRS{quirks}=="0x0"
    ATTRS{removable}=="unknown"
    ATTRS{rx_lanes}=="1"
    ATTRS{serial}=="3f980000.usb"
    ATTRS{speed}=="480"
    ATTRS{tx_lanes}=="1"
    ATTRS{urbnum}=="25"
    ATTRS{version}==" 2.00"


  looking at parent device '/devices/platform/soc/3f980000.usb':
    KERNELS=="3f980000.usb"
    SUBSYSTEMS=="platform"
    DRIVERS=="dwc_otg"
    ATTRS{busconnected}=="Bus Connected = 0x1"
    ATTRS{buspower}=="Bus Power = 0x1"
    ATTRS{bussuspend}=="Bus Suspend = 0x0"
    ATTRS{devspeed}=="Device Speed = 0x0"
    ATTRS{driver_override}=="(null)"
    ATTRS{enumspeed}=="Device Enumeration Speed = 0x1"
    ATTRS{fr_interval}=="Frame Interval = 0x1d4b"
    ATTRS{ggpio}=="GGPIO = 0x00000000"
    ATTRS{gnptxfsiz}=="GNPTXFSIZ = 0x01000306"
    ATTRS{gotgctl}=="GOTGCTL = 0x001c0001"
    ATTRS{gpvndctl}=="GPVNDCTL = 0x00000000"
    ATTRS{grxfsiz}=="GRXFSIZ = 0x00000306"
    ATTRS{gsnpsid}=="GSNPSID = 0x4f54280a"
    ATTRS{guid}=="GUID = 0x2708a000"
    ATTRS{gusbcfg}=="GUSBCFG = 0x20001700"
    ATTRS{hcd_frrem}=="HCD Dump Frame Remaining"
    ATTRS{hcddump}=="HCD Dump"
    ATTRS{hnp}=="HstNegScs = 0x0"
    ATTRS{hnpcapable}=="HNPCapable = 0x1"
    ATTRS{hprt0}=="HPRT0 = 0x00001005"
    ATTRS{hptxfsiz}=="HPTXFSIZ = 0x02000406"
    ATTRS{hsic_connect}=="HSIC Connect = 0x1"
    ATTRS{inv_sel_hsic}=="Invert Select HSIC = 0x0"
    ATTRS{mode}=="Mode = 0x1"
    ATTRS{mode_ch_tim_en}=="Mode Change Ready Timer Enable = 0x0"
    ATTRS{power/control}=="auto"
    ATTRS{power/runtime_active_time}=="0"
    ATTRS{power/runtime_status}=="unsupported"
    ATTRS{power/runtime_suspended_time}=="0"
    ATTRS{rd_reg_test}=="Time to read GNPTXFSIZ reg 10000000 times: 832 msecs (208 jiffies)"
    ATTRS{regdump}=="Register Dump"
    ATTRS{regoffset}=="0xffffffff"
    ATTRS{regvalue}=="invalid offset"
    ATTRS{rem_wakeup_pwrdn}==""
    ATTRS{remote_wakeup}=="Remote Wakeup Sig = 0 Enabled = 0 LPM Remote Wakeup = 0"
    ATTRS{spramdump}=="SPRAM Dump"
    ATTRS{srp}=="SesReqScs = 0x1"
    ATTRS{srpcapable}=="SRPCapable = 0x1"
    ATTRS{wr_reg_test}=="Time to write GNPTXFSIZ reg 10000000 times: 312 msecs (78 jiffies)"


  looking at parent device '/devices/platform/soc':
    KERNELS=="soc"
    SUBSYSTEMS=="platform"
    DRIVERS=="simple-pm-bus"
    ATTRS{driver_override}=="(null)"
    ATTRS{power/control}=="auto"
    ATTRS{power/runtime_active_time}=="0"
    ATTRS{power/runtime_status}=="unsupported"
    ATTRS{power/runtime_suspended_time}=="0"

  looking at parent device '/devices/platform':
    KERNELS=="platform"
    SUBSYSTEMS==""
    DRIVERS==""
    ATTRS{power/control}=="auto"
    ATTRS{power/runtime_active_time}=="0"
    ATTRS{power/runtime_status}=="unsupported"
    ATTRS{power/runtime_suspended_time}=="0"
Ich bin in Linux nicht sehr tief bewandert, kann mir jemand aus dieser Info eine bessere Regel bauen oder sieht sonst jemand, wo der Fehler ist?

Viele Grüße,
Christoph

Benutzeravatar
udo1toni
Beiträge: 13858
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Viessmann API mit OH3 auf RPi

Beitrag von udo1toni »

Das klingt für mich danach, dass der Stick irgendwann selbst Blödsinn verzapft.

Oder ist vielleicht noch eine andere udev Rule aktiv, die da Unsinn macht?
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

chrisfetz
Beiträge: 16
Registriert: 12. Mär 2021 14:00

Re: Viessmann API mit OH3 auf RPi

Beitrag von chrisfetz »

Servus,

naja, anfangs habe ich mit vMon gearbeitet, da sah es im dmesg so aus:

Code: Alles auswählen

$ dmesg | grep ttyUSB
[ 9.071670] usb 1-1.5: ch341-uart converter now attached to ttyUSB0
[ 1731.307724] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[ 1731.307861] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[ 1731.562677] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[ 1731.900063] usb 1-1.5: ch341-uart converter now attached to ttyUSB1
[ 2251.503555] ch341-uart ttyUSB1: ch341-uart converter now disconnected from ttyUSB1
[ 2251.843223] usb 1-1.5: ch341-uart converter now attached to ttyUSB1
Die Fehler "urb stopped" habe ich aber nie mehr gesehen, seit ich auf vclient umgestiegen bin und genau genommen springt seitdem das tty auch nicht mehr, scheint fix auf tty0 zu stehen. Guter Hinweis, dann lasse ich die udev-Geschichte mal und setze mich auf ttyUSB0, mal weiter beobachten.

Andere Frage, wo ich noch kurz einen Hinweis brauche:
auf welchem Weg bekomem ich denn aus dem exec-Binding mit JSONPath eine Number? Ein String funktioniert bisher einwandfrei. Will ich zwengs Persistence und Graphen eine Number erzeugen, sehe ich immer nur "NULL".
Derzeitiger Stand:
viessmann.things:

Code: Alles auswählen

Thing exec:command:getHeizungsdaten "Viessmann Heizungsdaten" [command="vclient -h rp3-kl-hz:3002 -c getTempA,getTempKist,getTempWWist -J", interval=20, timeout=20] 
heizung.items:

Code: Alles auswählen

Number Aussentemperatur "Außentemperatur [JSONPATH($..[?(@.command=='getTempA')].value): %.1f °C]" <temperature> (Influx,Heizung) {channel="exec:command:getHeizungsdaten:output"}
Number Warmwassertemperatur "Wassertemperatur [JSONPATH($..[?(@.command=='getTempWWist')].value): %s °C]" <temperature> (Influx,Heizung) {channel="exec:command:getHeizungsdaten:output"}
Number Kesseltemperatur "Kesseltemperatur [JSONPATH($..[?(@.command=='getTempKist')].value): %s °C]" <temperature> (Influx,Heizung) {channel="exec:command:getHeizungsdaten:output"}
(die verschiedenenen Darstellungsoptionen '%s' und '%.1f' stehen da nur zum Ausproieren - nützt aber nichts, bewirkt immer "NULL").
Hier noch so ein json-Obekt:

Code: Alles auswählen

[{"command":"getTempA","value":5.400000,"raw":"5.400000 °C","error":""},{"command":"getTempKist","value":69.500000,"raw":"69.500000 °C","error":""},{"command":"getTempWWist","value":50.299999,"raw":"50.299999 °C","error":""}] 
Ah, in einem Evaluator sehe ich, dass da nicht 5.4, sondern [5.4] rauskommt, das macht Sinn. Das scheint ein Array der Länge eins zu sein? Wie ich das dereferenziert kriege, schau ich mir noch genauer an. Danke fürs Zuhören! ;-)

Schönen Gruß,
Christoph

Benutzeravatar
udo1toni
Beiträge: 13858
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Viessmann API mit OH3 auf RPi

Beitrag von udo1toni »

exec kennt ausschließlich String, sowohl für Input als auch für Output. Du versuchst, JSONPATH in einem Number Channel im Label einzusetzen, was schon aus Prinzip nicht funktionieren kann, denn ein gültiges JSON Objekt ist immer ein String, gehören doch {}: und " zwingend zu den Zeichen die vorkommen.

Ein kurzer Schritt zurück, es gibt drei (vier) Stellen, an denen Du eine Transformation einsetzen kannst. In der Abfolge des Datenwegs:
  1. Im Channel selbst. Das Addon muss dies unterstützen (eigener Parameter im Channel) - das ist bei exec nicht der Fall.
  2. Im Link zwischen Channel und Item. Das heißt "Profile" und ist die Stelle, an der Du ansetzen musst. Damit JSONPATH im Link verwendet werden kann, muss der Channel zwingend vom Typ String sein (siehe oben).
  3. Im Label. Dabei wird nur die Anzeige beeinflusst, der gespeicherte Wert bleibt unangetastet. Dazu muss das Item selbst vom Typ String sein (siehe oben).
  4. Innerhalb einer Rule. Spielt hier keine Rolle, soll aber nicht unerwähnt bleiben...
Vor- und Nachteile der verschiedenen Positionen:
  1. -> V: Channel kann schon vom passenden Datentyp sein, damit ist auch UoM einfach möglich (so das Binding das unterstützt). N: Pro Wert ein Channel, auch wenn mehrere Werte aus dem selben JSON entnommen werden müssen -> potenziell erhöhter Datenverkehr.
  2. -> V: Ein Channel für mehrere Items, die unterschiedliche Werte anzeigen können, mit Textdateien sehr übersichtlich und bequem zu konfigurieren. N: Nur eine Transformation möglich; keine weiteren Profiles möglich, UoM evtl. nicht möglich (hab ich noch nicht getestet, ginge aber, wenn, dann nur über JS, weil man irgendwo die Einheit anhängen muss. Das State Format im Link ist die "Eingangsformatierung, also vor dem Profile, nicht danach...)
  3. -> V: Nur ein Item, um in einer UI unterschiedliche Werte voneinander getrennt anzuzeigen (unterschiedliche Labeldefinition in der Sitemap, Page usw.) N: String Items sind keine sinnvolle Datenquelle für Vergleiche und Grafen.
Wie gesagt brauchst Du Variante 2, um von exec auf direktem Weg zu Numer Items zu kommen:

Code: Alles auswählen

Number Aussentemperatur     "Außentemperatur  [%.1f °C]" <temperature> (Influx,Heizung) {channel="exec:command:getHeizungsdaten:output"[profile="transform:JSONPATH",function="$..[?(@.command=='getTempA')].value"]}
Number Warmwassertemperatur "Wassertemperatur [%.1f °C]" <temperature> (Influx,Heizung) {channel="exec:command:getHeizungsdaten:output"[profile="transform:JSONPATH",function="$..[?(@.command=='getTempWWist')].value"]}
Number Kesseltemperatur     "Kesseltemperatur [%.1f °C]" <temperature> (Influx,Heizung) {channel="exec:command:getHeizungsdaten:output"[profile="transform:JSONPATH",function="$..[?(@.command=='getTempKist')].value"]}
Edit: Schließende Klammern ergänzt
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

chrisfetz
Beiträge: 16
Registriert: 12. Mär 2021 14:00

Re: Viessmann API mit OH3 auf RPi

Beitrag von chrisfetz »

Servus,

Vielen Dank für den Hinweis!
In Deinen Beispiel ist die Syntax nicht ganz korrekt. Wenn man das aber korrigiert, funktioniert es auch nicht.
Zu Debug-Zwecken habe ich das mal so probiert:
<code>
String Aussentemp "Außentemp [%s]" <temperature> (Heizung) {channel="exec:command:getHeizungsdaten:output"[profile="transform:JSONPATH",function="$..[?(@.command=='getTempA')].value"]}
</code>

Die Ausgabe zeigt das ganze untransformierte JSon-Objekt. Nach Doku zu Profilen allegemein und beim JSon-Transformations-Plugin sehe ich aber keinen offensichtlichen Fehler.

Schönen Gruß,
Christoph

Benutzeravatar
udo1toni
Beiträge: 13858
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Viessmann API mit OH3 auf RPi

Beitrag von udo1toni »

Also, wenn wir bei korrekter Syntax sind…
Schau Dir doch bitte nach dem Speichern der Postings an, was Du gepostet hast, dann fällt gleich auf, dass das Schlüsselwort „code“ nicht mit spitzen Klammern <> geschrieben werden muss, sondern mit eckigen Klammern []… :) Im ersten Posting hatte ich das schon korrigiert ;)

Kannst Du mal das konkrete JSON Objekt posten? JSONPATH hast Du ja sicher installiert, das wäre die einzige Variante, die mir spontan als Fehlerquelle einfiele…
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

chrisfetz
Beiträge: 16
Registriert: 12. Mär 2021 14:00

Re: Viessmann API mit OH3 auf RPi

Beitrag von chrisfetz »

Servus,

und ich dachte mir noch "komisch, gestern gings doch". Sorry, ich schau sonst gerade den ganzen Tag xml an.

In der Transformation vorne beim Label ging es - ich habe den gleichen Text nur nach hinten kopiert. Ich behaupte mal kühn, dass das ganze Profil nicht greift. Auch ein simples (Obacht!)

Code: Alles auswählen

String Aussentemp "Außentemp [%s]" {channel="exec:command:getHeizungsdaten:output"[profile="transform:JSONPATH",function="$..command",sourceFormat="%s"]}
tut nichts, ein

Code: Alles auswählen

String Aussentemp "Außentemp [JSONPATH($..command): %s]" {channel="exec:command:getHeizungsdaten:output"}
dagegen schon (Ausgabe: ["getTempA", "getTempKist", "getTempWWist"]).

Hier das Objekt (Ein- und Ausgabe des ersten Falls):

Code: Alles auswählen

[{"command":"getTempA","value":5.100000,"raw":"5.100000 °C","error":""},{"command":"getTempKist","value":33.500000,"raw":"33.500000 °C","error":""},{"command":"getTempWWist","value":46.099998,"raw":"46.099998 °C","error":""}] 
Jetzt wirds noch abstruser:
ich habe mir das Debug-Item mit dem Profile transform:JSONPATH function $..command in der GUI zusammengeklickt - das tut wie erwartet.
Hmmm. Gibt es in dem Zusammenhang irgendeinen bekannten Fehler? Entweder in der Doku oder in der Software?

Wenn ich das Profil im link nochmal zum Editieren öffnen will, kann ich einen drehenden Donut bewundern und weiter passiert nichts. Da scheint wirklich etwas faul zu sein.

Schönen Gruß,
Christoph

Antworten