Beiträge von pula

Hallo,

bin noch immer im Test-Stadium. Während der Testerei für das pn532-keyboard ist mir aufgefallen, daß ich IRRSINNIGE Verzögerung zwischen Sprechen ins Handy (FritzFon-App) und Ausgabe auf dem Lautsprecher von meinem Doorpi (hängt per Kabel im Netzwerk) habe. Ich rede von etwa ZEHN Sekunden

Kennt jemand das Phänomen? Bin mir nicht ganz sicher, ob Logfiles hier helfen würden. Betreibe doorpi auf einem Raspi 1 mit einer noname-USB-Soundkarte unter jessie.
Habe im Log viele Einträge dieser Art:

2016-04-26 20:09:54,756 [WARNING]       [doorpi.sipphone.from_linphone] Too many samples to drop, dropping entire frame.
2016-04-26 20:09:54,806 [WARNING]       [doorpi.sipphone.from_linphone] Too many samples to drop, dropping entire frame.
2016-04-26 20:09:54,820 [WARNING]       [doorpi.sipphone.from_linphone] Too many samples to drop, dropping entire frame.
2016-04-26 20:09:54,859 [WARNING]       [doorpi.sipphone.from_linphone] Too many samples to drop, dropping entire frame.
2016-04-26 20:09:54,871 [INFO]          [doorpi.sipphone.from_linphone] Thread processing load: audio=51,723000 video=0,000000
2016-04-26 20:09:54,892 [WARNING]       [doorpi.sipphone.from_linphone] Too many samples to drop, dropping entire frame.
2016-04-26 20:09:54,933 [WARNING]       [doorpi.sipphone.from_linphone] Too many samples to drop, dropping entire frame.
2016-04-26 20:09:54,943 [WARNING]       [doorpi.sipphone.from_linphone] Too many samples to drop, dropping entire frame.
2016-04-26 20:09:54,980 [WARNING]       [doorpi.sipphone.from_linphone] Too many samples to drop, dropping entire frame.
2016-04-26 20:09:55,006 [DEBUG]         [doorpi.sipphone.from_linphone]         [PYLINPHONE] >>> pylinphone_Call_get_state(0xb6c77540 [0xb500b8a0])
2016-04-26 20:09:55,038 [DEBUG]         [doorpi.sipphone.from_linphone]         [PYLINPHONE] <<< pylinphone_Call_get_state -> 0xced868
2016-04-26 20:09:55,053 [DEBUG]         [doorpi.sipphone.from_linphone]         [PYLINPHONE] >>> pylinphone_Core_get_in_call_timeout(0xb3c89d58 [0xeb59b8])
2016-04-26 20:09:55,071 [DEBUG]         [doorpi.sipphone.from_linphone]         [PYLINPHONE] <<< pylinphone_Core_get_in_call_timeout -> 0xcedad4
2016-04-26 20:09:55,142 [DEBUG]         [doorpi.sipphone.from_linphone]                 [PYLINPHONE] >>> pylinphone_Core_callback_call_stats_updated(0xeb59b8, 0xb500b8a0, 0xb500bd60)
2016-04-26 20:09:55,151 [DEBUG]         [doorpi.sipphone.from_linphone]                 [PYLINPHONE] <<< pylinphone_Core_callback_call_stats_updated
2016-04-26 20:09:55,180 [WARNING]       [doorpi.sipphone.from_linphone] Too many samples to drop, dropping entire frame.
2016-04-26 20:09:55,198 [WARNING]       [doorpi.sipphone.from_linphone] Too many samples to drop, dropping entire frame.
2016-04-26 20:09:55,209 [WARNING]       [doorpi.sipphone.from_linphone] Too many samples to drop, dropping entire frame.
2016-04-26 20:09:55,235 [WARNING]       [doorpi.sipphone.from_linphone] Too many samples to drop, dropping entire frame.
2016-04-26 20:09:55,247 [WARNING]       [doorpi.sipphone.from_linphone] Too many samples to drop, dropping entire frame.
2016-04-26 20:09:55,260 [WARNING]       [doorpi.sipphone.from_linphone] Too many samples to drop, dropping entire frame.
2016-04-26 20:09:55,286 [WARNING]       [doorpi.sipphone.from_linphone] Too many samples to drop, dropping entire frame.

Meine ini sieht für linphone so aus:

[SIP-Phone]
firewallpolicy = PolicyNoFirewall
audio_codecs = PCMA,PCMU, Speex
echo_cancellation_enabled = TRUE
call_timeout = 15
capture_device = ALSA: USB PnP Sound Device
playback_device = ALSA: USB PnP Sound Device
dialtone = !BASEPATH!/media/ShortDialTone.wav
dialtone_renew_every_start = False
dialtone_volume = 35
echo_cancellation_enabled = True
identity = DoorPi
local_port = 5060
max_call_time = 120
record_while_dialing = False
records = !BASEPATH!/records/%Y-%m-%d_%H-%M-%S.wav
sipphonetyp = linphone
sipserver_password = xxxxxxxx
sipserver_realm = fritz.box
sipserver_server = 192.168.1.1
sipserver_username = 620
stun_server =

Kennt jemand dieses Problem oder kann mir sagen, was ich falsch gemacht habe bitte? Falls mehr Infos benötigt werden, gerne, bin mir momentan nur nicht schlüssig, welche das sein könnten?

sorry, da war ich ein wenig ZU eifrig, ich hatte nicht erkannt, daß der log-auszug von pah NICHT zu einem crash führt, sondern _nur_ ein error ist. mea culpa.

und da gebe ich pah wegen DAU schon recht - nur ist doorpi m. E. momentan eh noch nicht DAU-sicher

