Beiträge von Aldafera

    Moin Marcus,


    ich hab biometrische Systeme bereits bei Banken und mil. Kunden implementiert.


    Auf Linux haben wir Gesichtsbiometrie schon 1998 eingebaut, damals mit der Firma Cognitec aus Dresden.


    Es gilt also zu klären Web Dienst oder lokale Kernel Integration.


    Wo sollen die Enrolement Daten für eine biometrische Identität liegen?
    Wo soll das biometrische Template mit Deinen biometrischen Daten liegen?
    Wo soll die Entscheidung fallen auf dem lokalen Rechner oder auf dem WebService?
    Willst Du eine 1 zu 1 Prüfung der biometrische Identität?
    Willst Du eine 1 zu n Prüfung der biometrische Identität? - Dann heisst das wieder viel rechnen weil ich Dich dann aus einem Pool von ID's erst mit
    einer hohen Wahrscheinlichkeit rausfischen muss


    Der rechenintensivste Teil ist die Gesichtsfindung, da müssen ausreichend Frames von der Kamera
    geliefert werden, auch ist etwas Kooperation gefragt, wenn dann die eigentliche Gesichtserkennung gestartet wird.


    Das Problem dürfte mal wieder die Rechenleistung vom Raspi sein, wenn dieser laufend im Videostrom nach Gesichtern suchen soll.


    Das wird sicher funktionieren, aber was bleibt dann noch übrig für den Rest? - Versuch macht klug.


    Auch musst Du bedenken was passieren soll, wenn 2 Gesichter im Video zu sehen sind, Schlagschatten auf den Gesichtern sind oder die
    Kamera im IR Modus Bilder liefert, dann wird es heftig mit der soliden korrekten Erkennung :)


    Die Sicherheitskameras von Bosch haben den Web-Dienst von Bio-ID bereits in die Kamerafirmware eingebaut, somit wird der
    Rechner nicht mit Suchen und Erkennen belastet.


    Stichwort Kamera, hier haben wir das Problem, das der Doorpi zur Laufzeit die V4L Schnitte im Zugriff hat, also müsste erst am Doorpi geklingelt werden,
    Doorpi gibt dann die Kamera frei und triggert die Biometrie - danach Aquise - Vorverarbeitung der Bilder - Gesichter finden - Gesichter erkennen - Ergebnis gegen Template prüfen und dann die entsprechende Antwort and DoorPi zurückliefern.


    Spannend, würde aber gehen....


    Aus meiner eigenen Praxis und Erfahrung heraus jedoch bin ich was Haustüren, Zutrittssysteme und Banking angeht dann bei den
    Handvenenscannern geblieben. Dafür gibt es Einbaumodule von Fujitsu aber auch bereits fertige Systeme (z.B Firma PCS).


    Herzliche Grüsse


    Harald aka Aldafera

    Schönen Abend Thorsten,


    jop Deine Anfrage ist richtig.


    Solange Du keine Konfiguration in ein Startscript hinterlegst sind nach einem Reboot oder nach einem


    # wondershaper clear wlan0


    alle Einstellungen wieder weg.


    Noch ein paar Hintergründe betreffend WLAN... :)


    Weshalb ich mich auf das Netzwerk gestürzt habe und nicht auf mögliche Hardwareprobleme von Soundkarte, Micro und Lautsprecher ist historisch bedingt.


    Mein Probblem hier sind die Entfernungen welche ich zu überbrücken habe. Am Anfang hatte ich hier nur einen Sammlung von alten Fritz Boxen mit welchen ich über WLAN Brücken die einzelnen Gebäude anfahren konnte.


    Also habe ich für die Tierärzte alte Handys mit dem FritzBox! Phone bereitgestellt, in meinem Handy hatte ich noch eine Sim-Karte drin.


    Wann immer ich angerufen wurde und ich nahm den Anruf über die Fritz Box mit FritzBox! Phone entgegen, glaubten die Leute ich stehe in der Mitte einer Turnhalle - Hall und Echos ohne Ende....... Grübel


    Gleiches Handy ohne VoIP Client direkt angerufen über GSM... kein Echo, kein Hall, kein Knacken..... Grübel


    Anruf über Festnetz aber Dect über FritzBox ... kein Echo, kein Hall, kein Knacken..... Grübel


    Also konnte es einfach nicht die Hardware sein.....


    Einmal ankommender Anruf über die Fritz mit WLAN und dann über Fritz mit Dect und dann über GSM..


    Probleme gabe es nur wenn WLAN und lokales VoIP im Spiel war.


    Eine andere Beobachtung konnte ich machen, als ich mit Messer und Gabel am Küchentisch die DoorPi's zusammengebaut und diese mit WLAN gekoppelt hatte.


    Seit der FritzBox Firmware Version 5.x wird ja angezeigt wieviel WLAN Bandbreite jedes Gerät im Augenblick verwendet.....


    Als meine Frau mit Android Phone, Apple IPhone und Apple Tablett bewaffnet vor der Haustüre stand (alle WLAN on), ging mit dem DoorPi über WLAN am Haus gar nix mehr... :)


    Das ganze Netwerk war "irgendwie" in Unruhe, weil wohl jeder Teilnehmerknoten im WLAN eine Info bekam, ihr müsst die verfügbare Bandbreite jetzt neu aufteilen.


    Es dauerte bis zu 15 Minuten, bis das Ruhe eingekehrt war und die "Hackordnung" im WLAN neu ausgehandelt war.


    Unser neues Netzwerk hier kommt jetzt über Glasfaser und Backup mit Kupfer, die Komponenten von Cisco, also habe ich
    Cisco mal verständigt, die haben mir den Hinweis gegeben, das die Cisco Firmware Möglichkeiten von TOS und Cos bietet, welche
    ich für die jeweiligen Endknoten auf Portebene aktivieren kann.


    Ein VIOP Call produziert sehr viele kleine UDP Packete, welche manchmal zum Problem führen können, deswegen sollten diese priorisiert
    behandelt werden, das geht bei der FritzBox aber nur wenn die Pakete ins Internet geroutet werden.


    Eine weitere Empfehlung kam dann aus der VoIP Abteilung von Cisco, die Endknoten wenn möglich in der Bandbreite zumindest mal versuchen fest zu steuern.


    Also hab ich den Raspis einfach lokal gesagt, ihr habt für Up- und Downstream genau die Bandbreite, damit gibt es zwischen der
    FritzBox und den Raspis eine klare Abmachung, keine Verhandlungen mehr über die Bandbreite.


    Im weiteren wie ich heute erfahren habe, kann man die Optimierungen von LinPhone auf dem Raspi nicht einfach so verwenden, also auch hier der Ansatz über eine feste Bandbreite erstmal Ruhe zu bekommen.


    Es gibt weitere Möglichkeiten TOS und COS für SIP auf dem Raspi zu steuern, ich bin da erstmal nicht tiefer rein, da mittlerweile alle
    Raspis am Kabel hängen.


    Hoffe es hilft dennoch weiter.


    Schönen Abend noch Harald aka Aldafera

    Hallo Zusammen,


    ich hatte ähnliche Probleme am Anfang mit Hall und Echos.


    Ich habe die Probleme durch


    1. Optimierung des Sip Servers
    2. Optimierung der Netzwerk Infrastruktur (Priorisierung)
    2. Traffic Shaping mittels Wondershaper auf dem Doopi


    wesentlich reduzieren können.


    Hab meinen Aufbau und Optimierungspfad bei Hilfe und Ratschläge mal eingestellt.


    Leichte Echos habe ich jetzt nur noch an den Sprechstellen welche über WLAN angeschlossen sind.


    Im Bereich der Linphone Konfiguration gibt es noch ein paar Stellschrauben hierzu, Doorpi übergibt ja beispielsweise "firewallpolicy oder echo_canellation" usw. an die
    Linphone Schnittstelle aber das wird ja bereits getestet.


    Viel Erfolg bei der Optimierung und Problembehebung


    Aldafera aka Harald

    Teil-2


    Optimierung-1 (Optimierung des Sip Servers)


    Auf der Asterisk habe ich in der Sip.conf in Sektion [general] tos und cos eingestellt


    tos_sip=cs3 ; Sets TOS for SIP packets.
    tos_audio=ef ; Sets TOS for RTP audio packets.
    tos_video=af41 ; Sets TOS for RTP video packets.
    tos_text=af41 ; Sets TOS for RTP text packets.


    cos_sip=3 ; Sets 802.1p priority for SIP packets.
    cos_audio=5 ; Sets 802.1p priority for RTP audio packets.
    cos_video=4 ; Sets 802.1p priority for RTP video packets.
    cos_text=3


    Ergebnis Testsystem-1 (Lokals LAN) noch mittelstarke Echos welche auf den Aufnamen der DoorPi's zu hören sind
    Ergebnis Testsystem-2 (WLAN) immer noch Hall und starke Echos welche auf den Aufnamen der DoorPi's zu hören sind


    Optimierung-2 (Optimierung des Switches)


    Für Testsystem-1 (Lokals LAN) wird für den entsprechenden Port QosBasic aktiviert und auf höchste Priorität umgestellt
    Für Fritzbox (Lokaler LAN Anschluss) wird für den entsprechenden Port QosBasic aktiviert und auf höchste Priorität umgestellt


    Ergebnis Testsystem-1 (Lokals LAN) noch leichte Echos welche auf den Aufnamen der DoorPi's zu hören sind
    Ergebnis Testsystem-2 (WLAN) immer noch mittelstarke Echos und Hall welche auf den Aufnamen der DoorPi's zu hören sind


    Optimierung-3 (Optimierung an den DoorPi's )


    Installation vom Debian Paket wondershaper auf Testsystem 1 und 2


    Angaben sind in “Kilobits per second”, kbps


    # apt-get install wondershaper


    dann weiter auf Testsystem 1


    # wondershaper eth0 2048 2048


    # sudo doorpi_cli --trace



    dann weiter auf Testsystem 2


    # wondershaper wlan0 2048 2048


    # sudo doorpi_cli --trace


    Ergebnis Testsystem-1 (Lokals LAN) keine Echos mehr, trockener Sound


    Ergebnis Testsystem-2 (WLAN) minimale Echos (leichter Hall) welche nicht mehr stören




    Um verschiedene Shaping Einstellungen zu testen kann man mittels


    # wondershaper clear eth0


    seine akutelle Optimierung abstellen und eine neue Bandbreite vorgeben mittels


    # wondershaper eth0 xxx xxx


    Welche Werte für Euch wirksam sein könnten, müsst ihr einfach durch eigene Tests herausfinden.


    Fazit:
    Alle via Netzwerkkabel angebundenen Systeme weisen bei mir zumindest weniger Echo und Hall auf als jene Sprechstellen welche via WLAN angebunden sind.


    Viel Erfolg


    Aldafera aka Harald

    Teil-1


    Hallo Zusammen,
    da hier im Forum sehr rege über das Thema Echo diskutiert wird, habe ich mal meine Optimierung hier eingestellt, mit welchem
    ich Echo und Hall einschränken konnte.


    Testsystem-1 (Lokals LAN)
    HW: Raspi P3
    OS: Jessie Lite
    SK: Renkforce Soundkarte
    LS: JBL-Go Aktive Lautsprecher über 3,5 mm Klinke
    MI: 2 x MCE101 vorgespannt mit 1,5 Volt über 3,5 mm Klinke
    NW: Interne eth0 vom Raspi 3
    CA: Digitus Optiguard über IP LAN 1280 x 720 und über V4L Loopback mittels ffmpeg
    CO: Speex
    Alsa Mixer LS auf 65 Micro auf 62
    Dorpi 2.51


    Sip Backend-1
    SIP Asterisk 1.4 ohne tos und cos optimierung


    Sip Backend-2
    FritzBox 7490 OS 6.60


    Netwerk: Cisco SG350XG-2F10 ohne tos und cos Optimierung


    Ping zum Router durchschnittlich time=0.376 ms
    Ping zum Asterisk durchschnittlich time=0.245 ms


    Gegenstelle-1 Galaxy S5 mit AntiSip 5.21-82-4


    Gegenstelle-2 Laptop mit Windows 7 Liblinphone win32 SDK version 3.10.2
    Soundkarte Realtek und Logitech Funk Headset
    Anbindung interne Netzwerkkarte 1Gb Uplink


    Sprechtest langsames zählen von 1 bis 10


    Testsystem-2 (WLAN)
    HW: Raspi P3
    OS: Jessie Lite
    SK: Renkforce Soundkarte
    LS: JBL-Go Aktive Lautsprecher über 3,5 mm Klinke
    MI: 2 x MCE101 vorgespannt mit 1,5 Volt über 3,5 mm Klinke
    NW: Edimax WLAN Stecker an wlan0
    CA: Digitus Optiguard über IP LAN 1280 x 720 und über V4L Loopback mittels ffmpeg
    CO: Speex
    Dorpi 2.51


    Sip Backend-1
    SIP Asterisk 1.4 ohne tos und cos optimierung


    Sip Backend-2
    FritzBox 7490 OS 6.60


    Netzwerk FritzBox 7490 and Cisco SG350XG-2F10 ohne tos und cos Optimierung


    Ping zum Router durchschnittlich time=1.559 ms
    Ping zum Asterisk durchschnittlich time=1.642 ms


    Gegenstelle-1 Galaxy S5 mit AntiSip 5.21-82-4


    Gegenstelle-2 Laptop mit Windows 7 Liblinphone win32 SDK version 3.10.2
    Soundkarte Realtek und Logitech Funk Headset
    Anbindung interne Netzwerkkarte 1Gb Uplink


    Sprechtest langsames zählen von 1 bis 10


    Bei beiden Testsystemen habe ich signifikate Echos, diese sind auch auf den Aufnahmen der DoorPi's zu hören

    Teil-2



    21. Installation von Werkzeugen und Paketen (dkms)
    Um das Laden und Unterstützung für dynamische Kernelmodule (v4l2loopback ist ein solches Modul) zu erhalten müssen wir dazu auf der Kommandozeile wiefolgt eingeben


    # apt-get install dkms


    22. Installation von Werkzeugen und Paketen (bc)


    Die Linux Kernel Header brauchen das Debianpacket "bc" welches wir mittels Kommandozeile installieren


    Kommandozeile


    # apt-get install bc


    23.Jetzt Linux Kernel Header und v4l2loopback DEB Pakete kopieren auf den Raspi nach /tmp


    Auf der Kommandozeile in das /tmp Verzeichnis wechseln


    # cd /tmp


    24. Als erstes die Linux Kernel Header installieren


    Kommandozeile


    # dpkg -i linux-headers-4.4.34-v7+_4.4.34-v7+-2_armhf.deb


    Die ganzen "make" Prozesse dauern etwas (ca. 10 Minuten)... deshalb Kaffee nachschütten und Pferde füttern gehen....


    25. Dann die v4l2loopback Schnittstelle installieren


    Kommandozeile


    # dpkg -i v4l2loopback-dkms_0.9.1-4_all.deb


    So sollte das danach aussehen....






    26. Test der Einbindung der v4l2loopback Schnittstelle


    Auf der Kommandozeile eingeben


    # ls /dev/video*


    Ist keine USB Kamera oder Raspi Kamera angeschlossen dann ist die Antwort:


    "ls: cannot access /dev/video*: No such file or directory"


    Wir haben also freie Bahn...


    Auf der Kommandozeile eingeben


    # modprobe -v v4l2loopback


    Die Anworte sollte so aussehen:


    insmod /lib/modules/4.4.34-v7+/kernel/drivers/media/media.ko
    insmod /lib/modules/4.4.34-v7+/kernel/drivers/media/v4l2-core/videodev.ko
    insmod /lib/modules/4.4.34-v7+/extra/v4l2loopback.ko


    Auf der Kommandozeile eingeben


    # ls /dev/video*


    Die Antwort sollte lauten:


    /dev/video0


    Damit lauert also die v4l2loopback Schnittstelle auf Eingabe.


    Wichtiger Hinweis:


    A: Die v4l2loopback Schnittstelle sollte wenn sie sauber funktioniert in den Startprozess vom Raspi eingebunden werden, wer das nicht will kann auch die v4l2loopback Schnittstelle immer noch dyamisch via Script starten.


    Um das ganze bei Systemstart zu erledigen einfach v4l2loopback in die Datei "/etc/modules" eingetragen.


    B: Ist bereits die Raspi-Cam oder eine andere USB Kamera angeschlossen wird das Kernelmodul die Ausgabe auf /dev/video1 oder /dev/video2 umleiten.


    Jetzt wird es spannend..... :)


    27. Externes RTSP Video mittels ffmpeg in die (V4L Loopback Schnittstelle umleiten).


    Via "# ls /dev/video*" haben wir herausgefunden das die V4L Loopback Schnittstelle ihre Ausgabe auf "/dev/video0" umleiten wird.


    Doch als erstes müsst ihr herausfinden, wie die die Video URL Eurer IP Cam angesprochen werden kann.


    In meinem Fall einer Digitus IP Cam geht das via:


    rtsp://oc1.oc2.oc3.oc4:Port/xkanal


    Um das zu testen, verwende ich unter Windows den VLC oder MS Media Player. (Ist einfach bequemer)


    Meine Kamera liefert 3 Kanäle (Main Stream, Medium Stream, Mobile Stream), ich verwende zum Test erstmal den "Medium Stream", auf der Kamera habe ich noch OSD und Zeitstempel aktiviert um bei Test sehen zu können of die Kamera neue Bilder liefert.


    Also dann.... starten wir mal ffmpeg mit folgenden Schaltern...


    Kommandozeile


    # ffmpeg -i "rtsp://192.xxx.xxx.xxx:xxx/xx" -vcodec rawvideo -y -f v4l2 /dev/video0


    Die Ausgabe sollte dann kontinuierlich Information liefern, welche anzeigt das der Stream ansteht.


    etwa so...


    "frame= 672 fps= 32 q=-0.0 size=N/A time=00:00:25.92 bitrate=N/A dup=33..... uvm.


    Das ganze ruhig mal 15 Minuten laufen lassen und sehen ob der Stream stabil bleibt und ffmpeg nicht abbricht.


    Hinweis: Stimmt was nicht erfolgt die Ausgabe von ffmpeg leicht zeitversetzt, also habt etwas Geduld.


    28. Test ob Video oder Bilddaten über die V4L Schnittstelle abgerufen werden können.


    Wir hatten ja das Werkzeug fswebcam installiert.


    Wir öffnen dazu ein zweites Konsolenfenster parallel zur ffmpeg Debugausgabe.


    Auf der Komandozeile wechseln wir in das Verzeichnis /tmp


    # cd /tmp


    dann erfolgt die Eingabe


    # fswebcam 1.jpg -d /dev/video0


    3 Sekunden warten und Snap und gleich noch eins.....


    # fswebcam 2.jpg -d /dev/video0


    3 Sekunden warten und Snap und gleich noch eins.....


    # fswebcam 3.jpg -d /dev/video0


    Im Verzeichnis /tmp müssten jetzt 3 Bilder liegen, diese bitte öffnen und nachsehen ob ffmpeg den RTSP Stream sauber Bildinformationen von eurer Kamera an die Loopback Schnittstelle übergibt, da die Bilder zeitversetzt aufgenommen wurden müsste im OSD Bereich jeweils ein anderer Zeitstempel zu sehen sein.


    Wer NIX sieht, hat was falsch gemacht, oder sollte die Kamera aus dem Kühl- oder Kleiderschrank rausholen.... :)


    Wer was auf den Bildern sieht hat es erstmal geschafft, somit ist die Ein- und Anbindung von einem externen Videostrom und einer externen Kamera über IP (RTSP) an die Loopback-Schnittstelle erfolgt.


    29. Hinweise...
    Hier wurde nicht beschrieben wie die V4L Loopback Schnittstelle und FFMPEG mit einen Videostrom nach einem Reboot wieder selbstständig eingebunden werden und starten, dies muss und kann jeder für sich selbst entscheiden und erledigen wie er seine Ressourcen beim Neustart einbinden will.


    30. Einen saufen gehen wenn es erstmal nicht klappt oder Doopi nach Vorgabe wie hier im Forum installieren, in die SIP Infrastruktur reinhängen, die Codecs sauber setzen usw.


    31. Doorpi anrufen und Live Video über externe IP Videoquelle geniessen.


    Megawichtiger Hinweis:


    Bitte fragt mich NICHT nach Schaltern innerhalb ffmpeg für Kamerhersteller XYZ oder Kameramodel ABC, auch pflege und verfüge ich NICHT über eine Sammlung von Kamera-API's, welche man mittels DMTF und HTTP Requests einbinden kann. Wer hierzu mehr wissen will und muss, wende sich bitte an seinen Händler oder Hersteller oder einem Hacker seines Vertrauens.


    Wer seine Überwachungskamera über WLAN reinhängt und sich über zu hohe Latenzzeiten und Verbindungsabbrüche wundert, sollte lieber ein Kabel verlegen und die Kamera über das lokale Netwerk betreiben, alternativ einfach die Kamera mit einer USB LAN Netzwerkkarte an den Raspi anschliessen.


    Ob ihr OSD über die Kamera oder ffmpeg einbindet ist Euch überlassen, ebenso ob ihr das Videomaterial muxen müsst oder nicht, auch hierzu kann ich aufgrund einer fehlenden Glaskugel, samt Talent und Bedienugsanleitung nix sagen. Danke!


    Aldafera aka Harald

    Teil-1


    Hallo Zusammen,


    diese Anleitung beschäftigt sich mit der Ein- und Anbindung von nicht lokalen Videoströmen z.B von externen IP Kameras in die
    V4L Schnittstelle (Video for Linux) mittels einer Looback Schnittstelle (v4l2loopback) und einem Streamingwerkzeug (ffmpeg).


    Das Beispiel zeigt die Integration eines RTSP Streams, es können über ffmpeg auch andere Videoquellen angebunden werden, dies wird hier jedoch
    nicht beschrieben und sollte ausserhalb des Forums in den FFMPEG Foren zu finden sein.


    Ziel: Ein- und Anbindung von nicht lokalen Videoströmen oder Kamerahardware über IP in eine lokale Standardschnittstelle welche von Doorpi verwendet werden kann.


    Na dann mal los....


    1. Download Raspbian Image (Jessie Lite) unter raspberrypi.org/downloads/raspbian/


    2. Installation auf einer SD-Karte wie auf der offiziellen Webseite beschrieben.


    3. Lokal mittels (Funk)Tastatur anmelden.


    4. RaspConfig (sudo #raspi-config) ausführen und folgende Einstellungen setzen (raspberrypi.org/documentation/configuration/raspi-config.md)
    1 Expand Filesystem
    3 Boot Options -> B1 Console
    4 Internationalisation Options -> I1 Change Locale -> de_DE.UTF-8 UTF-8 (und auch als default auf der nächsten Seite setzen)
    4 Internationalisation Options -> I2 Change Timezone -> Europe -> Berlin
    4 Internationalisation Options -> I3 Change Keyboard Layout -> Generic 105-key (Intl) PC -> Other -> German -> German -> Rest bleibt Default
    5 Enable Camera -> NO (Da ich die RaspiCam NICHT nutze)
    7 Einen sexy Namen für den Raspi ausdenken und eintragen.
    7 SSH Server aktivieren -> Would you like the SSH server to be enabled? -> Yes
    7(Da ich den PiFace benutze) Advanced Options -> A6 SPI -> Yes -> Ok -> Yes
    Finish -> Yes
    Reboot -> Yes



    5. Nach dem Reboot SSH Konfiguration nach belieben anpassen, (Ich erlaube zur Konfiguration die Anmeldung von Root temporär. (Bei fertigen Systemen melde ich mich via SSH Schlüssel, BitVise als Client, gesteuert über LSC ERPM an))


    6. Password für das Konto pi setzen #passwd -> altes Password -> Neues Password -> Neues Password


    7. Password für das Konto "root" setzen #sudo passwd root -> Neues Password -> Neues Password


    8. Abmelden des Anwenders "pi" von der Konsole #exit


    9. Anmelden an der Konsole mit dem Anwender "root"


    10. Wenn notwendig IP Einstellungen anpassen (ich verwende ausschliesslich feste IP Adressen) (nano /etc/network/interfaces)


    Wenn alles passt dann einfach nochmal durchstarten mittels #reboot


    11. Nach dem Reboot Verbindung mit BitVise (Putty oder WinScp geht auch) herstellen Konsole öffnen


    12. Wenn die Basiskonfiguration steht erstmal das Betriebssystem aktualisieren mittels


    # apt-get update && apt-get upgrade (Dauert ein wenig)


    13.Pause! - Eine rauchen gehen und Kaffe nachfüllen :) während der Raspi aktualisiert


    14.Wenn alles passt dann einfach nochmal durchstarten mittels #reboot, da oftmals nicht alle Pakete und Kernelanteile neu geladen wurden nach dem Upgrade.


    15. Nach dem Reboot Verbindung mit BitVise (Putty oder WinScp geht auch) herstellen Konsole öffnen


    16. Befehl eingeben


    # uname -a


    - Als Ausgabe sollte "Linux (netbiosname) 4.4.34-v7+ #930 ....Datum Uhzeit)" erfolgen.


    - Von Interesse ist hier die aktuell verwendete Kernel Version (in meinem Fall) 4.4.34-v7+, das kann von Fall zu Fall und in der
    Zukunft anders aussehen, ist aber wichtig weil wir die entsprechenden Linux Header ebenfalls als Version 4.4.34-v7+ jetzt bereitstellen
    müssen das sonst der DKMS Loader bei einbinden der V4L Loopback Schnittstelle die Einbindung verweigert.


    17. Linux Kernel Header Dateien herunterladen.


    Ihr findet die für den Raspberry aktuellen aber auch älteren Linux Header Packete u.a hier:


    Linux Header


    In meinem Fall brauche ich also die Datei "linux-headers-4.4.34-v7+_4.4.34-v7+-2_armhf.deb", welche ich erstmal extern vom Raspi in einem Ordner speichere.


    18. Packet "v4l2loopback-dkms" herunterladen (bitte nicht via apt-get, aptitude oder was auch immer)


    In keinem Fall die Standardversion 0.8.0 aus der aktuellen Debian Jessie Distrubution verwenden, bitte sucht im Web in den Debian Standard Libarys im minimum die Version "v4l2loopback-dkms_0.9.1-4_all.deb".


    Hinweis! Version "v4l2loopback-dkms_0.10.0-1_all.deb" ist Stand 04.12.2016 noch als unstabil eingestuft.


    Loopback Package


    In meinem Fall nehme ich also die Datei "v4l2loopback-dkms_0.9.1-4_all.deb", welche ich erstmal extern vom Raspi in einem Ordner speichere (Dort wo auch die Linux Header Packete liegen.


    Wer will kann auch der Vollständigkeit wegen den Source dazu herunterladen "v4l2loopback-source_0.9.1-4_all.deb"


    19. Installation von Werkzeugen und Paketen (fswebcam)


    Ich verwende das Paket "fswebcam" um die mittels V4L bereitgestellen Schnittstellen auf der Kommandozeile testen zu können.


    Die Installation erfolgt hier via:


    # apt-get install fswebcam


    20. Installation von Werkzeugen und Paketen (ffmpeg)


    Das Packet "FFMPEG" ist nicht in der aktuellen Jessie Distrubution enthalten, deswegen muss man hier aktuell auf die offiziellen Debain Jessie Backport Quellen zurückgreifen.


    Dazu in der Datei "/etc/apt/sources.list" den folgenden Eintrag


    "deb http://ftp.uk.debian.org/debian jessie-backports main"


    hinzufügen.


    Hinweis: Bitte verwendet nicht die Debian Multimedia Gesocks Quellen, die meisten Pakete sind dort leider nicht brauchbar.


    Die Datei "/etc/apt/sources.list" speichern dann auf der Kommandozeile


    # apt-get update


    eingeben.... dann


    # apt-get install ffmpeg


    (ca. 150 Megabyte Platz werden gebraucht, alle abhängigen Pakete werden mit installiert)


    Nach der Installation von ffmpeg auf der Kommandozeile


    # ffmpeg


    eingeben, die Antwort sollte ensprechend sein


    "ffmpeg version 3.2-2~bpo8+2 Copyright (c) 2000-2016 the FFmpeg developers....." und weiter Blah Blah sein.


    Puh! - Fast fertig.... :)


    Teil-1 Ende

    Hallo Zusammen,


    ich habe ein V4l2loopback Device mit ffmpeg einem RTSP Stream (Digitus Kamera) und Doorpi am laufen.


    Im Hintergrund läuft Asterisk 14.


    Ich kann meine Sprechstation im Stall anrufen und habe sofort einen Videostrom auf meinen AntiSip Clients (Android).


    v4l2loopback ist unter dem aktuellen Raspian (Stand 03.12.2016) nicht mit den Standardquellen installierbar, das musst Du leider manuell erledigen.


    Die aktuelle Raspbian Version (Jessie) bringt v4l2loopback 0.8.0 auf den Raspi die in keinem Fall funzt, auch musst Du beim installieren mittels DKMS
    die Linux Header synchron haben um den dynamischen Kernel erstellen zu können.


    Ist alles etwas "tricky" läuft aber stabil.


    Ich hab das mal für mich gebaut, weil ich Doorpi nicht nur als Türstation verwende, sondern auch als Sprechstation mit Überwachungsfunktion, wobei ich
    dabei zielgerecht Leute ansprechen will und sehen will was die Leute tun und ob meinen Anweisungen nachgekommen wird. Das wollte ich mit einem direktion Anruf und Videobild erledigen und nicht erst den Browser oder die Ü-Software starten und dann den Doorpi parallel anrufen.


    Auch war die Leistung der Raspi-IR Kamera nicht besonders bei grösseren Entfernungen.


    Mittels DMTF kann ich auch noch HTTP Requests schicken und die Kamera drehen (Wenn es sich um eine Motorkamera handelt, welche eine entsprechende API bereitstellt.


    Wenn Bedarf besteht kann ich die Quellen bereitstellen und eine kleine Anleitung einstellen, ob es dann bei Euch funzt - keine Garantie :)


    Schönen Abend noch


    Harald aka Aldafera

    Hallo Zusammen,


    klar so ein leuchtendes Frontpanel kann zum schon zum Spielen und Zocken einladen.... :)


    Scheinbar sehen ein paar Frontpanels wie Spielautomaten aus, ich hätte gerne eine Erweiterung im Doopi, Unterstützung eines
    Münzeinwurfzählers.... 1x Klingeln kostet 1 Euro..... aber Scherz beseite...


    Ich hoffe mit dem Doorpi, welcher ja klare Ansagen über den Lautsprecher ermöglicht die Sturm- oder Langzeitklingler in den Zaum zu bekommen,
    nach dem Anbringen von Schildern mit den Hoföffnungszeiten wurde es hier bereits deutlich besser.


    Wenn der Hund draussen ist, dann ist der Zaun ohnehin erstmal gesichert, denn wenn die Klingel geht, dann klebt der Hund am Eingangstor und schlägt an, da weichen viele ohnhin erstmal wartend zurück.


    Klingelt es ausserhalb der Öffnungszeiten des Hofes an der Liefereinfahrt oder Werkstatt, lasse ich in der Zukunft den Ruf ohnehin nicht mehr durch und es kommt eine entsprechende Ansage aus dem Lautsprecher.


    Anfänglich hatte ich hier 5 Klingelknöpfe, Mieter-1, Mieter-2, Eigene Wohnung, Werkstatt und Stall, die kann ich dank Doorpi erstmal auf 3 reduzieren, wie der Doorpi reagiert auf das reihenweise durchdrücken aller Klingeltasten (was viele Paketboten und Schrottsammler machen) muss ich mal testen.


    Da ich auch mal auf dem Feld bin und über Handy mit dem Besucher verbunden sein werde, sollte es nicht möglich sein ein bestehendes Gespräch durch
    erneutes drücken der Klingelknöpfe zu beenden.


    Ich denke eine Option wo man dies selbst festlegen kann, wäre OK.


    Wie sich der Doorpi verhält, wenn mir einer einen Kaugummi auf den Taster schmiert oder dieser festgefrohren oder verklemmt ist, muss ich auch noch testen.


    Schönen Tag noch.


    Aldafer aka Harald

    Hallo Zusammen,


    habe das gleiche Problem wenn ich Aktoren auf meiner Homematic CCU ansprechen will.


    Events für Ausgänge oder Relais am Doorpi schalten klappt hervorragend aber "10 =url_call:http://homeatic-url-gelumpse/...." klappt auch nicht bei mir.


    Im Log wird angezeigt das die URL aufgerufen wird, es wird auch der Rückgabewert (Erfolgsmeldung) von der CCU im Log angezeigt,
    aber dennoch wir der Aktor nicht geschaltet.


    Was aber sehr gut geht ist, die Aufrufe in ein Shellscript zu packen und diese mittels "os_execute" einzubinden.


    Ich verwende "curl" um den Http Request auszuführen.


    Beispiel Einbindung in die Doorpi.ini
    10 = os_execute:/usr/local/etc/DoorPi/doscript/myscript.sh


    Halt nur darauf achten das auch die entsprechenden Rechte vorhanden sind um das Shellscript aufrufen oder ausführen zu dürfen.


    Schönen Abend noch


    Aldafera aka Harald

    Hallo Zusammen,


    vielleicht als Hilfe für andere Teilnehmer beim Debuggen.....


    Ich baue gerade RasDoorpi mit Linphone mit Asterisk 14 und Video Call zusammen.


    Als Kamera verwende ich die Raspi IR Cam.


    Test-1: Rufe ich von einem Tablett oder Handy via SIP Call (AntiSip) den RasDoorpi an, bekomme ich Verbindung und sofort ein Video Bild.


    Test-2: Rufe ich vom RasDoorpi über Asterisk eine einzelne SIP Nummer an, klingelt das SIP Android Phone, allerdings muss ich das Video manuell starten.
    (Wer weiss wie ich Linphone dazu bringen kann den Videoanruf direkt mitzuteilen, bitte kurze Info an mich)


    Test-3. Rufe ich vom RasDoorpi über Asterisk mehrere einzelne SIP Nummern an, klingeln alle SIP Android Phones, allerdings ist dann kein Video möglich, auch nicht wenn an einem der SIP Android Phones das Video manuell gestartet wird.


    Innerhalb von Asterisk "extensions.conf" verwende ich dazu eine Rufgruppe mittels



    Code
    [general
    exten => exten => 3333,1,Dial(${CALLALL})
    exten => 3333,1,Dial(SIP/3006&SIP/3002)
    [globals]
    CALLALL => SIP/3006&SIP/3002




    Das schöne daran ist, es klingeln alle SIP Android Phones und Dect Geräte im Haus, Stall, Werkstatt, Reitstube und alle Handys.


    Wird von mir oder meiner Frau der Anruf vom RasDoorpi entgegengenommen, hören alle anderen auf zu klingeln.


    Vielleicht hat der eine oder andere hier schon mal versucht eine Rufgruppe für Video hinzubekommen und kann hier noch einen Hinweis geben.


    Schoenen Abend noch


    Aldhafera (aka Harald)

    Jo MasterKalle,


    ich hab Zoiper mit Asterisk 13 und 14 im Labor, selbst bei 2x gleicher Hardware (Nexus7) ist bei mir derzeit kein Video Call möglich.


    Hab den Leuten von Zoiper geschrieben, nachdem ich verzweifelt war, scheint noch ein Bug zu sein.


    Bin dann auf einen freien Client unter Android (Antisip) seit dem kann ich den RasDoorpi anrufen und habe einen Videostrom.


    Vom RasDoorpi raus geht's noch nicht mit Video, da muss ich noch debuggen.


    Aldhafera

    Hallo Zusammen,


    bin der Neue und soll hier vortanzen...


    Vorname: Harald
    Alter: 49
    Beruf: Sicherheitsberater und Auditor (Unterschiedliche Branchen)
    Hobbys: E-Technik, Hausautomatisierung, Pferde, Hunde, Falken, Adler, Bogenschiessen


    Habe 6 kleine Projekte in Planung welche ich mittels Raspi und Doorpi realisieren möchte.


    1. Hofeinfahrt
    2. Lieferanteneinfahrt
    3. Hauseingang
    4. Sprechstelle Stall
    5. Sprechstelle Werkstatt und Reitplatz
    6. Sprechstelle Balkon und Terrasse


    Ansonsten wenn ihr mehr wissen müsst einfach fragen.


    Schönen Abend noch


    Harald (aka Aldhafera)