Nene, der Watchdog muss nicht zu einem Neustart führen. Auf der zweiten Seite ist beschrieben, wie mit einem kleinen Skript beliebige Aktionen ausgelöst werden können, die zum Reparieren einer unerwünschten Situation führen. Reboot ist dabei nur die Ultima Ratio.
LG
pah
Neben solchen Dingen wie dem Manipulationsschalter scheint es mirwichtig, den Hausbewohner ggf. bei einem Absturz des System zu warnen,
dass seine Türklingel nicht funktioniert. Dafür lässt sich derHardware-Watchdog des Raspberry Pi sehr gut nutzen - siehe
Kurzanleitung auf dem beiliegenden Auszug.
LG
pah
Na, dann darf ich euch mal über den Stand der Forschung aufklären:
Nahezu jede Software zur Gesichtserkennung kann man problemlos austricksen, indem man sich ein Foto des Betreffenden vorbindet. Das ist der unsicherste Weg, eine biometrische Zugangskontrolle zu realisieren. Fingerabdruckscanner lassen sich genauso gut überlisten, Stimmenerkennung ist nicht zuverlässig.
Stand der Technik ist eine zweikomponentige Authentifizierung - aber nicht über zwei biometrische Systeme, sondern über die Kombination aus Besitz und Wissen. Also z.B. RFID-Tag oder iButton, und Passwort oder PIN.
Ach ja, noch ein Nachtrag: Die beste TTS-Engine ist TTS Ivona - z.B. die Stimme "Marlene". In der Web-Version kann man sich damit problemlos beliebige feste Texte sprechen lassen und diese als MP3-Dateien aufnehmen. Derzeit ist Ivona für Android noch kostenfrei zu installieren, läuft auf allen meinen wandbefestigten Tablets als Sprachausgabe.
LG
pah
Das ist übrigens ein Trugschluss. Formatierung einer SD-Karte löscht keineswegs die enthaltenen Informationen.
LG
pah
Erst einmal ziehe ich iButtons den RFID-Tags vor - die iButtons kann man eben nicht im Vorbeigehen auslesen, die öffnen bei mir schon Hoftür und Garagentor.
Der Haupangriffspunkt für Sabotage ist immer die Frontplatte - die sollte also aus Metall sein. Bei der Schaeffer AG kann man sich diese in beliebiger Komplexität selbst designen und online bestellen - inklusive Bolzen für die verdeckte Befestigung.
Wichtiger als ein Sabotagekontakt erscheint mir die Kopplung an den internen Watchdog des Raspberry Pi - und eine regelmäßige Überprüfung in der Hauszentrale, ob DoorPi erreichbar ist.
LG
pah
Sehr gute maßgefertigte Blenden gibt es bei der Schaeffer AG.
LG
pah
Liebe Experten,
jetzt benötige ich bitte etwas Informationen:
- Müssen alle Inputpins eines keyboards real existieren, oder kann ich auch virtuelle Inputpins definieren ?
- Welche Events kann ich von außen auslösen - die entsprechende Sektion der Doku enthält ein "Kommt noch" ?
- Muss eine Event-Sektion einen Pin verwenden, der vorher definiert wurde, also z.B.
[onboardpins_InputPins]
35 = [JA WAS MUSS HIER STEHEN ?]
[EVENT_OnKeyPressed_onboardpins.35]
10 = os_execute:/root/test.sh
- Obwohl das in der Doku nicht enthalten ist: Gibt es eine Aktion, mit der man einen HTTP-Request mit beliebigen Parametern an eine externe Adresse abschicken kann ?
LG
pah
Ich vermute: Vergessen, mit raspi-config das Dateisystem so zu expandieren, dass es die Karte auch ausnutzt.
LG
pah
Oh, ich unterstütze Firmen sehr gerne. Aber prinzipiell nicht ohne Honorar.
LG
pah
Es scheint als ob noch ein Paar im FHEM Forum Interesse an einem Modul für FHEM hätten
Sieht so aus, ja ...
LG
pah
"IP-Adresse des Raspberry Pi, statt sich diese von der eigenen Kiste zu nehmen"
Offenbar macht doorpi mit der eigenen identity aus der doorpi.ini eine DNS-Anfrage bei der FritzBox - hat darum vom SIP-Server die *51 als angemeldete IP zurückerhalten. Das war jedenfalls den traces zu entnehmen: Authentifizierung erhalten für die *51, obwohl der Authentifizierungsrequest von der *195 ausging.
Man könnte sich dagegen absichern, indem die zurückgelieferte IP mit der des Senders verglichen wird.
Nea: Das ist normalerweise bei mir im Netz immer so - die FritzBox ist diesbezüglich etwas kritisch.
LG
pah
So, eine Woche später - Problem gelöst.
Offenbar holt sich linphone - oder doorpi - von der FritzBox die IP-Adresse des Raspberry Pi, statt sich diese von der eigenen Kiste zu nehmen.
Auf der FritzBox wiederum kann es passieren, dass der interne DNS-Eintrag noch auf eine alte (dynamisch vergebene) IP-Adresse verweist.
Führte dazu, dass dieser Raspberry - inzwischen mit statischer IP *.*.*.195 - eine SIP-Registrierung als *.*.*.51 bekam. TCP-Pakete werden offenbar in der FritzBox automatisch umgeleitet, aber UDP aus irgendeinem Grund nicht. Mit anderen Worten: Die von *.*.*.195 kommenden UDP-Pakete wurden vom IP-Phone-Client der FritzBox nicht akzeptiert, denn der wartete ja auf solche von *.*.*.51.
Soll ich jetzt der Firma AVM mal drei halbe Arbeitstage von mir in Rechnung stellen ?
LG
pah
OK, danke für die Tipps, weitere Tests müssen aber bis Mittwoch warten, weil ich morgen Einreichungsdeadline für zwei EU-Projektanträge habe. Der Feierabend ist gestrichen...
LG
pah
Ich habe gestern abend angefangen, auf dem gleichen Raspberry Pi einen Asterisk aufzusetzen - war dann aber zu müde, das bis zum Ende durchzuziehen.
Bisher meldet sich der Asterisk nur an der FritzBox an, und zwar mit denselben Daten, wie vorher das DoorPi
Das Interessante ist die folgende Fehlermeldung.
Apr 10 04:41:52] ERROR[8943]: chan_sip.c:4195 __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data
So wie es aussieht, stimmt etwas mit der Kommunikation nicht. Lassen wir mal Asterisk für den Moment aus dem Spiel - denn die Wahrscheinlichkeit ist sehr hoch, dass dasselbe Problem auch bei der Kommunikation zwischen DoorPi und fritzBox auftritt
SIP wird benutzt, um die Verbindung auszuhandeln. Die eigentlichen Audiopakete kommen danach über UDP-Ports. Offenbar ist die auftretende "Halbverbindung" (UDP-Pakete FritzBox -> DoorPi kommen an, UDP-Pakete DoorPi->FritzBox kommen nicht an) durch falsch ausgehandelte oder blockierte Ports zu erklären - und hinter einer FritzBox durchaus bekannt.
Zu dieser Interpretation passt es auch, dass bei vielen Nutzern von DoorPi das einfach Out-of-the-Box funktioniert, bei anderen mit komplizierten FritzBox-Setups aber nicht. Oder mal nicht und mal doch.
Ich werde heute deshalb ein wenig mit der FritzBox herumspielen. In die Runde aber vorerst die Frage: Kennt jemand eine einfache Möglichkeit, bei der Kombination linphone/DoorPi die im SIP ausgehandeltenUDP-Ports anzuzeigen ?
LG
pah
motom001_new: Danke, aber das wars auch nicht
Habe gerade PolicyUseNatAddress, PolicyUseUpnp und PolicyUseIce ausprobiert - kein Effekt.
Hätte mich auch gewundert, denn durch die FW gehe ich ja gar nicht.
LG
pah
Lustig.
1. Nagelneues Jessie, Komplettversion
Befehle _genau_ wie oben
Compiler bricht ab, weil er yaml.h nicht findet, automatisch startet ein neuer compile-Versuch mit dem Parameter --without-yaml.
Installation beendet
2. Konfigurationsdatei editiert (so wie oben gepostet, aber nur die Einträge geändert, die in der default-configdatei auch vorhanden sind)
Mit alsamixer die Settings der USB-Soundkarte angepasst, mit alsactl gesichert. Audiokarte gecheckt, OK mit aplay und arecord
3. doorpi startet, perfekt. LED blinkt. Tastendruck => ruft via Fritzbox eines der internen Telefone an, perfekt. Ich spreche ins Telefon und höre mich am Raspberry. Ich spreche am Raspberry => NIX.am Telefon.
Das Einzige, was ich bisher noch nicht geändert habe, ist die FritzBox 7390...
LG
pah
Ach ja: Installiert man das Paket python-yaml, wird pip komplett zerstört - beispielsweise ergibt danach ein
sudo pip install linphone4raspberry python-daemon
File "/usr/local/bin/pip", line 9, in <module>
load_entry_point('pip==1.5.6', 'console_scripts', 'pip')()
File "build/bdist.linux-armv7l/egg/pkg_resources/__init__.py", line 542, in load_entry_point
File "build/bdist.linux-armv7l/egg/pkg_resources/__init__.py", line 2542, in load_entry_point
File "build/bdist.linux-armv7l/egg/pkg_resources/__init__.py", line 2202, in load
File "build/bdist.linux-armv7l/egg/pkg_resources/__init__.py", line 2208, in resolve
File "/usr/lib/python2.7/dist-packages/pip/__init__.py", line 74, in <module>
from pip.vcs import git, mercurial, subversion, bazaar # noqa
File "/usr/lib/python2.7/dist-packages/pip/vcs/mercurial.py", line 9, in <module>
from pip.download import path_to_url
File "/usr/lib/python2.7/dist-packages/pip/download.py", line 25, in <module>
from requests.compat import IncompleteRead
ImportError: cannot import name IncompleteRead
Ich bin kein großer Freund von kompletten Neuinstallationen, aber in den sauren Apfel muss ich wohl beißen. Werde heute also mit einem frischen Jessie beginnen.
Hmm. Bei mir sitzt das on top einer Jessie-Minimalversion...
Werde also mal mit einem kompletten Jessie versuchen.
LG
pah
Ne ne, nix extrem leise. Habe das heute auch noch mal mit einem meiner digitalen Konferenzmikros aus meinem Labor getestet - es geht echt gar nix raus.
Dass man den Mikrofonsound in den Lautsprechern des DoorPi hört, hat mit der Mic replay-Einstellung von ALSA zu tun.
Der obige Screenshot zeigt, dass DoorPi etwas aufnimmt - aber wo geht das hin ? Jedenfalls nicht an die FritzBox, die Fehlermeldungen suggerieren, dass die Pakete eben nicht herausgeschickt werden.
LG
pah
OK, here we go.
doorpi.ini liegt bei,
Screenshot ebenso - und zwar während eines lauten Pfeifens meinerseits ins Mikro aufgenommen. Und ja: der Pegel variiert deutlich je nach Lautstärke des Gesprochenen (oder Gepfiffenen) zwischen -16 dBm und ca. 3 dBm.
doorpi.ini.txt
Aufgenommen werden die Daten wohl. Aber eben nicht weitergeleitet - nur in umgekehrter Richtung.
LG
pah
Sende ich gerne, wird aber heute nachmittag, weil ich heute früh ziemlich viel um die Ohren habe. Danke für die Unterstützung.
LG
pah
P.S.: Betreffend Dresden: Nein - kenne ich nur als schöne Stadt aus gelegentlichen Besuchen. Da ich in gewissen Bereichen viel herumkomme, kann es trotzdem sein, dass wir uns mal über den Weg gelaufen sind -> Stichwort pahenning learntec.
