Beiträge von Rewe2000

    Hallo,

    vielen Dank für euer Bemühen mir hier weiterzuhelfen.

    fred0815: Das mit der alten Anleitung war mir schon bewusst, deshalb habe ich auch versucht die neuesten Pakete unter Bookworm zu verwenden.


    Ich hänge hier mal meine Vorgehensweise mit an, in der Hoffnung ihr könnt eventuell noch Fehler finden oder jemand der mitliest hat ja Grocy noch auf einem Raspi in Betrieb.

    Voraussetzungen:

    Raspi3 mit 16 GB SD-Card - wenn es läuft bekommt dieser eine 32 GB SSD

    Debian 12 Bookworm 64bit full (mit grafischer Benutzeroberfläche)

    Anbindung nur im Heimnetz über LAN (WLAN abgeschaltet), statische IPv4 Netzwerkadresse

    Weitere Software befindet sich nicht auf dem Raspi3

    sudo nano data/config.php

    Code
    Setting('BASE_PATH', '/grocy/public');
    Setting('BASE_URL', '/grocy/public');
    Setting('DISABLE_URL_REWRITING', false);
    Setting('DEFAULT_LOCALE', 'de');
    Setting('CURRENCY', 'EUR');

    sudo nano /etc/apache2/apache2.conf

    Code
    <Directory /var/www/>
            Options Indexes FollowSymLinks
            AllowOverride All
            Require all granted
    </Directory>

    sudo systemctl restart apache2

    http://<IP-des-Raspi3>/grocy/public/

    Hier kommt dann folgende Fehlermeldung beim Start von Grocy:

    Code
    Unable to run Grocy: PHP module 'intl' not installed, but required.

    Ich musste hier noch die 2 php-Pakete nachinstallieren, (wahrscheinlich hätte ich die Grundinstallation von php anders aufrufen müssen):

    Code
    sudo apt-get install php-intl
    sudo apt-get install php-mbstring

    Nach einem Neustart des Apache-Servers hat es geklappt und Grocy ist erreichbar :) .

    Frage: :?:

    Könnt ihr euch noch erinnern, ob ihr die lite Version (ohne grafische Benutzeroberfläche) verwendet hattet?

    Ich denke für den alleinigen Betrieb für Grocy auf dem Raspi3 sollte dies ausreichen.

    Gruß Reinhard

    Hallo,

    habe eben versucht das Thema Grocy auf einen alten Raspi3 anzugehen und bin gemäß Anleitung von Jürgen #21 vorgegangen, leider fehlt mir noch der große Durchbruch.

    Da ich selbst kein großes Linux Licht bin, muss ich hier mal um eure Hilfe bitten, eventuell scheitert es ja auch schon an den Grundlagen.

    Was hab ich getan:

    Raspi3 mit 16 GB SD-Card komplett neu aufgesetzt mit Bookworm lite arm64 (reicht das für Grocy aus oder benötige ich da ein Debian Bookworm full arm64 Image?)

    Die Anleitung klappt auch bei mir, bis zum unzip Befehl.

    sudo unzip -d grocy_4.0.3.zip

    Hier startet kein Entpacken der Datei, sondern es wird immer die Kurzhilfe des unzip Befehls angezeigt, so als wie wenn der unzip Befehl nicht passen würde. Eine Fehlermeldung wird jedoch nicht angezeigt.

    Starte ich das Entpacken dagegen nur mit:

    sudo unzip grocy_4.0.3.zip

    Wird das Archiv anscheinend korrekt entpackt und auch die Ordner unter Grocy werden korrekt angelegt.

    Alles andere kann ich wieder fehlerfrei ausführen, lediglich der Start von Grocy über den Aufruf von

    http://192.168.xxx.xxx/grocy/public/

    bringt folgende Meldung

    Unable to run grocy: PHP module 'intl' not installed, but required.

    Ich habe auch selbst versucht etwas zu finden, aber wirklich weitergebracht hat es mich nicht: https://github.com/grocy/grocy/issues/1543

    Ich wäre für einige Tipps von euch dankbar.

    • Läuft Grocy überhaupt unter Debian light ohne der grafischen Oberfläche?
    • Läuft es unter Bookworm?
    • Was mache ich falsch beim unzip -d Befehl?
    • Hängt die Fehlermeldung beim Aufruf von Grocy eventuell mit einem vorhergehenden Fehler bei mir zusammen?

    Ich wollte noch einen Versuch mit der grafischen Oberfläche (Debian full arm64) wagen, aber da reicht mir meine 16 GB SD-Card für ein Update von Linux derzeit nicht aus.

    Gruß Reinhard

    Hallo,

    nun habe ich die Ursache gefunden, es waren zuviele / im mount Befehl enthalten, deshalb hat es nur auf der FritzBox nicht mehr funktioniert.

    Danke

    Gruß Reinhard

    Hallo hyle,

    das mit der Mountoption noserverino habe ich auch schon versucht, vorher natürlich ein umount gemacht, klappt aber auch nicht.

    Anbei noch die Ausgabe von ls -lisa /media/fritz_nas vor dem mount:

    Code
    pi@Fhem-Buster-SSD:~ $ ls -lisa /media/fritz_nas
    insgesamt 8
    1545218 4 drwxr-xr-x 2 root root 4096 Dez  5 10:19 .
    1545217 4 drwxr-xr-x 5 root root 4096 Dez  5 15:55 ..

    und nochmals, bei gemountetem Verzeichnis ohne Option noserverino:

    Code
    pi@Fhem-Buster-SSD:~ $ ls -lisa /media/fritz_nas
    insgesamt 4
    9332993024842119429 0 drwxr-xr-x 2 pi   pi      0 Dez  5 12:04 .
                1545217 4 drwxr-xr-x 5 root root 4096 Dez  5 15:55 ..

    und einmal, bei gemounteten Verzeichnis mit Option noserverino:

    Code
    pi@Fhem-Buster-SSD:~ $ ls -lisa /media/fritz_nas
    insgesamt 4
        120 0 drwxr-xr-x 2 pi   pi      0 Dez  5 12:04 .
    1545217 4 drwxr-xr-x 5 root root 4096 Dez  5 15:55 ..

    Ich hoffe ihr könnt da etwas erkennen.

    Gruß Reinhard

    Hallo,

    seit einigen Tagen klappt bei mir das automatische Backup von Dateien vom Raspi zum SSD-Speicher der FritzBox nicht mehr.

    Grundsätzlich hat dies über mehrere Jahre, nach der Anleitung von Hofei Netzwerkfreigabe mounten mit systemd Mount Unit bestens funktioniert.

    Damit ich das Problem eingrenzen kann, will ich zunächst manuell ein Verzeichnis mounten und darin nur mit nano eine Textdatei anlegen, selbst das klappt nicht und ich kann mir nicht vorstellen wo das Problem liegt.

    • Auf der FritzBox entferne ich den Haken bei SMBv1 somit werden nur mehr aktuelle Netzwerkprotokolle unterstützt.
    • Zur Sicherheit starte ich die FritzBox und den Raspi mal neu, ist wahrscheinlich nicht notwendig, aber schaden kann es auch nicht. Nach dem Neustart prüfe ich auf der FritzBox nochmals die Netzwerkeinstellungen und die Benutzerrechte des Users Fhem.

    Nun beende ich auf dem Raspi nach dem reboot (angemeldet als Pi, nicht als root) den mount wie folgt:

    Ich erkenne jetzt, dass aktuell kein Verzeichnis mehr gemountet ist.

    Nun versuche ich das Verzeichnis manuell zu mounten mit folgenden Befehl, angemeldet als Benutzer Pi über PuTTy:

    Das mounten wurde wieder ohne Fehler ausgeführt und scheint auch eingerichtet zu sein.

    Will ich nun mit nano wie folgt eine Datei anlegen (egal ob mit oder ohne "sudo"):

    Code
    pi@Fhem-Buster-SSD:/media $ cd /media/fritz_nas
    pi@Fhem-Buster-SSD:/media/fritz_nas $ ls -lh
    insgesamt 0
    pi@Fhem-Buster-SSD:/media/fritz_nas $ nano Text.txt

    So erhalte ich wieder folgende Fehlermeldung:

    Code
    [ Fehler beim Schreiben der Sperrdatei ./.Text.txt.swp: Datei oder Verzeichnis nicht gefunden ]

    Irgendwie kann oder darf der Raspi nicht in das Verzeichnis der SSD auf der FritzBox schreiben.

    Habt ihr als Linux Profis einige Tipps für einen Linux Anfänger was ich da falsch mache oder wie ich mein Problem eingrenzen kann?

    Noch ein Hinweis:

    Richte ich den mount zu einem Windows10 PC ein, so kann ich mit "sudo" problemlos eine Textdatei im gemounteten Verzeichnis erstellen. Ich habe fast die Vermutung da hat sich im Linux System oder im OS der FritzBox etwas geändert weil es bei mir nicht mehr klappt.

    Gruß Reinhard

    Hallo,

    gibt es hier noch User, bei welchen der mount vom Raspi (buster) zur FritzBox OS 7.29 noch funktioniert?

    Ich hatte über Jahre die Lösung wie im Post 1 von hofei beschrieben, und das hatte hervorragend geklappt. Vermutlich nach dem letzten Linux oder dem FritzBox update bekomme ich das mounten nicht mehr zum laufen. Es spielt hier keine Rolle was ich in der FritzBox bei SMBv1 aktiv schalte oder was ich im mount Befehl für eine Version wähle, es klappt einfach nicht mehr.

    Der manuelle mount Befehl wird ohne Fehler akzeptiert, aber ich kann keine Datei im mount Verzeichnis mehr ablegen, wenn das mount aktiv ist.

    Gerne liefere ich mehr Details, sollte mein Problem bei euch nicht bekannt sein.

    Auch das klappt bei mir nicht.

    Gibt es dazu schon einen Workaround?

    Gruß Reinhard

    Hallo Andreas,

    ich wollte mir dein vorgeschlagenes Programm hostrepair mal ansehen, aber ich habe festgestellt so einfach ist das (für mich) nicht.

    Zitat

    Den Quellcode kannst Du im Forum herunterladen.


    Wo kann ich das Programm hier im Forum downloaden? :s

    Kannst du mir mal einen Tipp geben, wo sich der Downloadbereich befindet, irgendwie zweifle ich schon an mir selbst!
    Auch Tante Google findet nur eine Firma in USA oder irgend welche Logos zum Thema.

    Gruß Reinhard

    Hallo Andreas,

    danke für die Info und das Angebot. Ich werde mir dein Programm mal ansehen und dieses ggf. testen.

    Bei mir hillft definitiv ein Dauerping, solange dieser läuft, habe ich Antwortzeiten um max. 10-11 Sekunden und damit kann ich prima leben. Ich denke ein Ping alle Sekunden muss es nicht sein, es sollten auch 10 Sekunden ausreichen, eine Minute ist jedenfalls zu lange.

    Da ich blutiger Linux Anfänger (im fortgeschrittenen Alter) bin, bräuchte ich noch etwas Hilfe bei der automatischen Einrichtung eines Dauerpings, welcher auch ein reboot übersteht.

    Mit crontab geht ja unter 1 Minute nichts und als Eintrag in etc/rc.local klappt das auch nicht (siehe oben im thread). Ich habe schon so ziemlich alles abgesucht was es in dieser Richtung gibt, aber leider nichts passendes gefunden.

    Hättest du oder ein anderer User noch einen Tipp zur Einrichtung des dauerhaften Dauerping für mich.

    Danke und Gruß Reinhard

    Hallo rpi444,

    eben habe ich noch einen Raspberry PI 3 und eine CCU2 (als Bausatz) bestellt, somit kann ich zumindestens ausschließen, dass Hardware defekt ist. Ganz umsonst ist die Investition ja auch nicht, denn somit habe ich immer Ersatz wenn ein Gerät zukünftig ausfallen sollte ;) .

    Bei dir möchte ich mich für die Hilfe vielmals bedanken, auch wenn wir mein Problem nicht lösen konnten. :thumbs1:
    Sollte ich neue Erkenntnisse gewinnen, so hänge ich diese an diesen Thread an.

    Gruß Reinhard

    P.s. Wie würden wir nur unsere freie Zeit verbringen, wenn es keine Computer geben würde?

    Hallo rpi444,

    die Umstellung auf statischen arp-cache hat leider nicht den gewünschten Erfolg gebracht.
    Ich vermute fast, es muss an der Hardware der CCU2 oder am Raspi liegen, da mir kein anderer User bekannt ist, welcher ähnliche Probleme hat und diese Verbindung (Raspi, CCU2, FHEM) nutzen viele.
    Aber so recht kann ich mir auch nicht vorstellen, dass es an elektronischen Bauteilen liegen könnte.

    Ich denke ich werde mir nochmals einen Raspi und eine CCU2 zulegen, damit ich eine vernünftige Ausschlußdiagnostik betreiben kann, auch wenn es finanziell ziemlich schmerzt.

    Die Laufzeiten messe ich wie folgt:

    1. Die Zeiten werden über einen NTP Zeitserver auf der Fritz Box beim Raspi und der CCU2 syncronisiert.
    2. Ein ankommendes Signal eines Bewegungsmelders in der CCU2, schreibt die Systemzeit der CCU2 in eine Systemvariable.
    3. Diese Systemvariable mit der CCU2 Zeit wird zum Raspi übertragen.
    4. Wenn das Signal des Bewegungsmelders im FHEM Server ankommt werden die Zeiten in eine Log-Datei geschrieben.

    Somit kann ich sehr genau die Verzögerungszeit messen.

    Anbei mal 2 Gegenüberstellungen der Zeiten:

    Verzögerungen mit Dauerping (1 Sekunde) und arp-cache dynamisch.Verzögerung mit ständigen Anpingen.pdf

    Verzögerungen mit Dauerping (1 Minute) und arp-cache dynamisch.Verzögerung mit dyn. arp-cache Eintrag.pdf

    Verzögerungen ohne Dauerping und arp-cache statisch .Verzögerung mit stat. arp-cache-Eintrag.pdf


    Hast du noch eine Idee was ich noch machen könnte?

    Gruß Reinhard

    Hallo rpi444,

    IPV6 sollte mir gelungen sein zu deaktivieren, guck bitte mal ob es so passt (nach Neustart):

    Code
    root@raspberrypi:~# ip addr show
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
       link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
       inet 127.0.0.1/8 scope host lo
          valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
       link/ether b8:27:eb:9f:e7:36 brd ff:ff:ff:ff:ff:ff
       inet 192.168.1.33/24 brd 192.168.1.255 scope global eth0
          valid_lft forever preferred_lft forever

    Mit "ip n s":

    Code
    root@raspberrypi:~# ip n s
    192.168.1.13 dev eth0 lladdr 9c:c7:a6:85:44:b3 REACHABLE
    192.168.1.32 dev eth0 lladdr 00:1a:22:08:40:11 REACHABLE
    192.168.1.30 dev eth0 lladdr 00:30:de:05:5a:d9 REACHABLE
    192.168.1.25 dev eth0 lladdr 00:11:e2:09:cf:1b REACHABLE

    Der obige Auszug ist nur eine Momentaufname, führe ich "ip n s" mehrmals hintereinander aus, wechseln die Zustände zwischen DELAY, STALE, REACHABLE bei allen Teilnehmern!

    WLAN und Bluetooth habe ich auch noch abgeschaltet, da ich es derzeit definitiv nicht benötige.
    Bezüglich der Konfiguration mit dem statischen arp-cache-Eintrag bin ich als Linux Neuling noch am suchen, eventuell benötige ich da noch Hilfe.

    Tausend Dank, Gruß Reinhard
    Automatisch zusammengefügt:
    Hallo rpi444,

    habe mich mal mit dem statischen arp-cache-Eintrag wie folgt versucht:


    Ich habe die Datei als root User neu erstellt:

    Code
    /etc/network/if-up.d/add-my-static-arp
    
    
    #!/bin/sh
    arp -i eth0 -s 192.168.1.13 9c:c7:a6:85:44:b3
    arp -i eth0 -s 192.168.1.32 00:1a:22:08:40:11
    
    
    chmod +x /etc/network/if-up.d/add-my-static-arp

    War es korrekt, dass ich für den Router (Fritz-Box) und für meine CCU2 eine statische arp Zuweisung anlege?
    Müsste ich nicht auch für meine WAGO Steuerung (192.168.1.30) eine statische arp Zuweisung anlegen, da ich alle 60 Sekunden vom Raspi von dieser SPS über MODBUS ca. 30 Variablen abhole?


    Ich hoffe es war korrekt so, Fehler kommen nach dem Reboot keine und die Kommunikation steht.

    Code
    192.168.1.32 dev eth0 lladdr 00:1a:22:08:40:11 PERMANENT
    192.168.1.25 dev eth0 lladdr 00:11:e2:09:cf:1b REACHABLE
    192.168.1.13 dev eth0 lladdr 9c:c7:a6:85:44:b3 PERMANENT
    192.168.1.30 dev eth0 lladdr 00:30:de:05:5a:d9 REACHABLE

    Ich habe mal den Dauerping wieder entfernt, damit ich die Übermittlungsverzögerungen korrekt messen kann. Somit kann ich sehen ob sich durch diese Maßnahmen etwas verbessert hat.


    Gruß Reinhard

    Hallo rpi444,

    danke für die schnelle Antwort. :thumbs1:

    So wie ich es interpretiere wird der Ping einmal pro Minute vom Rpi an die CCU2 gesendet:

    Code
    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    21:03:01.098010 b8:27:eb:9f:e7:36 > 00:1a:22:08:40:11, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 164, offset 0, flags [DF], proto ICMP (1), length 84)
       192.168.1.33 > 192.168.1.32: ICMP echo request, id 2015, seq 1, length 64
    21:03:01.098617 00:1a:22:08:40:11 > b8:27:eb:9f:e7:36, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 11669, offset 0, flags [none], proto ICMP (1), length 84)
    .....

    Somit sollte die Variante mit etc/crontab problemlos funktionieren.

    Zu meinem Problem mit der einschlafenden Kommunikation habe ich schon alle mir bekannten Register gezogen und Wochen damit verbracht das Problem mit Logik zu lösen, hier die wichtigsten in Stichpunkten:
    1. Alle Geräte Raspi und CCU2 komplett platt gemacht, Software neu aufgespielt und Test mit Minimalkonfiguration.
    2. Betrieb (nur Raspi und CCU2 alleine) mit statischen IP-Adressen über einen uralten NETGEAR Ethernet Switch (üblich Fritzbox 7390).
    3. CCU2 zum Herstellermit Fehlerbeschreibung eingesandt.

    Alle diese Maßnahmen brachten keinerlei Verbesserung.

    Führe ich aber vom Raspi zur CCU2 einen Dauerping aus, treten die Verzögerungen nicht auf. Lösche ich den Dauerping wieder werden die Antwortzeiten im Laufe der Zeit immer wieder länger, besonders nach einer Nacht (bei wenig Kommunikation zwischen Raspi und CCU2) sind diese am Morgen besonders lang.


    Anbei der Output bei "ip n s", bei Antwortzeiten von unter 10 Sekunden:

    Code
    192.168.1.27 dev eth0 lladdr 08:fd:0e:d9:05:89 STALE                     #Desktop PC 2
    192.168.1.30 dev eth0 lladdr 00:30:de:05:5a:d9 STALE                              #WAGO Steuerung (SPS)
    192.168.1.25 dev eth0 lladdr 00:11:e2:09:cf:1b REACHABLE                      #Desktop PC
    192.168.1.32 dev eth0 lladdr 00:1a:22:08:40:11 STALE                              #CCU2
    192.168.1.13 dev eth0 lladdr 9c:c7:a6:85:44:b3 REACHABLE                      #Fritz Box 7390 (Router)
    fe80::9ec7:a6ff:fe85:44b3 dev eth0 lladdr 9c:c7:a6:85:44:b3 router STALE
    fd00::9ec7:a6ff:fe85:44b3 dev eth0 lladdr 9c:c7:a6:85:44:b3 router STALE


    Den Output bei Antwortzeiten > 1 Minute liefere ich ggf. in den nächstn Tagen nach.

    Vorerst vielen Dank für deine Mühe, bei mir keimt wieder Hoffnung auf das Problem eventuell doch noch zu lösen.
    Gruß Reinhard

    Hallo,

    ich verwende einen Raspberry Pi 3 (Raspbian GNU/Linux 8) mit installiertem Fhem Server zur Steuerung meiner Hausautomatisation. Mit diesen greife ich über einen RPC Server auf eine CCU2 Zentrale (Homematic) zu, um die Verbindung zu den Homematic Sensoren und Aktoren über Fhem zu bekommen.
    Nun habe ich folgendes Problem, ich beobachte ein "einschlafen" der Kommunikation (LAN) vom Raspi zur CCU2 Zentrale, nach einer Laufzeit von mehr als ca. 6 Stunden inaktivität (Nachts), diese betragen teilweise mehr als 2 Minuten. Ich habe mir schon den Kopf zerbrochen und tagelang in Foren gestöbert aber ich selbst habe nur Vermutungen und kein anderer User hat das gleiche Problem.

    Richte ich aber einen Dauerping vom Raspi zur CCU2 ein, tritt das beschriebene "einschlafen" nicht mehr auf und ich habe Antwortzeiten von weniger als 11 Sekunden. Damit könnte ich prima leben.

    Nun brauche ich eure Hilfe bei der korrekten Einrichtung des Dauerpings auf dem Raspi, welches auch einen Neustart übersteht. Bisher habe ich nach Studium von div. Foren folgende Möglichkeiten versucht.

    Eintrag in etc/rc.local:

    Dieser Eintrag wird jedoch nicht beachtet, ich kann jedenfalls nach einem Neustart keinen gestarteten Ping über "ps ax" erkennen. :(

    Nun habe ich es über etc/crontab wie folgt versucht:

    Nach einem Neustart gibt es keine Fehler, aber wie kann ich erkennen ob der Ping ausgeführt wird?
    Ich denke die Angabe des User pi war hier korrekt oder?

    Noch lieber würde ich das einschlafen der Kommunikation lösen, aber da habe ich die Hoffnung ehrlich gesagt schon aufgegeben.

    Es wäre nett wenn ihr mir mit eurem Wissen hier weitrhelfen könntet.

    Gruß Reinhard