DBLog,sqlite DB defekt, zum zweiten mal

[Guybrush]

USB beim PI4 soll besser als bei 1-3 sein. Mich stöhrt schon, das Leute von "soll" sprechen ... Hardware muß einffach funktionieren.

wieso soll? der Pi 4 hat USB 3.0. Das IST besser/schneller als USB 2.0, was die Pi Vorgänger nur hatten. Für die Pis reicht aber auch eine USB 2.0 to Sata Schnittstelle. Sata schafft zwar theoretisch 300 mb/s, aber die 60 mb/s mit usb 2.0 reichen. Die meisten SD Karten sind langsamer...

[Frank_Huber]

Es geht um USB am Raspberry, nicht um USB generell.
Am PI sind die USB suboptimal an der CPU dran und teilen sich das noch mit dem Netzwerk.
Der 4er ist da besser designt. Aber obs in der Praxis auch was bringt...

Gesendet von meinem S68Pro mit Tapatalk

[Guybrush]

die 4 usb ports sind bei allen raspberry pi nativ an die cpu angebunden. das einzige mank daran ist nur, dass zur cpu nur eine usb 2.0 leitung besteht, die dann über eine. hub aufgeteilt wird, insofern solange kein problem, wie man keine anderen datenfresser ranhängt.

[Wernieman]

Dann würde ich Dir Vorschlagen, das Du die Doku liest. USB IST an Pi1-3 ein Problem. Egal welche Version. Gibt auch genug Test dafür ....

Aber wir werden jetzt OT

[Frank_Huber]

Und beim 4er gibt es noch keine aussagekräftigen Testberichte.
Also ist und bleibt USB am PI wackelig.

Gesendet von meinem S68Pro mit Tapatalk

[Guybrush]

das ist zwar sicherlich nicht (mehr) ganz beim thema. mich interessieren aber gerade die ,,probleme". geht das genauer oder ists nur weiter transportiertes hörensagen?

grundlegend ist das beim Pi ziemlich alternativlos über usb einen massenspeicher anzubinden, wenn man viel io hat. iscsi etc fressen z.b. zuviel leistung, zumal die meisten dafür keine infrastruktur haben.

[wowogiengen]

