Da ich inzwischen auch eine andere Freisprecheinrichtung hier habe und etwas Erfahrung mit IP-Symcon, hatte ich dieses Wochenende das Projekt wieder ausgegraben und wollte natürlich auch gleich eine Anbindung an IP-Symcon.
IP-Symcon für DoorPI vorbereiten
Recht unspektakulär hatte ich im IP-Symcon einfach 2 Boolean Variablen "Klingel EG" und "Klingel OG" erstellt.
Wichtig für die Anbindung sind die jeweils erzeugten Objekt-IDs da wir über diese die Variablen ermitteln und setzen.
DoorPI Konfiguration für IP-Symcon
Der DoorPI Software muss natürlich erstmal gesagt werden, wie und wo unser IP-Symcon Server zu erreichen ist:
mcedit /usr/local/etc/DoorPi/conf/doorpi.ini
[IP-Symcon]
server = http://IP-SYMCON-ADRESSE:3777/api/
username = IP-SYMCON-BENUTZER
password = IP-SYMCON-PASSWORT
jsonrpc = 2.0
Benutzername und Passwort sind von der Einrichtung bekannt, damit wird auch die IPS-Konsole verbunden.
Der Benutzernamen ist normalerweise eine Email Adresse mit einem @ Zeichen.
In meinem Fall war es NICHT notwendig, dieses Zeichen gegen ein %40 zu tauschen. Im Gegenteil, dadurch konnte keine Verbindung hergestellt werden.
Mit folgender Syntax können dann Variablen entsprechend True/False o.ä. gesetzt werden:
ipsrpc_setvalue:OBJEKT-ID:True
DoorPI kann keine Variablen im IP-Symcon ansteuern
Ab hier wurde es dann etwas ekelig, zumal ich bisher noch nie mit Python zu tun hatte, in jeden Fall wurden im IP-Symcon trotz korrekter Config und Syntax die Variablen nicht gesetzt.
Überprüfung der IP-Symcon API
Als erstes kontrollierte ich mit einem direkten CURL Aufruf, ob über die IP-Symcon API überhaupt die Variablen angesprochen werden können:
curl -i -X POST -H "Content-Type: application/json" -d "{\"jsonrpc\": \Value\", \"params\": [OBJEKT-ID, true]}" http://IP-SYMCON-BENUTZER:IP-SYMCON-PASSWORT@IP-SYMCON-ADRESSE:3777/api/
Hier ist Vorsicht geboten, denn Benutzer & Passwort werden durch ein @ vom Host getrennt. Ein @ im Benutzer würde hiermit zu einem Fehler führen. Bei diesem direkten Aufruf ist wie oben schon beschrieben das @ des Benutzers durch %40 zu ersetzen!
Damit wurde dann auch die Variable gesetzt, der Fehler ist also weiter auf der DoorPI Seite zu suchen.
DoorPI Debugging
Ich hatte als nächstes DoorPI gestoppt und im Debugging Mode aufgerufen:
/etc/init.d/doorpi stop
doorpi_cli
Damit startet DoorPI und gibt wichtige Informationen auf der Konsole aus.
In meiner DoorPI Config habe ich einfach mal eine Tastenaktion dafür verwendet, mir eine IP-Symcon Variable auf True zu setzen.
Bei einem Druck der Taste kam dann auch schon folgende Fehlermeldung auf der Konsole:
[doorpi.action.SingleActions.ipsrpc_setvalue] couldn't send IpsRpc ('instancemethod' object has no attribute '__getitem__')
In den weiteren Zeilen ging dann auch die Datei sowie Zeilen der Fehler hervor:
mcedit /usr/local/lib/python2.7/dist-packages/doorpi/action/SingleActions/ipsrpc_setvalue.py
Fehler 1 war Zeile 50 und der Aufruf der Funktion ips_rpc_check_variable_exists.
Die ganze Funktion ist ab Zeile 37 bzw. der genaue Fehler wird auch für Zeile 40 angezeigt.
return response.json['result']
Inhalte vom DoorPI auf der Konsole ausgeben
In dem Fall wollte ich einfach mal sehen, was denn da zurückkommt. Von der vorherigen Funktion sehe ich, dass ein "True" erwartet wird, was eigentlich auch sinnvoll ist, soll doch die Existenz der Variable geprüft werden.
Mit folgender Zeile kann der Teil vor der return Zeile ausgegeben werden:
logger.trace("i am the exists response: %s", response.json['result'])
Und siehe da, es kam eine Code 200 zurück. Da wir einen HTTP Request haben, heißt der Code dass erfolgreich eine Verbindung hergestellt werden konnte, aber nicht ob die Variable existiert.
Eine bewusste Config-Änderung z.B. falscher Server, Benutzer oder Passwort brachte entsprechend andere HTTP Codes.
Die Funktion gab mir also nicht wie erwartet, das Ergebnis ['result'] zurück.
Nach einiger Recherche fand ich dann heraus, dass wohl der JSON Funktionsaufruf noch Klammern benötigt:
logger.trace("im the exists response: %s", response.json()['result'])
Und schon kommt ein True zurück.
Die Logger Zeile hatte ich dann gleich wieder entfernt und die beiden Klammern in der Return Zeile hinzugefügt.
Die Fehler gingen dann leider noch weiter, bei der nächsten Abfrage, welchen Typ die Variable hat, war gleiches nochmal.
Auch hier ist dann die Lösung, einfach die beiden Klammern in den Result nach JSON zu schreiben.
Aber das wars immer noch nicht, mir wurden dann ständig Fehler bezüglich dem Boolean Typ angezeigt, den ich lange nicht verstand. Die Variable war ja Boolean?
[doorpi.action.SingleActions.ipsrpc_setvalue] couldn't send IpsRpc ('bool' object has no attribute '__getitem__')
Ein genaueres Ansehen des ganzen Results zeigte dann auch die Ursache:
return response.json()['result']['VariableValue']['ValueType']
Offensichtlich wurde vor einiger Zeit am JSON Format etwas verändert, in jeden Fall gab es keinen ValueType mehr. Dieser heißt nun VariableType. Auch ist dieser nicht innerhalb einer VariableValue "verschachtelt".
Die Lösung war dann die Änderung dieser Zeile in:
return response.json()['result']['VariableType']
Das wars dann endlich. Nun werden die Variablen im IP-Symcon korrekt gesetzt.
Das Echo Problem mit DoorPI
Auch wenn weder der Raspberry, noch die Software etwas dafür kann, in meiner ersten Variante hatte ich den Mono-Lautsprecher und das Mikro direkt an der Alublende befestigt.
Dies erzeugte eine extrem störende Rückkopplung, welche ich auch durch diverse Software-/Hardwarefilter nicht in Griff bekam.
Die Lösung war nebenstehende USB Freisprecheinrichtung, welche man z.B. auch für Skype Meetings verwenden kann.
Die Sache war eigentlich mit Plug & Play und der Umschaltung der Raspberry Soundkarte getan.
Folgende Konsolenbefehle sollten bei der Einrichtung der Soundkarte nützlich sein:
aplay -l # zeigt alle installierten Devices
speaker-test -c 2 # testet die Lautsprecher
aplay /usr/local/etc/DoorPi/media/ShortDialTone.wav # spielt die angegebene Datei ab
Um das Standard Device zu ändern:
mcedit /usr/share/alsa/alsa.conf
# folgende Variablen auf die Nr. des neuen Devices setzen, in meinem Fall 1
defaults.ctl.card 0 # wechseln auf 1
defaults.pcm.card 0 # wechseln auf 1
