Beiträge von maxkr

    Hi Arno,
    ja das geht grundsätzlich schon. Was für einen RasPi hast du denn im Einsatz? Mit dem 3er überhaupt kein Problem, mit den älterne Single Core RasPi ist anstelle vom Apache evt. lighttpd die bessere Wahl, weil der weniger Ressourcen braucht. Außerdem muss der Port über den du dann auf diesen Webserver zugreifen willst natürlich ein anderer sein als der vom DoorPi...


    Viele Grüße,
    Max

    Hi Arno,
    ja die Rechte sollten nicht das Problem sein. Ich denke du musst dir das mit dem modprobe-Verzeichnis mal anschauen und ob die Kamera auch aktiviert ist.


    Außerdem findest du vielleicht Hinweise mit:
    dmeg | grep video


    Bei mit sieht das dann z.B. so aus:

    Code
    1. [ 5.255542] Linux video capture interface: v2.00
    2. [ 5.388863] bcm2835-v4l2: V4L2 device registered as video0 - stills mode > 1280x720
    3. [ 5.393552] bcm2835-v4l2: Broadcom 2835 MMAL video capture ver 0.0.2 loaded.

    Hi Arno,


    vielleicht ein Rechtethema. Was liefert dir denn:
    ls -la /etc/init.d/mjpg_streamer
    sollte etwa so aussehen:
    -rwxr-xr-x 1 root root 1039 Apr 12 10:05 /etc/init.d/mjpg_streamer



    Im Verzeichnis /etc/modprobe.d/ sind diverse *.conf-Dateien ist da der Treiber ggf. mit blacklist aufgeführt? Dann würde er den nämlich nicht laden...


    Da es schon funktioniert hat unwahrscheinlich, aber:
    Hast du die Kamera per raspi-config > Interfacing Options aktiviert?


    Viele Grüße,
    Max

    Hallo Arno,


    habe gerade deinen Beitrag auf Github gesehen. Kannst du mir mal sagen welche Firmware-Version der Fritz-Box du hast. Ich habe wie gesagt seit der 6.87 das Problem gehabt, dass im der Anmeldename (bei dir 622) und auch das Kennwort zu einfach war. gesehen hat man das nur, wenn man bei den Telefoniegeräten in der Übersicht die Gräte anschaut. Mein Eintrag mit dem DoorPi war dann rechts (d.h. links von den Buttons) mit einem kleinen Warnsymbol mit Ausrufezeichen versehen. Erst nach Änderung konnte sich mein DoorPi wieder mit der FB per SIP verbinden...


    Für mich passen deine Netze nach wie vor nicht zusammen:

    Code
    1. 2018-04-01 11:13:42,067 [INFO] [doorpi.sipphone.from_linphone] Trying to connect to [UDP://192.168.188.1:5060]
    2. 2018-04-01 11:13:42,068 [INFO] [doorpi.sipphone.from_linphone] belle_sip_get_src_addr_for(): af_inet6=0
    3. 2018-04-01 11:13:42,068 [INFO] [doorpi.sipphone.from_linphone] Channel has local address 192.168.0.10:5060


    Nach wie vor meine ich, dass der DoorPi als auch deine Fritzbox im selben Subnetz liegen sollten. Bei mir sieht das zum Vergleich so aus:

    Code
    1. 2018-03-18 22:35:26,997 [INFO] [doorpi.sipphone.from_linphone] Trying to connect to [UDP://192.168.178.1:5060]
    2. 2018-03-18 22:35:27,000 [INFO] [doorpi.sipphone.from_linphone] belle_sip_get_src_addr_for(): af_inet6=0
    3. 2018-03-18 22:35:27,000 [INFO] [doorpi.sipphone.from_linphone] Channel has local address 192.168.178.30:5060

    ...es liegen beide im Netz 192.168.178.x


    Daher noch mal die Frage:
    Woher kommt bei dir die 192.168.0.10 (ist die fest konfiguriert?) bzw. zum anderen die 192.168.188.1 (das ist die Fritzbox oder?)...

    Danke für die Erklärung Martin,


    jetzt verstehe ich das Problem und eigentlich hast du es auch genauso beschrieben...
    Per Event wird ein Telefon vom DoorPi angerufen und sobald die Verbindung steht soll eine Datei abgespielt werden anstatt die Sprechverbindung aufzubauen. Was du also bräuchtest, müsste also den Weg nehmen, der üblicherweise über den Mikrofoneingang von der Türsprechstelle beim Angerufenen ankommt.


    Da fällt mir jetzt aber leider keine Lösung ein, was aber nicht heißt, dass es sie nicht gibt.
    Vielleicht kann man das über Alsamixer/ Pulseaudio irgendwie reinmischen. Das wäre evt. ein Ansatz, kenne mich aber da nicht gut genug aus.


    Alternativ kann man ja linphonecsh (und theoretisch ohne DoorPi) über die Kommandozeile steuern, damit könnte man so etwas evt. auch verpacken. Aber natürlich auch keine fertige Lösung...

    Vielleicht ist das Absturzproblem gelöst:
    Durch Zufall habe ich diesen Fork vom mjpg_streamer entdeckt:
    https://github.com/jacksonliam/mjpg-streamer


    Zuerst bin ich auf diese Seite aufmerksam geworden:
    https://discourse.octoprint.or…onfiguration-options/1106


    Die /etc/init.d/mjpg_streamer habe ich dazu wie folgt modifiziert:

    Code
    1. /usr/local/bin/mjpg_streamer -i "/usr/local/usr/local/lib/mjpg-streamer/input_raspicam.so -fps 24 -x 1024 -y 768 -ex auto -quality 85" -o "/usr/local/lib/output_http.so -n -w /usr/local/www -p 9000" >/dev/null 2>&1 &


    Das Beste: die Patches von Nea wollten nicht, scheinen hier aber enthalten zu sein (habe jetzt keinen richtigen Code-Review gemacht...).
    Mit -ex auto stellt man auto exposure ein, das mir mit input_uvc.so den mjpg_streamer zum Absturz gebracht hat. Nun sind die Farben zwar anders (aber auch viele Parameter da um das ggf. noch anzupassen).


    Der wirkliche Hammer ist aber:
    Der mjpg_streamer braucht jetzt unter 5% CPU-Leistung anstelle der rund 45% zuvor.


    Ob die Abstürze nun ausbleiben werden wohl erst die kommenden Tage und Wochen zeigen...


    ACHTUNG:
    Leider geht das nur mit einer RasPi-Kamera am CSI-Port!!! Wer eine USB-Kamera im Einsatz hat, dem bringt dieser Fork wahrscheinlich nichts...

    Hi Martin,


    in der Anahme, dass du dann einen Lautsprecher (mit Verstärker) am Soundausgang vom RasPi betreibst und den Ton dort ausgeben willst:


    Du könntest ja in der doorpi.ini die Einstellung dialtone entsprechend setzen, dann sollte das sogar schon vor dem Rufaufbau funktionieren.


    Ansonsten mache ich das auch:
    Wenn ich eine RFID erkenne, spiele ich einen Ton ab. Ich denke du musst ein wenig mit dem Ausgabedevice herumexperementieren, dann sollte das schon funktionieren. Oder deine Einstellungen im Alsamixer überprüfen, oder ob der Sound an den HDMI-Port geht, könnte auch ein Grund sein, dass kein Ton ankommt...


    Viele Grüße,
    Max

    Jetzt habe ich mal ein paar Einstellungen durchprobiert aber das "Einfrieren" des Bildes passiert schon recht häufig - auf ein Mal...


    Einstellungen mit uvcdynctrl bringt bei mir leider gar nichts. D.h. mit mit 'Auto Exposure' kann man den mjp_streamer zuverlässig zum Absturz bringen - danach muss ich ihn neu starten...


    Das Bild wirkt abends oft auch zu dunkel und tagsüber ist es meistens zu hell. Hier hilft bisher nur ein Neustart vom mjp_streamer. Auch wenn das schon länger her ist, scheint es da noch keine Lösung zu geben? Siehe auch:
    https://www.doorpi.org/forum/thread/719-mjpg-stream-zu-hell/
    https://www.doorpi.org/forum/t…mer-automatisch-anpassen/


    Da ich ja einen Helligkeitssensor an meiner Außenstelle am Teensy habe, könnte ich natürlich bei einer großen Helligkeitsänderung den Dienst neu starten.
    Oder ich verküpfe das zusätzlich mit compare indem ich Bilder passend zur Tagesheligkeit ablege und die mit dem aktuellen Livebild vergleiche und dabei das Bild suche, das am nächsten an der aktuellen Tageshelligkeit dran ist...


    Elegant ist das natürlich alles nicht...

    Um Störeinflüsse weitgehend auszuschließen würde ich dir auch zur digitalen Übertragung der Audio-Daten raten und dir daher empfehlen USB bis zur Außenstelle zu führen.


    Bei mehr als 5m würde ich dir aber eher so etwas empfehlen:
    http://www.logilink.eu/Produkt…0m_mit_4_Port_Hub-PoE.htm


    Allerdings muss deine Verkabelung auch min. CAT5 hergeben...
    Aber dann hast du immerhin 4 USB-Ports und könntest sogar später evt. eine Webcam nachrüsten und hast auch gleich reserven für einen Audio-Verstärker (um den Lautsprecher laut genug ansteuern zu können) - z.B. PAM8403 wie oben empfohlen...


    Himbeere :
    bei deiner Skizze oben willst du dein Mikro mit der Spannung vom RasPi versorgen. Das macht aber eine USB-Soundkarte (am Mikrofon-Eingang) üblicherweise bereits. Du brauchst also eigentlich keine extra Spannungsversprgung. Problem wird eher die Leitungslänge sein, wenn nichts mehr ankommt...


    Alternativ könntest du diesen Verstärker ausprobieren (an der Außenstelle): https://www.elv.de/smd-mikrofo…rker-komplettbausatz.html
    Musst aber sicher das Signal am Mikrofineingang begrenzen - zumindest habe ich mir an einer USB-Soundkarte damit den Mikrofoneingang erfolgreich zerstört...


    Die beiden Verstärker würde ich an der Außenstelle montieren. Dann brauchst du 5V + Masse, deine beiden Audiosignale (ggf. jeweils mit Masse), d.h. in Summe 6 Leitungen. Und dann noch deine Drähte pro Klingeltaster...


    Viele Grüße,
    Max

    Ich habe ja die RasPi-Cam am CSI-Port dran. Sollte das mit der Belichtungsnachführung dort auch funktionieren? Ich bekomme da nur eine Fehlemeldung, dass es den Befehl nicht gibt. Bei uvcdynctrl -c wird "Auto Exposure" aber mit aufgeführt...


    [Nachtrag]:
    uvcdynctrl -s 'Auto Exposure' 0 bzw.
    uvcdynctrl -s 'Auto Exposure' 1
    könnte funktionieren?!


    ...mit uvcdynctrl -c -v weiß ich nun mehr: 0=Auto, 1 Manual Mode...!


    Das mit compare ist auch nicht schlecht was die weißen Tagbilder angeht: >37% Abweichung.
    Nur bei Dunkelheit wird es eng: Dunkel mit Fehler weicht nur etwa 1,5% von einem Bild ohne Fehler ab.
    Aber vielleicht werde ich das mal mitprotokollieren, wenn sie sehr ähnlich sind.


    Also mit dem Auto Exposure verschlimmbessere ich das Ganze noch - das war gestern noch nicht der Fall:
    nach dem Umschalten auf manuell habe ich ein weißes Bild, zurückschalten auf Automatik hilft nicht. Der mjpg-streamer will neu gestartet werden, damit ich wieder ein Bild habe...


    Jetzt habe ich noch den Weißabgleich entdeckt (uvcdynctrl -s 'White Balance, Auto & Preset' 0 / 1). Mal sehen, ob ich damit das Bild wieder zurückbekomme.


    Ansonsten verfolge ich auch noch den Ansatz mit compare weiter...

    Danke CBMOD,


    wenn ich mir dein Beispielskript mit dem Watchdog für den mjpg-streamer anschaue, bekommst du am Port 9000 keine Daten mehr oder? Bei mir kommen immer noch Daten, so dass er den Ausfall bei mir wahrscheinlich gar nicht erkennt auf diesem Weg... Auch jpegs, die ich per Cron hole sind immer valide Bilder...


    Meine Idee wäre daher, dass ich diese über- oder unterbelichteten Bilder irgendwo ablege und mit den Bildern die ich regelmäßig ziehe irgenwie vergleiche. Stimmen die zu sehr über hängt der mjpg-streamer und ich starte dann neu.


    Ein erster Ansatz könnte ImageMagick mit compare sein...

    Wisst ihr eine Möglihckeit den mjpg_streamer zu überwachen bzw. die Ursache für die Abstürze zu finden:


    Hatte meinen DoorPi mehrere Wochen im Testbetrieb und dort hat sich der in der Zeit einmal verabschiedet. War mir aber nicht ganz sicher, ob da nicht jemand an die Verkabelung zur Kamera gekommen ist. Hier hat auch nur ein Neustart vom RasPi geholfen.


    Nach dem Einbau hatte ich meist nach weniger als 12 Stunden einen Ausfall, konnten mit service mjpg_streamer restart aber wieder ein Kamerabild bekommen.
    Danach habe ich einen cronjob eingerichtet der mir jede Viertelstunde ein Bild speichert, dann waren die Probleme erst mal weg.


    Seit drei Tagen etwa reicht das nicht mehr, der mjpg_streamer stürzt wieder vermehrt ab. Also habe ich einen cronjob eingerichtet, der den service einmal am Tag startet.


    Jetzt habe ich trotz dieser Maßnahmen oft bereits wenige Stunden nach diesem Neustart einen Ausfall.


    Das Bild ist entweder nahezu ganz weiß oder ganz schwarz mit einem winzigen Lichtpunkt von einer Straßenbeleuchtung, die tatsächlich an der Stelle im Bild ist.


    Gibt es eine Möglichkeit festzustellen, dass das Bild Mist ist, damit ich dann neu starten kann?
    Noch besser wäre es natürlich zu Wissen warum das überhaupt passiert...


    Viele Grüße,
    Max

    Welche Fritzbox-Version hast du denn?
    Bei mir war es wie gesagt so, dass er bei sipserver_username die 620 nicht mehr akzeptiert hat mit der 6.87. Hatte zuvor die Version 6.66 drauf...
    Habe nun sowohl in der FB als auch im DoorPi einen Namen eingetragen bei dem die FB nicht mehr meckert.


    Möglicherweise läuft auch auf deinem DoorPi noch was von LinPhone & Co im Hintergrund, also unabhängig vom DoorPi, was zumindest diese Info aus deinem Trace vermuten lässt:


    Code
    1. 2018-04-08 09:24:11,235 [INFO] [doorpi.sipphone.from_linphone] Creating listening point [0x22b3570] on [sip:0.0.0.0;transport=UDP]
    2. 2018-04-08 09:24:11,236 [INFO] [doorpi.sipphone.from_linphone] Creating listening point [0x22b3720] on [sip:0.0.0.0:5060;transport=TCP]
    3. 2018-04-08 09:24:11,236 [ERROR] [doorpi.sipphone.from_linphone] TCP bind() failed for 0.0.0.0 port 5060: Address already in use
    4. 2018-04-08 09:24:11,236 [INFO] [doorpi.sipphone.from_linphone] Listening point [0x22b3720] on [sip:0.0.0.0:5060;transport=TCP] destroyed
    5. 2018-04-08 09:24:11,237 [WARNING] [doorpi.sipphone.from_linphone] Could not start tcp transport on port 5060, maybe this port is already used.
    6. 2018-04-08 09:24:11,237 [INFO] [doorpi.sipphone.from_linphone] Creating listening point [0x229d1d8] on [sip:0.0.0.0:-1;transport=TLS]

    ...Address already in use deutet irgendwie darauf hin, dass der Port durch ein anderes Programm auf deinem DoorPi bereits belegt ist...


    Auch gab es einen Database Lock, was auch wieder darauf hindeutet, dass der DoorPi im Hintergrund mehrfach lief.


    Hoffe das hilft dir irgendwie weiter...!


    Viele Grüße,
    Max

    Hi Arno,


    wenn du in der FritzBox schaust ist dort ein Hinweis bei deinem DooPi unter Telefonie -> Telefoniegeräte zu sehen. Meine FB hat vorgestern ein Update durchgeführt (auf 6.87) und der war der Benutzername bzw. das Kennwort nicht sicher genug...


    Ich habe nach wie vor nämlich den Eindruck, dass sich dein DoorPi nicht an der FB anmeldet. Oder zumindest nicht richtig.


    In deiner Konfig ist dein Telefon als AdminNumber eingetragen. Kannst du mit **620 von deinem Telefon auf den DoorPi erreichen?. Sende ggf. davon auch mal ein Tracelog. Würde mich interessieren, ob der DoorPi überhaupt was mitbekommt...


    Viele Grüße,
    Max

    Das mit deiner Kamera ist echt bedenktlich. Einen anderen RasPi hast du wahrscheinlich nicht zum Testen oder?! Ansonsten noch mal Kabel zur Kamera testen: Richtig herum drin, gerade drin, vielleicht auch noch mal beide Enden aufmachen.
    Und nur um sicherzugehen: Dein RasPi sollte dabei unbedingt vom Strom getrennt sein, ein Kurzschluss beschädigt schnell dauerhaft etwas...


    Also auch bei mir ist Jessie drauf für den DoorPi, dachte es wäre schon Stretch, das ist aber ein andere Projekt von mir...


    Installiert habe ich nach dieser Anleitung (mag es nicht wenn alles automatisch läuft und man am Ende nicht so recht weiß warum es nicht geht...):
    https://www.doorpi.org/forum/l…em-raspberry-pi-raspbian/
    ...das sollte der anderen Anleitung bis Schritt 9 entsprechen.


    Viele Grüße,
    Max

    Hallo Arno,
    nur nicht aufgeben! Ich bin mir sicher, dass du den Vorschlaghammer nicht brauchen wirst!


    Wenn deine (neue) Fritzbox dann DHCP-, Nameserver und Telefonanlage ist, sollte sie unter einer einzigen IP-Adresse erreichbar sein (Achtung wegen LAN-Port 4...) und die Namensauflösung (ping fritz.box) funktionieren.


    Ich drücke dir fest die Daumen!!!
    Max