Ankündigung

Einklappen
Keine Ankündigung bisher.

Neuinstallation von CV 0.11.2 auf Raspi - was muss alles installiert werden?

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #61
    Zitat von Chris M. Beitrag anzeigen
    Ja, Deine Verbindung zum knxd funktioniert anscheinend nicht.

    Mit dem knxd 0.14.29-5 habe ich keine Erfahrung (genauer: für mich ist der 0.0.5 sehr stabil und später wurde dort ein Bug eingebaut durch den die CometVisu nicht mehr funktioniert hatte - keine Ahnung ob der inzwischen behoben wurde). Aber ist der Socket vom knxd korrekt erzeugt? Findet den das eibread-cgi (also der Symlink für den "r") auch?
    Kannst Du mir bitte schreiben, wie man den Socket korrekt erzeugt bzw. wie man prüfen kann, ob er das eibread-cgi auch findet?
    Nachdem Du den knxd 0.0.5 verwendest, weißt Du ja auch, wie man den installiert. Kannst Du das kurz beschreiben?
    Denn auf github finde ich die Version 0.0.5 vom knxd gar nicht mehr und die Installationsanleitung hat sich über die Versionen wohl auch etwas verändert.
    Wäre prima, dann kann ich mal checken ob das alles läuft wie es soll.
    Vielen Dank.

    Kommentar


      #62
      Die beste und einfachste Möglichkeit ist inzwischen das ganze über Docker laufen zu lassen, vgl. z.B. das Tutorial für den Raspberry Pi https://www.cometvisu.org/CometVisu/...cometvisu.html
      Die Erzeugung des Docker-Images (also das Docker File) geschieht durch: https://github.com/CometVisu/Docker/...ckerfile.cross - hier kannst Du auch sehen wie der knxd heruntergeladen, erzeugt und im Anschluss "installiert" wird.

      Wenn der eibread-cgi den Socket nicht findet, dürfte als Antwort kommen:
      Code:
      Content-Type: text/plain
      
      {'error': 'Open failed'}
      TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

      Kommentar


        #63
        Die CometVisu-Docker-Version hab ich schon zum Laufen gebracht - mit all den Tücken und Vor- und Nachteilen.

        Deshalb versuche ich nochmal auf meinem Spiel-Raspi eine saubere Neuinstallation hinzubekommen.
        Nachdem der aktuelle knxd 0.14.xx wohl immer noch Probleme in Verbindung mit der CometVisu macht (ich habe jedenfalls nichts Gegenteiliges gelesen), würde ich den knxd 0.0.5.1 nutzen wollen, der im Container wohl gut läuft.

        Ich hab mir das Dockerfile.cross angesehen und die mir wichtig erscheinenden Passagen (# Compile knxd 0.0.5.1, # build pthsem, # build knxd) händisch ausgeführt. Es ist alles ohne Fehler durchgelaufen. Auch in der readme.md vom knxd-0.0.5.1 steht nichts zusätzliches drin, was noch erforderlich wäre.

        Nun finde ich weder eine knxd.conf, wo ich die IP-Adresse meines Interfaces eintragen kann, noch läuft der knxd. Auch die eibread-cgi und eibwrite-cgi finde ich nirgends.
        Hab ich irgendwas vergessen?

        Auch den Test mit knxtool kann ich nicht machen, da er knxtool nicht findet.
        Eine Installation mit "apt-get install knxd-tools" schlägt fehl: "E: Unable to locate package knxd-tools".

        Hat jemand ne Idee?

        Kommentar


          #64
          So, nach unermüdlichen Versuchen sehe ich folgendes:

          knxd error read.JPG

          gestartet hab ich den knxd so:
          knxd -i iptn:192.168.170.223:3671 -e 1.1.225 -u/tmp/eib -d -c
          Die Verbindung zum KNX besteht wohl, denn nach dem Start sehe ich am IP-Interface, dass eine Verbindung belegt wurde. Stoppe ich den daemon wieder, wird die Verbindung wieder freigegeben. Daher sollte das passen.

          Aber so wie Chris schreibt, dürfte mit dieser Meldung der/die/das eibread-cgi den socket nicht finden.

          Konkret habe ich
          eibread-cgi und eibwrite-cgi aus dem knxd-0.0.5.1-Verzeichnis nach \usr\bin kopiert
          /usr/lib/cgi-bin/r : symlink to /usr/bin/eibread-cgi erstellt
          /usr/lib/cgi-bin/w : symlink to /usr/bin/eibwrite-cgi erstellt
          usr/lib/cgi-bin/l : Datei erstellt mit folgendem Inhalt:

          #!/bin/sh
          echo Content-Type: text/plain
          echo

          echo "{ "v":"0.0.1", "s":"SESSION" }"
          Sicherheitshalber habe ich diesen Dateien und dem Comet-Visu-Verzeichnis chmod 0777 gegeben.

          Was mache ich falsch bzw. kann ich prüfen?
          Das kann doch nicht so schwer sein, dass Ding zum Laufen zu bringen. Ich verzweifel bald...an mir selbst

          Kommentar


            #65
            Grundsätzlich sieht das schon mal richtig aus.

            Wird denn in /tmp/ der Socket /tmp/eib erzeugt? Welchen Eigentümer und welche Berechtigungen hat der? Unter welchem Eigentümer wird darauf zugegriffen?
            Hast Du dem Socket auch noch die Schreibrechte eingestellt, vgl. https://github.com/CometVisu/Docker/...entrypoint#L15 ?
            TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

            Kommentar


              #66
              Danke Chris für Deine Bemühungen !!!

              Zitat von Chris M. Beitrag anzeigen
              Grundsätzlich sieht das schon mal richtig aus.

              Wird denn in /tmp/ der Socket /tmp/eib erzeugt? Welchen Eigentümer und welche Berechtigungen hat der?
              Es ist in /tmp eine Datei "eib" vorhanden. Ich nehme an, es ist der Socket. Wer den erstellt hat oder durch was der erstellt wurde, weiß ich nicht.
              Gruppe/Eigentümer ist "root", Berechtigung ist 0755.

              Zitat von Chris M. Beitrag anzeigen
              Unter welchem Eigentümer wird darauf zugegriffen?
              Wer greift darauf zu? Ist das eibread-cgi und eibwrite-cgi? Falls ja, wie ist da der Zusammenhang? Woher wissen die voneinander bzw. wo die zu finden sind?

              Falls es eibread-cgi und eibwrite-cgi sind, die liegen in /usr/bin und Gruppe/Eigentümer ist "root", Berechtigung 0777.
              Falls ich falsch liege, bitte erklären :-)

              Zitat von Chris M. Beitrag anzeigen
              Hast Du dem Socket auch noch die Schreibrechte eingestellt, vgl. https://github.com/CometVisu/Docker/...entrypoint#L15 ?
              Nein, hatte ich vergessen. Habe nun
              chmod a+w /tmp/eib
              nachgeholt. Jetzt steht die Berechtigung auf 0777.


              Ändert aber leider nichts daran, die Fehlermeldung bleibt dieselbe.
              Auf die Anfrage "r?t=0&s=SESSION&a=3/1/6&a=3/1/7&a=10/5/0&a=10/5/1" kommt nach wie vor die Response "{'error': 'Open failed'}"
              Ich habe in die mitgelieferte visu_config.xml zwei Switch eingefügt mit diesen GAs.
              Jetzt fehlt nur noch die Antwort...

              Kommentar


                #67
                Auch wenn die Dateien eibread-cgi/eibwrite-cgi dem root gehören, sobald diese ausgeführt werden läuft der Prozess unter dem Account des ausführenden. Das ist normalerweise der Web-Server, also z.B. "www-data". Beispiel von meinem Test-Container:
                Code:
                # ps aux
                USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
                root 1 0.0 0.2 83576 11424 ? Ss Jun01 6:40 apache2 -DFOREGROUND
                root 7 0.4 0.0 6768 1980 ? Ss Jun01 264:44 knxd -i iptn:172.17.0.1:3700 -e 1.1.238 -u -d/var/log/eibd.log -c
                root 11 0.0 0.0 15852 2788 ? Ss Jun01 0:00 /usr/sbin/sshd
                root 2769 0.8 0.0 3996 3372 pts/0 Ss 21:29 0:00 bash
                www-data 2788 0.0 0.0 2788 740 ? S 21:29 0:00 /usr/lib/cgi-bin/r
                root 2789 0.0 0.0 7636 2776 pts/0 R+ 21:29 0:00 ps aux
                www-data 4184 0.0 0.3 84552 13564 ? S Jun03 2:52 apache2 -DFOREGROUND
                www-data 12763 0.0 0.1 84128 7040 ? S Jun06 0:16 apache2 -DFOREGROUND
                www-data 17919 0.0 0.3 84504 14116 ? S Jun05 1:16 apache2 -DFOREGROUND
                ...
                Bis auf den 'Open failed' Fehler sieht das bei Dir schon alles richtig aus.

                Grundsätzlich ist bei der Fehlersuche es auch einfacher mit einem Write zu testen als mit einem Read. Das Read muss ja eine Verbindung aufbauen und offen halten, da können verschiedene Sachen schief laufen. Beim Write wird nur ein simpler GET abgesetzt und fertig. Den kann man am einfachsten mit einem Trigger testen, da der keinen Zustand hat, der ja vorher über den Bus kommen sollte.

                Ansonsten, um noch etwas näher beim eibd/knxd zu suchen, ob da die Verbindung passt:
                In den Container wird ja mit https://github.com/CometVisu/Docker/...file.cross#L67 die Latte der Busmonitore so wie groupwrite und groupread bereitgestellt.
                => Funktioniert bei Dir denn vbusmonitor1time local:/tmp/eib ? Hier solltest Du alles sehen was am Bus passiert
                TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

                Kommentar


                  #68
                  Zitat von Chris M. Beitrag anzeigen
                  Auch wenn die Dateien eibread-cgi/eibwrite-cgi dem root gehören, sobald diese ausgeführt werden läuft der Prozess unter dem Account des ausführenden. Das ist normalerweise der Web-Server, also z.B. "www-data". Beispiel von meinem Test-Container:
                  Code:
                  # ps aux
                  USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
                  root 1 0.0 0.2 83576 11424 ? Ss Jun01 6:40 apache2 -DFOREGROUND
                  root 7 0.4 0.0 6768 1980 ? Ss Jun01 264:44 knxd -i iptn:172.17.0.1:3700 -e 1.1.238 -u -d/var/log/eibd.log -c
                  root 11 0.0 0.0 15852 2788 ? Ss Jun01 0:00 /usr/sbin/sshd
                  root 2769 0.8 0.0 3996 3372 pts/0 Ss 21:29 0:00 bash
                  www-data 2788 0.0 0.0 2788 740 ? S 21:29 0:00 /usr/lib/cgi-bin/r
                  root 2789 0.0 0.0 7636 2776 pts/0 R+ 21:29 0:00 ps aux
                  www-data 4184 0.0 0.3 84552 13564 ? S Jun03 2:52 apache2 -DFOREGROUND
                  www-data 12763 0.0 0.1 84128 7040 ? S Jun06 0:16 apache2 -DFOREGROUND
                  www-data 17919 0.0 0.3 84504 14116 ? S Jun05 1:16 apache2 -DFOREGROUND
                  ...
                  So siehts bei mir aus, allerdings hab ich aus ca. 120 Zeilen die (hoffentlich) interessanten rauskopiert. Was mir auffällt: /usr/lib/cgi-bin/r gibts bei mir nicht.
                  Das ist alles was mit apache, knxd, eib, cgi-bin usw. zu tun hat:

                  Code:
                  root@raspi4b:~# ps aux
                  USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
                  www-data   351  0.7  0.1 191776  6108 ?        S    18:49   0:02 /usr/sbin/apache2 -k start
                  root       579  0.0  0.4 191704 16932 ?        Ss   Jul13   0:06 /usr/sbin/apache2 -k start
                  root      1984  0.1  0.0   4616  1828 ?        Ss   Jul13   1:50 knxd -i iptn:192.168.170.223:3671 -e 1.1.225 -u/tmp/eib -d -c
                  www-data 29978 0.0 0.1 191776 6108 ? S 00:00 0:03 /usr/sbin/apache2 -k start
                  www-data 29981 0.0 0.1 191776 6108 ? S 00:00 0:03 /usr/sbin/apache2 -k start
                  www-data 29982 0.0 0.1 191776 6108 ? S 00:00 0:02 /usr/sbin/apache2 -k start
                  www-data 29983 0.0 0.1 191776 6108 ? S 00:00 0:03 /usr/sbin/apache2 -k start
                  www-data 29984 0.0 0.1 191776 6108 ? S 00:00 0:02 /usr/sbin/apache2 -k start
                  Siehst Du hier nen Fehler? Muss man /usr/lib/cgi-bin/r manuell starten?


                  Zitat von Chris M. Beitrag anzeigen
                  Bis auf den 'Open failed' Fehler sieht das bei Dir schon alles richtig aus.

                  Grundsätzlich ist bei der Fehlersuche es auch einfacher mit einem Write zu testen als mit einem Read. Das Read muss ja eine Verbindung aufbauen und offen halten, da können verschiedene Sachen schief laufen. Beim Write wird nur ein simpler GET abgesetzt und fertig. Den kann man am einfachsten mit einem Trigger testen, da der keinen Zustand hat, der ja vorher über den Bus kommen sollte.
                  Ich hab in meiner visu das dahingehend geändert, dass ich nur 2 Trigger eingebaut habe. Gehen auf die selbe GA, einmal mit 0 und einmal mit 1. Die Visu lädt nun ohne Fehler, da ja kein read ausgeführt wird. Sendet man einen write Befehl mittels Trigger sehe ich das in den Entwicklertools:

                  w?s=SESSION&a=10/5/0&v=81&ts=1626283509586" und als Reponse kommt nach wie vor: "{'error': 'Open failed'}"


                  Zitat von Chris M. Beitrag anzeigen
                  Ansonsten, um noch etwas näher beim eibd/knxd zu suchen, ob da die Verbindung passt:
                  In den Container wird ja mit https://github.com/CometVisu/Docker/...file.cross#L67 die Latte der Busmonitore so wie groupwrite und groupread bereitgestellt.
                  => Funktioniert bei Dir denn vbusmonitor1time local:/tmp/eib ? Hier solltest Du alles sehen was am Bus passiert
                  Hab ich probiert. Ich hatte schon alle angegebenen Dateien nach /usr/local/bin kopiert. Nachdem "Permission denied" kam, habe ich den Dateien die Berechtigung 0777 gesetzt. Danach gings:

                  Code:
                  root@raspi4b:~# vbusmonitor1time local:/tmp/eib
                  -bash: /usr/local/bin/vbusmonitor1time: Permission denied
                  root@raspi4b:~# vbusmonitor1time local:/tmp/eib
                  2021-07-14 19:01:49.675
                  19:01:52.112 LPDU: BC 11 FA 0C 01 F3 00 80 14 1A D8 :L_Data low from 1.1.250 to 1/4/1 hops: 07 T_DATA_XXX_REQ A_GroupValue_Write 14 1A
                  19:01:52.742 LPDU: BC 11 C9 0D 1F E5 00 80 43 84 80 00 AB :L_Data low from 1.1.201 to 1/5/31 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 43 84 80 00
                  19:01:52.966 LPDU: BC 11 C9 0D 1E E5 00 80 00 00 23 E9 27 :L_Data low from 1.1.201 to 1/5/30 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 00 00 23 E9
                  19:01:54.074 LPDU: BC 11 14 08 08 E3 00 80 26 62 61 :L_Data low from 1.1.20 to 1/0/8 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 26 62
                  19:01:54.107 LPDU: BC 11 14 08 02 E1 00 81 2C :L_Data low from 1.1.20 to 1/0/2 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 01
                  19:01:54.427 LPDU: BC 11 06 14 00 E3 00 80 00 3C 1F :L_Data low from 1.1.6 to 2/4/0 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 00 3C
                  19:01:55.706 LPDU: BC 11 54 73 00 E3 00 80 0C 4E 54 :L_Data low from 1.1.84 to 14/3/0 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 0C 4E
                  19:01:56.522 LPDU: BC 11 30 38 03 E3 00 80 0C 73 45 :L_Data low from 1.1.48 to 7/0/3 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 0C 73
                  19:01:56.574 LPDU: BC 11 21 45 00 E3 00 80 0C 77 2E :L_Data low from 1.1.33 to 8/5/0 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 0C 77
                  19:01:58.388 LPDU: BC 11 0C 3E 00 E3 00 80 0C BA B5 :L_Data low from 1.1.12 to 7/6/0 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 0C BA
                  19:01:58.565 LPDU: BC 11 02 0C 0A E3 00 80 15 28 08 :L_Data low from 1.1.2 to 1/4/10 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 15 28
                  19:01:58.741 LPDU: BC 11 C9 0D 1F E5 00 80 43 82 80 00 AD :L_Data low from 1.1.201 to 1/5/31 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 43 82 80 00
                  19:01:58.966 LPDU: BC 11 C9 0D 1E E5 00 80 00 00 23 E9 27 :L_Data low from 1.1.201 to 1/5/30 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 00 00 23 E9
                  19:01:59.289 LPDU: BC 11 0C 42 00 E3 00 80 0C 47 34 :L_Data low from 1.1.12 to 8/2/0 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 0C 47

                  Ich denke, knxd mit dem Bus funktioniert, aber CometVisu mit knxd nicht.
                  Hast Du noch ne Idee? Danke!

                  Kommentar


                    #69
                    Dass Du kein r siehst ist nicht überraschend, Du müsstest in genau dem Sekundenbruchteil ps ausführen wenn der Read-Request kommt. Und die Chance das wirklich zu sehen gibt's erst wenn alles läuft und der r so lange offen gehalten wird, bis eine neue Bus-Antwort an die Visu übermittelt werden soll.

                    Der ps sieht passend aus. Web-Server läuft als www-data, d.h. der eibwrite-cgi wird auch mit den User www-data ausgeführt.

                    OK, aber halten wir mal fest:
                    Busmonitor geht => der knxd funktioniert und hat eine Verbindung zum KNX
                    Der w hat "Open failed" => der eibwrite-cgi kann nicht auf den Socket zugreifen => entweder sucht der den an einer anderen Stelle oder die Zugriffsrechte passen nicht

                    Um zu klären ob es ein Berechtigungsproblem ist kannst Du den Monitor ja mal unter dem entsprechenden User ausführen:
                    Code:
                    su www-data -s /bin/bash -c 'vbusmonitor1time local:/tmp/eib'
                    Und um zu klären nach welcher Datei gesucht wird kannst Du in den Source Code schauen. Aber wenn Du die 0.0.5.1 Zip Datei nutzt muss es local:/tmp/eib sein, vgl. auch https://github.com/knxd/knxd/blob/0....ite-cgi.c#L227
                    TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

                    Kommentar


                      #70
                      Zitat von Chris M. Beitrag anzeigen
                      OK, aber halten wir mal fest:
                      Busmonitor geht => der knxd funktioniert und hat eine Verbindung zum KNX
                      Der w hat "Open failed" => der eibwrite-cgi kann nicht auf den Socket zugreifen => entweder sucht der den an einer anderen Stelle oder die Zugriffsrechte passen nicht

                      Um zu klären ob es ein Berechtigungsproblem ist kannst Du den Monitor ja mal unter dem entsprechenden User ausführen:
                      Code:
                      su www-data -s /bin/bash -c 'vbusmonitor1time local:/tmp/eib'
                      Also, der User www-data darf das nicht (Permission denied), der User pi darf das auch nicht. Der User root darf das.
                      Hab nochmal die Rechte von /tmp/eib kontrolliert, dort steht 0777. Hab diese nochmal auf was anderes gesetzt und wieder zurückgeändert auf 0777.
                      Nochmal probiert, Busmonitor läuft unter allen drei Benutzern. Offenbar ist hier beim Setzen der Rechte irgendwas schief gelaufen.

                      Leider hat sich das Verhalten der CometVisu nicht verändert. Ich starte den im Chrome mit geöffneten Entwicklertools, und "disable Cache" ist aktiviert.

                      Zitat von Chris M. Beitrag anzeigen
                      Und um zu klären nach welcher Datei gesucht wird kannst Du in den Source Code schauen. Aber wenn Du die 0.0.5.1 Zip Datei nutzt muss es local:/tmp/eib sein, vgl. auch https://github.com/knxd/knxd/blob/0....ite-cgi.c#L227
                      Hab ich kontrolliert. In meinem verwendeten knxd-0.0.5.1 steht ebenfalls \tmp\eib als default drin. Außerdem wird der knxd ja mit dem Parameter -u/tmp/eib gestartet, der dürfte das ja nochmal überschreiben.


                      Nochmal zum Verständnis: r und w liegen in /usr/lib/cgi-bin und zeigen auf /usr/bin/eibread-cgi bzw. /usr/bin/eibwrite-cgi. Passt hier das Verzeichnis /usr/bin? Also genügt es, dass die dort liegen, wohin der Link zeigt oder werden die tatsächlich in /usr/bin erwartet?

                      Kommentar


                        #71
                        r und w müssen da liegen, wo der Web-Server sein CGI-BIN sucht - also i.d.R. in /usr/lib/cgi-bin.
                        Wenn die dort aber physikalisch nicht liegen, sondern das per Symlink gelöst wird ist das auch i.O. - wichtig ist dann, dass der Symlink halt im CGI-BIN Verzeichnis liegt und auf ein Programm verweist das auch existiert. Dazu müssen noch die Datei-Berechtigungen vom Symlink und vom Programm selbst passen.

                        Das scheint aber bei dir alles schon zu funktionieren, sonst gäbe es keine durch den Programmfluss selbst erstelle Antwort - die gibt es mit {'error': 'Open failed'} aber.

                        Also bleibt nur noch #1, dass der Socket nicht existiert bzw. an einer Stelle existiert an der nicht gesucht wird. Das haben wir aber mit dem vbusmonitor1time erfolgreich geprüft.

                        Und #2, dass der Socket zwar passt, aber eben nicht auf diesen zugegriffen werden kann/darf. Das haben wir mit dem su erfolgreich getestet.
                        Da habe ich jetzt nicht verstanden warum es zuerst nicht ging und dann mit genau der gleichen Berechtigung aber schon. (Evtl. ist hier irgend was grundsätzliches im Argen?)

                        Wenn das nun alles funktioniert fehlt mir die Phantasie was nun noch das Problem sein kann.
                        TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

                        Kommentar


                          #72
                          By the way! Hat der Raspi eine ausreichende Stromversorgung?

                          Kommentar


                            #73
                            Zitat von Tontechniker Beitrag anzeigen
                            By the way! Hat der Raspi eine ausreichende Stromversorgung?
                            Ich gehe davon aus. Ich verwende das original Netzteil und habe keine Peripherie angeschlossen.

                            Kommentar


                              #74
                              Und der andere Klassiker beim RPi: läuft der mit einer SD Karte und könnte die inzwischen eine Macke haben?

                              (Einen produktiv genutzten RPi sollte man immer nur mit einem stabilen Speichermedium betreiben, SD Karte und USB-Stick scheiden da aus)
                              TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

                              Kommentar


                                #75
                                Guter Hinweis. Die SD-Karte ist nagelneu, die hab ich erst vor ein paar Tagen ausgepackt.

                                Kommentar

                                Lädt...
                                X