DoorPi-Projekt

[pula]

Wenn ich endlich mein Audio-Problem löse (vermutlich eine Port-Frage), werde ich das sicher exemplarisch und evtl. mit eineme Modul angehen.
LG
pah

Ein Modul wäre toll - wobei ich gefühlsmäßig meinen würde, daß das dann bilateral auch in doorpi implementiert werden müsste, nicht nur in fhem?
Habe das Audio-Problem mittlerweile leider auch (wobei es NICHT an der Fritzbox liegen sollte, da bei mir das schon einmal mit der gleichen Hardware funktioniert hat, allerdings unter wheezy ) - nur habe ich momentan keine Zeit, mich darum zu kümmern, weil ich noch zu viele andere Baustellen offen habe (Heizungs-Automatisierung per VNC, Anbindung neuer Hardware wie Arduino an doorpi), bevor ich mich dem produktiven doorpi widmen kann....

Cheers,

Pula

[Prof. Dr. Peter Henning]

Ein kleiner Zusatz auf DoorPi-Seite ist sicher kein Problem.

LG

pah

[pula]

Da ich für doorpi das I2C-Keyboard entwickelt habe, hab ich ein bisschen Know-How und könnte  hier bei Interesse gerne mit anpacken auf doorpi-Seite...

[Prof. Dr. Peter Henning]

Prima - das nennen wir ein Konsortium.

LG

pah

[Prof. Dr. Peter Henning]

So, eine Woche später - Audio-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

[Prof. Dr. Peter Henning]

Mal sammeln, was die Integration so alles leisten soll.

1. Einmal pro Minute von DoorPi einen Request an FHEM absenden als Nachricht, dass es noch lebt => Watchdog in FHEM
2. Bei Tastendrücken normale DoorPi-Funktionen aufrufen. Zusätzlich an FHEM melden, was es gerade tut
3. Via FHEM fernsteuerbar sein: Tastendrücke aller Art auslösen
4. Via FHEM fernkonfigurierbar sein (Beispiel: Umschaltung der anzurufenden Telefonnummern)

Sonst noch etwas ?

LG

pah

[bgewehr]

Umsetzung als MQTT Client fändenich nicht schlecht. Das wäre DoorPi seitig einfach mit z. B. ein bisschen Python und endlich ein insgesamt generischer Ansatz. Was meint Ihr?

[bgewehr]

Kleines MQTT command API und auch die Fernkonfig ist kein Problem.

[Prof. Dr. Peter Henning]

Genausowenig undefiniert wie in der MQTT-Spec der Begriff "Small Code Footprint" ist, scheint mir dies Dein "Kleines MQTT command API" zu sein. Das müssten aber die DoorPi-Entwickler entscheiden.

Ansonsten spricht m.E. außer persönlichen Vorlieben nur die Verlässlichkeit für MQTT - dagegen spricht der Overhead. Es macht wenig Sinn, 10 Sekunden nach dem Drücken auf den Klingelknopf den Gong ertönen zu lassen. (Quasi-)Echtzeitfähigkeit ist hier m.E. wichtiger, und das trifft für MQTT nun wirklich nicht zu.

LG

pah

[bgewehr]

Oh. Ich dachte bisher, das wäre möglich... http://www.redbooks.ibm.com/redbooks/pdfs/sg248228.pdf

[Prof. Dr. Peter Henning]

Ich nehme an, dass ein schneller IBM MessageSight Server das tatsächlich ermöglichen würde. Willst Du den zwischen Türklingel und FHEM aufbauen ?

LG

pah

[Joker]

3. Via FHEM fernsteuerbar sein: Tastendrücke aller Art auslösen
4. Via FHEM fernkonfigurierbar sein (Beispiel: Umschaltung der anzurufenden Telefonnummern)

Das geht ja jetzt schon, oder? Man kann per HTTP-Request an DoorPi alle beliebigen Tasten auslösen. Habe ich in FHEM schon am laufen. Das umschalten der Telefonnummern geht auch: DoorPi kann fix konfiguriert werden, dass es bei Klingeltastendruck eine Nummer aus einem File auslöst. Mit einer virtuellen Taste, die man ebenfalls per HTTP-Request auslöst, kann man die Umschaltung triggern: Einfach in DoorPi eine Action hinterlegen, die die neue Nummer in das File schreibt. Das kann man mit beliebig vielen Tasten und beliebig vielen Nummern machen.

Wäre das über ein FHEM-Modul besser lösbar?

[Prof. Dr. Peter Henning]

Besser, im Sinne von komfortabler. Statt fünf unabhängiger Dummies wäre das dann ein FHEM-Device mit set und get.

LG

pah

[motomm01]

So ist das mit der Doku - ich komme aktuell auch nicht dazu die Version 2.5 weiter zu dokumentieren, da ich an der 3er hänge...
Aber da gab es noch was:
https://github.com/motom001/DoorPi/blob/master/doorpi/status/webserver_lib/request_handler.py#L27

Meint soviel wie:

Code Auswählen Erweitern

http://raspberry/control/config_value_set?module=sektion&name=key&value=test
Damit würde ein config Eintrag manipuliert werden. Resultat:

Code Auswählen Erweitern


[sektion]
key = test

Die config würde noch nicht in der Configfile gespeichert und gilt somit nur für die Dauer so lange DoorPi läuft...

Auch interessant könnte für euch die DoorPi Status Abfrage sein.

Code Auswählen Erweitern

http://raspberry/status
Die Statusabfrage kann auch mit den GET-Parametern module und name eingegrenzt werden.

[Prof. Dr. Peter Henning]

@motom001: Danke, das ist nützlich.

Ich kämpfe derzeit noch mit dem Python-Modul url_call.py, um in FHEM etwas auszulösen.

Mit dem Eintrag in der doorpi.ini

Code Auswählen Erweitern

10 = url_call:http://192.168.0.90:8085/fhem?XHR=1&cmd.WZ.3x=set WZ.3x toggle
wird der Request zwar abgeschickt, kommt aber bei FHEM nicht an. --trace zeigt sehr schön die Ausführung in url_call - das wars dann aber auch. Keine Fehlermeldung, kein Timeout.

Habe ich stattdessen in der doorpi.ini

Code Auswählen Erweitern

10 = os_execute:/root/test.sh
und in dem zugehörigen Skript die triviale Zeile

Code Auswählen Erweitern


wget 'http://192.168.0.90:8085/fhem?XHR=1&cmd.WZ.3x=set WZ.3x toggle'


geht das Schalten problemlos.

LG

pah