Es ist kein USB-Speicher für die Speicherung der Diagrammdaten vorhanden oder auf diesen konnte nicht zugegriffen werden

[digi100]

Ich bekomme seit neustem die Fehlermeldung "Es ist kein USB-Speicher für die Speicherung der Diagrammdaten vorhanden oder auf diesen konnte nicht zugegriffen werden. Um die Diagrammdaten zu speichern, ist externer USB-Speicher erforderlich. "

Die Fehlermeldung erscheint bei Aufruf der Diagrammdaten via "Status & Bedienung" als auch via "Einstellungen. Ich habe die neueste Version 3.51.6.20200621 auf einem RasperryMatic installiert.

Unter der "Allgemeinen Einstellungen" wird korrekt "externeren USB Speicher vorhanden" angezeigt. Ebenso funktioniert Daten sichern auf USB. Auch CCU-Historian funktioniert perferkt.

Woher kann meine Problem kommen? Wie behebe ich dies ?

Danke im Voraus
Stefan

[MuellerT]

Hallo,
ich habe genau das gleiche Problem, Stick wird erkannt, aber beim Aufruf der Diagramme ist angeblich kein USB Speicher vorhanden.
Habe auch schon einiges versucht, anderer Steckplatz, Neustart usw., bin aber auch zu keinen Erfolg gekommen.
Vielleicht hat noch jemand eine Idee ?

Gruß
Torsten

[PaulM]

Das Problem habe ich auf meinem Remote System mit Firmware 3.51.6.20200420 auch. USB0 wird nicht angezeigt, bisherige CCU-Historian Daten (de facto auf USB1 gespeichert) werden nach Neustart gelöscht.

Die Daten werden auch gelöscht, wenn in der CCU-Historian Konfiguration USB1 (statt USB0) gesetzt ist.

Im laufenden Betrieb scheint der USB-Speicher normal zu funktionieren.

[DJDieter]

Es liegt wahrscheinlich daran, dass usb0 - warum auch immer - nicht mehr existiert. usb0 hat einen Softlink auf usb1. Dieses Problem hatte ich auch mal und die Lösung dafür gibt's hier: viewtopic.php?f=65&t=57552#p572821

[mkninc]

@digi100: Konntest du das Problem lösen?

Ich habe auch grade das Problem, dass der USB Stick für die Diagramme nicht erkannt wird.

Der USB Stick wird normal gemountet und ist schreib/lesbar. CCU-Historian und Nodered Logdateien werden ohne Probleme darauf geschrieben.

Code: Alles auswählen

root@homematic-raspi:~# mount
/dev/root on / type ext4 (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=462620k,nr_inodes=115655,mode=755)
proc on /proc type proc (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,relatime,mode=777)
tmpfs on /tmp type tmpfs (rw,noatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noatime,mode=755)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /var type tmpfs (rw,noatime)
tmpfs on /media type tmpfs (rw,noatime)
/dev/mmcblk0p3 on /usr/local type ext4 (rw,noatime,nodiratime,nodelalloc,data=journal)
/dev/mmcblk0p1 on /boot type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sda1 on /media/usb1 type f2fs (rw,lazytime,nodev,noexec,noatime,nodiratime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=reuse,fsync_mode=posix)

/media/usb0 ist auch vorhanden.

Code: Alles auswählen

root@homematic-raspi:~# ls -la /media/
total 8
drwxrwxrwt   10 root     root           220 Sep 19 22:55 .
drwxr-xr-x   23 root     root          4096 Sep 19 12:16 ..
lrwxrwxrwx    1 root     root            11 Sep 19 22:55 usb0 -> /media/usb1
drwxr-xr-x    6 root     root          4096 Sep 19 23:16 usb1
drwxr-xr-x    2 root     root            40 Sep 19 22:55 usb2
drwxr-xr-x    2 root     root            40 Sep 19 22:55 usb3
drwxr-xr-x    2 root     root            40 Sep 19 22:55 usb4
drwxr-xr-x    2 root     root            40 Sep 19 22:55 usb5
drwxr-xr-x    2 root     root            40 Sep 19 22:55 usb6
drwxr-xr-x    2 root     root            40 Sep 19 22:55 usb7
drwxr-xr-x    2 root     root            40 Sep 19 22:55 usb8

in der "Systemsteuerung -> Allgemeine Einstellungen -> Externer USB-Speicher" steht auch "Status: externer USB-Speicher vorhanden."

In den Diagrammeinstellungen kommt dann aber nur die Fehlermeldung
"Es ist kein USB-Speicher für die Speicherung der Diagrammdaten vorhanden oder auf diesen konnte nicht zugegriffen werden. Um die Diagrammdaten zu speichern, ist externer USB-Speicher erforderlich."

[Hütte]

Wieviele Diagramme zeichnest du schon auf?

Ich meine, mich zu erinnern, dass es da innerhalb der CCU (somit auch in RaspberryMatic) eine Begrenzung in der Anzahl der Diagramme, die angelegt werden können, gibt.

