Umsteig von fhem.cfg auf configDB

Begonnen von -Stefan-, 01 November 2014, 17:08:43

Vorheriges Thema - Nächstes Thema

Otto123

Sorry aber zumindest ab dem Post in diesem Thread von 11:24 Uhr bis jetzt muss "das Du beides umstellen willst" irgendwo zwischen deinem Kopf und den Händen steckengeblieben sein.  ;D Aber egal, haben wir ja jetzt geklärt.
Wobei dieser Thread gemacht wurde wegen Umstieg von fhem.cfg auf configDb - den würde ich jetzt nicht für DbLog kapern.

Datenbank auf dem Raspberry mit SD Card (auf SD Card) würde ich nicht machen. Ich fürchte, das "frisst Löcher" in die SD Card.
Zum Umstieg auf configDb kann ich nichts sagen.
Umstieg auf DbLog evaluiere ich gerade, das bringt sicher viele Vorteile. Die Umstellung der Plots kommt bei mir nicht einfach rüber. Bau Dir dazu was zum Testen und probiere etwas.
So jetzt ist gut mit DbLog im falschen Thread  :-X
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

87insane

Guter Hinweis wegen der SD. 2.5 jahre hat sie nun auf dem Buckel und lebt noch ...die wird sicher bald fällig. Aber gut, hatte auch schon überlegt alle beweglichen Daten auf dem NAS aus zu lagern. Allerdings kann ich dann hibernation oder sonst was vergessen. Naja...ich überlege noch.

Aber du migrierst gerade auch und ich persönlich würde mich freuen von dir zu hören...wie es lief, was nicht so toll war und und und. Wenn es keiner lesen mag, gern auch PN. Denke aber das wäre für alle gut. :)

Gesendet von meinem LG-H850 mit Tapatalk


betateilchen

... denn sie wissen nicht, was sie tun ...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

87insane

? In dem Fall?

Gesendet von meinem LG-H850 mit Tapatalk


FHEM-User22

Hallo,
ich war mal 3 Jahre mit 2 Raspis auf ConfigDB. Ich habe keinerlei Vorteile gefunden. Jetzt bin ich wieder zurück auf die fhem.cfg.
Für mich ist die fhem.cfg einfacher, weil:
-man im äussersten Notfall diese händisch ändern kann. Ich meine nur im äussersten Notfall.
-auch kann man einfach die fhem.cfg sichern und wenn man wenigstens aufs Dateisystem kommt, kann man immer eine ältere reinkopieren, wenn mal gar nichts mehr geht.

Dies soll zwar auch bei der DB funktionieren, das habe ich aber nicht hinbekommen bzw. hatte keine Geduld dazu.

Weiterin habe ich gehört (bitte berichtigen, wenns nicht stimmt!) das die cfg sowieso nur beim Start einmal eingelesen wird und dann ist sie im RAM. Auch vom Umfang her ists egal, denn ich habe eine fhem.cfg mit über 12.000 Zeilen gesehen, die funktionierte super und schnell.

Dies sind aber nur meine Meinungen/Erfahrungen und ich lasse mich gerne anderweitig informieren.

Viele Grüße
FHEM auf Raspberry Pi und Proxmox und... und.... und....

mele

Ich nutze config.db dank SQL-Kentnissen gerne zum Nachschlagen oder Wiederherstellen einzelner Config-Teile. Diese läuft auf einer Diskstation im Raid.

Gerade das save config / Neustarts empfinde ich deutlich schneller und das SD-Problem gibts nicht mehr. Hatte vorher schon eine SSD dran, aber mangels Backup-Möglichkeit ein schlechtes Gefühl.

LogDB habe ich erst später aufgebaut. Das Ganze als Container auf meinem NUC.

Offtopic: FHEM läuft in einem separaten Container auf dem NUC. Dank Snapshots lässt sich hier vieles ausprobieren und zurückdrehen.

Gesendet von meinem SM-G973F mit Tapatalk

FHEM auf NUC/Proxmox (Rpi 2 / Rpi Zero W mit FHEM2FHEM, RFHEM)
Homematic/LaCrosse/PCA301/Shelly, Rollladen, Batterieaktor + Relais zur Schaltung Garagentor (Promatic 2), Xiaomi FlowerSens, Bewässerungssteuerung Garten und Gewächshaus, Weatherman und Landroid

dirkcx

#51
Wie komme ich denn nach dem Umstieg auf configDB.db wieder zurück auf fhem.cfg?
Gibts auch ein configdb [b]un[/b]migrate

Mein Problem ist, dass mein FHEM nach einem shutdown restart nicht mehr startet.

Das fhem.log zeigt nur den Fehler Undefined subroutine &MQTT::DEVICE::client_attr called at ./FHEM/10_MQTT_DEVICE.pm line 232.
aber vor dem shutdown lief es ja.

Natürlich kann ich wieder normal starten mit der alten fhem.cfg, aber dann gehen ja alle Änderungen seit der Umstellung verloren.
Und deaktivieren von Devices geht ja leider auch nicht mehr so einfach, in der fhem.cfg konnte ich ja Bereiche "includen".

Außerdem ist die DB (Sqlite3) nun schreibgeschützt, d.h. auch mit sqlite3 configDB.db kann ich die DB zwar lesen, aber nicht schreiben: Error: attempt to write a readonly database
Und ja, ich habe die db temporär auf chmod 777 gesetzt und auch chown/chgrp auf meinen user/gruppe gesetzt.

