Hallo Rudi,
Ich hatte Probleme mit Umlauten im param->{data} Value beim senden über HttpUtils_BlockingGet.
Fehlermeldung war
substr outside of string at FHEM/HttpUtils.pm line 749
Folgende Änderung in der HttpUtils.pm hat mir geholfen den Fehler zu beseitigen und die Daten ohne Fehler zu übertragen.
@@ -738,7 +738,7 @@ HttpUtils_Connect2($)
$data = $hdr.(defined($data) ? $data:"");
$hash->{directWriteFn} = sub($) { # Nonblocking write
- my $ret = syswrite $hash->{conn}, $data;
+ my $ret = syswrite $hash->{conn}, Encode::decode("UTF-8", $data);
if(!defined($ret) || $ret <= 0) {
return if($! == EAGAIN);
my $err = $!;
Grüße
Marko
In der Voreinstellung (attr global encoding bytestream) darf diese Zeile nicht notwendig sein, da per Definition in diesem Modus interne Datenstrukturen als UTF-8 Bytestrom gespeichert sind.
ALLERDINGS ist eine Dekodierung nach UTF-8 notwendig, falls "attr global encoding unicode" gesetzt ist (die globale Variable $unicodeEncoding ist dann 1)
Das habe ich nachgeholt.
Hallo Rudi,
Ich hatte das Attribut encoding global nicht gesetzt. Sollte also bytestream dann sein.
Aber wenn ich nun versuche das Attribut zu setzen, egal mit welchen Wert dann macht FHEM ein neustart.
Log verbose 5 anbei.
Leider klappt es auch mit der aktuell im svn vorhandenen HttpUtils nicht.
Log
2022.12.28 18:24:01.498 1: !!!DEBUG - MsgcreateParamRef: r0/rooms/!FEMjJvKtkZzFnrnUZH:matrix.cooltux.net/send/m.room.message?access_token=syt_c3lzdGVtbWVzc2FnZV9ib3Q_lvlxzTClcdnRBUkTQhSr_028fVd
2022.12.28 18:24:01.498 1: !!!DEBUG - Def: msg ParamValue: urlPath Resp: r0/rooms/!FEMjJvKtkZzFnrnUZH:matrix.cooltux.net/send/m.room.message?access_token=syt_c3lzdGVtbWVzc2FnZV9ib3Q_lvlxzTClcdnRBUkTQhSr_028fVd
2022.12.28 18:24:01.498 1: !!!DEBUG - MsgcreateParamRef: {"msgtype":"m.text", "body":"test"}
2022.12.28 18:24:01.498 1: !!!DEBUG - Def: msg ParamValue: data Resp: {"msgtype":"m.text", "body":"test"}
2022.12.28 18:24:01.534 1: !!!DEBUG - TOKEN aus Hash: syt_c3lzdGVtbWVzc2FnZV9ib3Q_lvlxzTClcdnRBUkTQhSr_028fVd
2022.12.28 18:24:12.894 1: !!!DEBUG - MsgcreateParamRef: r0/rooms/!FEMjJvKtkZzFnrnUZH:matrix.cooltux.net/send/m.room.message?access_token=syt_c3lzdGVtbWVzc2FnZV9ib3Q_lvlxzTClcdnRBUkTQhSr_028fVd
2022.12.28 18:24:12.894 1: !!!DEBUG - Def: msg ParamValue: urlPath Resp: r0/rooms/!FEMjJvKtkZzFnrnUZH:matrix.cooltux.net/send/m.room.message?access_token=syt_c3lzdGVtbWVzc2FnZV9ib3Q_lvlxzTClcdnRBUkTQhSr_028fVd
2022.12.28 18:24:12.894 1: !!!DEBUG - MsgcreateParamRef: {"msgtype":"m.text", "body":"täst"}
2022.12.28 18:24:12.894 1: !!!DEBUG - Def: msg ParamValue: data Resp: {"msgtype":"m.text", "body":"täst"}
2022.12.28 18:24:12.897 1: PERL WARNING: substr outside of string at FHEM/HttpUtils.pm line 752.
2022.12.28 18:24:12.898 1: stacktrace:
2022.12.28 18:24:12.898 1: main::__ANON__ called by FHEM/HttpUtils.pm (752)
2022.12.28 18:24:12.898 1: main::__ANON__ called by fhem.pl (791)
2022.12.28 18:24:12.898 1: PERL WARNING: Use of uninitialized value $data in numeric eq (==) at FHEM/HttpUtils.pm line 753.
2022.12.28 18:24:12.898 1: stacktrace:
2022.12.28 18:24:12.898 1: main::__ANON__ called by FHEM/HttpUtils.pm (753)
2022.12.28 18:24:12.898 1: main::__ANON__ called by fhem.pl (791)
2022.12.28 18:24:12.899 1: !!!DEBUG - TOKEN aus Hash: syt_c3lzdGVtbWVzc2FnZV9ib3Q_lvlxzTClcdnRBUkTQhSr_028fVd
Siehe einmal test und einmal täst
ZitatIch hatte das Attribut encoding global nicht gesetzt. Sollte also bytestream dann sein.
In diesem Fall muss derjenige, der $data liefert, dafuer sorgen, dass die Daten in UTF-8 Format (bytestream, bereits "dekodiert") vorliegen.
ZitatAber wenn ich nun versuche das Attribut zu setzen, egal mit welchen Wert dann macht FHEM ein neustart.
Wieso aber?
encoding
Set the internal encoding used for storing strings. Possible values: bytestream (default) and unicode.
Notes:
Since not all modules were checked, if they work correctly with the internal unicode encoding, this feature is experimental.
Changing the attribute value triggers a save and a shutdown restartZitatLeider klappt es auch mit der aktuell im svn vorhandenen HttpUtils nicht.
Diese Version sollte auch nur den Fall "attr global encoding unicode" fixen, und da Du ihn nicht gesetzt hast, duerfte sie in deinem Fall keine Auswirkung haben.
Zitat von: rudolfkoenig am 28 Dezember 2022, 18:47:56
In diesem Fall muss derjenige, der $data liefert, dafuer sorgen, dass die Daten in UTF-8 Format (bytestream, bereits "dekodiert") vorliegen.
Wieso aber?
encoding
Set the internal encoding used for storing strings. Possible values: bytestream (default) and unicode.
Notes:
Since not all modules were checked, if they work correctly with the internal unicode encoding, this feature is experimental.
Changing the attribute value triggers a save and a shutdown restart
Diese Version sollte auch nur den Fall "attr global encoding unicode" fixen, und da Du ihn nicht gesetzt hast, duerfte sie in deinem Fall keine Auswirkung haben.
OK das mit dem Attribut habe ich verstanden.
Zurück zu meinem HttpUtils Problem. Ich bin ja selbst der jenigen der Data liefert, oder besser gesagt das FHEMWEB. Der String wird auch nicht mehr angefasst und genau so an HttpUtils geliefert.
Kannst Du mir ein Beispiel zeigen?
https://forum.fhem.de/index.php/topic,131207.msg1254030.html#msg1254030
Sowas hier? Oder was möchtest Du genau haben?
Irgendwas, womit ich das Problem nachstellen kann.
https://git.cooltux.net/FHEM/fhem-matrix/src/branch/patch-CoolTux
Du benötigst
lib/FHEM/Devices/Matrix/Client.pm
FHEM/70_Matrix.pm
defmod matrix Matrix matrix.cooltux.net <USER_BEKOMMST_DU_PER_SMS>
attr matrix matrixMessage <BEKOMMST_DU_PER_SMS>
attr matrix matrixSender <BEKOMMST_DU_PER_SMS>
attr matrix room Test
attr matrix verbose 1
Damit solltest Du testen können.
Nach dem anlegen musst Du noch das Passwort vergeben welches Du per SMS bekommst.
set matrix setPassword pass=<BEKOMMST_DU_PER_SMS>
Dann kannst Du testen
set matrix msg Dies ist ein Test
das geht keine Fehlermeldung im Log
set matrix msg Dies ist ein Täst
Fehlermeldung im Log und es kommt nichts an.
Grüße
Marko
Auf der verlinkten Seite gibt es kein Client.pm, nur ein Matrix.pm.
Wenn ich die nach Client.pm umbenenne, kriege ich
Undefined subroutine &FHEM::Matrix::GP_Import called at lib/FHEM/Devices/Matrix/Client.pm line 27.
Zitat von: rudolfkoenig am 29 Dezember 2022, 16:08:36
Auf der verlinkten Seite gibt es kein Client.pm, nur ein Matrix.pm.
Wenn ich die nach Client.pm umbenenne, kriege ich
Undefined subroutine &FHEM::Matrix::GP_Import called at lib/FHEM/Devices/Matrix/Client.pm line 27.
Hallo Rudi,
ist ja auch im lib - Verzeichnis: https://git.cooltux.net/FHEM/fhem-matrix/src/branch/patch-CoolTux/lib/FHEM/Devices/Matrix
Grüße Jörg
Zitat von: rudolfkoenig am 29 Dezember 2022, 16:08:36
Auf der verlinkten Seite gibt es kein Client.pm, nur ein Matrix.pm.
Wenn ich die nach Client.pm umbenenne, kriege ich
Undefined subroutine &FHEM::Matrix::GP_Import called at lib/FHEM/Devices/Matrix/Client.pm line 27.
Ist das Thema noch aktuell Rudi? Habe gesehen das Du schon Nachrichten versendet hast.
Du warst aber im Branch patch-CoolTux? Oder bist Du im falschen Branch irgendwann gelandet?
Grüße
Zitatset matrix msg Dies ist ein Täst
Ich sehe keine Fehlermeldung, nur sehr viele !!!DEBUG Meldungen, und Täst kommt in meinem Fall auch als Bytestream im Modul an:
2022.12.29 16:24:39 1: !!!DEBUG - MsgcreateParamRef: {"msgtype":"m.text", "body":"Dies ist ein Täst"}
2022.12.29 16:24:39 1: !!!DEBUG - Def: msg ParamValue: data Resp: {"msgtype":"m.text", "body":"Dies ist ein Täst"} / {"msgtype":"m.text", "body":"Dies ist ein T(195)(164)st"}
2022.12.29 16:24:39 3: matrix 2 msg Request Busy/Sync 1 / 0
2022.12.29 16:24:39 3: matrix 2 msg Result 200
2022.12.29 16:24:39 1: !!!DEBUG - TOKEN aus Hash: syt_c3lzdGVtbWVzc2FnZV9ib3Q_vLiDPMClbVjtzPvDnbgI_00cPh9
Um Klarheit zu haben, habe ich die DEBUG Ausgabe in Client.pm mit dem folgenden Patch erweitert:
--- /home/rudi/Downloads/Client.pm 2022-12-29 16:27:00.853159346 +0100
+++ lib/FHEM/Devices/Matrix/Client.pm 2022-12-29 16:24:16.691586249 +0100
@@ -908,13 +908,16 @@
::Log( 1,
'!!!DEBUG - MsgcreateParamRef: ' . $paramref->{$def}->{$paramValue} );
+ my $dbg = $paramref->{$def}->{$paramValue};
+ $dbg =~ s/([^ -~])/"(".ord($1).")"/ge;
::Log( 1,
'!!!DEBUG - Def: '
. $def
. ' ParamValue: '
. $paramValue
. ' Resp: '
- . $paramref->{$def}->{$paramValue} );
+ . $paramref->{$def}->{$paramValue}
+ . " / $dbg");
return (
exists( $paramref->{$def}->{$paramValue} )
&& $paramref->{$def}->{$paramValue}
Und Du musstest nichts ändern das es geht?
Ich habe es sogar über telnet direkt auf dem FHEM Server gemacht und bekam die Fehlermeldung.
Auf jeden Fall vielen vielen Dank für's testen. Dann muss ich schauen und mal Deinen Patch nehmen für Ausgaben.
Habe mit dem Patch getestet. Es kommt
2022.12.29 16:59:21.811 1: !!!DEBUG - Def: msg ParamValue: data Resp: {"msgtype":"m.text", "body":"täst"} / {"msgtype":"m.text", "body":"t(195)(164)st"}
2022.12.29 16:59:21.815 1: PERL WARNING: substr outside of string at FHEM/HttpUtils.pm line 752.
2022.12.29 16:59:21.815 1: stacktrace:
2022.12.29 16:59:21.815 1: main::__ANON__ called by FHEM/HttpUtils.pm (752)
2022.12.29 16:59:21.815 1: main::__ANON__ called by fhem.pl (791)
2022.12.29 16:59:21.815 1: PERL WARNING: Use of uninitialized value $data in numeric eq (==) at FHEM/HttpUtils.pm line 753.
2022.12.29 16:59:21.815 1: stacktrace:
2022.12.29 16:59:21.815 1: main::__ANON__ called by FHEM/HttpUtils.pm (753)
2022.12.29 16:59:21.815 1: main::__ANON__ called by fhem.pl (791)
Ich teste mal auf einem zweiten System
Ok also das ist jetzt ober peinlich.
Auf meinem Produktivsystem geht es. Keine Fehlermeldung und es kommen die Nachrichten an. Nun muss ich mal schauen was da anders ist. Ich hatte schon den Ansatz mit locale mir angeschaut, hatte da aber nichts feststellen können. Diesen werde ich nun noch einmal genauer prüfen.
Danke Rudi, sorry für den Aufwand. Tut mir echt Leid. :-[
Interessant. Ich habe auf dem Testsystem zusätzlich noch en_US.utf8 als locale hinzugefügt. Ausserdem habe ich die locale Einstellungen noch mal neu abgespeichert und die locale generieren lassen.
Und nun habe ich das Problem auf meinem Produktivsystem auch. Wo es bis eben aber geklappt hat
root@p-fhem:/opt/fhem/lib/FHEM/Devices/Matrix# locale -a
C
C.UTF-8
de_DE.utf8
en_US.utf8
POSIX
Gesetzt mit
dpkg-reconfigure locales
und de_DE.utf8 als Standard.
2022.12.29 17:24:33 1: !!!DEBUG - MsgcreateParamRef: {"msgtype":"m.text", "body":"täst"}
2022.12.29 17:24:33 1: !!!DEBUG - Def: msg ParamValue: data Resp: {"msgtype":"m.text", "body":"täst"} / {"msgtype":"m.text", "body":"t(195)(164)st"}
2022.12.29 17:24:33 1: PERL WARNING: substr outside of string at FHEM/HttpUtils.pm line 749.
2022.12.29 17:24:33 1: PERL WARNING: Use of uninitialized value $data in numeric eq (==) at FHEM/HttpUtils.pm line 750.
Brauchst kein Mitleid zu haben: mein "encoding unicode" Fix in HttpUtils.pm war nicht sauber.
Das scheint aber jetzt auch zu funktionieren.
In Client.pm steht:
header => 'User-Agent: HttpUtils/2.2.3\r\nAccept: application/json'
Ich fuerchte das ist zu viel, weil \r\n damit nicht in <cr><nl> gewandelt wird, sondern verbatim \r\n bleibt.
Ich habe die Quotes getauscht: header => "...", und so getestet.
Und nun habe ich das Problem auf meinem Produktivsystem auch.
Auf was steht $LANG? Und "env | grep LC_"?
env sagt
SHELL=/bin/bash
SUDO_GID=1000
SUDO_COMMAND=/bin/bash
SUDO_USER=marko
PWD=/opt/fhem
LOGNAME=root
HOME=/root
LANG=de_DE.UTF-8
TERM=xterm-256color
USER=root
SHLVL=1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
SUDO_UID=1000
MAIL=/var/mail/root
_=/usr/bin/env
OLDPWD=/root
"env | grep LC_"
sagt gar nichts
Strange. Vmtl. neumodisches Zeug.
Und sehr verwirrend, dass das FHEM beeinflusst.
Wie schaut es mit "attr global encoding unicode" aus?
Habe ich auf beiden Systemen nicht gesetzt.
Was mir noch aufgefallen ist.
Auf dem Produktivsystem sieht die Fehlermeldung so aus
2022.12.29 17:37:42 1: !!!DEBUG - Def: msg ParamValue: urlPath Resp: r0/rooms/!FEMjJvKtkZzFnrnUZH:matrix.cooltux.net/send/m.room.message?access_token=syt_c3lzdGVtbWVzc2FnZV9ib3Q_YVwrRypJFSBfAnJJTRrQ_1obFJx / r0/rooms/!FEMjJvKtkZzFnrnUZH:matrix.cooltux.net/send/m.room.message?access_token=syt_c3lzdGVtbWVzc2FnZV9ib3Q_YVwrRypJFSBfAnJJTRrQ_1obFJx
2022.12.29 17:37:42 1: !!!DEBUG - MsgcreateParamRef: {"msgtype":"m.text", "body":"täst"}
2022.12.29 17:37:42 1: !!!DEBUG - Def: msg ParamValue: data Resp: {"msgtype":"m.text", "body":"täst"} / {"msgtype":"m.text", "body":"t(195)(164)st"}
2022.12.29 17:37:42 1: PERL WARNING: substr outside of string at FHEM/HttpUtils.pm line 752.
2022.12.29 17:37:42 1: PERL WARNING: Use of uninitialized value $data in numeric eq (==) at FHEM/HttpUtils.pm line 753.
Auf dem Testsystem so
2022.12.29 17:37:06.645 1: !!!DEBUG - Def: msg ParamValue: urlPath Resp: r0/rooms/!FEMjJvKtkZzFnrnUZH:matrix.cooltux.net/send/m.room.message?access_token=syt_c3lzdGVtbWVzc2FnZV9ib3Q_JKlYtnmEtiOFEVDSujZq_28R8Ew / r0/rooms/!FEMjJvKtkZzFnrnUZH:matrix.cooltux.net/send/m.room.message?access_token=syt_c3lzdGVtbWVzc2FnZV9ib3Q_JKlYtnmEtiOFEVDSujZq_28R8Ew
2022.12.29 17:37:06.645 1: !!!DEBUG - MsgcreateParamRef: {"msgtype":"m.text", "body":"täst"}
2022.12.29 17:37:06.645 1: !!!DEBUG - Def: msg ParamValue: data Resp: {"msgtype":"m.text", "body":"täst"} / {"msgtype":"m.text", "body":"t(195)(164)st"}
2022.12.29 17:37:06.649 1: PERL WARNING: substr outside of string at FHEM/HttpUtils.pm line 752.
2022.12.29 17:37:06.649 1: stacktrace:
2022.12.29 17:37:06.649 1: main::__ANON__ called by FHEM/HttpUtils.pm (752)
2022.12.29 17:37:06.649 1: main::__ANON__ called by fhem.pl (791)
2022.12.29 17:37:06.649 1: PERL WARNING: Use of uninitialized value $data in numeric eq (==) at FHEM/HttpUtils.pm line 753.
2022.12.29 17:37:06.649 1: stacktrace:
2022.12.29 17:37:06.649 1: main::__ANON__ called by FHEM/HttpUtils.pm (753)
2022.12.29 17:37:06.649 1: main::__ANON__ called by fhem.pl (791)
Beide Systeme habe ich eben upgedatet.
Ok, ich habe auf dem Testsystem stacktrace aktiv.
Zitat von: rudolfkoenig am 29 Dezember 2022, 17:30:40
Brauchst kein Mitleid zu haben: mein "encoding unicode" Fix in HttpUtils.pm war nicht sauber.
Das scheint aber jetzt auch zu funktionieren.
In Client.pm steht:
header => 'User-Agent: HttpUtils/2.2.3\r\nAccept: application/json'
Ich fuerchte das ist zu viel, weil \r\n damit nicht in <cr><nl> gewandelt wird, sondern verbatim \r\n bleibt.
Ich habe die Quotes getauscht: header => "...", und so getestet.
Und nun habe ich das Problem auf meinem Produktivsystem auch.
Auf was steht $LANG? Und "env | grep LC_"?
Die Quotes habe ich im übrigen geändert bei mir
2022.12.29 17:37:42 1: PERL WARNING: Use of uninitialized value $data in numeric eq (==) at FHEM/HttpUtils.pm line 753.
Die Meldung kommt, wenn in HttpUtils.pm Daten auftauchen (header order data), die nicht als UTF-8 Bytestrom kodiert sind, und "attr global encoding unicode" auch nicht gesetzt ist. Eigentlich(TM) muessen die Module je nach Attributwert die Daten "richtig" liefern.
2022.12.29 18:06:09.330 1: !!!DEBUG - MsgcreateParamRef: {"msgtype":"m.text", "body":"täst"}
2022.12.29 18:06:09.330 1: !!!DEBUG - Def: msg ParamValue: data Resp: {"msgtype":"m.text", "body":"täst"} / {"msgtype":"m.text", "body":"t(195)(164)st"}
2022.12.29 18:06:09.333 1: PERL WARNING: substr outside of string at FHEM/HttpUtils.pm line 751.
2022.12.29 18:06:09.333 1: stacktrace:
2022.12.29 18:06:09.333 1: main::__ANON__ called by FHEM/HttpUtils.pm (751)
2022.12.29 18:06:09.334 1: main::__ANON__ called by fhem.pl (791)
2022.12.29 18:06:09.334 1: PERL WARNING: Use of uninitialized value $data in numeric eq (==) at FHEM/HttpUtils.pm line 752.
2022.12.29 18:06:09.334 1: stacktrace:
2022.12.29 18:06:09.334 1: main::__ANON__ called by FHEM/HttpUtils.pm (752)
2022.12.29 18:06:09.334 1: main::__ANON__ called by fhem.pl (791)
Ich habe mal die neuste HttpUtils installiert.
Also, ganz scheint es noch nicht zu stimmen. Ich habe mir am Wochenende einen Wolf gesucht, weil mein TelegramBot nach dem Umzug auf einen Mini-Server partout keine Umlaute mehr senden wollte.
Ganz sicher hat das aufrufende Perl-Programm UTF8 gesendet. Aber sobald ich damit den TelegramBot (und damit die HttpUtils...) aufgerufen habe, stieg das mit der Fehlermeldung
ZitatNonBlockingGet timed out on read ... after 30s
aus. Wie ich hier beschrieben habe https://forum.fhem.de/index.php/topic,131467.msg1256479.html#msg1256479
funktionierte es aber, wenn man die Umlaute direkt eingetippt hat, also vollkommen wirre Sache.
Erst nach den Hinweisen von JoWiemann und CoolTux habe ich zuerst die Locale überprüft und korrekt auf de_DE.UTF8 gesetzt. Dann trat der Fehler wenigstens mit ordentlicher Meldung auf:
Zitat2023.01.10 16:05:48 1: PERL WARNING: substr outside of string at /opt/fhem/FHEM/HttpUtils.pm line 752.
2023.01.10 16:05:48 1: PERL WARNING: Use of uninitialized value $data in numeric eq (==) at /opt/fhem/FHEM/HttpUtils.pm line 753.
Schließlich habe ich noch utfspecial=1 gesetzt beim TelegramBot => Keine Fehlermeldung, Nachricht mit Umlauten geht raus
Die Fehlermeldungen wegen der Zeile 752 und 753 könnte man aber sicher noch abfangen.
LG
pah
ZitatDie Fehlermeldungen wegen der Zeile 752 und 753 könnte man aber sicher noch abfangen.
Um festzustellen, wer das Problem verursacht, muesste man ein stacktrace haben, am besten optional.
Das muss man entweder explizit programmieren, oder man laesst das WARNING passieren, so wie jetzt.
Ich habe aber eine zusaetzliche Log-Asusgabe eingebaut:
Encoding problem in data/header (not UTF-8), check Forum #131207
Ich dachte eigentlich, dass Stacktrace da überflüssig sei - weil ich den Kontext vorher genannt habe. Das ist irgendein fieses locale-Problem, das auftritt, wenn man die Locale auf C.UTF-8 hat und einen UTF8-String mit deutschen Umlauten vom TelegramBot an HttpUtils weiterleitet.
Ich seh zu, dass ich das bei Gelegenheit noch nachliefere.
LG
pah
ZitatIch dachte eigentlich, dass Stacktrace da überflüssig sei
In diesem Fall sicher, aber es gibt vmtl. noch Faelle, wo HttpUtils aus einem anderen Modul aufgerufen wird.
Hallo zusammen.
Zitat von: rudolfkoenig am 11 Januar 2023, 08:52:19
Ich habe aber eine zusaetzliche Log-Asusgabe eingebaut:
Diese verweist mich seit einigen Tagen hartnäckig einmal täglich auf diesen Thread. Weil ich anscheinend der einzige User damit bin, überlege ich seit Tagen, ob ich mich hier outen soll :-\
Das Log sagt:
2023.02.24 11:16:21 1: Encoding problem in data/header (not UTF-8), check Forum #131207
2023.02.24 11:16:21 1: PERL WARNING: substr outside of string at FHEM/HttpUtils.pm line 756.
2023.02.24 11:16:21 1: stacktrace:
2023.02.24 11:16:21 1: main::__ANON__ called by FHEM/HttpUtils.pm (756)
2023.02.24 11:16:21 1: main::__ANON__ called by fhem.pl (791)
2023.02.24 11:16:21 1: PERL WARNING: Use of uninitialized value $data in numeric eq (==) at FHEM/HttpUtils.pm line 757.
2023.02.24 11:16:21 1: stacktrace:
2023.02.24 11:16:21 1: main::__ANON__ called by FHEM/HttpUtils.pm (757)
2023.02.24 11:16:21 1: main::__ANON__ called by fhem.pl (791)
Die Uhrzeit korreliert mit keiner Telegram-Aktion. Ich habe auch nirgends Probleme mit Umlauten bemerkt. Nur mein Log ist überzeugt ein Problem haben zu wollen ;D
Eigentlich würde ich das wegignorieren wie in manch anderem Fall ...
Nach etwas Suche habe ich per Zeitstempel nur eine Korrelation gefunden, welche auch genau zu 1xtgl. passt: mein Müllkalender (via 57_Calendar.pm). Die dort für url definierte Adresse enthält das 'ß'. Nur Indizien, kein Beweis.
Ich könnte also auf "...strasse" statt "...straße" umstellen, dann ist die Meldung ggf. auch weg, dachte aber ich melde mich doch hier (s.u.) :)
Viele Grüße
rob
Zum Reproduzieren:
define myCalender Calendar ical url https://web.c-trace.de/augsburglandkreis/abfallkalender/cal?Gemeinde=Ellgau&Ort=Ellgau&Strasse=Mühlstraße&Hausnr=6&Jahr=%Y&abfall=9|2|3|4|8| 82800
attr myCalender cutoffOlderThan 06:00:00
attr myCalender defaultFormat "starts $T1 - ends $T2 $S $M"
attr myCalender defaultTimeFormat %d.%m.%Y
attr myCalender hideLaterThan 30d
attr myCalender hideOlderThan 06:00:00
attr myCalender synchronousUpdate 0
attr myCalender verbose 0
# DEF ical url https://web.c-trace.de/augsburglandkreis/abfallkalender/cal?Gemeinde=Ellgau&Ort=Ellgau&Strasse=Mühlstraße&Hausnr=6&Jahr=%Y&abfall=9|2|3|4|8| 82800
# FUUID 63f8a6ba-f33f-47bb-440b-291b9ba09a38b372
# FVERSION 57_Calendar.pm:0.263440/2022-08-22
# NAME myCalender
# NOTIFYDEV global
# NR 52
# NTFY_ORDER 50-myCalender
# STATE triggered
# TYPE Calendar
# eventCount 5
# READINGS:
# 2023-02-24 13:02:08 calname Abfuhrdaten Landkreis AugsburgLandkreis
# 2023-02-24 13:02:08 lastUpdate 2023-02-24 13:02:06
# 2023-02-24 13:02:08 nextUpdate 2023-02-25 12:02:06
# 2023-02-24 13:02:08 nextWakeup 2023-02-25 00:00:00
# 2023-02-24 13:02:08 state triggered
#
setstate myCalender triggered
setstate myCalender 2023-02-24 13:02:08 calname Abfuhrdaten Landkreis AugsburgLandkreis
setstate myCalender 2023-02-24 13:02:08 lastUpdate 2023-02-24 13:02:06
setstate myCalender 2023-02-24 13:02:08 nextUpdate 2023-02-25 12:02:06
setstate myCalender 2023-02-24 13:02:08 nextWakeup 2023-02-25 00:00:00
setstate myCalender 2023-02-24 13:02:08 state triggered
* Adresse ist äquivalent, aber nicht meine - hier habe ich absichtlich eine Straße ganz woanders gewählt, die auch noch das 'ü' enthält :P Warum? Weil umschreiben auf '...strasse' nicht reicht und ändern des ü auf '...Muehlstrasse' keinen Kalender mehr bringt.
Mit 'get myCalender update' kann ich die Log-Meldung also provozieren.
FHEM ist aktuell, läuft im Docker-Container und "locale -a" bringt dort:
C
C.UTF-8
de_DE
de_DE@euro
de_DE.iso88591
de_DE.iso885915@euro
de_DE.utf8
deutsch
dutch
en_DK
en_DK.iso88591
en_DK.iso885915
en_DK.utf8
en_GB
en_GB.iso88591
en_GB.iso885915
en_GB.utf8
en_IE
en_IE.iso88591
en_IE.iso885915
en_IE.utf8
en_US
en_US.iso88591
en_US.iso885915
en_US.utf8
es_ES
es_ES@euro
es_ES.iso88591
es_ES.iso885915@euro
es_ES.utf8
french
fr_FR
fr_FR@euro
fr_FR.iso88591
fr_FR.iso885915@euro
fr_FR.utf8
german
italian
it_IT
it_IT@euro
it_IT.iso88591
it_IT.iso885915@euro
it_IT.utf8
nl_NL
nl_NL@euro
nl_NL.iso88591
nl_NL.iso885915@euro
nl_NL.utf8
pl_PL
pl_PL.iso88592
pl_PL.utf8
polish
POSIX
spanish
Was soll denn "locale -a" bewirken ? Das zeigt doch nur alle möglichen Werte, aber eben nicht den eingestellten. Siehe hier: https://forum.fhem.de/index.php/topic,131207.msg1257843.html#msg1257843
LG
pah
Gute Frage. Habs hier im Fred aufgeschnappt und als sinnvolle Info unterstellt ;) - für meinen Fall bitte ignorieren
VG
rob
ZitatWeil ich anscheinend der einzige User damit bin, überlege ich seit Tagen, ob ich mich hier outen soll :-\
Vielen Dank fuer den Hinweis.
Grund:
- Calendar.pm ruft ResolveDateTime() in fhem.pl auf, um %Y zu wandeln
- da wird POSIX::strftime() aufgerufen, was bei LC_TIME=de_DE.UTF-8 das UTF-8 Input ungefragt nach widechar Output konvertiert.
Ich habe fhem.pl jetzt angepasst, damit das Output wieder zurueckkonvertiert wird.
Eigentlich(TM) darf im URL nur ASCII vorkommen, es exisitert eine URL-Kodierung um andere Zeichen unterzubringen.
Der Haken: Mühlstraße wird nach der URL-Kodierung zu M%C3%BChlstra%C3%9Fe, was strftime wiederum zu M203FebruaryChlstra2032023-02-24e aendert.
D.h. die URL-Kodierung hilft dem Benutzer nicht, hier muss der Modulautor eingreifen.
Vielen Dank für den Fix + Erläuterung 8)
Ich habe kurzerhand zum Kalendermodul einen Fred eingestellt (https://forum.fhem.de/index.php/topic,132475.0.html (https://forum.fhem.de/index.php/topic,132475.0.html)), falls wer hier stolpert/ aufschlägt ;)
VG
rob
Zitat von: Prof. Dr. Peter Henning am 10 Januar 2023, 16:22:52Schließlich habe ich noch utfspecial=1 gesetzt beim TelegramBot => Keine Fehlermeldung, Nachricht mit Umlauten geht raus
Kann ich mal nachfragen, was Du alles insgesamt gemacht hattest? Dieses Attribut gesetzt plus
dpkg-reconfigure localesund dann UTF8-deutsch auswählen? Bei mir reichen beide Sachen nämlich nicht, ich kann weiter keine Nachrichten über den Bot mit Umlauten senden.
Na, genau in der Reihenfolge wie beschrieben: locale gesetzt, dann kamen erst die ordentlichen Fehlermeldungen. Dann utfspecial = 1 - und sonst gar nichts.
LG
pah