Viessmann API mit OH3 auf RPi
-
- Beiträge: 16
- Registriert: 12. Mär 2021 14:00
Re: Viessmann API mit OH3 auf RPi
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
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
-
- Beiträge: 199
- Registriert: 22. Sep 2018 10:38
Re: Viessmann API mit OH3 auf RPi
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
mit
Code: Alles auswählen
udevadm info --name=/dev/ttyUSB0 --attribute-walk
Code: Alles auswählen
sudo nano /etc/udev/rules.d/10-usb-serial.rules
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
-
- Beiträge: 16
- Registriert: 12. Mär 2021 14:00
Re: Viessmann API mit OH3 auf RPi
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
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
-
- Beiträge: 16
- Registriert: 12. Mär 2021 14:00
Re: Viessmann API mit OH3 auf RPi
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?!
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
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"
Viele Grüße,
Christoph
- udo1toni
- Beiträge: 14038
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Viessmann API mit OH3 auf RPi
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?
Oder ist vielleicht noch eine andere udev Rule aktiv, die da Unsinn macht?
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.2.2, LXC), mit openHABian eingerichtet
-
- Beiträge: 16
- Registriert: 12. Mär 2021 14:00
Re: Viessmann API mit OH3 auf RPi
Servus,
naja, anfangs habe ich mit vMon gearbeitet, da sah es im dmesg so aus:
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:
heizung.items:
(die verschiedenenen Darstellungsoptionen '%s' und '%.1f' stehen da nur zum Ausproieren - nützt aber nichts, bewirkt immer "NULL").
Hier noch so ein json-Obekt:
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
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
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]
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"}
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":""}]
Schönen Gruß,
Christoph
- udo1toni
- Beiträge: 14038
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Viessmann API mit OH3 auf RPi
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:
Edit: Schließende Klammern ergänzt
Ein kurzer Schritt zurück, es gibt drei (vier) Stellen, an denen Du eine Transformation einsetzen kannst. In der Abfolge des Datenwegs:
- Im Channel selbst. Das Addon muss dies unterstützen (eigener Parameter im Channel) - das ist bei exec nicht der Fall.
- 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).
- Im Label. Dabei wird nur die Anzeige beeinflusst, der gespeicherte Wert bleibt unangetastet. Dazu muss das Item selbst vom Typ String sein (siehe oben).
- Innerhalb einer Rule. Spielt hier keine Rolle, soll aber nicht unerwähnt bleiben...
- -> 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.
- -> 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...)
- -> 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.
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"]}
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.2.2, LXC), mit openHABian eingerichtet
-
- Beiträge: 16
- Registriert: 12. Mär 2021 14:00
Re: Viessmann API mit OH3 auf RPi
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
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
- udo1toni
- Beiträge: 14038
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Viessmann API mit OH3 auf RPi
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…
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.2.2, LXC), mit openHABian eingerichtet
-
- Beiträge: 16
- Registriert: 12. Mär 2021 14:00
Re: Viessmann API mit OH3 auf RPi
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!)
tut nichts, ein
dagegen schon (Ausgabe: ["getTempA", "getTempKist", "getTempWWist"]).
Hier das Objekt (Ein- und Ausgabe des ersten Falls):
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
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"]}
Code: Alles auswählen
String Aussentemp "Außentemp [JSONPATH($..command): %s]" {channel="exec:command:getHeizungsdaten:output"}
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":""}]
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