Moin zusammen
Mein fhem hat es zerrissen. Die im Titel angegebene Meldung ist die letzte im log.
Dummerweise bin ich ja nicht so fit mit Datenbanken, so dass man mich immer erst in die richtige Richtung stuppsen muss.
Leider ist das mein Hauptsystem, und ja ich habe es immer noch nicht hochgezogen.
Kann mir eventuell jemand helfen?
Gruss und Danke im Voraus
Christoph
Database oder Disk full? => was sagt "df -h" auf dem DB Server?
Moin und sorry
Die Hitze schafft mich!
Ich habe echt null Bock am Rechner zu sitzen!
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root 30G 28G 2,7M 100% /
devtmpfs 458M 0 458M 0% /dev
tmpfs 462M 0 462M 0% /dev/shm
tmpfs 462M 6,4M 456M 2% /run
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 462M 0 462M 0% /sys/fs/cgroup
/dev/mmcblk0p1 63M 21M 42M 34% /boot
Zugegebenermassen lief es irgendwann dann doch wieder, ich hatte wegen disk-full auch schon diverse logs geloescht. Aber jetzt ist es einfach so mittendrin gestorben!
2020.08.11 12:07:36 3: Cube: Unknown code A06B7D0663EEB81, help me!
2020.08.11 12:07:44 3: myJeeLink: Unknown code OK 9 36 1 4 242 54, help me!
2020.08.11 12:07:52 3: myJeeLink: Unknown code OK 9 36 1 4 242 54, help me!
2020.08.11 12:08:00 2: Display: Error from line 'img 20 33 0.5 png file { "/opt/fhem/www/images/default/weather/" . ReadingsVal("Wetter","icon","") . ".png" }' in layout definition: Can't use an undefined value as a symbol reference at /usr/lib/arm-linux-gnueabihf/perl5/5.20/GD/Image.pm line 176.
2020.08.11 12:08:00 3: myJeeLink: Unknown code OK 9 36 1 4 242 54, help me!
2020.08.11 12:08:01 3: Cube: Unknown code A065126D1B1CFBB, help me!
2020.08.11 12:08:01 3: Cube: Unknown code A0644F870B1CFBB, help me!
2020.08.11 12:08:01 3: Cube: Unknown code A0644F870B1CFBB, help me!
2020.08.11 12:08:02 3: Cube: Unknown code A0644F870B1CFBB, help me!
2020.08.11 12:08:03 3: Cube: Unknown code A0644F870B1CFBB, help me!
2020.08.11 12:08:03 3: Cube: Unknown code A0644F870B1CFBB, help me!
2020.08.11 12:08:04 3: Cube: Unknown code A0644F870B1CFBB, help me!
2020.08.11 12:08:09 3: myJeeLink: Unknown code OK 9 36 1 4 242 54, help me!
2020.08.11 12:08:10 3: GW_CUL_868_Reconnect: GW_CUL_868 version => V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) miniCUL (F-Band: 868MHz)
2020.08.11 12:08:15 3: Cube: Unknown code A0659A400B1CFBB, help me!
2020.08.11 12:08:17 3: GW_CUL_433_Reconnect: GW_CUL_433 version => V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) miniCUL (F-Band: 433MHz)
2020.08.11 12:08:17 3: myJeeLink: Unknown code OK 9 36 1 4 242 54, help me!
2020.08.11 12:08:22 3: GW_CUL_NEX_433_Reconnect: GW_CUL_NEX_433 version => No answer
2020.08.11 12:08:24 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at ./FHEM/72_FRITZBOX.pm line 1514.
2020.08.11 12:08:26 3: myJeeLink: Unknown code OK 9 36 1 4 242 54, help me!
2020.08.11 12:08:26 3: SIGNALESP_433: Unknown code u20#D5D7FD5DF75FD5FD7D750, help me!
2020.08.11 12:08:35 3: Cube: Unknown code A069D2F94B1CFBB, help me!
2020.08.11 12:08:36 3: myJeeLink: Unknown code OK 9 36 1 4 242 54, help me!
2020.08.11 12:08:43 3: PCA301 PCA301_022053, channel changed from 11 to 04
2020.08.11 12:08:48 3: PCA301 PCA301_022053, channel changed from 04 to 11
2020.08.11 12:09:00 1: PERL WARNING: DBD::SQLite::db commit failed: database or disk is full at configDB.pm line 552.
DBD::SQLite::db commit failed: database or disk is full at configDB.pm line 552.
Ich weiss ja, dass ich seit zwei (oder sind es schon drei?) Jahren davon rede, dass ich das System mal hochziehen muesste.
Wie habe ich es frueher immer zu meinen MA gesagt: lernen durch Schmerzen!
Das bloede ist nur, dass die Config-db nicht so wirklich dokumentiert ist. So dass ich alles einfach raus und wieder reinbekomme.
Vor Donnerstag wird es aber nichts, da morgen Stammtisch!
Gruss und Danke
Christoph
Zitat von: pc1246 am 11 August 2020, 22:59:56
Das bloede ist nur, dass die Config-db nicht so wirklich dokumentiert ist. So dass ich alles einfach raus und wieder reinbekomme.
Vor Donnerstag wird es aber nichts, da morgen Stammtisch!
Erstens ist Dein Beitrag in "Anfängerfragen" völlig falsch.
Zweitens ist das, was Du da als "fehlend" bemängelst, nichts was configDB spezifisch wäre, es handelt sich um bei Dir fehlendes Datenbank-Grundwissen.
Drittens bist Du ganz schön mutig, Dein FHEM in diesem instabilen Zustand noch bis Donnerstag laufen lassen zu wollen.
Aber Du hast doch auch Glück: Du arbeitest mit sqlite. Da ist der Umzug der configDB sehr einfach und besteht nur aus dem Kopieren der verwendeten Datenbankdatei vom alten System auf das neue System.
Die Datenbankdatei solltest Du auf jeden Fall jetzt schonmal irgendwohin ausserhalb Deines FHEM kopieren, damit Du am Donnerstag wenigstens noch eine hoffentlich funktionierende Datenbank hast.
Moin
Und danke fuer die ermunternden Worte!
Die DB ist 27GB gross, das wird wohl das Problem sein!? Wie mache ich die denn mal klein, und ja ich weiss, dass mein Wissen da sehr gering ist, wenn nicht sogar gegen null geht!
Gruss Christoph
P.S.: Morgen habe ich uebrigens auch nicht wirklich Zeit, da habe ich 1E-Hochzeitstag
Mach doch mal ein "configdb reorg 5" dann werden alle alten gespeicherten Konfigurationen aus der Datenbank gelöscht - bis auf die letzten 5.
Nach dem Aufruf nicht die Geduld verlieren, bei einer so großen Datenbank kann das eine Weile dauern.
Zitat von: pc1246 am 12 August 2020, 17:54:50
Wie mache ich die denn mal klein, und ja ich weiss, dass mein Wissen da sehr gering ist, wenn nicht sogar gegen null geht!
Wir reden hier über einen FHEM-internen Befehl zur configDB. Dazu muss man nicht viel mehr Wissen haben, als dass es eine commandref dazu gibt, in der man sowas nachlesen könnte.
Moin
Danke Udo, aber so wie es aussieht, mag fhem nicht mehr am Leben bleiben. Somit muss ich das von BS Ebene aus machen.
Ich meine diesen Befehl auch schon mal ausgefuehrt zu haben. Aber wer weiss das schon?
Gruss Christoph
Hast Du mal probiert, FHEM im rescue-Modus zu starten und dann das configdb reorg auszuführen?
Nee
Habe ich natuerlich nicht, da ich gar nicht weiss wie es geht!
Ich habe hier https://forum.fhem.de/index.php/topic,66646.msg579338.html#msg579338 was gefunden, nur meine ich das "vacuum" bei mir nicht mehr geht, da ich ja keinen Speicher mehr frei auf der Karte habe!?
Gruss und Danke fuer Deine Zeit
Christoph
Nachtrag
Gibt e das in meiner fhem Version ueberhaupt schon?
fhem.pl 15182 2017-10-03 10:45:29Z rudolfkoenig $
Zitat von: pc1246 am 12 August 2020, 18:41:18
Habe ich natuerlich nicht, da ich gar nicht weiss wie es geht!
Auch das steht in der commandref. Und es gibt hier im Forum auch Beschreibungen dazu.
Die Reparaturversuche werden aber alle nicht funktionieren, wenn Du das auf der vollen SD Karte versuchst.
Kopiere die Datenbankdatei auf einen möglichst großen USB Stick (mindestens 2 * 27GB) und versuche dort das vacuum auszuführen.
immer wieder wird empfohlen, ein desaster-recovery zumindest mal zu üben, solange alles funktioniert.
Aber nein, sowas braucht man ja nicht... *kopfschüttel*
Nach einer Datensicherung der Datenbank wage ich gar nicht mehr zu fragen...
Ok
Das dachte ich mir schon! Dann ziehe ich mal eine Kopie. Und wenn ich nachher zurueckkomme, sollte die ja fertig sein.
Gruss Christoph
Zitat von: betateilchen am 12 August 2020, 18:45:06
immer wieder wird empfohlen, ein desaster-recovery zumindest mal zu üben, solange alles funktioniert.
Aber nein, sowas braucht man ja nicht... *kopfschüttel*
Nach einer Datensicherung der Datenbank wage ich gar nicht mehr zu fragen...
Doch gibt es, ist ca. 3 Monate alt
Zitat von: pc1246 am 12 August 2020, 18:42:21
Nachtrag
Gibt e das in meiner fhem Version ueberhaupt schon?
den rescue mode gibt es mindestens seit Januar 2016, das Vorgehen hat sich aber 2018 geändert.
Aber sowohl das alte wie das neue Verfahren sind im Forum beschrieben.
Moin
So die DB ist jetzt 2mal auf meinem Rechner.
Mit DB-Browser for SQLite wuerde ich jetzt komprimieren wollen. Es gibt auch einen Menuepunkt "Datenbank komprimieren", aber kleiner wird sie nicht, zumindest das file.
Zur Wahl stehen zwei Datenbanken, "main" und "temp". Main laeuft auch recht lange, und der Rechner ackert auch ordentlich, aber hinterher ist nichts passiert. Oder is ein Schliessen der DB das Mittel der Wahl?
Gaebe es auch einen SQL-Befehl, mit dem ich die Datenmenge reduzieren koennte? In welcher Tabelle wuerde ich die Unmengen an Daten denn sehen. Die config scheint leer zu sein, zumindest erster Blick im Browser!
Irgendwie stehe ich immer wieder wie der Ochs vorm Tor. Ich bekomme meinen Kopf nicht dazu das so zu verinnerlichen, dass ich mich mit Leichtigkeit bewegen kann!
Mir sind die Tabellen klar, und auch die Eintraege, und auch die eigentliche "Historie", aber trotzdem stehe ich an!
Ich lass den jetzt noch mal auf der main ackern, und sehe dann ja morgen was passiert ist.
Ihr braucht auch kein Blatt vor den Mund nehmen (macht Udo ja eh nicht! ???), das ficht mich nicht an!
Ich habe immer so viel auf dem Zettel, dass das dann irgendwann einfach runterfaellt, es laeuft ja.
Ok momentan nicht, aber das ist fast nicht so schlimm, es wird nur ein wenig waermer, da Rollaeden nicht beschatten.
Demuetige Gruesse
Christoph
P.S.: Wenn ich jetzt eine 128GB Karte stecke, und alles darauf packe, ginge das verkleinern dann? ODer ist die DB einfach schon zu gross?
Moin
Da habe ich mir ja mal wieder was eingebrockt.
Ok, jetzt meine Frage an Udo, in der VERSIONUUID wird ja irgendwie Datum und Uhrzeit oder etwas Aehnliches enthalten sein.
Somit haette ich die Moeglichkeit per SQL Befehl alte Daten zu loeschen. Kann man das aufschluesseln, so dass ich nicht mehr drei oder vier Jahre in der DB habe?
So ganz nebenbei, ein CSV Export hat eine knapp 16GB grosse CSV erzeugt. Zum Gluck kann man das splitten.
Danke und Gruss
Christoph
Nachtrag: So langsam sehe ich durch. Was mich allerdings sehr verwundert, es sind alle paar Minuten (keine wirkliche Regelmaessigkeit, aber um die 2) neue Eintraege in der DB.
Deswegen ist die auch so gross, denn alle 2 Minuten knapp 5000 Zeilen, das laeppert sich! Das hat irgendwann letztes Jahr angefangen, davor war es ab und zu mal fuer eine kurze Zeit, dass das passiert ist.
Zwischenfragen von einem bisher stillen Mitleser:
- Warum gehst du hier (sobald FHEM wieder läuft) über externe SQL-Befehle und nicht über den in configdb integrierten "behalte xyz-Versionen"-Befehl (reorg)?
- Wenn die DB wächst, muß es eigentlich doch auch Änderungen in der config (oder in der DB vorhandenen Files einschließlich der "statefile") geben? Und (sofern cfg) dazu (vermutlich) sowas wie ein (automatisches) "save" abgesetzt werden? Sonst wird doch auch die DB doch eigentlich nur lesend zugegriffen, oder unterliege ich da einem grundsätzlichen Verständnisirrtum?
Zitat von: Beta-User am 14 August 2020, 10:29:54
- Wenn die DB wächst, muß es eigentlich doch auch Änderungen in der config (oder in der DB vorhandenen Files einschließlich der "statefile") geben?
Das Statefile wird nicht mit versioniert, das ist immer nur einmal in der Datenbank vorhanden.
Gleiches gilt für in der Datenbank gespeicherte Dateien, auch die sind nur einmal vorhanden.
@pc1246
Zitat von: pc1246 am 14 August 2020, 09:13:32
in der VERSIONUUID wird ja irgendwie Datum und Uhrzeit oder etwas Aehnliches enthalten sein.
Nein.
Zu den Versuchen, manuell in der Datenbank rumzupfuschen, kann (und will) ich eigentlich keinen Support leisten.
Trotzdem ein Tipp:
- suche Dir in der Tabelle fhemversions die Version 0 raus und verwende die zugehörige VERSIONUUID
- lösche in in der Tabelle fhemconfig alle Einträge, bei denen die VERSIONUUID nicht der in 1. notierten UUID entspricht
Du solltest in Deiner configDB - wenn Dein FHEM wieder funktioniert - das Attribut "maxversions" setzen.
Wie das geht, steht wie vieles andere auch, in der commandref.
Warum Dein FHEM alle zwei Minuten die Konfiguration abspeichert, musst Du in Deiner Installation rausfinden.
@Beta-User
Leider laeuft fhem nicht mehr! Und wenn ich es richtig verstanden habe, dann braucht reorg auch ersteinmal Platz!?
@betateilchen
Danke, das hatte ich mit den CSV-Dateien auch schon gefunden.
Dein Vorschlag ist fuer mich aber irgendwie nicht durchfuehrbar, oder ich muss laenger warten.
Ich bin ein visueller Mensch, darum habe ich totale Probleme eine DB in der Kommandozeile zu oeffnen, da ich mich dann blind fuehle.
Der "DB Browser for SQLite" zeigt mir aber erstmal den Inhalt der Tabelle fhemconfig nicht, und ist jetzt gerade einfach abgestuerzt.
Das liegt mich Sicherheit daran, dass ich ca. 186.786.000 Zeilen in der DB habe.
Ich habe jetzt mal eine Idee, und werde das mal versuchen.
Gruss Christoph
Zitat von: pc1246 am 14 August 2020, 11:39:43
Ich bin ein visueller Mensch, darum habe ich totale Probleme eine DB in der Kommandozeile zu oeffnen, da ich mich dann blind fuehle.
auch blinde Menschen kommen in ihrem Leben ganz gut zurecht...
sqlite3 <datenbankName>
select versionuuid from fhemversions where version = 0;
delete from fhemconfig where versionuuid != <versionuuid_aus_dem_ersten_Befehl>;
vacuum;
.exit
Moin
So dann mal meine Vollzugmeldung. Danke fuer die Anleitung, leider kam die Meldung "ERROR unrecognized token: "xxx"".
Da ich mir ja schon einen eigenen Plan zurechtgelegt hatte, war der natuerlich vorher dran.
Ich habe aus den knapp 600 CSVs die erste und die letzte genommen, davon Teile in eine neue zusammenkopiert, und das in eine leere fhemconfig Tabelle importiert.
Hier kam auch wieder die Nase, da irgendwie das Escapen mit den "" beim Import nicht richtig erkannt wurde.
Ok, dann noch SQLiteStudio gefunden, und siehe da, ich konnte mir die Tabelle nach einiger Zeit ansehen. Aber immer nur 1000 Zeilen pro Seite, und der Seitenwechsel geht in der Bundesliga schneller. Somit auch keine Loesung!
Mit betateilchens Weg hat es wie oben geschrieben auch nicht funktioniert.Und jetzt mache ich den doppelten Schritt.
Die Befehle im SQLiteStudio eingegeben, und mit etwas rumprobieren festgestellt, dass die versionuuid natuerlich keine Zahl ist, und in "" gehoert.
Jetzt loescht er, und dann noch vacuum und dann sollte das fhem wieder laufen!
Gruss und Danke an alle
Christoph
Moin
Trotzdem das eigentliche Problem zwar geloest ist, habe ich aber noch ein paar Probleme!
Diese sind, aufgrund des alten fhem, recht vielschichtig.
- erstmal Entschuldigung an Udo: das Problem, dass ich immer meine, dass configDB nicht dokumentiert ist, liegt daran, dass es bei mir so alt ist.
Somit kann ich in der Befehlszeile gar nichts eingeben, was irgendwie mit configdb zu tun hat - Das 2-minuetige Speichern laeuft immer noch, so dass ich schon wieder bei 7 GB bin.
Im Eventmonitor sehe ich alle ca. 2 Minuten "Global global SAVE"
Im global device habe ich daraufhin das autosave ausgeschaltet, speichert aber froehlich weiter. - $Id: configDB.pm 15096 2017-09-19 12:55:19Z
- $Id: fhem.pl 15182 2017-10-03 10:45:29Z
Ich weiss, dass ich schon seit Ewigkeiten schreibe, dass ich das fhem hochziehe, aber es fehlt mir echt die Zeit.
Habe ich irgendeine Chance rauszufinden, wer da staendig meint speichern zu muessen?
Kann ich das fhem irgendwie dazu ueberreden, dass ich die configdb Befehle eingeben kann?
Danke und Gruss
Christoph
Mach endlich ein Update! Zitat von: pc1246 am 23 August 2020, 15:07:36
Ich weiss, dass ich schon seit Ewigkeiten schreibe, dass ich das fhem hochziehe, aber es fehlt mir echt die Zeit.
Das Argument "keine Zeit" lasse ich nicht mehr gelten. Überlege mal, wieviel Zeit Du
(und ich) schon völlig sinnloserweise, in die Lösung Deines aktuell bestehenden Problems investiert und verschwendet haben.
In dieser Zeit hätte man problemlos 10 FHEM Neuinstallationen inkl. Übernahme der bestehenden Konfiguration durchführen können.
Tja, und Du erwartest ernsthaft weiterhin, dass man Dir hier dauerhaft unbegrenzt weiterhilft?
Erste Regel für Anwender mit Problemen bei FHEM: Verwende die aktuelle Version!
Dein Verhalten finde ich als Entwickler äußerst unfair und egoistisch (anderen Anwendern gegenüber).
Zitat von: pc1246 am 23 August 2020, 15:07:36
Kann ich das fhem irgendwie dazu ueberreden, dass ich die configdb Befehle eingeben kann?
Die Datei 98_configdb.pm, in der die FHEM Befehle bereitgestellt werden, gibt es bereits seit 2014...
Entweder Deine FHEM Installation ist nicht nur alt, sondern auch unvollständig oder Du machst beim Eingeben der configdb Befehle irgendwas grundsätzlich falsch.
Was passiert denn, wenn Du "configdb info" eingibst?
Um das Anwachsen der Datenbank zu reduzieren, hatte ich bereits die Verwendung von "configdb reorg" oder das Setzen des Attributes "configdb attr maxversions 5" empfohlen.
Bei mir läuft "configdb reorg" per at jede Nacht um 3 Uhr, das ist die perfomantere Lösung im Vergleich zum Setzen des Attributes.
Zitat von: pc1246 am 23 August 2020, 15:07:36
Habe ich irgendeine Chance rauszufinden, wer da staendig meint speichern zu muessen?
Vermutlich indem Du den Loglevel Deiner FHEM Installation hochdrehst und das Log beobachtest.
Aber mit configDB hat diese Suche nichts zu tun.
Zitat von: pc1246 am 23 August 2020, 15:07:36
erstmal Entschuldigung an Udo: das Problem, dass ich immer meine, dass configDB nicht dokumentiert ist, liegt daran, dass es bei mir so alt ist.
Somit kann ich in der Befehlszeile gar nichts eingeben, was irgendwie mit configdb zu tun hat
Diese Behauptung ist absoluter Blödsinn. Selbst wenn es diesen Zusammenhang gäbe, könntest Du die (aktuelle) Dokumentation zumindest auf https://commandref.fhem.de nachlesen.
Moin
Unknown command configdb, try help.
Und das ist somit genau mein Problem! (Abgesehen von mir selbst!)
Wenn man gar nichts in Bezug auf configdb eingeben kann, dann ist es extrem schwierig! Und dann hilft auch keine Doku, die ja nicht passt.
Gruss Christoph
Internals:
DEF no definition
NAME global
NR 1
STATE no definition
TYPE Global
currentlogfile ./log/fhem-2020-08.log
logfile ./log/fhem-%Y-%m.log
Attributes:
altitude 72
autoload_undefined_devices 1
autosave 0
backupdir /home/pi/NAS/Backups
configfile configDB
holiday2we ni.holiday
latitude 52.293889
logfile ./log/fhem-%Y-%m.log
longitude 10.404722
modpath .
motd SecurityCheck:
WEB,WEBhook,WEBphone,WEBtablet has no associated allowed device with basicAuth.
telnetPort has no associated allowed device with password/globalpassword.
Restart FHEM for a new check if the problem is fixed,
or set the global attribute motd to none to supress this message.
room IO_DEV
sendStatistics onUpdate
statefile ./log/fhem.save
updateInBackground 1
userattr DbLogExclude DbLogInclude alarmDevice:Actor,Sensor alarmSettings cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride
verbose 5
version fhem.pl:15182/2017-10-03
- und steht dazu was im Log?
- existiert in Deinem FHEM die Datei ./FHEM/98_configdb.pm?
- Was willst Du mir mit dem list Deines global device sagen?
log ist im Bezug darauf leer
global sollte Dir nur zeigen, dass ich auch wirklich configdb nutze
98_configdb.pm ist da: $Id: 98_configdb.pm 16218 2018-02-18 19:23:23Z
was ergibt ein "reload 98_configdb.pm" ?
Zitat von: pc1246 am 23 August 2020, 17:24:40
global sollte Dir nur zeigen, dass ich auch wirklich configdb nutze
Habe ich das irgendwo bezweifelt?
Nein
So ich habe jetzt noch mal gelesen, was Du geschrieben hast. Im log steht natuerlich doch was drin, ich hatte den event-Monitor leider im Fokus:
2020.08.23 17:20:31 4: WEB_192.168.178.119_62939 POST /fhem&fw_id=118988&room=IO_DEV&fwcsrf=csrf_143779232006080&cmd=configdb+info; BUFLEN:0
2020.08.23 17:20:31 5: Cmd: >configdb info<
2020.08.23 17:20:31 5: Loading ./FHEM/98_configdb.pm
2020.08.23 17:20:31 1: reload: Error:Modul 98_configdb deactivated:
Too many arguments for main::_cfgDB_Info at ./FHEM/98_configdb.pm line 220, near "'$Id: 98_configdb.pm 16218 2018-02-18 19:23:23Z betateilchen $')"
BEGIN not safe after errors--compilation aborted at ./FHEM/98_configdb.pm line 300.
2020.08.23 17:20:31 0: Too many arguments for main::_cfgDB_Info at ./FHEM/98_configdb.pm line 220, near "'$Id: 98_configdb.pm 16218 2018-02-18 19:23:23Z betateilchen $')"
BEGIN not safe after errors--compilation aborted at ./FHEM/98_configdb.pm line 300.
2020.08.23 17:20:31 4: WEB: /fhem&fw_id=118988&room=IO_DEV&fwcsrf=csrf_143779232006080&cmd=configdb+info / RL:1739 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
Und ich habe zwischenzeitlich die Ursache gefunden...
Zitat von: pc1246 am 23 August 2020, 15:07:36
$Id: configDB.pm 15096 2017-09-19 12:55:19Z
Zitat von: pc1246 am 23 August 2020, 17:24:40
$Id: 98_configdb.pm 16218 2018-02-18 19:23:23Z
Warum ist die Datei 98_configdb.pm sehr viel jünger als die Datei configDB.pm?
Beide Dateien wurden in der Rev #16218 bereitgestellt, in Deinem FHEM wurde aber nur eine der Dateien aktualisiert.
Mach endlich ein Update!
Zitat von: pc1246 am 23 August 2020, 17:17:18
Und das ist somit genau mein Problem! (Abgesehen von mir selbst!)
Nein, das hier ist Dein Problem:
Du hast ein total vermurkstes FHEM, in dem die Modulversionen altersbedingt nicht zusammenpassen und wunderst Dich über merkwürdige Effekte... *kopfschüttel*