Neue Version von HTTPMOD mit neuen Features zum Testen

Begonnen von StefanStrobel, 05 Dezember 2015, 08:31:32

Vorheriges Thema - Nächstes Thema

alkazaa

Ich kriegs leider ums Verrecken nicht hin, ein HTTPMOD-set zu definieren, das mit POST arbeitet. Ich habe schon in zwei threads gepostet, hier und hier, bin aber nicht wirklich weiter.

Um irgendwelche Wechselwirkungen zu minimieren, habe ich jetzt ein rudimentäres device nur für diesen Zweck angelegt:
define Tecalor_Lueften HTTPMOD http://servicewelt/?s=4,2,2 1000
attr Tecalor_Lueften room Xprimtl
attr Tecalor_Lueften set01Data [{"name":"val91","value":"$val"}]
attr Tecalor_Lueften set01Method POST
attr Tecalor_Lueften set01Name I_Zuluft1
attr Tecalor_Lueften set01URL http://192.168.188.35//save.php
attr Tecalor_Lueften verbose 5
#   BUSY       0
#   CFGFN     
#   DEF        http://servicewelt/?s=4,2,2 1000
#   FUUID      650718f5-f33f-a50b-e455-ee9f11051e4ff54a
#   Interval   1000
#   MainURL    http://servicewelt/?s=4,2,2
#   ModuleVersion 4.1.16 - 4.4.2023
#   NAME       Tecalor_Lueften
#   NOTIFYDEV  global
#   NR         6588
#   NTFY_ORDER 50-Tecalor_Lueften
#   STATE      ???
#   TYPE       HTTPMOD
#   eventCount 6
#   value      23
#   HTTPCookieHash:
#     PHPSESSID;/:
#       Name       PHPSESSID
#       Options    path=/
#       Path       /
#       Value      39b8d8b88690d412121acc0ca67b48a9
#   HttpUtils:
#     NAME       
#     addr       http://192.168.188.35:80
#     auth       0
#     buf       
#     code       200
#     compress   1
#     conn       
#     data       [{"name":"val91","value":"23"}]
#     displayurl http://192.168.188.35//save.php
#     header     Cookie: PHPSESSID=39b8d8b88690d412121acc0ca67b48a9
#     host       192.168.188.35
#     httpheader HTTP/1.0 200 OK
#Connection: close
#X-Powered-By: PHP/5.3.0
#Expires: Thu, 19 Nov 1981 08:52:00 GMT
#Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
#Pragma: no-cache
#Content-type: application/json
#Content-Length: 78
#Date: Sun, 17 Sep 2023 15:26:07 GMT
#Server: lighttpd/1.4.19
#     httpversion 1.0
#     hu_blocking 0
#     hu_filecount 1
#     hu_port    80
#     hu_portSfx
#     ignoreredirects 1
#     loglevel   4
#     method     POST
#     path       //save.php
#     protocol   http
#     redirects  0
#     timeout    2
#     url        http://192.168.188.35//save.php
#     sslargs:
#   QUEUE:
#   READINGS:
#   REQUEST:
#     context    set
#     data       [{"name":"val91","value":"$val"}]
#     header     
#     ignoreredirects 0
#     method     POST
#     num        01
#     retryCount 0
#     type       set01
#     url        http://192.168.188.35//save.php
#     value      23
#   hmccu:
#
Bei Aufruf mit z.B. 'set Tecalor_Lueften I_Zuluft1 20' ist aber die einzige POST message, die im Browser-F12-Fenster auftaucht, diese: POST http://192.168.188.22:8083/fhem
Das verbose=5 log sieht so aus:2023.09.17 17:38:20 5: Tecalor_Lueften: set called with I_Zuluft1 10
2023.09.17 17:38:20 5: Tecalor_Lueften: set found option I_Zuluft1 in attribute set01Name
2023.09.17 17:38:20 4: Tecalor_Lueften: set will now set I_Zuluft1 -> 10
2023.09.17 17:38:20 5: Tecalor_Lueften: AddToQueue adds type set01 to URL http://192.168.188.35//save.php, data [{"name":"val91","value":"$val"}], no headers, retry 0, initial queue len: 0
2023.09.17 17:38:20 5: Tecalor_Lueften: HandleSendQueue called from AddToSendQueue, qlen = 1
2023.09.17 17:38:20 5: Tecalor_Lueften: HandleSendQueue - call with HTTP METHOD: POST
2023.09.17 17:38:20 5: Tecalor_Lueften: HandleSendQueue is using Cookie PHPSESSID with path / and Value 39b8d8b88690d412121acc0ca67b48a9 (key PHPSESSID;/, destination path is //save.php)
2023.09.17 17:38:20 5: Tecalor_Lueften: DoCookies is adding Cookie header: PHPSESSID=39b8d8b88690d412121acc0ca67b48a9
2023.09.17 17:38:20 4: Tecalor_Lueften: HandleSendQueue sends set01 with timeout 2 to http://192.168.188.35//save.php,
data: [{"name":"val91","value":"10"}],
header: Cookie: PHPSESSID=39b8d8b88690d412121acc0ca67b48a9
2023.09.17 17:38:21 5: Tecalor_Lueften: ReadCallback called from __ANON__
2023.09.17 17:38:21 4: Tecalor_Lueften: Read callback: request type was set01 retry 0,
header: HTTP/1.0 200 OK
Connection: close
X-Powered-By: PHP/5.3.0
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-type: application/json
Content-Length: 78
Date: Sun, 17 Sep 2023 15:37:44 GMT
Server: lighttpd/1.4.19, body length 78
2023.09.17 17:38:21 5: Tecalor_Lueften: Read callback: body
{"success":true,"message":"Die Einstellungen wurden erfolgreich gespeichert."}
2023.09.17 17:38:21 4: Tecalor_Lueften: BodyDecode is not decoding the response body (charset not found, bodyDecode defaults to none)
2023.09.17 17:38:21 5: Tecalor_Lueften: GetCookies is looking for Cookies
2023.09.17 17:38:21 5: Tecalor_Lueften: ExtractSid called, context set, num 01
2023.09.17 17:38:21 4: Tecalor_Lueften: checking for redirects, code=200, ignore=0
2023.09.17 17:38:21 4: Tecalor_Lueften: no redirects to handle
2023.09.17 17:38:21 5: Tecalor_Lueften: Read callback sets LAST_REQUEST to set01
2023.09.17 17:38:21 5: Tecalor_Lueften: CheckAuth decided no authentication required

Darin die Meldung {"success":true,"message":"Die Einstellungen wurden erfolgreich gespeichert."} zeigt an, das zumindest das Gerät etwas empfangen hat und antwortet. Allein, die POST Daten sind offensichtlich nicht angekommen.

Nach zwei Tagen trial-error habe ich keine Ahnung, wie ich weitermachen könnte. Was mach ich falsch?

-Franz

StefanStrobel

Hallo Franz,

es liegt nicht daran, dass Du kein set mit Post machen kannst. Der Request scheint laut Log zu funktionieren und ist auch ein Post.
Das Problem ist dass Deine Lüftungsanlage offenbar die gesendeten Daten nicht korrekt verarbeitet und trotzdem eine Bestätigung zurücksendet.

Um das Problem zu lösen würde ich zunächst mit dem Browser über Burp auf die Lüftung gehen und den Wert ändern. Dabei alles aufzeichnen und dann genau diesen Request mit allen Headern, Cookies, Tokens o.ä. in HTTPMOD nachbilden.

Wird denn über den Browser kein Login abgefragt?
Falls ja müsstest Du das Einloggen auch im HTTPMOD nachbauen!

In Deinem Mitschnitt werden die Daten kodiert gesendet:
data=%5B%7B%22name%22%3A%22val91%22%2C%22value%22%3A%2247%22%7D%5D
Warum bildest Du das nicht nach sondern schickst es ohne Kodierung?

Gruss
   Stefan


alkazaa

#1277
Zitat von: StefanStrobel am 20 September 2023, 19:19:15Um das Problem zu lösen würde ich zunächst mit dem Browser über Burp auf die Lüftung gehen und den Wert ändern. Dabei alles aufzeichnen

Der HTTP traffic sieht dann (in Burp-Suite) so aus:
Du darfst diesen Dateianhang nicht ansehen.
Und die erste Zeile mit POST so:
Du darfst diesen Dateianhang nicht ansehen.

Versuch ich das gleiche mit FHEM, sieht es so aus:
Du darfst diesen Dateianhang nicht ansehen.
bzw. das POST im Detail:
Du darfst diesen Dateianhang nicht ansehen.

Es werden in dem POST aus FHEM heraus also gar keine Daten geschickt. Ich habe auch alles vieles Mögliche probiert mit diversen Attributen wie setHeader1,2 usw. und auch mit set01Header1,2 usw. und auch requestHeader, aber der von BURP abgefangene POST request ändert sich nie.

Irgendwas habe ich anscheinend gar nicht verstanden...

EDIT:
Das 1. Bild falsch, ist jetzt korrigiert




alkazaa

Hallo,
Ich komme nicht weiter und versuche daher hier nochmal eine detaillierte Beschreibung meines Vorgehens.
Zunächst ist da die Formularseite, mit der die Luftvolumenströme gesetzt werden können:
Du darfst diesen Dateianhang nicht ansehen.
Man trägt dort den/die gewünschten Werte ein und klickt dann auf den 'Speichern'-button. Dessen hinterlegter HTML-code sieht so aus:
<div class="button left" onclick="document.forms['werte'].onsubmit();"><div class="bg_r">&nbsp;</div><a>Speichern</a></div>
Was dabei dann passiert, zeigen die folgenden Screenshots der F12-Netzwerkanalyse-Seite des Browsers (Ich habe die Seite so vergrößert, dass von der Formularseite nur noch der 'Speichern'-button sichtbar ist). Relevant ist wohl nur die erste Zeile mit der POST Anfrage. Deren Details sind in der rechten Fensterhälfte in den Tabs 'Kopfzeilen', 'Cookies', 'Anfrage', 'Antwort' und 'Aufrufliste' aufgeführt. Der Inhalt der Tabs ist in den folgenden Screenshots zu sehen.
Du darfst diesen Dateianhang nicht ansehen. 
Du darfst diesen Dateianhang nicht ansehen.
Du darfst diesen Dateianhang nicht ansehen.
Du darfst diesen Dateianhang nicht ansehen.   
Du darfst diesen Dateianhang nicht ansehen.
Das ist inhaltlich das gleiche, wie im folgenden Burp_Suite Text (bzw. den Burp-Suite screenshots meines vorigen Posts):
POST //save.php HTTP/1.1
Host: 192.168.188.35
Content-Length: 362
Accept: text/plain, */*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.5938.132 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Origin: http://192.168.188.35
Referer: http://192.168.188.35//?s=4,2,2
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: PHPSESSID=0caac0c81912686374fcaaa614f476ca
Connection: close

data=%5B%7B%22name%22%3A%22val91%22%2C%22value%22%3A%22125%22%7D%2C%7B%22name%22%3A%22val92%22%2C%22value%22%3A%22180%22%7D%2C%7B%22name%22%3A%22val93%22%2C%22value%22%3A%22270%22%7D%2C%7B%22name%22%3A%22val94%22%2C%22value%22%3A%22130%22%7D%2C%7B%22name%22%3A%22val95%22%2C%22value%22%3A%22180%22%7D%2C%7B%22name%22%3A%22val96%22%2C%22value%22%3A%22270%22%7D%5D


Ich verstehe aber nicht, warum bei all meinen Versuchen, das mittels HTTPMOD in FHEM nachzubilden, beim POST-Befehl unter 'Host' im F12-Analysefenster immer nur die IP-Adresse des FHEM-Servers auftaucht (192.168.188.22:8083) und nicht die IP-Adresse 192.168.188.35 des Lüftungsgeräts. Selbstverständlich habe ich auch versucht, die optionalen header Felder 'origin' und 'referer' mit Attributen 'set01Header[1,2]' anzugeben, und sie tauchen auch in den Anfrage-Kopfzeilen korrekt auf. Nur funktionieren tut's nicht...

Kann es sein, dass der beschriebene Ablauf mit HTTPMOD überhaupt nicht nachzubilden ist?

Bin für jede Hilfe dankbar
-Franz

P.S.:
Gibt es eine Möglichkeit, bei foren-attachments von Bildern die Größe einszustellen?

StefanStrobel

Hallo Franz,

ich bin mir nicht sicher ob ich verstehe was Du machen möchtest bzw wie Du vorgehst.
Wenn Du im Browser mit F12 über die Entwicklertools des Browsers Requests ansiehst, dann siehst Du natürlich immer nur die Kommunikation zwischen Deinem Browser und Fhem.
Was HTTPMOD bzw. Fhem mit der Website Deiner Lüftungsanlage redet, kann Dein Browser natürlich nicht sehen.
Dafür solltest Du im Fhem-Log nachsehen. Wenn das Httpmod-Gerät auf Verbose 5 steht, siehst Du den ausgehenden Request im Log.
Ob die Website die Daten akzeptiert ist eine andere Frage.
Wie wird denn authentisiert?

Gruß
    Stefan

alkazaa

#1280
Zitat von: StefanStrobel am 09 Oktober 2023, 15:24:14ich bin mir nicht sicher ob ich verstehe was Du machen möchtest bzw wie Du vorgehst.
Wenn Du im Browser mit F12 über die Entwicklertools des Browsers Requests ansiehst, dann siehst Du natürlich immer nur die Kommunikation zwischen Deinem Browser und Fhem.

Was HTTPMOD bzw. Fhem mit der Website Deiner Lüftungsanlage redet, kann Dein Browser natürlich nicht sehen.
Dafür solltest Du im Fhem-Log nachsehen. Wenn das Httpmod-Gerät auf Verbose 5 steht, siehst Du den ausgehenden Request im Log.
Das verbose5 log sieht so aus:
2023.10.09 17:06:43.941 5: Tecalor_Lueften: set called with I_Zuluft1 33
2023.10.09 17:06:43.942 5: Tecalor_Lueften: set found option I_Zuluft1 in attribute set01Name
2023.10.09 17:06:43.943 4: Tecalor_Lueften: set will now set I_Zuluft1 -> 33
2023.10.09 17:06:43.944 5: Tecalor_Lueften: AddToQueue adds type set01 to URL http://192.168.188.35//save.php, data %5B%7B%22name%22%3A%22val91%22%2C%22value%22%3A%2240%22%7D%2C%7B%22name%22%3A%22val92%22%2C%22value%22%3A%22180%22%7D%2C%7B%22name%22%3A%22val93%22%2C%22value%22%3A%22270%22%7D%2C%7B%22name%22%3A%22val94%22%2C%22value%22%3A%22130%22%7D%2C%7B%22name%22%3A%22val95%22%2C%22value%22%3A%22180%22%7D%2C%7B%22name%22%3A%22val96%22%2C%22value%22%3A%22270%22%7D%5D, header Origin: 192.168.188.35, retry 0, initial queue len: 0
2023.10.09 17:06:43.945 5: Tecalor_Lueften: HandleSendQueue called from AddToSendQueue, qlen = 1
2023.10.09 17:06:43.946 5: Tecalor_Lueften: HandleSendQueue - call with HTTP METHOD: POST
2023.10.09 17:06:43.946 5: Tecalor_Lueften: HandleSendQueue is using Cookie PHPSESSID with path / and Value 8014310949ae5211d77f98925bb6fc32 (key PHPSESSID;/, destination path is //save.php)
2023.10.09 17:06:43.947 5: Tecalor_Lueften: DoCookies is adding Cookie header: PHPSESSID=8014310949ae5211d77f98925bb6fc32
2023.10.09 17:06:43.947 4: Tecalor_Lueften: HandleSendQueue sends set01 with timeout 2 to http://192.168.188.35//save.php,
data: %5B%7B%22name%22%3A%22val91%22%2C%22value%22%3A%2240%22%7D%2C%7B%22name%22%3A%22val92%22%2C%22value%22%3A%22180%22%7D%2C%7B%22name%22%3A%22val93%22%2C%22value%22%3A%22270%22%7D%2C%7B%22name%22%3A%22val94%22%2C%22value%22%3A%22130%22%7D%2C%7B%22name%22%3A%22val95%22%2C%22value%22%3A%22180%22%7D%2C%7B%22name%22%3A%22val96%22%2C%22value%22%3A%22270%22%7D%5D,
header: Origin: 192.168.188.35
Cookie: PHPSESSID=8014310949ae5211d77f98925bb6fc32
2023.10.09 17:06:44.722 5: Tecalor_Lueften: ReadCallback called from __ANON__
2023.10.09 17:06:44.722 4: Tecalor_Lueften: Read callback: request type was set01 retry 0,
header: HTTP/1.0 200 OK
Connection: close
X-Powered-By: PHP/5.3.0
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-type: application/json
Content-Length: 78
Date: Mon, 09 Oct 2023 15:03:59 GMT
Server: lighttpd/1.4.19, body length 78
2023.10.09 17:06:44.722 5: Tecalor_Lueften: Read callback: body
{"success":true,"message":"Die Einstellungen wurden erfolgreich gespeichert."}
2023.10.09 17:06:44.723 4: Tecalor_Lueften: BodyDecode is not decoding the response body (charset not found, bodyDecode defaults to none)
2023.10.09 17:06:44.723 5: Tecalor_Lueften: GetCookies is looking for Cookies
2023.10.09 17:06:44.723 5: Tecalor_Lueften: ExtractSid called, context set, num 01
2023.10.09 17:06:44.724 4: Tecalor_Lueften: checking for redirects, code=200, ignore=0
2023.10.09 17:06:44.724 4: Tecalor_Lueften: no redirects to handle
2023.10.09 17:06:44.724 5: Tecalor_Lueften: Read callback sets LAST_REQUEST to set01
2023.10.09 17:06:44.724 5: Tecalor_Lueften: CheckAuth decided no authentication required
Es wird also wohl wirklich ein POST gesendet.
Ich weiß aber nicht, ob das dann mit POST gesendete "http://192.168.188.35//save.php" richtig ist. Dass es überhaupt auf dem Tecalor Gateway ein 'save.php' script gibt, habe ich aus dem burp-Mitschnitt gesehen.
ZitatOb die Website die Daten akzeptiert ist eine andere Frage.
Wie wird denn authentisiert?
Authentisiert wird nicht. Ich vermute mittlerweile auch, dass die website die Daten ger nicht akzeptiert. Aber die website "beschwert" sich halt nicht in einer Form, mit der ich was anfangen könnte.

Ich werd bei Gelegenheit noch bisschen weiter rumspielen, vielleicht kommte ja von irgendwo irgendein Geistesblitz...

Danke erstmal,
Gruß
Franz 

Nachtrag:
Ich vermute jetzt, dass es das cookie namens PHPSESSID sein könnte. Ich werd's jetzt mal versuchen, mit dem 'enableCookies' Attribute (hab ich erst jetzt entdeckt...schäm)

alkazaa

Zitat von: alkazaa am 09 Oktober 2023, 17:30:58Nachtrag:
Ich vermute jetzt, dass es das cookie namens PHPSESSID sein könnte.
PHPSESSID war's auch nicht.
Ich mache es jetzt mit curl, da geht's ganz einfach:
curl -s -d 'data=[{"name":"val91","value":"120"}]' http://192.168.188.35/save.phpKeine Ahnung, warum ich es mit HTTPMOD nicht hinkriege..,

StefanStrobel

Hallo Franz,

wie hast Du HTTPMOD denn konfiguriert?
Hast Du die HTTP-Version wie im Burp-Mitschnitt zu sehen auf 1.1 gesetzt und alle Header wie im Burp-Mitschnitt definiert?
In Deinem Log fehlen die.
Curl setzt ja z.B. bei -d automatisch den Header
content-type application/x-www-form-urlencoded
Und im Burp-Mitschnitt war das auch zu sehen. Dein Slot deutet aber darauf hin, dass Du den Header nicht definiert hast.

Gruß
    Stefan

alkazaa

Ich fress den berühmten Besen:
Es muss nicht heißen
attr Tecalor_Lueften set01Data [{"name":"val91","value":"$val"}]sondern
attr Tecalor_Lueften set01Data data=[{"name":"val91","value":"$val"}]
Alles andere (httpVersion, Header, set01Method=POST, etc.) ist nicht nötig. Die Minimal-Konfiguration für den set-Befehl ist also:
attr Tecalor_Lueften set01Data data=[{"name":"val91","value":"$val"}]
attr Tecalor_Lueften set01Name I_Zuluft1
attr Tecalor_Lueften set01URL http://192.168.188.35//save.php

Ich hatte set01Data naiverweise so verstanden, dass da nur die 'data' selber genannt werden, nicht data='data'.

Sorry für den ganzen Aufriss

-Franz

StefanStrobel

Hallo zusammen,

anbei eine neue Version von HTTPMOD zum Testen.
Mit dem Attribut (get|set)[0-9]*(-[0-9]+)?ValueSeparator kann man ein Trennzeichen für set-Optionen definieren und dann in einem set mehrere Parameter übergeben, die dann mit $val1, $val2 etc. referenziert werden können.
Zudem habe ich mal versucht, die Extraktion von OAuth-Tokens zu vereinfachen. Siehe Attribut enableTokens. Damit werden automatisch JSON codierte access_token or refresh_token erkannt und gespeichert. In künftigen Requests können die dann als %%ACCESS_TOKEN%% and %%REFRESH_TOKEN%% verwendet werden.

Gruss
  Stefan

blueberry63

Hallo,

ich bräuchte mal Hilfe mit einem Reading, dass mehrere Werte, getrennt durch | , zurückliefert:

reading01JSON statetext
reading01Name Status-Text

Wert: Zwischenbehälterfüllstand wird kalibriert|Kesseltemp grösser Wiedereinschalttemp.|Aus

Ich bin nur interessiert am letzten Wert (hier: AUS), kenne mich nicht mit RegEx aus und würde mich freuen, wenn mir jemand den Ausdruck zusammenbauen könnte.

Danke und Gruß
Blueberry63
FHEM auf BBB mit Wheezy: 1x CUL_HM_HM_SCI_3_FM, 1x INSTAR CAM3010, 1x HM-LC-SW1-PL2, 1x HM-LC-Bl1PBU-FM, 1x HM-Sen-MDIR-O, Viessmann Heizung, Gaszähler via GPIO, Klingel via HM-LC-Bl1PBU-FM an FBox, Mailcheck, AVR, XBMC, NanoCUL 433+668 an Raspi per Ethernet, Funksteckdosen (Pollin, IT), Automower

Jostar

#1286
Hallo zusammen,

replacement26Mode expression
replacement26Regex %%26wind%%
replacement26Value sprintf("%s", ReadingsVal("netatmo_Out","state","� �") )
funktioniert, es werden die Zeichencode korrekt prozessiert und ausgewertet.

Versuche ich die Konfiguration/den Code etwas lesbarer zu gestalten, scheitere ich leider an den Hex-Werten,:
replacement26Value sprintf("%s [color=red]%s[/color]", ReadingsVal("netatmo_Out","state","� �"), [color=red]chr(hex("F000"))[/color] )
Führt zum Absturz von fhem, der letzte Log-Eintrag (verbose 5) scheint das ersetzen gemacht zu haben, allerdings ist das Format etwas anders (also auch nicht lesbar in Buchstaben):
2023.11.27 17:42:24 4: OpenEPaper: HandleSendQueue sends set01 with timeout 4 to http://192.168.178.156/jsonupload,
data: mac=0000021EF888341C&json=[ { "text": [20, 8, "min -1  max 8", "fonts/bahnschrift20", 1] }, { "text": [6, 12, "ï��", "/fonts/weathericons.ttf", 1, 0, 22] }, { "text": [85, 55, "100 rel", "fonts/bahnschrift20", 1, 2] }, { "text": [100, 30, "-1.2 °C", "fonts/calibrib30", 2, 2] }, { "text": [105, 13, "ï��", "/fonts/weathericons.ttf", 1, 0, 36] }, { "text": [4, 45, "ï�º", "/fonts/weathericons.ttf", 1, 0, 22] }, { "text": [75, 65, "�", "/fonts/weathericons.ttf", 1, 2, 36] }, { "text": [2, 112, "Trend: down", "fonts/bahnschrift20", 1] }, { "text": [95, 35, "ï�®", "/fonts/weathericons.ttf", 1, 0, 48] }, { "text": [3,141,"{ap_time}", "", 1] }, { "text": [70,141,"{ap_date}", "", 1] } ], No Header
Wide character in syswrite at FHEM/HttpUtils.pm line 768.

Es scheint irgendwie eine andere Art Codierung zu sein (rot markiertet Teil!). Sichtbar hier nur 1 Zeichen, statt wie bei den anderen Übergaben 3.

Hingegen funktioniert der folgende Ausdruck in der fhem-Befehlszeile wie erwartet:
{ sprintf("hallo".chr(hex("F000"))) }
Ziel sind so kleine Bildchen für das Wetter im übrigen. Symbol-Auswahl in Word: Du darfst diesen Dateianhang nicht ansehen.

Jemand vielleicht eine Idee?

Grüße!
Raspberry Pi(s) mit FHEM auf Rasbian Jessie/Strech, DbLog/DbRep mit mySQL, piface, 1Wire-USB-Master von SMS-GUARD, RFXtrx433E

StefanStrobel

Hallo Jostar,

Die Fhem HttpUtils verwenden syswrite zum Senden der Daten. Da werden Bytes übergeben. Zeichen, die mehrere Bytes lang sind, müsstest Du vermutlich als Bytefolge senden, nicht als Multibyte-Zeichen. Am besten bleibst Du bei UTF-8.

Gruss
   Stefan

Aurel_B

Zitat von: blueberry63 am 23 November 2023, 15:52:08Hallo,

ich bräuchte mal Hilfe mit einem Reading, dass mehrere Werte, getrennt durch | , zurückliefert:

reading01JSON statetext
reading01Name Status-Text

Wert: Zwischenbehälterfüllstand wird kalibriert|Kesseltemp grösser Wiedereinschalttemp.|Aus

Ich bin nur interessiert am letzten Wert (hier: AUS), kenne mich nicht mit RegEx aus und würde mich freuen, wenn mir jemand den Ausdruck zusammenbauen könnte.


Schau dir "The Regex Coach" an: http://weitz.de/regex-coach/. Damit solltest du das hinbekommen und du verlierst die Hemmung vor RegEx  ;)

Jostar

Zitat von: StefanStrobel am 04 Dezember 2023, 18:21:04Hallo Jostar,

Die Fhem HttpUtils verwenden syswrite zum Senden der Daten. Da werden Bytes übergeben. Zeichen, die mehrere Bytes lang sind, müsstest Du vermutlich als Bytefolge senden, nicht als Multibyte-Zeichen. Am besten bleibst Du bei UTF-8.

Gruss
   Stefan

Würde natürlich gerne bei UTF bleiben, nur das Sonderzeichen nicht "unlesbar" via Copy&Paste als String in die Definition kopieren, sondern numerisch angeben "U+1234". Nur entweder finde ich nicht das richtige Format oder die httputil oder Modul http unterstützen das nicht. Ist das Problem soweit gut beschrieben?
Raspberry Pi(s) mit FHEM auf Rasbian Jessie/Strech, DbLog/DbRep mit mySQL, piface, 1Wire-USB-Master von SMS-GUARD, RFXtrx433E