Loxone Intercom Gen2 - Webschnittstelle um Bild/Video rauszubekommen

**Jan W.** · 23.01.2022, 09:36

Vorab: ich habe nicht die neue Intercom und lese aus Interesse mit, weil ich das Thema sehr spannend finde. In #13 sieht man eine SDP=Session Description Message. Normalerweise läuft SDP als Zusatzprotokoll über SIP, um die Endpunkte für die Medienübertragung einer Audio- oder Videosessession, aber auch die Codecs auszuhandeln. Ich kenne das Protokoll nur in der Form, dass die eine Seite den Videostrom "anfordert" und dabei IP-Adresse, Port angibt, wo das Video hingesendet werden soll und evtl. mehrere Vorschläge für Codec und weitere Optionen macht. Die Gegenseite sucht sich dann aus der Liste einen der Codecs aus (evtl. gab es auch nur ein Vorschlag) und antwortet dann. Das ist vermutlich das Paket in #13, weil dort "sendonly" steht. Im Internet gibt es viele Beschreibungen zu SDP, i.d.R. in Verbindung mit SIP.

Für eine bessere Lesbarkeit von JSON Ausgaben gibt es jq. Die Ausgabe wird einfach über Pipe an jq gesendet.

**Laubi** · 23.01.2022, 14:06

OK, vielleicht ist die Annahme die Box könnte H264 falsch:

im log gibts folgenden Eintrag bei mir:

Code:

2022-01-23 13:59:56.978 Warning   Baresip: video: could not find decoder (H264)

**Laubi** · 23.01.2022, 14:07

sprich was auch immer die sendet, vielleicht doch kein H246

**Jan W.** · 23.01.2022, 17:38

Lt. Deiner vorherigen Posts, z.B. #13 ist es H.246! Das SDP (siehe RFC 8866, dort z.B. nach c= suchen) beschreibt die Optionen:

Code:

c=IN IP4 192.168.178.73      // c=connection data, die IPv4 IP-Adresse dieses Gerätes
t=0 0                                      // t=timing, nicht relevant
a=ice-ufrag:YripK3q              // a=attribute, hierüber werden zusätzliche Infos übermittelt
a=ice-pwd:xxxxxxxxxxxxxxxxxxxxxxxxxxx
a=setup:active
a=fingerprint:SHA-256 E5...
m=video 16494 UDP\/TLS\/RTP\/SAVPF 108 123     //m=media, hier UDP auf Port 16494 (Port des Senders)
a=rtpmap:108 H264\/90000     // Beschreibung der RTP Payload, hier eine Variante "Nr. 108" mit Inhalt H264 mit clock rate 90000 Herz
a=fmtp:108 packetization-mode=0;profile-level-id=42e01f
a=rtpmap:123 H264\/90000    // hier noch eine andere Variante "Nr. 123", siehe RFC 6184 für Details zu Unterschieden
a=fmtp:123 packetization-mode=1;profile-level-id=42e01f
a=sendonly
a=ssrc:3878327014 cname:8KOFxnfnN0gX2IM
a=framerate:20.00
a=rtcp-fb:* nack pli
a=mid:0
a=rtcp-mux

Wie schon im vorhergehenden Beitrag erwähnt, gibt es immer ein Offer (Angebot) und eine Response (Antwort), d.h. die Kamera (Offerer) bietet verschiedene Parameter an und derjenige, der das Video sehen möchte (Answerer) entscheidet sich für eine der angebotenen Varianten und gibt seine IP-Adresse, seinen UDP Port, seine Attribute etc. an. Im Datenstrom, wo Du die Ausgabe von #13 herbekommen hast, musst Du nach der Antwort der Gegenseite suchen. Das eigentliche Video kann man im Wireshark anhand der UDP Daten zwischen den beiden IP-Adresse und Ports finden. Sofern Anmeldedaten etc. beim Aushandeln über SDP korrekt sind, sollte die Kamera das Video senden.

**Laubi** · 24.01.2022, 07:29

Hi Jan,
ersteinmal danke für Deine Ideen und Hinweise:

