Beiträge von AndyGR42

    Hi.


    Also, das Teil fühlt sich echt gut an. Allein die 4 unterschiedlichen Montagearten inkl. Rosettenverschraubung sind super. Das Teil hält auch bombenfest am Zylinder, so lange er mind. 6-7mm raus guckt. Da merkt man schon, dass der Hersteller Erfahrung mit Schließtechnik hat und nicht aus dem Elektronik Bereich kommt. Leider war der Einzelhandelspreis so dermaßen unverschämt, dass ich das Teil nun doch bei ELV bestellen werden. Aber wahrscheinlich erst Anfang August. Vorher schaffe ich das nicht und ich will erst Mal die 1. Ausbaustufe fertig stellen.

    Moin.


    Ich habe gerade per Zufall gesehen, dass Abus nun auch einen Antrieb baut: http://www.elv.de/abus-funk-tu…b-hometec-pro-silber.html


    Der ist etwas günstiger als Keymatic und macht, von dem was man in der Anleitung lesen kann) einen etwas besser durchdachten Eindruck bei Montage und Bedienung. Hier stellt sich nur die Frage, wie man den ansteuert. Ich denke, am einfachsten wäre es einen Handsender umzubauen. Ich versuche das Teil mal im Fachhandel in die Finger zu bekommen.

    Moin


    Ob Du ein PiFace nutzen kannst oder nicht hängt davon ab, WIE Du die Türe öffnest. Für einen normalen Türöffner brauchst Du im Prinzip nur einen Relaiskontakt. Das geht mit PiFace oder im Eigenbau. Für alle Arten von Motorschlössern wird etwas mehr Aufwand nötig sein. Z.B. Keymatic, wenn man das nicht komplett in die Türe einbauen kann / möchte. Da hilft PiFace nicht weiter.

    Moin.
    Ich bin immer noch der Meinung, dies als Event in DoorPi zu integrieren. Mir fehlen das insgesamt zwei:


    • Event zu einer beliebigen Uhrzeit (oder gibt es das schon?)
    • Event "Dämmerung"

    Beides wäre IMHO sinnvoll um Aufgaben rund um einen Eingangsbereich zu erledigen. Z.B. Licht, verriegeln von Türen, etc. Ich würde mich damit ja befassen, habe derzeit nur absolut keine Zeit und vor allem kein ausreichendes Python Know how um das in einem solchen Projekt einzubauen.

    Könnte es ansonsten sein, dass der Gmail Server seine lokale Zeit hinzufügt, da er kein Date findet?

    Das ist durchaus möglich, wenn date fehlt oder in einem falschen Format ist. Ein Fehlen könnte auch der Grund für das Problem von Nokia001 sein. Wenn man die RFC streng auslegt wäre das Fehlen eines verbindlichen Headers ein Grund die Mail abzuweisen. Die meisten Server werden aber vermutlich das Datum selbst ergänzen.

    Da stehen leider auch nur die SIP Pakete drin. Die FB sendet auch keinen Grund für das BYE. Ich vermute aber, dass es am fehlenden RTP liegt. Oder weil sie nach dem Senden von DTMF immer auflegt. Das habe ich aber noch nicht getestet.


    Schreibt die VTO auch irgendwelche Protokolle? Ansonsten könnte man noch schauen ob die VTO tatsächlich kein RTP sendet oder ob die Pakete nur nicht ankommen. Dazu müsste man aber den Ethernet Port spiegeln, was einen passenden Switch voraussetzt. Oder einen uralten Ethernet Hub :)


    Mir ist allerdings noch einigermaßen schleierhaft, wie Du das mit DoorPi verbinden willst. Im Grunde ersetzt die Sprechstelle DoorPi vollständig.

    Moin.


    Du kannst Dir in Wireshark unter "Telephony" -> Voip Calls den Flow anzeigen lassen.


    Im 1. Call kommt die Verbindung zustande und wird von der FB (.254) beendet. Allerdings kommt nur RTP von der FB in Richtung VTO zustande. Die FB beantwortet den INVITE soweit korrekt und sendet early media / RTP. Nur beginnt VTO nicht damit, RTP zu senden. Wenn die FB einige Sekunden kein RTP empfängt legt sie anscheinend auf. Das ist völlig korrekt so. Die FB sendet auch DTMF (123) als INFO Pakete, die korrekt mit OK beantwortet werden. Allerdings so schnell (200ms Abstand), dass ich mir kaum vorstellen kann, dass Du sie per Hand gewählt hast. Warum macht die das? Unabhängig davon müsste die VTO aber RTP senden.



    Der Anruf von der FB zu VTO funktioniert ja einwandfrei.
    Ob VTO nicht sendet, oder die Pakete nicht ankommen, dass kann ich von hier nicht sagen. Wie ist der Trace zustande gekommen? Port Mirroring? Wenn ja, FB oder VTO? VTO wäre in diesem Fall hilfreich, um zu sehen ob die RTP Pakete gesendet werden und nur einfach nicht ankommen.

    @Marcus: Danke. Allerdings ist das, wie es scheint, eine schon weitergeleitete Mail. Im Prinzip müsste man die aus dem Postausgang des Postfachs haben, mit dem DoorPi sich zum senden verbindet.


    @pah: Völlig richtig. Aber eben mit Abweichung zu UTC. time.asctime() gibt diese im String nicht mit zurück. In diversen Python Scripts wird strftime("%a, %d %b %Y %H:%M:%S +0000", gmtime()) verwendet.

    Äh, mal langsam. Nur weil EIN Mail Relay Probleme mit einem Header hat bedeutet das noch lange nicht, dass der Fehler in DoorPi liegt. Der Versand funktioniert bei vielen einwandfrei.


    time.asctime() gibt die localtime ohne Angabe der Zeitzone zurück. Die RFC5322 oder RFC2822 sehen die Angabe der Abweichung zu UTC vor. Damit wäre die Mail mit der Date Angabe aus time.asctime() nicht mehr RFC konform. Konform wäre: strftime("%a, %d %b %Y %H:%M:%S +0000", gmtime())


    Ich habe keinen Mailversand konfiguriert. Kann bitte mal jemand, bei dem das funktioniert, die Mail Header hier posten?

    Asterisk ist eine komplette SIP TK Anlage. :) Die müsstest Du zusätzlich haben. Einige hier haben sich damit schon beschäftigt.


    Wenn die App den Videostrom selbst anzeigen würde, dann wäre es quasi egal ob der Anruf über die FP oder vom linphone direkt kommt. Bei der FB wäre es egal, sobald die "Klingel" angerufen wird und eine Bild URL hinterlegt ist, wird das Bild auch angezeigt. Es könnte natürlich noch sein, dass die App auch die Calling Party prüft. Da der Call von der Rufgruppe nun von der Fb und nicht mehr von Linphone kommt, könnte das ein Grund sein warum der Stream nicht angezeigt wird. Das müsste in der App Konfiguration zu erkennen sein.


    Linphone kann auch Video senden. Das ist dann ein zweiter RTP Kanal, vergleichbar mit Audio. Die FB kann damit nix anfangen und der Kanal wird einfach nicht aufgebaut. Wenn die App das kann, würde sie Video anzeigen. Die FB wird aber mit ziemlicher Sicherheit diese Informationen beim Gruppenruf nicht mit senden.


    Christian: Das solltest Du auf jeden Fall vorher noch mal prüfen. Asterisk ist keine wirklich einfache Geschichte :)

    Hm. Ich fürchte, das wird nicht ohne einen SIP Proxy (Asterisk oder ähnliches) funktionieren. Linphone kann kein dual forking, also gleichzeitig mehr als einen Call signalisieren. Wenn bereits einer besteht, kann ein weitere Teilnehmer angerufen werden um eine Konferenz aufzubauen. Aber das führt hier nicht zum Ziel.


    Da die FB Rufgruppe anscheinend kein Video signalisieren kann (hier geht es nur um die Signalisierung, der RTP Strom würde P2P gehen) ist das auch keine Option.

    Wenn ich das richtig sehe, werden nur die 1 und 2 gesendet:


    2016-06-15 21:35:42,453 [INFO] [doorpi.sipphone.from_linphone] channel [0x12c40a0]: received [550] new bytes from [UDP://192.168.178.1:5060]:


    INFO sip:620@192.168.178.64 SIP/2.0
    Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bKC76AA1FC7F37A149
    From: <sip:610@192.168.178.1>;tag=23F3D13051C203B6
    To: "DoorPi" <sip:620@192.168.178.1>;tag=zwz~nUybi
    Call-ID: mJ1vUx2G0I
    CSeq: 22 INFO
    Contact: <sip:15A676A928633C703817F1AF171FD@192.168.178.1>
    Max-Forwards: 70
    User-Agent: AVM FRITZ!Box Fon WLAN 7390 (UI) 84.06.51 (Apr 11 2016)
    Supported: 100rel,replaces,timer
    Allow-Events: telephone-event,refer
    Content-Type: application/dtmf-relay
    Content-Length: 24
    Signal=1
    Duration=100



    2016-06-15 21:35:43,399 [INFO] [doorpi.sipphone.from_linphone] channel [0x12c40a0]: received [550] new bytes from [UDP://192.168.178.1:5060]:


    INFO sip:620@192.168.178.64 SIP/2.0
    Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bK8023E8B8BC605901
    From: <sip:610@192.168.178.1>;tag=23F3D13051C203B6
    To: "DoorPi" <sip:620@192.168.178.1>;tag=zwz~nUybi
    Call-ID: mJ1vUx2G0I
    CSeq: 23 INFO
    Contact: <sip:15A676A928633C703817F1AF171FD@192.168.178.1>
    Max-Forwards: 70
    User-Agent: AVM FRITZ!Box Fon WLAN 7390 (UI) 84.06.51 (Apr 11 2016)
    Supported: 100rel,replaces,timer
    Allow-Events: telephone-event,refer
    Content-Type: application/dtmf-relay
    Content-Length: 24
    Signal=2
    Duration=100



    Danach legt die FB auf:


    2016-06-15 21:35:45,817 [INFO] [doorpi.sipphone.from_linphone] channel [0x12c40a0]: received [699] new bytes from [UDP://192.168.178.1:5060]:


    BYE sip:620@192.168.178.64 SIP/2.0
    Via: SIP/2.0/UDP 192.168.178.1:5060;branch=z9hG4bKDB50CD55F8E43998
    From: <sip:610@192.168.178.1>;tag=23F3D13051C203B6
    To: "DoorPi" <sip:620@192.168.178.1>;tag=zwz~nUybi
    Call-ID: mJ1vUx2G0I
    CSeq: 24 BYE
    X-RTP-Stat: CS=0;PS=333;ES=398;OS=53280;SP=0/0;SO=0;QS=-;PR=387;ER=398;OR=61920;CR=0;SR=0;QR=-;PL=0,0;BL=0;LS=0;RB=0/0;SB=-/-;EN=PCMU;DE=PCMU;JI=227,7;DL=9,9,10;IP=192.168.178.1:7078,192.168.178.64:7078
    X-RTP-Stat-Add: DQ=23;DSS=0;DS=0;PLCS=96;JS=99
    Reason: Q.850; cause=16
    Max-Forwards: 70
    User-Agent: AVM FRITZ!Box Fon WLAN 7390 (UI) 84.06.51 (Apr 11 2016)
    Supported: 100rel,replaces,timer
    Allow-Events: telephone-event,refer
    Content-Length: 0

    Der Stecker ist nicht "original", das steht mal fest :) Mich würde es wundern, wenn das kein 1+n ist. So alt sieht das HT noch gar nicht aus. Eventuell hat man mal eine alte Anlage ersetzt und einfach den Stecker an das neue HT gebaut.


    Das ist vermutlich ein Mehrfamilienhaus? bei einem 1+n Bus wäre das Anschalten an den Taster im Telefon tatsächlich die einfachste Lösung. Es sei denn, Du kommst an das Modul in der Verteilung. Sollte das tatsächlich noch eine alte Verdrahtung sein kann man den Türöffner an der Dose anschließen. Die sicherste Methode das herauszufinden wäre das Modul in der Verteilung zu identifizieren. Vielleicht reicht ja schon das HT. Steht auf der Unterseite des Telefon eine Modell Nummer?