Ich haben einen Versuch mit configDB gestartet - mySQL.
Ist so weit am Laufen - die Daten sid migriert, alles bootet.
1. Test: Ändern eines Attributs eines Devices -funktioniert.
2. save - funktioniert "configDB saved"
3. prüfen der Datanbank: Änderung ist nach save sichtbar - alles prima
4. fhem shutdown restore => die Änderung des Attributs ist nicht mehr vorhanden.
Mir als Datenbank Laien ist es nun nicht klar, woher FHEM nun die Daten beim Reboot zieht und warum es beim Speichern kein Problem anzeigt.
- was ist "shutdown restore" ?
- wie startest Du Dein FHEM ?
Ich vermute, Du hast zwar die Migration durchgeführt, aber das Startskript für FHEM nicht geändert, sodass jetzt immer noch die Konfiguration aus der fhem.cfg gelesen wird statt aus der Datenbank.
Mach mal bitte ein "list global"
Der Titel diese Threads ist übrigens komplett unsinnig. Wenn - wie Du selbst schreibst - die Änderung in der Datenbank steht, ist sie doch auch schon gespeichert...
sorry, restart.
Am Script liegt es nicht.
Ich habe es mehrfach probiert: "shutdown", dann ein "perl fhem configDB". Auch ein restart.
Wenn ich in der Datenbank lese sehe ich, dass sich der Wert "ändert", also der "Alte" wieder gesetzt wird. Es kann also nicht mit fhem.cfg gestartet worden sein.
Das Skript ist in der Tat nicht geändert, wird aber eben auch nicht genutzt
und: Speichert nicht stimmt in der Tat nicht "komplett". Unsinnig ist es aber erst, wenn ich das verfahren verstanden habe. Es wird etwas irdendwohin gespeichet aber beim Booten etwas anderes genutzt. Damit wird es schlussendlich zumindest nicht an der korrekten Stelle gespeichert.
Wenn du die Lösung kennst kann ich den Titel entsprechend anpassen.
Zitat von: martinp876 am 24 März 2018, 16:52:29
Damit wird es schlussendlich zumindest nicht an der korrekten Stelle gespeichert.
Falsch. Dein FHEM liest vermutlich etwas von der falschen Stelle. Und zwar
nur Dein FHEM.
Du bist doch derjenige, der immer 728 Forderungen an Fragesteller bzgl. Homematic stellt: Logauszüge, Informationen zu devices, gesniffte Funkdaten etc. Aber von Dir habe ich bisher werde etwas darüber gelesen, welche Meldungen Du auf der Konsole bekommst, wenn Du FHEM manuell startest, geschweige denn irgendwelche Logauszüge vom FHEM Start, aus denen man irgendwelche brauchbare Informationen ziehen kann.
Sorry - aber hellsehen kann ich auch nicht. Gerne helfe ich Dir, Deinem Problem auf die Spur zu kommen.
Nochmal... mach bitte ein "list global" und poste die Ausgabe.
Dann bitte noch die Ausgaben folgender Befehle:
- "configdb info"
- "configdb list deviceName" von dem device, in dem das Attribut nicht gesetzt wird.
Und höre auf, in der Datenbank herumzusuchen, das was
Du dort findest, hilft mir ziemlich wenig (genauer: nix).
klar nur mein FHEM. Logisch.
Aber warum und woher.
im "normalen" log sehe ich nichts. Ich frage dann immer nach "sniffen" was ich auch beschrieben habe.
Welche Logs kann ich zu Verfügung stellen? Welche muss ich einschalten?
-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
d:$Id: configDB.pm 16235 2018-02-20 21:53:26Z betateilchen $
c:$Id: 98_configdb.pm 16218 2018-02-18 19:23:23Z betateilchen $
-----------------------------------------------------------------
dbconn: mysql:database=fhem;host=192.168.178.33;port=3306
dbuser: fhemuser
dbpass: fhempassword
dbtype: MYSQL
-----------------------------------------------------------------
config: 34898 entries
Ver 0 saved: Sat Mar 24 16:25:29 2018 def: 353 attr: 2330
Ver 1 saved: Sat Mar 24 16:25:06 2018 def: 353 attr: 2330
Ver 2 saved: Sat Mar 24 15:52:13 2018 def: 353 attr: 2330
Ver 3 saved: Sat Mar 24 15:46:09 2018 def: 353 attr: 2330
Ver 4 saved: Sat Mar 24 15:43:25 2018 def: 353 attr: 2329
Ver 5 saved: Sat Mar 24 15:42:08 2018 def: 353 attr: 2329
Ver 6 saved: Sat Mar 24 15:41:25 2018 def: 353 attr: 2329
Ver 7 saved: Sat Mar 24 15:24:31 2018 def: 353 attr: 2330
Ver 8 saved: Sat Mar 24 15:23:34 2018 def: 353 attr: 2330
Ver 9 saved: Sat Mar 24 15:03:04 2018 def: 353 attr: 2330
Ver 10 saved: Sat Mar 24 15:01:56 2018 def: 353 attr: 2330
Ver 11 saved: Sat Mar 24 15:01:32 2018 def: 353 attr: 2330
Ver 12 saved: Sat Mar 24 14:58:10 2018 def: 353 attr: 2330
Ver 13 saved: by cfgDB_Init def: 3 attr: 5
-----------------------------------------------------------------
state: 10504 entries saved: Sat Mar 24 16:53:08 2018
-----------------------------------------------------------------
filesave: 16 files stored in database
-----------------------------------------------------------------
search result for device: deviceName in version: 0
--------------------------------------------------------------------------------
2018.03.24 19:01:16 1: PERL WARNING: main::readingsGroup() called too early to check prototype at ./FHEM/99_myUtils.pm line 740.
2018.03.24 19:01:16 1: PERL WARNING: main::readingsGroup() called too early to check prototype at ./FHEM/99_myUtils.pm line 756.
2018.03.24 19:01:16 1: PERL WARNING: main::readingsGroup() called too early to check prototype at ./FHEM/99_myUtils.pm line 773.
2018.03.24 19:01:16 1: PERL WARNING: main::readingsGroup() called too early to check prototype at ./FHEM/99_myUtils.pm line 780.
2018.03.24 19:01:16 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/99_myUtils.pm line 194.
2018.03.24 19:01:18.803 1: HMLAN_Parse: iohl1 new condition disconnected
2018.03.24 19:01:18.828 1: HMLAN_Parse: iohl1 new condition init
2018.03.24 19:01:31.852 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4137.
2018.03.24 19:01:39.708 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 470) line 1.
2018.03.24 19:01:39.711 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 471) line 1.
2018.03.24 19:01:39.719 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 476) line 1.
2018.03.24 19:01:39.722 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 477) line 1.
2018.03.24 19:01:39.729 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 482) line 1.
2018.03.24 19:01:39.732 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 483) line 1.
2018.03.24 19:01:39.739 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 488) line 1.
2018.03.24 19:01:39.741 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 489) line 1.
2018.03.24 19:01:41.997 1: PERL WARNING: laLnge userReadings duration evaluated to undef at fhem.pl line 4389.
2018.03.24 19:01:45.205 1: usb create starting
2018.03.24 19:01:46.129 1: usb create end
2018.03.24 19:01:46.662 1: Including setup/c_User.cfg
2018.03.24 19:01:49.464 1: ERROR evaluating {myfc("setup/tempList.cfg")}: Undefined subroutine &main::myfc called at (eval 1265) line 1, <$fh> line 48.
2018.03.24 19:01:49.947 0: Featurelevel: 5.8
2018.03.24 19:01:49.948 0: Server started with 354 defined entities (fhem.pl:16312/2018-03-02 perl:5.020002 os:linux user:pi pid:27858)
2018.03.24 19:01:50.232 0: HMLAN_Parse: iohl1 R:E610E1C stat:0000 t:000F8A7B d:FF r:FFBA m:88 A270 610E1C 1743BF 0092340000006400C8098D
2018.03.24 19:01:50.360 0: HMLAN_Parse: iohl1 R:E610E1C stat:0000 t:000F8D2E d:FF r:FFBB m:88 A270 610E1C 1743BF 0092340000006400C8098D
und schade, dass du nicht hellsehen kannst. Da hättest du mir deutlich etwas voraus :)
Mir ist unklar - und ich würde geren verstehen:
wenn ich einen Eintrag in der Datenbank sehe (mit fhem-externen tool, also direkt in mysql) ist es ja "drin". Wenn FHEM bootet liest es die Datenbank. Wenn ich nach der Migration boote wird die Datenbank gelesen - korrekt? Sie wurde also durch die Migration geschrieben - korrekt? Was läuft hier anders? Kann ich die Datenbank falsch aufgesetzt haben? Wenn ja, was kann man falsch machen?
Ich habe versucht, mich an die Anleitung zu halten. Weiter würde ich hoffen, dass ein Schreiben mir einer Fehlermeldung abbricht, wenn es nicht funktioniert (ok, hat ja - ein bisschen). Was also kann beim Booten anders laufen und warum und warum wird es beim Schreiben nicht gemerkt - und nicht alarmiert?
Ich bin ja nicht der erste und habe auch keine "besondere" Installation.
Zitat von: martinp876 am 24 März 2018, 19:16:08
search result for device: deviceName in version: 0
--------------------------------------------------------------------------------
Und jetzt das Ganze bitte nochmal in der Form, dass Du "deviceName" durch den tatsächlichen Namen des devices in Deiner Installation ersetzt...
Zitat von: martinp876 am 24 März 2018, 19:16:08
Wenn ich nach der Migration boote wird die Datenbank gelesen - korrekt?
Kommt darauf an, was Du mit "booten" meinst. Dein FHEM startet nach der Migration nicht automatisch mit der Datenbank.
Deshalb zum
dritten und letzten Mal:
Zitat von: betateilchen am 24 März 2018, 18:01:36
mach bitte ein "list global" und poste die Ausgabe.
Zitat von: martinp876 am 24 März 2018, 19:16:08
Was läuft hier anders?
Genau das versuche ich herauszufinden. Aber solange Du meine Fragen nicht beantwortest, habe ich dazu keine Chance.
sorry. Dass es leer ist sehe ich.
Willst du ein Beispiel? Oder soll ich alle Devices eintragen?
Hier ein Beispiel.
Dabei die Frage: Wie funktioniert das Kommando? Offensichtlich eine regexp... ?
search result for device: hv in version: 0
--------------------------------------------------------------------------------
define hv CUL_HM 3B0912
attr hv IODev iohl1
attr hv IOgrp ccu:iohl1
attr hv actCycle 000:10
attr hv actStatus alive
attr hv autoReadReg 5_readMissing
attr hv event-on-change-reading .*
attr hv expert 12_templOnly
attr hv firmware 1.4
attr hv group heatDevice
attr hv model HM-CC-RT-DN
attr hv room CUL_HM,Device,Heating
attr hv serialNr MEQ0449431
attr hv subType thermostat
attr hv webCmd getConfig:clear msgEvents:burstXmit
define hv_Clima CUL_HM 3B091204
attr hv_Clima event-on-change-reading .*
attr hv_Clima group heatCtrl
attr hv_Clima model HM-CC-RT-DN
attr hv_Clima peerIDs 00000000,
attr hv_Clima room CUL_HM,Heating
attr hv_Clima tempListTmpl Kind_weg
attr hv_Clima userReadings mystate {ReadingsVal($NAME,"state","-")." $NAME: 1"}
attr hv_Clima webCmd desired-temp:controlMode:tempTmplSet
define hv_Climate CUL_HM 3B091202
attr hv_Climate event-on-change-reading .*
attr hv_Climate group heatSupport
attr hv_Climate model HM-CC-RT-DN
attr hv_Climate peerIDs 00000000,
attr hv_Climate room unused
define hv_ClimaTeam CUL_HM 3B091205
attr hv_ClimaTeam event-on-change-reading .*
attr hv_ClimaTeam group heatSupport
attr hv_ClimaTeam model HM-CC-RT-DN
attr hv_ClimaTeam peerIDs 00000000,
attr hv_ClimaTeam room unused
define hv_remote CUL_HM 3B091206
attr hv_remote event-on-change-reading .*
attr hv_remote group heatSupport
attr hv_remote model HM-CC-RT-DN
attr hv_remote peerIDs 00000000,
attr hv_remote room unused
define hv_Weather CUL_HM 3B091201
attr hv_Weather event-on-change-reading .*
attr hv_Weather group temperatur
attr hv_Weather model HM-CC-RT-DN
attr hv_Weather peerIDs 00000000,610E1C01,
attr hv_Weather room CUL_HM,Heating,Sensor
define hv_WindowRec CUL_HM 3B091203
attr hv_WindowRec event-on-change-reading .*
attr hv_WindowRec group heatSupport
attr hv_WindowRec model HM-CC-RT-DN
attr hv_WindowRec peerIDs 00000000,
attr hv_WindowRec room unused
attr hv_WindowRec stateFormat last:trigLast
Hast Du einen Clown gefrühstückt?
Zitat von: martinp876 am 24 März 2018, 20:00:16
sorry. Dass es leer ist sehe ich.
Natürlich ist das leer, wenn Du keinen tatsächlich existierenden Namen eingibst.
Zitat von: martinp876 am 24 März 2018, 16:26:58
1. Test: Ändern eines Attributs eines Devices -funktioniert.
2. save - funktioniert "configDB saved"
3. prüfen der Datanbank: Änderung ist nach save sichtbar - alles prima
4. fhem shutdown restore => die Änderung des Attributs ist nicht mehr vorhanden.
Nimm den Namen DIESES devices, anhand dessen Du eingangs das Problem beschrieben hast.
Zitat von: martinp876 am 24 März 2018, 20:00:16
Dabei die Frage: Wie funktioniert das Kommando?
Das steht in der commandref. Aber der einfachste Fall ist: der Name EINES device.
Und auf das bereits
dreimal angefragte "list global"
warte ich immer noch!
von einem list device erwarte ich eigentlich etwas ähnliches wie von einem "list" eine Liste der devices. Aber in FHEM ist das überall anders.
Da ich erst anfange mit configDB habe ich auch mit den Komamndos noch nicht gespielt.
Das ist der name DIESES devices.
hier das list global
Internals:
DEF no definition
NAME global
NR 1
STATE no definition
TYPE Global
currentlogfile ./log/fhem-2018-03.log
logfile ./log/fhem-%Y-%m.log
Attributes:
autoload_undefined_devices 1
autosave 0
configfile configDB
logfile ./log/fhem-%Y-%m.log
modpath .
motd SecurityCheck:
WEB is not password protected
WEBphone is not password protected
WEBtablet is not password protected
telnetPort is not password protected
Protect this FHEM installation by defining an allowed device with define allowed allowed
You can disable this message with attr global motd none
mseclog 1
showInternalValues 0
statefile ./log/fhem.save
updateInBackground 1
userattr DbLogExclude DbLogInclude cmdIcon devStateIcon devStateStyle fp_anbau icon sortby webCmd webCmdLabel:textField-long widgetOverride
verbose 1
version fhem.pl:16312/2018-03-02
und wo (ausser im Code) kann man nun erfahren, wie die Daten von configDB eingelesen werden? geschrieben wird ja offensichtlich.
nun aber mal zusammenfassend:
ich hoffe nun alle Infos geschickt zu haben. Aber schaust du nicht völlig in die falsche Richtung?
- FHEM bootet aus der Danekbank
- fhem schreibt in die Datenbank
- fhem bootet mit historischen werten
=> liefert die Datenbank also historische Werte? Ist die Datenbank falsch eingestellt? Fragt FHEM nun "historiche" Werte ab oder liefert die Datenbank fälschlich historische Werte?
Da würde/werde ich ansetzen. Nur muss ich mich in das Verhalten und die Möglichkeiten erst einarbeiten/einlesen.
Kann FHEM die Korrekte Arbeitesweise der Datenbank prüfen? Also nach dem Schreiben testweise einfachen einen oder mehr Werte zurücklesen?
Zitat von: martinp876 am 25 März 2018, 07:34:02
Da würde/werde ich ansetzen. Nur muss ich mich in das Verhalten und die Möglichkeiten erst einarbeiten/einlesen.
Brauchst Du nicht.
Zitat von: martinp876 am 24 März 2018, 22:35:25
Da ich erst anfange mit configDB habe ich auch mit den Komamndos noch nicht gespielt.
Die sind auch nicht zum Spielen gedacht.
Zitat von: martinp876 am 25 März 2018, 07:34:02
Kann FHEM die Korrekte Arbeitesweise der Datenbank prüfen? Also nach dem Schreiben testweise einfachen einen oder mehr Werte zurücklesen?
Ja. Das versuche ich ja die ganze Zeit, mit Dir zu machen. Aber bisher boykottierst Du
jeden meiner Hilfeversuche.
Zitat von: martinp876 am 24 März 2018, 22:35:25
Das ist der name DIESES devices.
? ? ? ? ? Ich weiss immer noch nicht, von welchem Device Du redest. Aber das ist mir inzwischen auch egal.
Mach bitte
genau folgendes:
- define testDummy dummy
- save config
- configdb list testDummy -> Ausgabe hier posten
- attr testDummy verbose 0
- save config
- configdb list testDummy -> Ausgabe hier posten
Dann sehen wir weiter.
ZitatAber bisher boykottierst Du jeden meiner Hilfeversuche.
hm. von den Versuchen habe ich in der Tat bisher nichts gemerkt. Ausser den angeforderten debug infos.
search result for device: testDummy in version: 0
--------------------------------------------------------------------------------
define testDummy dummy
search result for device: testDummy in version: 0
--------------------------------------------------------------------------------
define testDummy dummy
attr testDummy verbose 0Das hat aber bisher immer funktioniert - habe ich einleitend mitgeteilt.
Das Problem tritt erst
nach einem Neustart auf.
Übrigens hat es nun zum Ersten mal fuktioniert:
ergab nun zum Ersten mal, dass nach den Neustart die 2. Gruppe eingetragen blieb.
attr hv group heatDevice
,lightSchaltund ja, ich habe immer ein save gemacht und dann einen shutdown. Und es war Zeit dazwischen, die Bestätgung des Save ist erfolgt.
Unterschied: Ich habe die Kommandos nun über ein Terminalfenster eingegeben, vorher über den Webbrowser.
Weiter:
In mySQL sind jede Menge historische Einträge. Können diese ein Problem sein? Kann es sein, dass gelegentlich von mySQL diese historischen Einträge gemeldet und verarbeitet werden?
Leider kann ich das Problem auch nach dem einen Erfolg nich tals gelöst verbuchen, ohne die Gründe verstanden zu haben.
Die beiden Testergebnisse belegen eindeutig, dass die Datenbank die Änderung korrekt in die Datenbank schreibt und auch von dort wieder zurückliest.
Beim Neustart wird IMMER die Version 0 aus der Datenbank gelesen. Nach einem Neustart muss also in dem testDummy auch das Attribut "verbose" wieder auf 0 stehen.
Zitat von: martinp876 am 25 März 2018, 11:37:26
In mySQL sind jede Menge historische Einträge. Können diese ein Problem sein?
Nein. Die Datenbank kannst Du aber auch jederzeit bereinigen, wenn Du die alten Versionen nicht mehr brauchst. "configdb reorg 5" löscht alle Konfigurationen aus der Datenbank - ausser den 5 neuesten Versionen. Bei mir läuft jede Nacht per AT ein reorg-Job, der 3 Versionen behält.
Zitat von: martinp876 am 25 März 2018, 11:37:26
Kann es sein, dass gelegentlich von mySQL diese historischen Einträge gemeldet und verarbeitet werden?
Nein. Es wird immer die Version 0 aus der Datenbank gelesen und als Konfiguration geladen, es sei denn, Du hättest FHEM mit Datenbank im rescue Modus gestartet und dabei eine bestimmte historische Version zum Laden vorbestimmt. Da Du aber offenbar die Doku eh noch nicht gelesen hast, schließe ich diesen Fall einfach aus.
Zitat von: martinp876 am 25 März 2018, 11:37:26
Leider kann ich das Problem auch nach dem einen Erfolg nich tals gelöst verbuchen, ohne die Gründe verstanden zu haben.
Für mich hat ein Problem nie bestanden und besteht auch jetzt nicht. Irgendwas hast Du vermutlich falschgemacht. Aber ich kann beim besten Willen nicht herausfinden, was das gewesen sein könnte. Wie die von Dir gelieferten Ergebnisse meiner Testanweisung beweisen, schreibt und liest die configDB absolut korrekt.
Zitat von: martinp876 am 25 März 2018, 11:37:26
hm. von den Versuchen habe ich in der Tat bisher nichts gemerkt. Ausser den angeforderten debug infos.
... die Du lange Zeit einfach nicht geliefert hattest. Wie soll ich da helfen?
Schönen Sonntag.
auf jeden Fall - Danke.
Ich werden es beobachten - und weiter üben :)
Da gibt es nichts zu üben. Das Ziel der Datenbank ist, so transparent zu funktionieren, dass für den Benutzer überhaupt keinen Unterschied zum Arbeiten mit textbasierten Konfigurationsdateien bemerkt.
Probleme mit der configDB haben hier im Forum eigentlich immer nur hyperaktive Anwender, die meinen, alles besser zu können als FHEM selbst.
Nun, das configfile funktioniert wunderbar. Warum stelle ich also auf eine datenbank um?
Von der datenbank erhoffe ich mir die gleiche Stabilität wie vom config file. Das ich in der lage sein will, diese zu bedienen ist mein ziel und, wie du festgestellt hast, keine voraussetzung für einen admin. Für hyperaktiv halte ich mich deswegen dennoch nicht.
Wie du schon angeleitet hast kann man die history in der db reduzieren. Beim config evtl nicht so wichtig, bei den logs schon. Meine Himbeere hat gelegentlich speicherplatz probleme. Aktuell sieht es wieder sehr gut aus. Aber dennoch muss ich es im auge behalten und mit den daten umgehen können. Nicht erst, wenn sie das nächste mal chashed.
Den aktuellen vorteil verspreche ich mir eigentlich nur von der auswertung der logs und dem erstellen von graphiken. Bei logfiles gibt es probleme mit der filegrösse sowie beim übergang von einem log in das nächste. Das sollte mit der db gelöst sein.
Das bereinigen der db von alten logs welche mich nicht mehr interessieren ( ich mache keine historischen wetteraufzeichnungen) muss ich mir also ansehen.
Fhem ist im Übrigen eine hobby installation. Konzeptionell so aufgesetzt. Viele anwender wollen wissen, wie das eine oder andere funktioniert. Je nach Neigung. Das ist das Konzept.
Zitat von: martinp876 am 26 März 2018, 06:40:19
Wie du schon angeleitet hast kann man die history in der db reduzieren. Beim config evtl nicht so wichtig, bei den logs schon.
...
Den aktuellen vorteil verspreche ich mir eigentlich nur von der auswertung der logs und dem erstellen von graphiken. Bei logfiles gibt es probleme mit der filegrösse sowie beim übergang von einem log in das nächste. Das sollte mit der db gelöst sein.
Das bereinigen der db von alten logs welche mich nicht mehr interessieren muss ich mir also ansehen.
Ja, schau Dir das gerne an. Aber bedenke bitte:
Das Logfile,das gesamte Thema Logging und Grafikaufbereitung mittels SVG hat mit der configDB soviel zu tun wie eine Kuh mit Strahlenschutz:
NULL - NIX - GAR NIXDbLog und configDB sind zwei völlig voneinander unabhängige Datenbankanwendungen innerhalb von FHEM.
Zitat von: betateilchen am 26 März 2018, 10:22:56
DbLog und configDB sind zwei völlig voneinander unabhängige Datenbankanwendungen innerhalb von FHEM.
oder, um es in Deiner FHEM-Welt zu beschreiben: Man muss keine MAX-Komponenten in FHEM einrichten, um Homematic nutzen zu können.
Ok, danke. (Sehr) gut zu wissen. Das habe ich im dblog wiki so nicht verstanden. Ich hatte verstanden, dass es aufbauend zu installieren ist. Gefaellt mir so VIEL besser!!!
Den Grund hatte ich nicht verstanden und so macht es Sinn. Die config brauche ich eigentlich nicht. Werde wiki noch mal mit diesem hintergrund lesen
Zitat von: martinp876 am 26 März 2018, 19:13:37
Ich hatte verstanden, dass es aufbauend zu installieren ist.
Du bist in über 4 Jahren Existenz von configDB der ERSTE, der auf diese absurde Idee kam.
An der Doku kann es also sicher nicht liegen.
Jetzt kann ich zumindest die Beruhigungstabletten wieder wegpacken und danach geh ich Popcorn holen.