Crash bei "Save config" mit configDB

[bmmini1]

Liebe Forum-Mitglieder und FHEM-Spezialisten!

Ich verwende inzwischen seit ca. 4 Jahren FHEM. Zu Beginn auf einem RPI 2, seit Ende 2020 auf einem RPI 4 in einem Docker Container.
Mehrere Arduinos melden verschiedenste Infos per MQTT an FHEM und das funktioniert alles bestens.
Ich habe keine CULs oder ähnliche USB Sticks - alles läuft über LAN und MQTT.
Nach ca. einem Jahr ist jetzt ein weiterer Arduino dazu gekommen, und der soll natürlich auch in FHEM eingebunden werden.

Dummerweise lässt sich aber die Konfiguration nicht mehr speichern!
Bei jedem Klick auf "Save config" stürzt FHEM ab und es wird "Connection lost, trying a reconnct every 5 seconds." angezeigt.
Die Änderungen in der Konfiguration sind damit leider wieder weg.

Im Logfile finde ich dazu diesen Eintrag, und das jederzeit reproduzierbar:
Wide character in subroutine entry at configDB.pm line 427.
2022.03.31 07:01:03.643 1: PERL WARNING: Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle database=fhem;host=mysql;port=3306 at configDB.pm line 427.

Jetzt kann man zwar noch relativ schnell herausfinden, dass "Wide characters" etwas mit Unicode zu tun haben, aber weitere Analysen scheitern leider an meinen ziemlich limitierten Perl-Kenntnissen.
Aus der Code-Zeile 427 ( $sth->execute($filename,encode_base64(join("\n", @content))); ) kann ich noch herauslesen, dass der Fehler beim Speichern des base64-codierten config-Files in die Datenbank auftritt, aber das geht auch schon aus der Fehlermeldung hervor.
Durch die Befragung einer Suchmaschine je nach persönlicher Vorliebe, kann man auch noch herausfinden, dass das "Wide character" Problem offensichtlich im Befehl "encode_base64" auftritt.