Zitat von pahenning

return self.return_fallback_content(self.server.online_fallback, path)
AttributeError: DoorPiWebRequestHandler instance has no attribute 'return_fallback_content'
2016-04-26 09:48:00,088 [ERROR] [doorpi.status.webserver_lib.request_handler_static_functions] [192.168.0.20] (500, "DoorPiWebRequestHandler instance has no attribute 'return_fallback_content'")

den ersten fehler sollte die angehängte version fixen (ungetestet) - dann würde kein ERROR mehr kommen...
default-wert macht hier aber m. E. nach keinen Sinn...

Zitat von no_Legend

Meine rolladensteurung ist ein wenig komplizierter. Aber von Prinzip her würde das reichen.
Man könnte auch einfach mit zwei notify arbeiten.

Bin heute nicht dazu gekommen, mir ist mal wieder mein raspi dhcp und bind abgeraucht. Man sollte halt einfach nicht so viel an wichtigen System rumspielen. Ach und oft genug ein Backup ziehen!!!!

Ja, das habe ich auch ziemlich leidvoll feststellen müssen. Einmal unbedacht einen Befehl abgesetzt, dann war die Arbeit an fhem von 3 Monaten futsch. Seitdem läuft ein cronjob, der täglich die fhem.cfg wegsichert....

Ich hab so was (zum Beispiel) für die Rolladensteuerung mit sunset und sunrise am laufen.

define at_Rolladen_auf at *{sunrise(-60)} { \
     fhem 'set ez_rolladen_links off';;\
     fhem 'set ez_rolladen_rechts off';;\
     fhem 'set wz_rolladen_links off';;\
     fhem 'set wz_rolladen_rechts off';;\
     fhem 'set wz_rolladen_balkon off';;\
}
attr at_Rolladen_auf room Rolladen

Ist nicht aufwändig, nicht so genau, aber für meine Ansprüche bei den Rolladen passt das....
Twilight läuft bei mir auch, ist aber um einiges aufwändiger

Stimmt, bei den meisten war der zu. Aber einige hatte ich, wo die offen waren (hat mich damals manchmal geärgert gg)

so, grundsätzlich bekomme ich mal von dem Teil per python die IDs ausgelesen (hab halt nur zwei Tags zum testen).
als nächstes kommt, das in ein doorpi-keyboard zu gießen, aber ich bin heute schon ziemlich ausgelaugt.
folgt die tage.
Bei dem teil ist um einiges mehr für den User zu installieren als zum Beispiel beim RDM6300 (wegen nfc-Unterstützung). Dafür kann es (theoretisch) auch WESENTLICH mehr (und der Chip von meiner Arbeit, den ich immer an der Gürtelschlaufe habe, wird auch erkannt). Mein Plan ist, zuerst mal die "einfachen" tags zu implementieren und dann weiter zu forschen, was Identifizierung per Handy betrifft....

schau mal hier, so was in der art? gibts sicher auch female-female...
http://www.aliexpress.com/item…76-4470-ab65-4e08d50c6b67

ein altes ide-kabel? die waren doch 40 pinnig?

Ich nutze das hier mal ein wenig als Notizzettel für ein späteres readme...

Installation libnfc nach https://learn.adafruit.com/ada…pberry-pi/building-libnfc
(link ändern - ist jetzt auf github)
vor automake noch ein touch NEWS und touch README (sonst stürzt automake)
pip installieren, falls nicht schon vorhanden
dann danach vorgehen:
http://nfcpy.org/latest/topics/get-started.html#installation

Verkabelung standard:
VCC - 5V
GND - GND
RX - TX (GPIO 14)
TX - RX (GPIO 15)

python tagtool.py --device tty:AMA0:pn532 -- funktioniert, tag gefunden

srccode nach /usr/local/lib/python2.7/dist-packages/nfc kopieren (sudo)

erfolgreich in python, gibt die IDs meiner (2) tags aus:

import nfc
def connected(tag):
    try:
        hmm = str(tag)
        bla, ID = hmm.split('ID=')
        print(ID)
        return False
    except KeyboardInterrupt:
        raise
clf = nfc.ContactlessFrontend('tty:AMA0:pn532')
while True:
    try:
        clf.connect(rdwr={'on-connect': connected})
    except KeyboardInterrupt:
        raise

todo: keyboard basteln....

wird ein wenig dauern, scheinbar braucht es auch libnfc und das eine oder andere python-modul...
aber ich bin dran...

Soda... heute ist mein PN532 angekommen.
Man kann das Ding (wie Nea schon geschrieben hat) entweder per UART, I2C oder SPI betreiben.
Da hier eh keine riesigen Datenmengen fließen, würde ich meinen, daß (analog zu dem RDM6300) UART ausreichen sollte. Ich würde mich da mal an die Implementierung machen.
Irgendwelche Einwände gegen den Plan?

Hallo,

nein, kein Problem. Ich markiere das Thema einfach als gelöst - wenn Du noch Fragen haben solltest, bitte einen neuen Thread aufmachen...

ok, danke

@pah: läuft das bei dir schon? wie hast du das gemacht?

Hallo pah,

das finde ich toll, daß die Integration voranschreitet! Wie wird denn die Integration aussehen?

Hallo und willkommen im Forum!

Ich würde Dir sehr ans Herz legen, zuerst im Wiki nachzulesen...
https://github.com/motom001/DoorPi/wiki

dann müsstest du dir was bauen, das im doorpi per web-call eine aktion auslöst, die du dann in deinem skript prüfen kannst (zb anlegen einer datei).....

nice

Zitat von Joker

Hehe, ich sehe es auch so. Man machts halt "weils geht"

Und WEIL MAN ES KANN