Authorization Keys (Telegram, Alexa, etc.) gehen nach Neustart verloren

Begonnen von Flanders, 18 März 2022, 06:22:34

Vorheriges Thema - Nächstes Thema

Flanders

Hallo,

leider habe ich zu spät festgestellt, dass meine Festplatte randvoll ist.
Ein Click auf Speichern in FHEM zeigte eine Fehlermeldung.
Nun habe ich ein Backup zurückgespielt (Proxmox VM) und die Festplatte vergrößert.
FHEM läuft auch mit allen Komponenten anstandslos. Wenn ich nun auf SAVE drücke ist auch alles OK.

Nur wenn ich FHEM Neustarte, sehe ich im Startbild den ersten Fehler, das Telegram-Bot nicht erstellt wird, da ein Authorization-Token fehlt.
Alexa wird auch rot angezeigt, falsches Format im username:password.

Also es scheint, als würden die Authorization-Keys nicht korrekt gespeichert.
In welcher Datei werden sie gespeichert? Wie kann ich das Speichern forcieren?! Wo könnte der Fehler liegen?

Greets

Flanders

Flanders

Ich mutmaße ohne Wissen, das die Token nicht in der fhem.cfg gespeichert werden, sondern in der fhem.save?
Ist das korrekt?

Also würde ein speichern nur die aktuellen Geräte in die fhem.cfg schreiben.
Damit aber auch der Status und die Token?? gesichert werden (war ja wegen Speichermangels zunächst nicht möglich) würde ggf. ein {WriteStatefile()} helfen??

Greets

Flanders

Flanders

configfile: no predefined token found specify token in define: define  TelegramBot
setuuid: Please define Telegram first

und im log auch solche Fehlermeldungen:
2022.03.18 08:19:23.182 2: HUEBridge_OpenDev: got empty config
2022.03.18 08:19:23.280 2: gassistant: starting gassistant-fhem: /usr/bin/gassistant-fhem -c ./gassistant-fhem.cfg -a
022.03.18 08:19:43.025 2: alexa: starting alexa-fhem: /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg -a
2022.03.18 08:19:43.038 3: alexa: starting
2022.03.18 08:19:43.060 3: alexa: using logfile: ./log/alexa-2022-03-18.log
2022.03.18 08:19:43.147 3: alexa: read: end of file reached while sysread
2022.03.18 08:19:43.148 3: alexa: stopped
2022.03.18 08:19:43.378 3: CUL_HM set WLAN_Garten statusRequest noArg
2022.03.18 08:19:44.025 2: gassistant: starting gassistant-fhem: /usr/bin/gassistant-fhem -c ./gassistant-fhem.cfg -a

Spricht für eine inkorrekte Config


Greets

Flanders

Beta-User

In dem Backup sollte eigentlich auch die Datei "uniquiId" (Verzeichnis: FHEM/FhemUtils) zu finden sein. Da speichern die meisten (!) Module ihre Zugangsdaten rein, wenn sie sie nicht in der cfg haben wollen.

Ansonsten: Code-Tags sagt dir was? (sonst bitte mal die angepinnten Beiträge in diesem Forenbereich lesen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Flanders

Hallo,

die enstprechenden Daten scheinen ja noch im Speicher zu sein. Gibt es eine Möglichkeit sie wieder in die Dateien zu schreiben (analog eines Save, WriteStatefile()) Befehls?

Greets

Flanders

Beta-User

Wenn die Datei beim Start nicht da war, ist auch nichts im RAM zu finden.
Man kann zwar einzelne keys in die Datei schreiben, aber das würde ich hier nicht empfehlen, sondern wenn, dann musst du die Datei von deiner alten Installation holen.

Warum hast du da eigentlich nicht einfach erst mal für "etwas" Platz gesorgt um dann in Ruhe die laufende Konfiguration kommplett in ein Backup zu schreiben?

Im Übrigen: die aufgeführten .cfg-Dateien hast du auch in das neue System transferiert? Sonst kann es an der Stelle auch deswegen nicht klappen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Flanders

Also ich habe ein Backup zurückgespielt, da läuft alles beim Start. Nach einem Neustart von FHEM fehlen ihm die Daten. Daher scheint es doch irgendwo im Speicher zu sein.

Mit dem Platz schaffen ist lustig, ich habe es vermutlich zu spät bemerkt...

Also habe ich nun folgendes gemacht, ein Backup (VM) von Februar zurück gespielt, da war noch was Platz auf der Platte und ein Neustart von FHEM läuft auch noch, Platz gemacht (Platte vergrößert). Jetzt werde ich die fehlenden Configs nachtragen....

Ich vermute, dass eine Datei beim Schreiben korrupt wurde, da kein Platz mehr auf der Platte war...

Greets

Flanders

MadMax-FHEM

Bei alexa-fhem gibt es neben den Zugangsdaten für ein u.U. abgesichertes fhem (attr alexaFHEM-auth / gespeichert verm. wie Beta-User geschrieben hat) auch noch (sofern alexa-fhem Connector) die ssh-Schlüssel unter /opt/fhem/.ssh (Standardinstallation).

Entweder diese (falls "weg") auch aus Altsystem sichern (Rechte beachten!! Nicht einfach irgendwelche Rechte/Besitzstände "drüberbügeln"!) oder den Skill neu verbinden (u.U. vorher "deregistirieren" -> siehe Wiki).

EDIT: u.U. auch bei gassistant, ist ja "ähnliche Code-Basis"...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)