Aha,
gut... Muss ich mir angucken.
Aber ich glaube, nein ich weiss, dass meine zerschossene Sqlite-DB auf meine Kappe geht...
Ich habe ein rsync von der diskstation auf den rpi gemacht, und irgendwie sichert der alles, was geht. Habe zwar ein exclude auf .db gemacht, aber eben nicht *.db und /proc/*, so dass die Datenbank während des Betriebs kopiert wurde, und das kann nur schief gehen.

Habe jetzt zum einen dem FHEM eine Zwangspause beim Beschreiben der Datenbank eingerichtet, für 4h, das sollte erst mal reichen. Zum Anderen habe ich den rsync wie oben beschrieben angepasst...:

Code Auswählen Erweitern

rsync -avuz --delete --numeric-ids --exclude=*.db --exclude=/mnt/* /proc/* -e ssh root@fhem2:/ /volume1/für_alle/Büro/Heimautomation/fhem2/aktuell/ >> /volume1/für_alle/Büro/Heimautomation/fhem2/$(date +%Y%m%d)-backup.log 2>&1
cp -Rv /volume1/für_alle/Büro/Heimautomation/fhem2/aktuell/ /volume1/für_alle/Büro/Heimautomation/fhem2/$(date +%Y%m%d) 2>&1

Viele Grüße
Wolfgang

Hallo,
bleiben wir mal beim Thema 

ich hab offensichtlich laut Log keine Probleme mit der Datenbank, aber beim SVGPlot kommen keine aktuellen Werte an.
Die Daten der letzten Wochen / Monate muss ich nochmals aus den ebenfalls vorhandenen Text-Logdateien importieren, aber alles was neu ist, ist nicht zu sehen

Wo kann ich da gucken ?
Werde heute abend mal nochmal die DB dumpen und dann auf dem PC anschauen, was da alles drin steht.
wo kann man die SVG-Plots zwischen History und Current umschalten?

VG Wolfgang

[Guybrush]

ich hab offensichtlich laut Log keine Probleme mit der Datenbank, aber beim SVGPlot kommen keine aktuellen Werte an.
Die Daten der letzten Wochen / Monate muss ich nochmals aus den ebenfalls vorhandenen Text-Logdateien importieren, aber alles was neu ist, ist nicht zu sehen

Wo kann ich da gucken ?
Werde heute abend mal nochmal die DB dumpen und dann auf dem PC anschauen, was da alles drin steht.
wo kann man die SVG-Plots zwischen History und Current umschalten?

define <name> SVG <logDevice>:<gplotfile>:<logfile>

bei <logfile> dann statt HISTORY CURRENT angeben

ansonsten würde ich einfach mal händisch daten aus der db auslesen, welche seit dem reingeschrieben worden sein müssen. wenn das schon keine Ergebnisse liefert, liegt das Problem jedenfalls nicht am SVGPlot

[DS_Starter]

Will mal kurz was gerade rücken ...

wo kann man die SVG-Plots zwischen History und Current umschalten?

garnicht. SVG-Plots mit DbLog ziehen die Daten immer aus der history Tabelle.
Die current ist ausschließlich als Ausfüllhilfe bei SVG Editor vorhanden.

Du kannst mit einem DbRep Device und "set <> fetchrows" immer einen Blick in die history oder auch current Tabelle werfen und siehst was drin steht bzw. geloggt wird.

Für eine SQLIte gibt es im DbRep auch eine Reparaturmöglichkeit (repairSQLite). Zumindest kann man es damit versuchen sofern nötig.

Grüße,
Heiko

[Guybrush]

@DS_Starter - das ist hardcoded im Quellcode drin? Gut zu wissen... ging jetzt nur davon aus, dass das nur als Default gilt. Wobei die Current von der Struktur für Plots wenig Sinn macht, hätte man mal vorher mehr denken müssen

[DS_Starter]

das ist hardcoded im Quellcode drin?

Es kommt eine Fehlermeldung wenn Current angegeben ist und wird intern auf history umgesetzt.

[Tedious]

das ist zwar sicherlich nicht (mehr) ganz beim thema. mich interessieren aber gerade die ,,probleme". geht das genauer oder ists nur weiter transportiertes hörensagen?

grundlegend ist das beim Pi ziemlich alternativlos über usb einen massenspeicher anzubinden, wenn man viel io hat. iscsi etc fressen z.b. zuviel leistung, zumal die meisten dafür keine infrastruktur haben.

Nichts ist alternativlos - da die Einrichtung etwas komplexer ist weil es nicht für jeden Schritt ein YT-Video gibt kann man auch Ebay und Co für einen ganz schmalen Taler Bananapi-M1/2/3 schießen. ich nutze u.a. auch einen einen BananaPi M2 Ultra - der hat von Haus aus 2GB DDR-3-Ram,  8Gb emmc Flash (man braucht also keine SD-Karte zum Betrieb, nur zum Einrichten) und einen dedizierten SATA-Port. Gepaart mit einer quad-core cortex -A7 ist der flott und sparsam unterwegs.

[Guybrush]

Nichts ist alternativlos - da die Einrichtung etwas komplexer ist weil es nicht für jeden Schritt ein YT-Video gibt kann man auch Ebay und Co für einen ganz schmalen Taler Bananapi-M1/2/3 schießen. ich nutze u.a. auch einen einen BananaPi M2 Ultra - der hat von Haus aus 2GB DDR-3-Ram,  8Gb emmc Flash (man braucht also keine SD-Karte zum Betrieb, nur zum Einrichten) und einen dedizierten SATA-Port. Gepaart mit einer quad-core cortex -A7 ist der flott und sparsam unterwegs.

Es mag sicher Alternativen geben. Ich bezog mein Feedback auf Raspberry Pi. Davon ab: Der Banana Pi ist jedenfalls keine Alternative. Der hat zwar einen direkten Sata Port, aber auch nur USB 2.0. Die Sata Schnittstelle ist jedoch nicht "dediziert". Das ist eine USB-to-Sata Bridge... Ist also defakto genauso schnell/lahm wie bei einem Raspberry Pi 1-3. USB/Eth/SATA haben da - wie beim Pi 1-3 - zusammen eine maximale Bandbreite von 60mb/s. Der Pi4 schafft wegen USB 3.0 600mb/s. Das langt für eine SSD und 1Gbe.

[Tedious]

...aber es ging ja hierbei nicht drum (ursprünglich) einen schnellen Fileserver aufzusetzen, sondern ein stabiles DB-System zu etablieren was nicht an ständigem Sterben von MicroSDs oder USB-Sticks durch hohe E/A leidet. Dabei ist es denn egal ob USB2 oder 3, denn einer SSD machen die vielen Schreibzugriffe im Vergleich zu obigem nahezu nichts aus. Zudem besitzt der Controller eine eigene Logik, Stichwort SMART und möglichem Alerting.

Zuguterletzt möchte ich (und ich habe auch diverse PIs im Einsatz) die interne eMMC definitiv nicht mehr missen.

[Wernieman]

Ich muß gestehen, das ich für eine dauerhafte Stabile HomeAutomatisation auf eine bessere Hardware als Pi (und Vergleichbare) setzen würde. Möchte da mein x86 Server nicht missen. Mit 7W (incl. Zusatz USB-Hub) ist er nicht weit weg von dem Verbrauch eines Pis, bei einer deutlich anderen Leistungsklasse.

Habe hier auch einen Pi, der macht aber "nur" Gateway .... und schreibt deshalb praktisch nichts. Genau das schreiben dürfte hier das Problem sein ....