Für mich stellen sich jetzt mehrere Fragen.
Warum kann ein File, dass mit Unicode-Zeichen in der DB bereits gespeichert ist, erfolgreich gelesen, aber dann mehr in die selbe DB gespeichert werden?
Wie kann ich herausfinden, welche der Zeichen in dem Config-File den Fehler verursachen? Diese könnte ich ggf. ersetzen/entfernen.
Was kann ich machen, um diesen Fehler in Zukunft zu vermeiden?
Könnte der Ansatz in diesem Thread (https://stackoverflow.com/questions/27270929/mime-base64-encode-wide-characters) zu einer nachhaltigen Lösung beitragen?
Und die wichtigste Frage: Was kann ich jetzt kurzfristig unternehmen, dass es wieder funktioniert?

Ich bin für jeden Hinweis, der zu einer (auch nur vorübergehenden) Lösung führt überaus dankbar!

Vielen Dank im Voraus!

Beste Grüße
Rainer


Hier noch meine Systemkonfiguration:

Raspberry 4, 4 GB, Raspbian 10 (buster), Docker, alles am letzten Patch-Level

Getrennte Docker Container für FHEM (fhem/fhem:latest), MariaDB (jsurf/rpi-mariadb:latest, 10.3.27-MariaDB-0+deb10u1), mosquitto (eclipse-mosquitto:latest, 2.0.14) und weitere, die nichts mit FHEM zu tun haben.
FHEM Versionen:

File                  Rev   Last Change

fhem.pl               25891 2022-03-28 08:56:05Z rudolfkoenig
57_ABFALL.pm          11023 2018-06-13 12:34:34Z uniqueck
96_allowed.pm         25797 2022-03-08 08:54:57Z rudolfkoenig
98_apptime.pm         19468 2019-05-26 07:13:48Z martinp876
42_AptToDate.pm       19639 2019-06-18 13:43:31Z CoolTux
90_at.pm              25248 2021-11-21 10:29:01Z rudolfkoenig
98_autocreate.pm      23727 2021-02-12 20:31:37Z rudolfkoenig
57_Calendar.pm        25643 2022-02-06 16:53:20Z neubert
98_cmdalias.pm        16300 2018-03-01 08:48:21Z rudolfkoenig
93_DbLog.pm           25800 2022-03-08 20:07:32Z DS_Starter
No Id found for 99_DockerImageInfo.pm
98_DOIF.pm            25819 2022-03-12 23:15:22Z Damian
91_eventTypes.pm      23471 2021-01-04 19:24:21Z rudolfkoenig
No Id found for 99_FHEMControlPush.pm
01_FHEMWEB.pm         25869 2022-03-21 10:38:18Z rudolfkoenig
92_FileLog.pm         25748 2022-02-27 10:29:56Z rudolfkoenig
98_freezemon.pm       25141 2021-10-28 19:13:56Z Adimarantis
02_HTTPSRV.pm         20110 2019-09-05 17:30:20Z neubert
98_Installer.pm       20949 2020-01-12 09:53:11Z loredo
98_JsonList2.pm       23727 2021-02-12 20:31:37Z rudolfkoenig
82_LGTV_WebOS.pm      25823 2022-03-13 10:20:53Z CoolTux
00_MQTT2_CLIENT.pm    25723 2022-02-21 08:59:09Z rudolfkoenig
10_MQTT2_DEVICE.pm    25889 2022-03-27 10:39:22Z rudolfkoenig
91_notify.pm          25888 2022-03-27 10:22:58Z rudolfkoenig
42_npmjs.pm           20933 2020-01-10 12:27:41Z loredo
33_readingsGroup.pm   23844 2021-02-27 19:43:24Z justme1968
70_SolarEdgeAPI.pm    22510 2020-08-01 10:19:18Z pizmus
99_SUNRISE_EL.pm      24249 2021-04-14 05:45:49Z rudolfkoenig
98_SVG.pm             25876 2022-03-23 11:28:24Z rudolfkoenig
50_TelegramBot.pm     24867 2021-08-23 10:23:15Z viegener
98_telnet.pm          25754 2022-02-27 16:49:52Z rudolfkoenig
99_Utils.pm           24128 2021-04-02 16:29:11Z rudolfkoenig
98_version.pm         15140 2017-09-26 09:20:09Z markusbloch
98_vitoconnect.pm     25061 2021-10-10 14:13:07Z andreas13

ABFALL_getEvents.pm   11023 2018-06-13 12:34:34Z uniqueck
ABFALL_setUpdate.pm   11021 2017-09-13 00:32:22Z uniqueck
AttrTemplate.pm       25155 2021-10-30 12:48:21Z rudolfkoenig
Blocking.pm           23268 2020-12-01 11:48:48Z rudolfkoenig
Color.pm              20813 2019-12-22 18:42:10Z justme1968
configDB.pm           25860 2022-03-20 10:03:20Z betateilchen
DevIo.pm              25716 2022-02-20 17:39:00Z rudolfkoenig
GPUtils.pm            19666 2019-06-20 11:17:29Z CoolTux
HttpUtils.pm          25784 2022-03-06 09:20:24Z rudolfkoenig
Meta.pm               21008 2020-01-18 10:22:10Z loredo
RTypes.pm             10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm      25286 2021-12-03 10:16:56Z rudolfkoenig
SubProcess.pm         14334 2017-05-20 23:11:06Z neubert
TcpServerUtils.pm     25866 2022-03-21 09:01:16Z rudolfkoenig
TimeSeries.pm         22980 2020-10-17 09:21:43Z neubert

doif.js                    24438 2021-05-14 18:08:18Z Ellert
f18.js                     25656 2022-02-08 09:49:53Z rudolfkoenig
fhemweb.js                 25856 2022-03-18 18:09:03Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968

[rudolfkoenig]

In der Voreinstellung speichert FHEM Strings intern im utf-8 Format, auch "bytestream" genannt. Das bedeutet, dass in den Modulen beim Schreiben und Lesen von Daten mit low-level Funktionen keine Konvertierung notwendig ist, da in der "Aussenwelt" heutzutage fast alles als utf-8 kodiert ist.
Leider(?) konvertieren einige Perl Bibliotheken Strings in die interne "unicode" Darstellung, d.h. Umlaute, Smilies, etc werden als Wide Character gespeichert. Das vereinfacht Regexps und Zeichenlaenge-Zaehlen mit Umlaut-Strings. Modul-Maintainer, die solche Funktionen verwenden, muessen diese Daten nach utf-8 konvertieren. Du verwendest vermutlich ein Modul, wo der Maintainer das nicht gemacht hat.

Seit kurzem gibt es ein global encoding Attribut, mit den moeglichen Werten bytestream (Voreinstellung) und unicode.
Wenn dieses Attribut auf unicode gestellt ist, dann verwendet FHEM die gleiche String-Codierung wie die o.g. Bibliotheken, Umlaute, Smileys, etc werden intern als Wide-Character gespeichert. Hier muss man darauf achten, dass bei Verwendung von low-level Funktionen eine Konvertierung durchgefuehrt wird.
Ich habe alles, was ich betreue, und in Frage kommt (fhem.pl, FHEMWEB, MQTT2*, FileLog, SVG, update, DevIo, HttpUtils), angepasst.
Wenn ein Modul die FHEM-Framework Funktionen aus HttpUitils und DevIo verwendet, dann muss sie nicht angepasst werden. Wenn es aber direkt sysread/etc verwendet, _und_ potentiell unicode Daten einliest oder schreibt, dann schon. Welche Module noch diese Anpassung benoetigen, weiss ich nicht.

Zur Loesung des vorliegenden Problems sehe ich zwei Varianten:
- "attr global encoding unicode" setzen, und testen ob es reicht.
- den Verursacher finden, und den Maintainer benachrichtigen, damit das Problem gefixt wird.
Um den Verursacher zu finden wuerde ich in configDB.pm vor Zeile 427 Folgende einfuegen:

Code Auswählen Erweitern

          map { my $e=Encode::encode('UTF-8',$_); Log 1,"CheckMe:$e" if($e ne $_) } @content;

Jetzt muss man den Crash prvozieren, das FHEM-Log nach "CheckMe" durchsuchen, und aus der Ausgabe auf dem Modul schliessen.

[bmmini1]

Vielen Dank für die ausführliche und verständliche Erklärung.
Mir Hilfe der zusätzlichen Code-Zeile konnte ich die Zeilen mit den "Wide characters" identifizieren und schlussendlich auch den Übeltäter ausfindig machen.

Interessanterweise beginnen alle gefundenen Zeilen mit "setstate", womit aus meiner Sicht die Config selbst gar nicht "fehlerhaft" ist , sondern das Problem im Inhalt der Readings zu finden sein musste.
Das konnte ich auch so weit eingrenzen, indem ich die Devices, zu denen die gefundenen Readings gehören, deaktiviert und die Readings gelöscht habe.
Mit den gelöschten Readings konnte ich ohne Fehler die Config speichern.
Somit ist hier offensichtlich ein Zusammenhang mit dem Thread https://forum.fhem.de/index.php/topic,126966.0.html vorhanden.

Nach und nach habe ich dann die Devices wieder aktiviert und in 98_vitoconnect.pm ein einziges Reading als Auslöser des Fehlers identifiziert.

Leider kann ich den Inhalt dieses Readings nicht beeinflussen, da der störende Inhalt bereits von Viessmann geliefert wird.

Code Auswählen Erweitern

setstate Waermepumpe 2022-04-02 13:44:37 Kessel_Seriennummer ����������������
Detail am Rande: Es handelt sich um eine Luft-Wärmepumpe, die gar keinen Kessel hat ...

Ich habe noch versucht, mit "attr global encoding unicode" das FHEM encoding umzustellen, was mit das vitoconnect Modul mit folgendem Fehler zunichte macht.

JSON error while request: Wide character in subroutine entry at ./FHEM/98_vitoconnect.pm line 1937.

mit

Code Auswählen Erweitern

attr Waermepumpe suppressReading Kessel_Seriennummer
konnte ich das fehlerhafte Reading "unschädlich" machen und es funktioniert wieder alles einwandfrei.

Das beobachtete Verhalten werde ich noch dem Modul-Maintainer melden.

Nochmals vielen Dank für die Unterstützung!

[rudolfkoenig]

Kannst Du bitte pruefen, ob "fhemdebug utf8check" bei Dir was meldet?
Diesen Befehl habe ich glatt uebersehen

[bmmini1]

Diesen Output liefert "fhemdebug utf8check"

Code Auswählen Erweitern

Checked 10943 elements
Strings with utf8-flag set:
Key: def::Telegram::HU_UPD_PARAMS::hu_inProgress Value: TelegramBot_UpdatePoll:2429 TelegramBot_Callback:704 __ANON__:778
Key: modules::DockerImageInfo::META::x_lang::de::abstract Value:Zeigt Informationen über das aktuell verwendete FHEM Docker Image und den laufenden Container
Key: modules::Global::META::abstract Value:FHEM® is a Perl server for house automation
Key: modules::Global::META::description Value:FHEM® (registered trademark) is a GPL'd Perl server for house automation. It is used to automate some common tasks in the household like switching lamps / shutters / heating / etc. and to log events like temperature / humidity / power consumption.\nThe program runs as a server, you can control it via web or smartphone frontends, telnet or TCP/IP directly.\nIn order to use FHEM you'll need a 24/7 server (NAS, RPi, PC, Mac Mini, etc.) with a Perl interpreter and some attached hardware like the CUL-, EnOcean-, Z-Wave-USB-Stick, etc. to access the actors and sensors.\nIt is pronounced without the h, like in feminine.
Key: modules::Global::META::x_lang::de::abstract Value:FHEM® ist ein Perl Server zur Hausautomatisierung
Key: modules::Global::META::x_lang::de::description Value:FHEM® (eingetragene Marke) ist ein in Perl geschriebener, GPL lizensierter Server für die Heimautomatisierung. Man kann mit FHEM häufig auftretende Aufgaben automatisieren, wie z.Bsp. Lampen / Rollladen / Heizung / usw. schalten, oder Ereignisse wie Temperatur / Feuchtigkeit / Stromverbrauch protokollieren und visualisieren.\nDas Programm läuft als Server, man kann es über WEB, dedizierte Smartphone Apps oder telnet bedienen, TCP Schnittstellen für JSON und XML existieren ebenfalls.\nUm es zu verwenden benötigt man einen 24/7 Rechner (NAS, RPi, PC, Mac Mini, etc.) mit einem Perl Interpreter und angeschlossene Hardware-Komponenten wie CUL-, EnOcean-, Z-Wave-USB-Stick, etc. für einen Zugang zu den Aktoren und Sensoren.\nAusgesprochen wird es ohne h, wie bei feminin.
Key: modules::TelegramBot::META::prereqs::runtime::requires::DevIo
Key: modules::TelegramBot::META::prereqs::runtime::requires::Encode
Key: modules::TelegramBot::META::prereqs::runtime::requires::File::Basename
Key: modules::TelegramBot::META::prereqs::runtime::requires::JSON
Key: modules::TelegramBot::META::prereqs::runtime::requires::Scalar::Util
Key: modules::TelegramBot::META::prereqs::runtime::requires::URI::Escape
Key: modules::TelegramBot::META::prereqs::runtime::suggests::Digest::MD5
Key: modules::freezemon::META::x_lang::de::abstract Value:Ein Modul das beim �berwachen und Analysieren von System freezes hilft
Key: modules::freezemon::META::x_lang::de::description Value:Das Modul �berwacht Verz�gerungen im FHEM System und stellt verschiedene Information bereit, die helfen, die Verursacher der Verz�gerung zu identifizieren

[rudolfkoenig]

Danke.

Die Funktion sucht nach Schluessel oder Werte, die "Wide-Character" enthalten oder mit dem internen UTF8-Flag markiert sind.
Letzteres ist nicht wirklich relevant.

[helmut]

Kannst Du bitte pruefen, ob "fhemdebug utf8check" bei Dir was meldet?
Diesen Befehl habe ich glatt uebersehen

Hallo Rudi,

dabei faellt mir gerade auf, dass die Hilfe des CLI mit der CommandRef nicht uebereinstimmt:

Usage: fhemdebug {enable | disable | status | timerList | addTimerStacktrace {0|1} | forceEvents {0|1} }

Gruss Helmut

[rudolfkoenig]

Danke fuer den Hinweis, habs geaendert.