*UPDATE*: der Mqtt Fehler lag schlicht an der falschen Reihenfolge. Das Device MQTT2_SERVER war später definiert als MQTT2_DEVICEs, was zur nächsten Frage führt: wie kann man bei Nutzung der configDB die Startreihenfolge der Devices beim Start von FHEM beeinflussen? Ich bin jetzt leider wieder bei fhem.cfg statt auf der DB Lösung :-( 

Tipps? Vielen Dank im Voraus
Server: Gigabyte GB-BACE3160 | Ubuntu 20.04 LTS Server | aktuelles FHEM | CULUSB (busware) FS20/FHT/... | MySensors: seriell / esp8266 | ZigBee (Zigbee CC2531 / zigbee2mqtt) | homebridge / homebridge-config-ui

amenomade

Zurück auf fhem.cfg ist hier dokumentiert: https://forum.fhem.de/index.php/topic,30551.msg232131.html#msg232131
Aber ich vermute, dein Problem hat eine andere Ursache...
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

betateilchen

Zitat von: dirkcx am 15 Dezember 2019, 09:29:25
*UPDATE*: der Mqtt Fehler lag schlicht an der falschen Reihenfolge. Das Device MQTT2_SERVER war später definiert als MQTT2_DEVICEs, was zur nächsten Frage führt: wie kann man bei Nutzung der configDB die Startreihenfolge der Devices beim Start von FHEM beeinflussen? Ich bin jetzt leider wieder bei fhem.cfg statt auf der DB Lösung :-( 

Tipps? Vielen Dank im Voraus


Das solltest Du im entsprechenden Forum zu MQTT posten. Die Reihenfolge der devices sollte eigentlich inzwischen keine Rolle mehr spielen. Umso mehr wundert es mich, dass gerade bei von Rudi programmierten Modulen dieses Fehlverhalten nach wie vor auftritt. Das Problem muss vom Modulautor für MQTT2.* gelöst werden, nicht von der configDB.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Noch ein Tipp: Nach einem "configdb migrate" hilft es nicht, ein "shutdown restart" auszuführen, und zu hoffen, dass FHEM dann mit configDB startet. FHEM muss dazu einmal komplett beendet und danach neu (mit configDB im Startskript) gestartet werden. Bei einem "shutdown restart" werden zwischenzeitliche Änderungen im Startskript nicht berücksichtigt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

amenomade

Zitat von: betateilchen am 15 Dezember 2019, 12:52:00
Noch ein Tipp: Nach einem "configdb migrate" hilft es nicht, ein "shutdown restart" auszuführen, und zu hoffen, dass FHEM dann mit configDB startet. FHEM muss dazu einmal komplett beendet und danach neu (mit configDB im Startskript) gestartet werden. Bei einem "shutdown restart" werden zwischenzeitliche Änderungen im Startskript nicht berücksichtigt.
Und genauso wenn man zurück auf fhem.cfg kommen will (wenn es dann unbedingt nötig wäre...)
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

dirkcx

Zitat von: betateilchen am 15 Dezember 2019, 12:52:00
Noch ein Tipp: Nach einem "configdb migrate" hilft es nicht, ein "shutdown restart" auszuführen, und zu hoffen, dass FHEM dann mit configDB startet. FHEM muss dazu einmal komplett beendet und danach neu (mit configDB im Startskript) gestartet werden. Bei einem "shutdown restart" werden zwischenzeitliche Änderungen im Startskript nicht berücksichtigt.

das hatte ich natürlich im /etc/systemd/system/fhem.service geändert, aber hier im konkreten Fall habe tatsächlich klassisch über die Kommandozeile gestartet "perl fhem.pl fhem.cfg"  ;)
Server: Gigabyte GB-BACE3160 | Ubuntu 20.04 LTS Server | aktuelles FHEM | CULUSB (busware) FS20/FHT/... | MySensors: seriell / esp8266 | ZigBee (Zigbee CC2531 / zigbee2mqtt) | homebridge / homebridge-config-ui

v1nc3nt

#57
Meiner Meinung nach fehlt in der Anleitung ein Hinweis für die Umstellung des Startskript. Im nachhinein ist das logisch, aber wenn man vor dem Problem sitzt, dass Fhem die Änderungen nicht in die DB übernimmt, dann sieht man das offensichtliche nicht. Bei mir kam in der Suche auch leider der Workshop für die Umstellung nicht, weswegen ich es auch nicht gefunden habe, habe aber im nachhinein über den Link im Commandref finden können. Trotzdem fände ich den Hinweis praktisch, da zumindest ich hauptsächlich das Commandref und ggf. das Wiki verwende.

Übrings ist das Startskript bei systemd-basierten System oft unter /etc/systemd/system/fhem.service zu finden als unter /etc/init.d/fhem wie es im Workshop beschrieben wird.

betateilchen

Zitat von: v1nc3nt am 01 September 2020, 22:29:22
Übrings ist das Startskript bei systemd-basierten System oft unter /etc/systemd/system/fhem.service zu finden als unter /etc/init.d/fhem wie es im Workshop beschrieben wird.

Mecker motz klugscheiß... mann mann mann...

Man achte einfach auf das Datum: als der Workshop 2016 entstand, war systemd noch kein Thema in/für FHEM.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!