[mkninc]

Wieviele Diagramme zeichnest du schon auf?

Sind aktuell nur 13 Diagramme.
Wenn ich das richtig in DiagrammSettingsListPage.ftl https://github.com/eq-3/occu/blob/maste ... ge.ftl#L20 sehe, ist das Limit bei 50 und hat eine andere Fehlermeldung.

[mkninc]

Das Problem war eine defekte RRD Datei.
Auszug aus "/var/log/hmserver.log"

Code: Alles auswählen

Sep 20 12:11:28 de.eq3.lib.datalogging.rrd.RrdDatalogging ERROR [Timer-0] Could not initialize rrd database
java.io.IOException: Invalid file header. File [/tmp/measurement/5.rrd] is not a RRD4J RRD file

[MCSmurf]

Hallo zusammen,

ich möchte das Thema noch mal aufgreifen, da bei mir auch keine Diagramme gespeichert werden können, obwohl der USB-Stick offensichtlich erkannt wird..

Das Problem war eine defekte RRD Datei.
Auszug aus "/var/log/hmserver.log"

Code: Alles auswählen

Sep 20 12:11:28 de.eq3.lib.datalogging.rrd.RrdDatalogging ERROR [Timer-0] Could not initialize rrd database
java.io.IOException: Invalid file header. File [/tmp/measurement/5.rrd] is not a RRD4J RRD file

Wie kann man das lösen?

Wenn ich in den allgemeinen Einstellungen beim USB Stick auf Daten sichern klicke, lädt er auch eine TAR Datei mit folgenden Inhalt runter
BackupUSBStorage.tar.gz\BackupUSBStorage.tar\media\usb0\measurement\2.rrd (und 3.rrd / 4.rrd)

Smurf

[Hütte]

Ich würde mal folgendes versuchen:
1. System komplett und sauber herunterfahren - also nicht einfach direkt den Stecker ziehen. Erst danach vom Strom trennen.
2. USB-Stick abziehen und an einem anderen Rechner anstecken, im allgemeinen sind sie ja mit FAT-32 formatiert und sollten erkannt werden.
3. Alle Dateien lokal sichern.
4. die Datei "5.rrd" (die laut Log angemeckert wird) vom USB-Stick löschen.
5. Stick zurück in dein System und System wieder starten.

Meine Vermutung ist, dass dann eine neue Datei angelegt wird und die neuen Daten nun aufgezeichnet werden. Die alten Daten sind dann allerdings leider verloren.

Alternativ habe ich gerade mal gegoogelt, ob man solche Dateien reparieren kann, denn es handelt sich hier um eine Datenbankdatei. Dabei habe ich diesen Link von 2011 (http://pierre.palatin.fr/old/rrd-repair) gefunden. Und der Kommentar, warum dieses Datenbankfile korrupt ist, ist wirklich interessant. Nämlich dass durch irgendwelche "blöden" Umstände die Systemzeit in der Zukunft lag und somit Daten mit einem Zeitstempel in der Zukunft abgelegt wurden. Und nun stimmt deine Systemzeit wieder und das System hat Probleme, diese Datenbankdatei zu lesen. Aber auch bei diesem Reparatur-Versuch scheinen wohl zumindest die Daten verloren zu sein, die einen Zeitstempel aus der Zukunft aufwiesen

Ich habe mir aber weder das Script angeschaut noch getestet. Ich kann also somit nicht bestätigen, ob das funktioniert. Denn wie es in dem Beitrag aussieht, muss man das Ganze auf einem UNIX/LINUX System machen. Aber damit kenne ich mich nur sehr rudimentär aus. Eventuell könnte man es auch auf einem Windows- oder Mac-System machen, wenn man entsprechend die nötigen Koponenten für Python installiert hat. Aber auch da bin ich hier raus aus der Nummer.

Und nur nebenbei. Jetzt wird mir auch klar, warum sich scheinbar einerseits die Dateigröße der Datei nicht nicht ändert, aber die Größe der Datei "BackupUSBStorage.tar.gz", wenn man mehhrfach ein Backup macht. Beim Erstellen der jeweilgen Datenbankdatei für das entsprechende Diagramm wird zuerst eine fester Speicherbereich (wohl 153 kB) reserviert, der anfangs komplett mit NULL-Werten gefüllt ist. Nach und nach werden diese NULL-Werte durch die entsprechenden Daten überschrieben und somit wächst die Größe der kompimierten Datei. Wenn der Bereich ausgenutzt ist, wird die Datei vergrößert und der neue Bereich ebenfalls anfangs mit NULL-Werten gefüllt und später mit den echten Werten überschrieben. Daher habe ich auch bei mir eine Datei, die doppelt so groß ist wie die anderen Dateien - weil der erste Block voll war. Aber so gehen andere Datenbanken ja auch vor.

Wieder etwas dazu gelernt