Wie schon im vorhergehenden Beitrag erwähnt, gibt es immer ein Offer (Angebot) und eine Response (Antwort), d.h. die Kamera (Offerer) bietet verschiedene Parameter an und derjenige, der das Video sehen möchte (Answerer) entscheidet sich für eine der angebotenen Varianten und gibt seine IP-Adresse, seinen UDP Port, seine Attribute etc. an. Im Datenstrom, wo Du die Ausgabe von #13 herbekommen hast, musst Du nach der Antwort der Gegenseite suchen. Das eigentliche Video kann man im Wireshark anhand der UDP Daten zwischen den beiden IP-Adresse und Ports finden. Sofern Anmeldedaten etc. beim Aushandeln über SDP korrekt sind, sollte die Kamera das Video senden.

Nach dem in diesem Thread manche Aussage durcheinander gerät, was vermutlich einfach am Trial and Error liegt und für Außenstehende dann ohne Intercom kaum noch nachzuvollziehen ist, fasse ich mal kurz zusammen wie sich mir die Lage darstellt:

das "offer" versendet der Client (nicht die Klingel)
die "klingel" antwortet mit einem answer (das Beispiel #13 ist ebenfalls eine answer)

=> Zusammengefasst ist das vielleicht ganz gut in #23, da ich hier noch mit einem aus einem tcpdump kopierten Offer gearbeitet habe, und damit die Websocket Antwort auch sehr original sein muss.

Was mach ich jetzt mit dem:

Code:

2022-01-23 13:59:56.978 Warning Baresip: video: could not find decoder (H264)

Mein eingänglichster aktueller Verdacht und der passt dann wieder zum "not find decoder" ist diese Theorie:

aiortc baut den offer mit einem "a=sendrecv", der Loxone Client macht von vornherein nur ein "a=recvonly";
=> für beide mach das Sinn, der Client hat gar keinen Zugriff auf eine Kamera; der aiortc Client baut selbst ein fakevideo ("A video track that returns an animated flag")

die intercom antwortet in beiden fällen im answer mit einem a=sendonly,
=> auch das macht (für mich) sinn, weil beide clients ja Empfangsfähig sind, einigen sie sich auf den gemeinsamen Nenner (Intercom sendet; Client empfängt)

Zwischenzeitlich habe ich aber den Verdacht das aiortc sich jetzt nicht so verhält wie wir es erwarten würden; er sendet nämlich trotzdem, im Verlose log (#29) sehen wir daher auch eine menge an log eintragen mit:

Code:

DEBUG:aiortc.rtcrtpsender:RTCRtpSender(video) > RtpPacket(seq=40459, ts=1790200327, marker=0, payload=101, 1264 bytes)

Damals hatte ich "RTCRtpSender(video) > RtpPacket" einfach mangels anderer Informationen einfach Missinterpretiert, von daher glaube ich unterdessen das der Log-Eintrag davon kommt, das mein client einfach Videodaten über den Stream sendet, ohne das die Gegenseite das will. (Bug im aiortc oder Feature was ich nicht verstehe?) Ich stell das heute Abend nochmal nach, weil ich eigentlich der Meinung war das der TCPdump das so nicht hergab.

Für mich spricht da gerade dafür, das das gesamt Log-Verhalten ganz anders ausschaut, wenn ich vor übergabe des offers diesen manipuliere. Mir ist nur nicht klar warum, angesichts des unveränderten answer müsste sich doch die Intercom Genauso verhalten wie sonst; Oder habe ich da einen Denkfehler???? Und mein aiortc client erfährt ja gleich gar nix von dieser "Manipulation"

=> Auch das versuche ich nochmal in den unterschiedlichen Konstellationen nachzustellen und zu dokumentieren

Aktuellste Frage für mich wäre kann jemand so gut Python, das man den aiortc (https://github.com/aiortc/aiortc/blo...eam-cli/cli.py) beibringt im Offer nur ein recvonly zu senden und sich dann selbst auch so zu verhalten? Also ersteres mach ich während des copy&paste Vorgangs auch selbst aber der 2. Teil ...

Danke einen schönen Tag und bis bald
Laubi

**Laubi** · 24.01.2022, 16:55

Zwischenstand: Ich habe die Authentifizierung; für was sie gut ist bin ich mir noch nicht sicher

Aber zumindest dürfte es die Fehlersuche vereinfachen, Authentifizierungsfehler ausschließen.
Im tcpdump findet man sowas hier:

Code:

{
"jsonrpc": "2.0",
"result": {
"code": 200,
"message": "Ok",
"data": [
"admin",
"688 - Zeichendn danach =",
"1188 - Zeichen und danach =="
]
},
"id": 0
}

Auch wenn es erstmal wie eine OK Meldung der Intercom aussieht, das sendet der Client als OK auf die Initiale Auth-Meldung der Intercom zurück und dann gibts auch als Bestätigung:

Code:

< {"id":1,"jsonrpc":"2.0","method":"reachMode","params":[]}
< {"jsonrpc":"2.0","method":"ready"}

Der Stream wird vom aiorc aber immer noch nicht gespeichert ... und am Rande; für meinem dafürhalten ist der Username rein Informativ und wird nicht ausgewertet. Ich gehe aktuell davon aus, das die Methoden zur Erstellung der verschlüsselten Information in den Standort Websocket Dokumenten von Loxone beschrieben sind. Jetzt fehlt mir tatsächlich der Mirrorport:

Aber wie gesagt am Stream ändert sich erstmal nichts damit :-/

**Laubi** · 24.01.2022, 18:54

noch ein Hinweis

meine Annahme:

aiortc baut den offer mit einem "a=sendrecv", der Loxone Client macht von vornherein nur ein "a=recvonly";

war wohl falsch, die Intercom sendet tatsächlich ein "a=sendrecv" wenn die Gegenseite kein Recvonly sendet, wenn ein recvonly kam, dann gibts auch ein sendonly

**Laubi** · 15.02.2022, 19:36

Statusupdate:

Ich habe noch nicht aufgegeben

... Aktuell versuche ich irgendwie etwas JavaScript KnowHow aufzubauen, mit einem curl/wget auf den Miniserver und folgenden Pfaden:

Code:

./scripts/app.js
./scripts/cacheBuster.js
./scripts/controls1.js
./scripts/Controls/atheneControl/atheneControlCommandSrc.js
./scripts/Controls/atheneControl/atheneControl.js
./scripts/Controls/atheneControl/content/controlContent.js
./scripts/Controls/atheneControl/content/screens/atheneNotReady/atheneNotReady.js
./scripts/Controls/controlCommandSrc.js
./scripts/Controls/control.js
./scripts/Controls/infoViewControl/infoViewControl.js
./scripts/Controls/intercomControl/intercomControlCommandSrc.js
./scripts/controls.js
./scripts/Controls/sliderControl/sliderControl.js
./scripts/Controls/weatherControl/weatherControl.js
./scripts/GUI/ActiveMiniserver/favorites/favoritesScreenV2.js
./scripts/GUI/DeviceManagement/connectingWaiting/connectingWaitingScreen.js
./scripts/gui.js
./scripts/resources.js
./scripts/scripts1.js
./scripts/scripts.js
./scripts/stateContainers.js
./scripts/UtilityComp/LxEnums.js
./scripts/vendor1.js
./scripts/vendor.js
./scripts/wi-adds.js

hat man zumindest den Baukasten um die Kommunikation zu verstehen. Einige kleine Anpassungen und ein Aufruf über den eigenen Webserver verbindet trotzdem zum Miniserver und damit kann man schon mal ordentlich ins logging eingreifen.

Status Quo bei mir: Ich habe keine Ahnung was ich tue :-/. Also falls hier jemand mit JavaScript KnowHow helfen kann und will: Ich glaube immer weniger an ein Verschlüsselungs-Thema, aktuell habe ich ne lokale Webseite wo die drei Buttons ralsgepatcht sind, und wo ich nur noch einen Click hin habe (Zugangsdaten im javascript hinterlegt.

=> Nebenerkenntnis:

- Loxone verwendet stun.loxone.com als stun oder turn Server -> aber der Videostream fordert keine Verbindung dazu.
- Der Turn-User und das Turn-Passwort -> meine Erkenntnis nach statisch und Hardware-Gebunden bekommt man ohne Authentifizierung mittels: '{"id":2,"jsonrpc":"2.0","method":"info"}' per webrtc, (gleich nach dem login einfach absenden)

=> Sollte jetzt jemand mitlesen, der mir verraten kann wie ich (generisch) nach einer websocket-Verbindung einen
- PerrConnection starten
- einen Offer erstellen und per json 2.0 versenden kann

der kann gerne mal die Hand heben. Ich werde da - mangels zeit - noch ein paar Wochen brauchen ... aber gelöst wird das Thema

LG
Laubi

**bladerb** · 01.04.2022, 07:55

Ich verfolge das Thema seit ein paar Tagen und habe mir die Scripte von Kaubi angesehen. Super Arbeit. Das hat mir das debuggen des HTTP-Traffik erspart. Ich hab mich letzte Nacht mal mit dem bereitstellen eines Loxberry Plugins beschäftigt und würde in den nächsten Tagen etwas ins git hochladen.

Grundlegender Funktionsumfang:

Hinterlegen der Intercom Adresse samt Port
Bereitstellen eines Webhook für Loxone zum anstossen der Bildspeicherung bei z.B. Klingeln in Loxberry
Erweiterter Webhook der Bei Bildgenerierung aufgerufen werden kann (Weitergabe der Bild URL per GET-Request für die beliebige Weiterverarbeitung) Aktuell nutze ich die Weitergabe um das Bild des Besuchers auf einem MagicMirror auszugeben.

Später wäre noch die von Laubi beschriebene automatische Backupfunktion für das BIldarchiv ein must have.

**bladerb** · 04.04.2022, 20:38

Hier gibt es die erste Version die alle Basics aus den beiden Scripten von Laubi unterstützt. Für Verbesserungsvorschläge und Ideen einfach hier Feedback geben. Es wäre natürlich super wenn wir das mit dem Videostream auch noch hinbekommen und in das Plugin einbauen könnten. https://github.com/bladerb/intercom2...tags/1.0.0.zip

**Laubi** · 05.04.2022, 20:04

bladerb

Ich glaub im wesentlichen waren es reine Timeout Themen, Diff zwischen meinem Produktiven Script und dem in deinem Plugin:

Code:

# diff ../github/intercom-gen2-last-picture.sh /usr/local/bin/intercom-gen2-last-picture.sh
20c20
< # Version: 2022-01-19 19:46
---
> # Version: 2022-01-17 21:22
25,26d24
< # intercom="192.168.127.3:80" # Die IP und der Port der InterCom Gen.2
< intercom=$(cat $LBPDATA/intercom22lox/data.json | jq .intercomip | tr -d '"')
28,33c26,32
< wscatwait=0.9 # Geschätzte Zeit für den Lauf der Funktion make_pictures -> brauchen wir bei -w vom wscat
< makewait=0.5 # Geschätzte Zeit bis die Info von der Intercom im tempfile sind -> brauchen wir beim sleep vor dem auslesen des tempfiles
< # websocat="/usr/local/bin/websocat_linuxarm32" # wscat hat sich als unbrauchbar für den Scripteinsatz erwiesen
< websocat="websocat" # wscat hat sich als unbrauchbar für den Scripteinsatz erwiesen
< # lastpict="/opt/loxberry/webfrontend/html/tmp/lastpicture.jpg" # -> Ja das sollte noch hinter das Auth landen
< lastpict="lastpicture.jpg"
---
>
> intercom="172.16.2.190:80" # Die IP und der Port der InterCom Gen.2
> wscatwait=10 # Geschätzte Zeit für den Lauf der Funktion make_pictures -> brauchen wir besleep im echo vor dem Websocket
> makewait=1 # Geschätzte Zeit bis die Info von der Intercom im tempfile sind -> brauchen wir beim sleep vor dem auslesen des tempfiles
> websocat="/usr/local/bin/websocat_linuxarm32" # wscat hat sich als unbrauchbar für den Scripteinsatz erwiesen
> lastpict="/opt/loxberry/webfrontend/html/tmp/lastpicture.jpg" # -> Ja das sollte noch hinter das Auth landen
> # In der Fritz steht damit ${loxberry}/tmp/lastpicture.jpg
69,71c68,72
<
< ( echo '{"jsonrpc":"2.0","method":"info","id":0}' ; sleep ${wscatwait} ) | ${websocat} --protocol webrtc-signaling ws://${intercom} > ${tempfile}
< rm -f ${tempfile}
---
>
> echo "DEBUG $(date)"
> ( echo '{"jsonrpc":"2.0","method":"info","id":0}' ; sleep ${wscatwait} ) | ${websocat} --protocol webrtc-signaling ws://${intercom} | tee ${tempfile}
> echo rm ${tempfile}
> echo "DEBUG $(date)"
82c83
< curl --output ${lastpict} "http://${intercom}/jpg/image.jpg?auth=${authkey}"
---
> curl --output ${lastpict} "http://${intercom}/jpg/image.jpg?auth=${authkey}" 2> /dev/null

Ich bin mir nicht sicher, aber glaube das tee im websocat war nur für Debug-Zwecke.
Aktuell habe ich das Script etwas "hard" in text2sip hineingebaut und schiebe es von dort direkt in den Hintergrund wegen der Timeouts:

Code:

:/opt/loxberry# grep intercom ./webfrontend/htmlauth/plugins/text2sip/index.cgi ./webfrontend/html/plugins/text2sip/index.php
./webfrontend/htmlauth/plugins/text2sip/index.cgi: system ("/usr/local/bin/intercom-gen2-last-picture.sh -w > /dev/null 2>&1 &");
./webfrontend/html/plugins/text2sip/index.php: system ("/usr/local/bin/intercom-gen2-last-picture.sh -w > /dev/null 2>&1 &");
:/opt/loxberry#
#

Das ganze funktioniert derart verzögert das das FritzFon in der Lage ist das Bild während des Klingelns aufzubauen, die Mail die in der Fritz zum Versand eingestellt ist aber so früh rausgeht, das das Bild nicht sauber angehängt wird.

=> Ich bin bisher davon ausgegangen das dies an meinem "stabilen" Netz liegt (Devolo dLan im Schaltschrannk mit gerade mal 100 Mbit/s synchron, auf altes Klingelkabel ...) Wobei die Videoübertragung in die App ziehmlich stabil ist. Aber ab und zu hab ich tatsächlich auch Aussetzer im Aufbau der Websocket-Verbindung.

LG
Laubi

**bladerb** · 13.04.2022, 17:31

Laubi ich bin die Scripte nochmal durchgegangen und auch mit den angepasssten Timeouts bekomme ich mal ein bild und mal keins. Hast du die neuste Firmware auf der intercom? Bei mir ist die 12.04.03.30 drauf.

Ich habe es immer wieder total willkürlich das ich ein Bild bekomme oder aber eben keins. Auch habe ich es schon einige Male gehabt das die Intercom einfach aussteit und es wird eine Sabotage Mail verschickt weil die Intercom nicht erreichbar ist. Tagsüber sowie Abends das ganze ist nicht sehr Zufriedenstellend wo man nun fast ein Jahr auf die Intercom gewartet hat.

Auch der neue NFC Code Touch Gen2. ist scheinbar um einiges empfindlicher als der Alte Code Touch. Der hatte nie eine Phantomeingabe der neue hingegen ständig. was ganz schön nervig sein kann.

Bist du mit dem Video abgreifen schon weitergekommen. Schade das Loxone das ganze nicht mittels Config Bausteinen und Ausgängen zur verfügung stellt. Die Fotos der Intercom nützen ja nichts wenn sie auf der Intercom liegen die aber geklaut wurde... das nur als ein Beispiel.

**bladerb** · 18.05.2022, 12:00

Bei mir ist das Thema wegen Zeitmangel und einer immer öfter nicht erreichbaren Intercom momentan etwas in den Hintergrund gerückt. Ich hoffe das ich sobald die Intercom wieder besser funktioniert wieder dazu komme mich an das Thema zu setzen.

**Laubi** · 11.10.2022, 16:49

Ähmmm gerade in einem anderen Threat (https://www.loxforum.com/forum/hardw...031#post356031) gefunden:

Stream über https://USER:PASS@IPDERINTERCOM/mjpg/video.mjpg

Ähhhmmmm das ist ja mal spannend, bei mir funktioniert.

**bladerb** · 27.01.2023, 19:56

Hallo in die Runde, die letzten Monate hatte ich etliche Problem mit der Intercom weshalb die Weiterentwicklung des Plugins nicht voran ging. Ich habe mein Loxberry Plugin dahingehend angepasst das das Bild aus dem MJPG Stream genommen wird. Das ganze funktioniert um einige schneller und zumindest bei mir Zuverlässiger als das Script von Laubi. Hier der neue Release:

https://github.com/bladerb/intercom22lox/archive/refs/tags/1.1.0.zip

Ich würde mich freuen wenn es jemand ausprobiert und vielleicht noch Ideen beisteuern kann wie man das ganze evtl noch erweitern / aufbohren kann.

Loxone Intercom Gen2 - Webschnittstelle um Bild/Video rauszubekommen

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar