Hallo muellerjm,
LCD für draußen? Text? Farbe? SPI, I2C, UART oder HDMI? Mit/ohne Touch?
Da wäre das Stichwort Nextion vielleicht keine schlechte Wahl. Sollte bei den Projekten hier im Forum auch beschrieben sein.
Den Nachteil habe ich darin gesehen, dass man die Bilder mit der SW von denen aufspielen muss. Es geht dann wohl nicht mehr im eingebauten Zustand, wenn das Display mit dem Raspberry verbunden ist..
Oder weiß da jemand mehr?
Sagen wir so: Er macht alles in Python, ich nur wenn sein muss.. 
Ich werde ihn auf jeden Fall morgen mal fragen, und ich versuche auch dabei zu sein..
Viele Grüße
Max
Da schaue ich ja nichts ahnend im richtigen Moment hier vorbei - und nur weil ich einen Merge pull auf github von Thomas in meinem Mails gesehen habe.
Ich versuche gerne bei der Organsation zu helfen und auch bei der Entwicklung.
Python ist aber definitiv nicht meine Kernkompetenz, aber vielleicht kann ich ja noch meinen Sohn gewinnen.. 
Auf jeden Fall super, dass ihr das Projekt wieder zum Leben erwecken wollt!
Großartig! Ich freue mich sehr!
Viele Grüße
Max
Klasse Idee! Meine Wünsche sind:
- Python3
- MQTT und/ oder Anbindung an Home Assistant
- Unterstützung für RockPi4
Hi steph,
also ich muss zwar mit dem RFID-Chip (Schlüsselanhänger bei mir) das Display nahezu berühren aber die Erkennung klappt dann zuverlässig.
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
Sorry vertippt! Danke Wal!
Und kommst du jetzt weiter Arno?
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:
[ 5.255542] Linux video capture interface: v2.00
[ 5.388863] bcm2835-v4l2: V4L2 device registered as video0 - stills mode > 1280x720
[ 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,
hast du schon versucht es per:
apt-get install imagemagick
zu installieren? Kann mich nicht daran erinnern damit Probleme gehabt zu haben...
Super, das freut mich Arno!
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:
2018-04-01 11:13:42,067 [INFO] [doorpi.sipphone.from_linphone] Trying to connect to [UDP://192.168.188.1:5060]
2018-04-01 11:13:42,068 [INFO] [doorpi.sipphone.from_linphone] belle_sip_get_src_addr_for(): af_inet6=0
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:
2018-03-18 22:35:26,997 [INFO] [doorpi.sipphone.from_linphone] Trying to connect to [UDP://192.168.178.1:5060]
2018-03-18 22:35:27,000 [INFO] [doorpi.sipphone.from_linphone] belle_sip_get_src_addr_for(): af_inet6=0
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:
/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