Test Adapter eusec 3.x.x

typhos

@Ephi Danke für den Test und die Logzeilen, die haben gereicht.

Was passiert: Nach dem Schließen eines Streams läuft der Livestream der Kamera noch 10 Sekunden weiter, damit ein Neuladen der Seite nicht jedes Mal die Kamera neu aufwecken muss. Öffnest du in diesen 10 Sekunden eine andere Kamera derselben HomeBase, startet der Adapter sie, obwohl die HomeBase noch den alten Livestream überträgt. Die Bibliothek, über die der Adapter mit der HomeBase spricht, beendet den alten Livestream dann nur bei sich, schickt der HomeBase aber keinen Stopp. Die neue Kamera liefert daraufhin nichts, und der Adapter versucht es bis zu fünf Minuten lang weiter. In dieser Zeit gilt die Station als belegt, deshalb die Meldung „the station is busy with the livestream of …“ und das „404 Not Found“ beim Kompatibilitäts-Stream der S340.

Wartest du die 10 Sekunden ab, hat der Adapter den alten Livestream schon selbst ordentlich beendet – deshalb geht es dann.

Ab Version 3.6.2 stoppt der Adapter den Livestream der geschlossenen Kamera sofort, sobald eine andere Kamera derselben HomeBase geöffnet wird, und startet die neue erst danach. Sie ist veröffentlicht und erscheint in Kürze im latest-Repository. Ich habe hier keine HomeBase mit mehreren Kameras, um das am echten Gerät nachzustellen – über eine Rückmeldung, ob der schnelle Wechsel damit klappt, würde ich mich freuen. Bis zum Update hilft es, nach dem Schließen 10 Sekunden zu warten.

Das Loglevel kannst du wieder auf „info“ zurückstellen.

Ephi

@typhos

Danke, ich gebe gerne Rückmeldung!

Ephi

@typhos

Habe 3.6.2 gerade ausprobiert. Solange ich innerhalb der Kompatibilitäts-Streams (also bei den Außenkameras Solocam S340) bleibe funktioniert es jetzt. Sobald ich aber danach innerhalb der 10 Sekunden auf die Innenkamera Pan&Tilt (kein Kompatibilitäts-Stream) wechseln will, kommt es wieder zu den o.g. Fehlern (derselbe Inhalt, deshalb verzichte ich auf nochmaliges vollständiges Posten des Logs). Bedeutet: Der Stream von der Pan&Tilt startet nicht, auch nicht bei mehrfachen Versuchen, und ab da klappt auch der Start der beiden anderen Streams (S340) nicht mehr; Fehlermeldungen: Station Busy + 404 wie oben dargestellt, auch Timeout ist wieder da. Mein Gefühl ist, dass bei einer Mischung von Kompatibiltäts- und normalem Stream (bei unterschiedlichen Kameras) es zu dem Fehlerbild kommt. Bleibe ich bei einer Art, scheint der Fehler nicht aufzutreten. Falls du doch alle Fehler im Log brauchst, sag gerne Bescheid.

typhos

@Ephi Danke für den schnellen Test – deine Vermutung mit der Mischung ist eine gute Spur.

Ich glaube allerdings, es liegt nicht am Kompatibilitäts-Stream selbst, sondern am Videoformat dahinter: Die S340 sendet H.265, die Pan&Tilt H.264. Seit 3.6.2 stoppt der Adapter beim Wechsel den alten Livestream und startet den neuen direkt danach. Die HomeBase schickt aber vermutlich noch einen Moment lang Daten der alten Kamera hinterher, und die Bibliothek, über die der Adapter mit der HomeBase spricht, prüft nicht, von welcher Kamera die Daten kommen. Der neue Livestream der Pan&Tilt würde dann mit dem Rest der S340 beginnen und als H.265 eingestuft. Die eigentlichen H.264-Bilder der Pan&Tilt passen nicht dazu, go2rtc bekommt nichts Abspielbares, und der Adapter wartet bis zu fünf Minuten weiter – in der Zeit ist die HomeBase belegt, daher wieder „Station busy“, „404“ und „timeout“ bei den S340.
Zwischen den beiden S340 fällt das nicht auf, weil beide H.265 senden.

Da ich hier keine HomeBase mit mehreren Kameras habe, kann ich das nur aus dem Code ableiten. Bevor ich eine neue Version veröffentliche, würde ich das gern mit deinem Log bestätigen. Könntest du den Wechsel S340 → Pan&Tilt noch einmal nachstellen und mir die Zeilen mit „On-demand stream“ ab dem Schließen der S340 bis etwa eine Minute danach posten (Loglevel „debug“ reicht wie zuletzt)? Mich interessiert vor allem, ob kurz nach

On-demand stream <S340>: <Pan&Tilt> takes over the station - stopping livestream

eine Zeile

On-demand stream <Pan&Tilt>: first picture 0 seconds after the request

(oder 1 Sekunde) kommt. So schnell wacht die Pan&Tilt nicht auf – dann wären das die Daten der S340, und die Erklärung passt.

Falls du Lust hast, auch den umgekehrten Weg zu testen: Ich erwarte, dass Pan&Tilt schließen und innerhalb von 10 Sekunden eine S340 öffnen mit 3.6.2 genauso hängen bleibt.

Eine Korrektur habe ich vorbereitet: Der Adapter wartet nach dem Stopp einer Kamera zwei Sekunden, bevor er eine andere Kamera derselben HomeBase startet – in der Zeit verwirft die Bibliothek die nachkommenden Daten noch. Bis dahin hilft es, nach dem Schließen gut 10 Sekunden zu warten.

Ephi

@typhos

Vielen Dank und entschuldige die späte Rückmeldung. Bin erst gerade von einer beruflichen Fortbildung zurückgekommen und bin heute Abend zu platt für den Test. Ich werde den Test aber morgen durchführen können.

Ephi

Hallo @typhos

Habe gerade die Tests wie von dir gewünscht gemacht. Der erste Teil des Tests verlief genau so, wie Du vermutet hast (die Kamera mit der Serien-Nr. T84 zu Beginn ist die Pan&Tilt, die mit der T81 eine der beiden S340):

2026-10-28 16:08:15.091  - [34mdebug[39m: eusec.0 (34247) [Object.debug] On-demand stream T84XXXXXXXXXXA25: go2rtc requests the video
2026-10-28 16:08:15.091  - [32minfo[39m: eusec.0 (34247) On-demand stream T84XXXXXXXXXXA25: requested by go2rtc - starting livestream
2026-10-28 16:08:15.092  - [32minfo[39m: eusec.0 (34247) On-demand stream T81XXXXXXXXXX604: T84XXXXXXXXXXA25 takes over the station - stopping livestream

Etwas später dann diese Zeilen:

2026-10-28 16:08:15.900  - [32minfo[39m: eusec.0 (34247) On-demand stream T84XXXXXXXXXXA25: first picture 1 seconds after the request, 1 video request(s) of go2rtc waiting
2026-10-28 16:08:15.903  - [34mdebug[39m: eusec.0 (34247) [Object.debug] On-demand stream T84XXXXXXXXXXA25: go2rtc requests the audio of the running livestream

Hier der umgekehrte Weg (zuerst Pan&Tilt, danach S340):

2026-10-28 16:21:02.228  - [34mdebug[39m: eusec.0 (34247) [Object.debug] On-demand stream T81XXXXXXXXXX604: go2rtc requests the video
2026-10-28 16:21:02.228  - [32minfo[39m: eusec.0 (34247) On-demand stream T81XXXXXXXXXX604: requested by go2rtc - starting livestream
2026-10-28 16:21:02.228  - [32minfo[39m: eusec.0 (34247) On-demand stream T84XXXXXXXXXXA25: T81XXXXXXXXXX604 takes over the station - stopping livestream

Etwas später dann:

2026-10-28 16:21:05.085  - [32minfo[39m: eusec.0 (34247) On-demand stream T81XXXXXXXXXX604: first picture 3 seconds after the request, 1 video request(s) of go2rtc waiting
2026-10-28 16:21:05.086  - [34mdebug[39m: eusec.0 (34247) [Object.debug] On-demand stream T81XXXXXXXXXX604: go2rtc requests the audio of the running livestream

Bei dem Gegenversuch war tatsächlich ein Bild bei der S340 zu sehen (wahrscheinlich weil der Wert hier 3 seconds war, oder es war nur ein Glückstreffer?). Falls Du noch mehr brauchst, lass es mich wissen. Danke!

typhos

@Ephi Danke für die Tests, das hilft sehr – und kein Grund zur Entschuldigung.

Der erste Teil bestätigt die Erklärung: Die Pan&Tilt meldet ihr erstes Bild 0,8 Sekunden nach der Anfrage. So schnell wacht sie nicht auf, das waren noch Daten der S340. Damit beginnt der Livestream der Pan&Tilt als H.265, und ihre eigenen H.264-Bilder passen nicht mehr dazu.

Beim umgekehrten Weg lag ich falsch: Die 3 Sekunden sind diesmal ein echtes Bild der S340, deshalb siehst du sie auch. Die Pan&Tilt hat nach dem Stopp offenbar nichts mehr hinterhergeschickt. Ob das immer so ist oder diesmal nur Glück war, kann ich aus einem Versuch nicht sagen – es hängt davon ab, ob bei der HomeBase im Moment des Starts noch Daten der alten Kamera unterwegs sind. Die Korrektur deckt beide Richtungen ab: Nach dem Stopp einer Kamera wartet der Adapter zwei Sekunden, bevor er eine andere Kamera derselben HomeBase startet. Bei dir kamen die Daten der S340 nach 0,8 Sekunden, das liegt gut innerhalb dieser Zeit.

Die Korrektur ist in 3.6.3, die gerade erschienen ist. Wenn du magst, probier den Wechsel S340 → Pan&Tilt damit noch einmal aus. Die Pan&Tilt sollte dann frühestens zwei Sekunden nach dem Stopp der S340 ihr erstes Bild melden und normal laufen.

Ephi

@typhos

Ich habe Version 3.6.3 gerade installiert und mehrfach in beide Richtungen (zuerst S340 und dann Pan&Tilt sowie umgekehrt) ausprobiert und es funktioniert jetzt tadellos und ohne Probleme. Vielen Dank für deine Arbeit.

guitardoc

Hat mal jemand eine Eufy T8210 Türklingel mit Vorschaubild und Stream zum Laufen gebracht und dann über yahka an Apple übergeben bekommen? Und zwar so, dass der Akku nicht leergesaugt wird?
Ich bekomme es einfach nicht hin…

typhos

@guitardoc Mit der T8210 selbst habe ich es nicht probiert, aber der Akku hängt vor allem daran, woher yahka das Vorschaubild holt.

Solange die Home-App offen ist und die Kachel der Klingel zeigt, fragt sie etwa alle zehn Sekunden ein neues Vorschaubild ab. yahka holt dieses Bild in der Grundeinstellung mit ffmpeg aus derselben Quelle wie den Stream (-i ${source} im Feld "FFMPEG Command Line - Snapshot"). Jede Abfrage weckt damit die Klingel und startet einen Livestream. Das leert den Akku schnell.

So sollte es gehen, ohne dass die Klingel ständig wach ist:

Stream: In den Einstellungen von eusec "Livestreams bei Bedarf starten" einschalten. Dann startet der Livestream erst, wenn jemand die RTSP-Adresse öffnet, und endet kurz nachdem der letzte Zuschauer weg ist. Die Adresse steht im State livestream_rtsp der Klingel; sie gehört in yahka in das Feld "Source".
Vorschaubild: Nicht aus dem Stream nehmen, sondern das letzte Ereignisbild, das eusec ohnehin speichert. Der Pfad steht im State picture_url der Klingel, z. B. /files/eusec.0/<Station>/last_event/<Seriennummer>.jpg. Der web-Adapter liefert die Datei ohne das /files aus: http://<ioBroker-IP>:8082/eusec.0/<Station>/last_event/<Seriennummer>.jpg. Im Feld "FFMPEG Command Line - Snapshot" nur ${source} durch diese Adresse ersetzen, der Rest bleibt:

[
  "-re",
  "-i", "http://<ioBroker-IP>:8082/eusec.0/<Station>/last_event/<Seriennummer>.jpg",
  "-t", "1",
  "-s", "${width}x${height}",
  "-f", "image2",
  "-"
]

ffmpeg kann sich nicht anmelden. Die Adresse muss also ohne Login das Bild zeigen; am einfachsten vorher im Browser testen.

Der Haken: Das Vorschaubild zeigt dann das letzte Ereignis (Klingeln oder Bewegung), nicht das aktuelle Bild vor der Tür. Ein aktuelles Bild gibt es bei einer Akku-Klingel nur, wenn man sie weckt.

Falls es danach noch hakt: Welche Version von eusec nutzt du, ist "bei Bedarf" an, und was steht in yahka in "Source" und im Snapshot-Befehl? Und was genau klappt nicht - kein Bild, kein Stream, oder läuft der Akku leer?

guitardoc

Das funktioniert leider nicht. Ich bekomme die Kamera zwar im Browser angezeigt, aber nicht in Apple Home. Das Vorschaubild liefert schon im Browser nur einen Platzhalter:

typhos

@guitardoc Danke für den Screenshot. Zwei getrennte Dinge:

Vorschaubild: Der Browser zeigt ein echtes Bild, keinen Fehler. Fehlte die Datei, käme vom web-Adapter nur eine Fehlermeldung und kein graues Bild. Was du siehst, ist also das, was eusec als letztes Ereignisbild der Klingel gespeichert hat. Ich kann auf dem Screenshot nicht erkennen, ob es ein echtes, sehr dunkles oder unscharfes Bild ist oder ein Platzhalter von eufy.

Zeigt die eufy-App beim letzten Ereignis der Klingel ein anderes Bild?
Ändert sich das Bild im Browser, wenn du einmal klingelst und danach etwa eine Minute wartest?
Steht im Log von eusec eine Zeile "Event picture of device ... could not be decoded"?

Stream in Apple Home: Dass er im Browser läuft, zeigt nur, dass eusec ihn liefert. Für Apple Home holt yahka den Stream per ffmpeg von der RTSP-Adresse, wandelt ihn um und schickt ihn verschlüsselt an das iPhone. Dabei kann an mehreren Stellen etwas fehlen. Damit ich nicht raten muss:

Welche Version von eusec und yahka nutzt du?
Was steht in yahka in "Source" und im Feld "FFMPEG Command Line - Stream"?
Was gibt ffmpeg -version auf dem ioBroker-Rechner aus?
Stell yahka auf Log-Stufe "debug", öffne die Klingel in der Home-App und warte, bis sie aufgibt. Dann bitte das Log von yahka und eusec aus dieser Zeit. Bei eusec interessiert mich vor allem die Zeile "On-demand stream ...: first picture ... seconds after the request". Sie zeigt, wie lange die Klingel zum Aufwachen braucht. Wartet die Home-App weniger lange, bricht sie ab, bevor ein Bild kommt.
Was zeigt die Home-App genau: gar keine Kachel, die Kachel ohne Bild, oder hängt sie beim Öffnen des Live-Bilds?

guitardoc

@typhos sagte:

Zeigt die eufy-App beim letzten Ereignis der Klingel ein anderes Bild?

Ja, das richtige Bild der Straße.

@typhos sagte:

Ändert sich das Bild im Browser, wenn du einmal klingelst und danach etwa eine Minute wartest?

Ja, es ändert sich leicht. In dem grauen Bild sind teils Streifen drin, die ändern sich ein bisschen bei jedem Screenshot.

@typhos sagte:

Steht im Log von eusec eine Zeile "Event picture of device ... could not be decoded"?

Nein, da war nichts davon drin. Ich habe mal einen Teil des Logs angehangen:

eusec.0
2026-11-04 14:53:38.262	debug	[Object.write] [p2p] [P2PClientProtocol.handleDataControl] Handle DATA CONTROL - CMD_NOTIFY_PAYLOAD Livestream status [{"stationSN":"T8010N2320201304","payload":{"num":1}}]

eusec.0
2026-11-04 14:53:38.261	debug	[Object.write] [p2p] [P2PClientProtocol.handleDataControl] Station Handle DATA CONTROL - CMD_NOTIFY_PAYLOAD [{"stationSN":"T8010N2320201304","payload":"{\"cmd\":6246,\"payload\":{\"num\":1}}\u0000\u0000\u0000\u00001\u0000\u0000\u0000{\"cmd\":6"}]

eusec.0
2026-11-04 14:53:38.261	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA CONTROL - Processing sequence 248... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"CONTROL","seqNo":248}]

eusec.0
2026-11-04 14:53:28.355	debug	[Object.write] [push] [PushClient.handleHeartbeatAck] Push client - Heartbeat acknowledge [{"message":"{\"tag\":1,\"object\":{\"lastStreamIdReceived\":3}}"}]

eusec.0
2026-11-04 14:53:28.334	debug	[Object.write] [push] [PushClient.buildHeartbeatPingRequest] Push client - heartbeatPingRequest [{"streamId":3,"request":"{\"last_stream_id_received\":3}"}]

eusec.0
2026-11-04 14:53:28.334	debug	[Object.write] [push] [PushClient.sendHeartbeat] Push client - Sending heartbeat... [{"streamId":3}]

eusec.0
2026-11-04 14:53:26.981	debug	[Object.write] [p2p] [P2PClientProtocol.handleDataControl] Handle DATA CONTROL - CMD_SET_FLOODLIGHT_MANUAL_SWITCH [{"stationSN":"T8010N2320201304","enabled":false,"payload":"\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000"}]

eusec.0
2026-11-04 14:53:26.980	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA CONTROL - Processing sequence 247... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"CONTROL","seqNo":247}]

eusec.0
2026-11-04 14:53:15.696	debug	[euSec.onStateChange] state eusec.0.T8010P2320100018.cameras.T8114P0219521D94.charging_status changed: 0 (ack = true) was already acknowledged, ignore it...

eusec.0
2026-11-04 14:53:15.693	debug	[Object.write] [p2p] [P2PClientProtocol.handleDataControl] Handle DATA CONTROL - SUB1G_REP_UNPLUG_POWER_LINE [{"stationSN":"T8010P2320100018","payload":"\u0002\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000"}]

eusec.0
2026-11-04 14:53:15.693	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA CONTROL - Processing sequence 93... [{"stationSN":"T8010P2320100018","remoteAddress":"192.168.188.100","remotePort":15265,"dataType":"CONTROL","seqNo":93}]

eusec.0
2026-11-04 14:51:59.153	debug	[Object.write] [http] [Station.onCommandResponse] Station got p2p command response [{"station":"T8010N2320201304","commandType":1004,"channel":3,"returnCodeName":"ERROR_PPCS_SUCCESSFUL","returnCode":0,"customData":{"command":{"name":"deviceStopLivestream"}}}]

eusec.0
2026-11-04 14:51:59.153	debug	[Object.write] [p2p] [P2PClientProtocol.handleData] Handle DATA DATA - Result data for command received [{"stationSN":"T8010N2320201304","message":{"sequence":20,"commandType":1004,"channel":3,"acknowledged":true,"retries":0,"returnCode":0,"data":{"type":"Buffer","data":[209,0,0,20,88,90,89,72,236,3,16,0,0,0,1,0,3,1,0,0,229,117,150,171,130,139,13,76,239,198,64,238,81,151,135,137]},"customData":{"command":{"name":"deviceStopLivestream"}}},"resultCodeName":"ERROR_PPCS_SUCCESSFUL","resultCode":0}]

eusec.0
2026-11-04 14:51:59.153	debug	[Object.write] [p2p] [P2PClientProtocol.handleData] Handle DATA DATA - Received data [{"stationSN":"T8010N2320201304","seqNo":19,"commandIdName":"CMD_STOP_REALTIME_MEDIA","commandId":1004,"resultCodeName":"ERROR_PPCS_SUCCESSFUL","resultCode":0,"resultData":"0039000037230000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","data":"000000000039000037230000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","seqNumber":21,"p2pDataSeqNumber":20,"offsetDataSeqNumber":1}]

eusec.0
2026-11-04 14:51:59.153	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA DATA - Processing sequence 18... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"DATA","seqNo":18}]

eusec.0
2026-11-04 14:51:58.797	debug	[euSec.onStateChange] state eusec.0.T8010N2320201304.cameras.T8210P102013295F.livestream_rtsp changed: rtsp://192.168.188.124:8554/T8210P102013295F (ack = true) was already acknowledged, ignore it...

eusec.0
2026-11-04 14:51:58.755	debug	[euSec.onStateChange] state eusec.0.T8010N2320201304.cameras.T8210P102013295F.livestream changed: http://192.168.188.124:1984/stream.html?src=T8210P102013295F&background=false (ack = true) was already acknowledged, ignore it...

eusec.0
2026-11-04 14:51:58.753	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3490... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3490}]

eusec.0
2026-11-04 14:51:58.725	debug	[Object.write] [p2p] [P2PClientProtocol._sendCommand] Sending p2p command... [{"station":"T8010N2320201304","sequence":20,"commandType":1004,"channel":3,"retries":0,"messageStatesSize":1}]

eusec.0
2026-11-04 14:51:58.725	debug	[Object.write] [http] [Station.stopLivestream] Station stop livestream - sending command [{"stationSN":"T8010N2320201304","deviceSN":"T8210P102013295F"}]

eusec.0
2026-11-04 14:51:58.724	info	Stopping the livestream of device T8210P102013295F, because it reached the maximum duration of 30 seconds since the first picture

eusec.0
2026-11-04 14:51:58.673	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3489... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3489}]

eusec.0
2026-11-04 14:51:58.625	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3488... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3488}]

eusec.0
2026-11-04 14:51:58.609	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3487... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3487}]

eusec.0
2026-11-04 14:51:58.597	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3487... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3487}]

eusec.0
2026-11-04 14:51:58.546	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3486... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3486}]

eusec.0
2026-11-04 14:51:58.482	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3485... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3485}]

eusec.0
2026-11-04 14:51:58.450	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3484... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3484}]

eusec.0
2026-11-04 14:51:58.400	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3483... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3483}]

eusec.0
2026-11-04 14:51:58.370	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3482... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3482}]

eusec.0
2026-11-04 14:51:58.344	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3481... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3481}]

eusec.0
2026-11-04 14:51:58.273	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3480... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3480}]

eusec.0
2026-11-04 14:51:58.224	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3479... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3479}]

eusec.0
2026-11-04 14:51:58.193	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3478... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3478}]

eusec.0
2026-11-04 14:51:58.161	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3477... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3477}]

eusec.0
2026-11-04 14:51:58.114	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3476... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3476}]

eusec.0
2026-11-04 14:51:58.082	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3475... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3475}]

eusec.0
2026-11-04 14:51:58.052	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3474... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3474}]

eusec.0
2026-11-04 14:51:58.000	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3473... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3473}]

eusec.0
2026-11-04 14:51:57.984	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3472... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3472}]

eusec.0
2026-11-04 14:51:57.970	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3472... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3472}]

eusec.0
2026-11-04 14:51:57.924	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3471... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3471}]

eusec.0
2026-11-04 14:51:57.857	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3470... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3470}]

eusec.0
2026-11-04 14:51:57.825	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3469... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3469}]

eusec.0
2026-11-04 14:51:57.780	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3468... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3468}]

eusec.0
2026-11-04 14:51:57.745	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3467... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3467}]

eusec.0
2026-11-04 14:51:57.718	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3466... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3466}]

eusec.0
2026-11-04 14:51:57.665	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3465... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3465}]

eusec.0
2026-11-04 14:51:57.632	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3464... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3464}]

eusec.0
2026-11-04 14:51:57.601	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3463... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3463}]

eusec.0
2026-11-04 14:51:57.596	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3463... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3463}]

eusec.0
2026-11-04 14:51:57.537	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3462... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3462}]

eusec.0
2026-11-04 14:51:57.489	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3461... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3461}]

eusec.0
2026-11-04 14:51:57.456	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3460... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3460}]

eusec.0
2026-11-04 14:51:57.410	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3459... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3459}]

eusec.0
2026-11-04 14:51:57.410	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3458... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3458}]

eusec.0
2026-11-04 14:51:57.396	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA VIDEO - Processing sequence 3459... [{"stationSN":"T8010N2320201304","remoteAddress":"192.168.188.103","remotePort":15265,"dataType":"VIDEO","seqNo":3459}]

@typhos sagte:

Für Apple Home holt yahka den Stream per ffmpeg von der RTSP-Adresse

Die Kamera liefert keinen RTSP-Stream. Ein Stream wird nur unter http://192.168.188.124:1984/stream.html?src=T8210xyz&background=false angezeigt. Der RTSP-Stream gibt nichts aus, die Kamera kann auch kein RTSP.

@typhos sagte:

Welche Version von eusec und yahka nutzt du?

EUSEC: 3.6.2 (direkt von Git)
YAHKA: 1.1.6

@typhos sagte:

Was steht in yahka in "Source" und im Feld "FFMPEG Command Line - Stream"?

Da die Kamera kein RTSP kann, hab ich bei Source http://192.168.188.124:1984/stream.html?src=T8210xyz&background=false eingetragen.
FFMPEG Command Line - Stream geht auf den Standardwerten.

@typhos sagte:

Was gibt ffmpeg -version auf dem ioBroker-Rechner aus?

ffmpeg version 7.1.5-0+deb13u1 Copyright (c) 2000-2026 the FFmpeg developers
built with gcc 14 (Debian 14.2.0-19)
configuration: --prefix=/usr --extra-version=0+deb13u1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --disable-libmfx --disable-omx --enable-gnutls --enable-libaom --enable-libass --enable-libbs2b --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libglslang --enable-libgme --enable-libgsm --enable-libharfbuzz --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-openal --enable-opencl --enable-opengl --disable-sndio --enable-libvpl --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-ladspa --enable-libbluray --enable-libcaca --enable-libdvdnav --enable-libdvdread --enable-libjack --enable-libpulse --enable-librabbitmq --enable-librist --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libx264 --enable-libzmq --enable-libzvbi --enable-lv2 --enable-sdl2 --enable-libplacebo --enable-librav1e --enable-pocketsphinx --enable-librsvg --enable-libjxl --enable-shared
libavutil      59. 39.100 / 59. 39.100
libavcodec     61. 19.101 / 61. 19.101
libavformat    61.  7.103 / 61.  7.103
libavdevice    61.  3.100 / 61.  3.100
libavfilter    10.  5.100 / 10.  5.100
libswscale      8.  3.100 /  8.  3.100
libswresample   5.  3.100 /  5.  3.100
libpostproc    58.  3.100 / 58.  3.100

guitardoc

@typhos sagte:

Stell yahka auf Log-Stufe "debug..."

EUSEC meldet:


eusec.0
2026-11-04 15:06:44.943	debug	[euSec.onStateChange] state eusec.0.T8010P2320100018.cameras.T8114P0220032A09.charging_status changed: 1 (ack = true) was already acknowledged, ignore it...

eusec.0
2026-11-04 15:06:44.940	debug	[Object.write] [p2p] [P2PClientProtocol.handleDataControl] Handle DATA CONTROL - SUB1G_REP_UNPLUG_POWER_LINE [{"stationSN":"T8010P2320100018","payload":"\u0001\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000"}]

eusec.0
2026-11-04 15:06:44.939	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA CONTROL - Processing sequence 100... [{"stationSN":"T8010P2320100018","remoteAddress":"192.168.188.100","remotePort":15265,"dataType":"CONTROL","seqNo":100}]

eusec.0
2026-11-04 15:06:07.651	debug	[Object.write] [p2p] [P2PClientProtocol.handleDataControl] Handle DATA CONTROL - SUB1G_REP_UNPLUG_POWER_LINE [{"stationSN":"T8010P2320100018","payload":"\u0001\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000"}]

eusec.0
2026-11-04 15:06:07.651	debug	[Object.write] [p2p] [P2PClientProtocol.handleMsg] Received message - DATA CONTROL - Processing sequence 99... [{"stationSN":"T8010P2320100018","remoteAddress":"192.168.188.100","remotePort":15265,"dataType":"CONTROL","seqNo":99}]

YAHKA meldet:
yahka.pdf
Da ist jetzt alles drin, ich habe nicht nach der Kamera gefiltert.

@typhos sagte:

Was zeigt die Home-App genau: gar keine Kachel, die Kachel ohne Bild, oder hängt sie beim Öffnen des Live-Bilds?

Sie zeigt das graue "Vorschaubild", was nicht richtig ist. Wenn ich auf die Kamera drücke, dann zeigt sie weiter das graue Bild und dann passiert nichts weiter.

typhos

@guitardoc Danke für die Logs, damit ist der Stream klar.

Stream in Apple Home

Im yahka-Log steht bei jedem Versuch:

Error opening input file http://192.168.188.124:1984/stream.html?src=T8210P102013295F&background=false.
Error opening input files: Invalid data found when processing input

stream.html ist die Player-Webseite von go2rtc, kein Videostream. Der Browser kann sie anzeigen, ffmpeg kann damit nichts anfangen und bricht sofort ab. Deshalb bleibt die Home-App hängen.

Die Klingel selbst muss kein RTSP können. eusec holt das Bild per P2P von der HomeBase und stellt es über go2rtc als RTSP bereit. Das ist dieselbe Quelle, die du im Browser siehst. Die Adresse steht im Datenpunkt livestream_rtsp, laut deinem eusec-Log:

rtsp://192.168.188.124:8554/T8210P102013295F

Bitte trag genau diese Adresse in yahka bei "Source" ein. "FFMPEG Command Line - Stream" kann auf den Standardwerten bleiben.

Wie hattest du RTSP getestet, als nichts kam? Safari spielt rtsp:// gar nicht ab, und in VLC braucht die Klingel erst ein paar Sekunden zum Aufwachen. Am zuverlässigsten ist ein Test direkt auf dem ioBroker-Rechner:

ffmpeg -rtsp_transport tcp -i rtsp://192.168.188.124:8554/T8210P102013295F -frames:v 1 -y /tmp/klingel.jpg

Wenn danach in /tmp/klingel.jpg ein Bild der Straße liegt, funktioniert der Weg, den yahka nimmt.

Noch ein Hinweis: In deinem Log beendet eusec den Livestream nach 30 Sekunden ("maximum duration of 30 seconds"). Das ist die Einstellung "Maximale Livestream-Dauer der Kamera" in eusec, Standard sind 120 Sekunden. Mit 30 Sekunden endet auch das Live-Bild in der Home-App nach einer halben Minute.

Vorschaubild

Das Snapshot-Kommando nutzt laut Log schon das Ereignisbild aus eusec, das passt so. Das Problem ist das Bild selbst. Graue Fläche mit schrägen, gestrichelten Linien, die sich bei jedem Klingeln ändern: Das sieht danach aus, dass die Bilddaten echt sind, aber falsch zusammengesetzt wurden. Neuere eufy-Firmware schickt die Ereignisbilder mit verschlüsseltem Kopf. Die Bibliothek, die eusec nutzt, baut diesen Kopf nach und muss dabei die Bildgröße schätzen. Liegt sie daneben, läuft das Bild schräg und wird grau. Das ist bisher nur meine Vermutung.

Um das zu prüfen, brauche ich die Datei selbst, nicht einen Screenshot. Kannst du das Bild unter http://192.168.188.124:8082/eusec.0/T8010N2320201304/last_event/T8210P102013295F.jpg speichern und als ZIP anhängen? Als ZIP, damit das Forum das Bild nicht neu komprimiert. Am besten direkt nach einem Klingeln, dazu ein Screenshot desselben Ereignisses aus der eufy-App zum Vergleich.

Bis das gelöst ist, bleibt das Vorschaubild in der Home-App grau. Ein Snapshot aus dem Livestream würde die Klingel bei jeder Aktualisierung der Kachel wecken, das würde ich bei einer Akku-Klingel nicht machen.

guitardoc

Ich habe mal RTSP auf dem ioBroker-Rechner laufen gelassen, aber da kommen Fehler:

ffmpeg -rtsp_transport tcp -i rtsp://192.168.188.124:8554/T8210P102013295F -frames:v 1 -y /tmp/klingel.jpg
ffmpeg version 7.1.5-0+deb13u1 Copyright (c) 2000-2026 the FFmpeg developers
  built with gcc 14 (Debian 14.2.0-19)
  configuration: --prefix=/usr --extra-version=0+deb13u1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --disable-libmfx --disable-omx --enable-gnutls --enable-libaom --enable-libass --enable-libbs2b --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libglslang --enable-libgme --enable-libgsm --enable-libharfbuzz --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-openal --enable-opencl --enable-opengl --disable-sndio --enable-libvpl --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-ladspa --enable-libbluray --enable-libcaca --enable-libdvdnav --enable-libdvdread --enable-libjack --enable-libpulse --enable-librabbitmq --enable-librist --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libx264 --enable-libzmq --enable-libzvbi --enable-lv2 --enable-sdl2 --enable-libplacebo --enable-librav1e --enable-pocketsphinx --enable-librsvg --enable-libjxl --enable-shared
  libavutil      59. 39.100 / 59. 39.100
  libavcodec     61. 19.101 / 61. 19.101
  libavformat    61.  7.103 / 61.  7.103
  libavdevice    61.  3.100 / 61.  3.100
  libavfilter    10.  5.100 / 10.  5.100
  libswscale      8.  3.100 /  8.  3.100
  libswresample   5.  3.100 /  5.  3.100
  libpostproc    58.  3.100 / 58.  3.100
Input #0, rtsp, from 'rtsp://192.168.188.124:8554/T8210P102013295F':
  Metadata:
    title           : go2rtc/1.9.14
  Duration: N/A, start: 0.000000, bitrate: N/A
  Stream #0:0: Video: h264 (High), yuv420p(progressive), 640x480, 15 fps, 30 tbr, 90k tbn
  Stream #0:1: Audio: aac (LC), 16000 Hz, mono, fltp
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> mjpeg (native))
Press [q] to stop, [?] for help
Output #0, image2, to '/tmp/klingel.jpg':
  Metadata:
    title           : go2rtc/1.9.14
    encoder         : Lavf61.7.103
  Stream #0:0: Video: mjpeg, yuv420p(pc, progressive), 640x480, q=2-31, 200 kb/s, 15 fps, 15 tbn
      Metadata:
        encoder         : Lavc61.19.101 mjpeg
      Side data:
        cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: N/A
[image2 @ 0x61e9f9369e00] The specified filename '/tmp/klingel.jpg' does not contain an image sequence pattern or a pattern is invalid.
[image2 @ 0x61e9f9369e00] Use a pattern such as %03d for an image sequence or use the -update option (with -frames:v 1 if needed) to write a single image.
[out#0/image2 @ 0x61e9f9525600] video:70KiB audio:0KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown
frame=    1 fps=0.0 q=7.3 Lsize=N/A time=00:00:00.06 bitrate=N/A speed=3.22x

Es wurde die Datei aber richtig angelegt und zeigt auch das richtige Bild:
klingel.jpg.zip

Hier ist das graue Vorschaubild:
T8210P102013295F.jpg.zip

typhos

@guitardoc Danke, mit der Datei war der Fehler schnell gefunden.

RTSP

Das passt. Die Meldung "does not contain an image sequence pattern" ist nur ein Hinweis von ffmpeg zum Dateinamen. Das Bild wurde trotzdem geschrieben, und go2rtc liefert H.264 mit 640x480 und Ton. Hast du die Adresse rtsp://192.168.188.124:8554/T8210P102013295F inzwischen in yahka bei "Source" eingetragen? Wenn ja: Läuft das Live-Bild jetzt in der Home-App?

Vorschaubild

Deine Datei hat 288x176 Pixel, das echte Bild der Klingel aber 800x600. Die Ursache liegt in der Bibliothek, die eusec nutzt. Deine HomeBase 3 schickt das Ereignisbild direkt per P2P, nicht über die Cloud. Für diesen Weg nimmt die Bibliothek immer die Größe 288x176 an, statt die echte Größe zu ermitteln. Ein größeres Bild wird dadurch zeilenweise falsch zusammengesetzt, und es entsteht die graue Fläche mit den schrägen Streifen.

Dazu kam ein zweites Problem: Einen Teil der Bilddaten verschlüsselt eufy, darunter die Angaben zur Kompression. Die Bibliothek setzt dafür Standardwerte ein, die bei deiner Klingel nicht passen. Das Bild war dadurch auch in der richtigen Größe blass und grau wie im Nebel.

Aus deiner Datei konnte ich das richtige Bild wiederherstellen (die Straße vom 5.11. um 9:37 Uhr, mit der Mülltonne vorne rechts). eusec ermittelt jetzt die echte Größe selbst, schätzt die Kompression aus dem Bild und baut es neu auf, bevor es gespeichert wird. Ganz so scharf wie in der eufy-App wird es nicht werden, aber Farben und Kontrast stimmen. Das kommt mit der nächsten Version.

Testpaket

Wenn du es vorher ausprobieren möchtest, hier ein Testpaket:
iobroker.eusec-3.6.4-picture.1.zip

ZIP entpacken. Heraus kommt die Datei iobroker.eusec-3.6.4-picture.1.tgz. Den Dateinamen bitte nicht ändern, der Admin erkennt daran den Adapter.
Im Admin den Expertenmodus einschalten.
Unter "Adapter" erscheint dann oben das GitHub-Symbol "Installieren aus eigener URL". Darauf klicken.
Den Reiter "Aus Datei" wählen, auf "Datei auswählen" klicken und die .tgz-Datei angeben.
Den Haken bei "Adapter nach der Installation neu starten" setzen und auf "Installieren" klicken.

Danach einmal klingeln und etwa eine Minute warten. Das Bild wird erst gespeichert, wenn die Aufnahme beendet ist. Im Log von eusec sollte dann einmal die Zeile "... at a fixed 288x176. The adapter rebuilds it at its real size." stehen, und das Vorschaubild sollte die Straße zeigen. Sobald die nächste Version erscheint, kannst du sie ganz normal über den Admin installieren, sie ersetzt das Testpaket.

guitardoc

Yesss!!! Jetzt funktioniert das Vorschaubild, sowohl im Browser als auch in Home! Danke für die Anpassung!!!!

Aber der Stream kommt in Home nicht an. Wenn ich auf die Kamera klicke, dann dreht sich das Zahnrad und das wars. Im Browser wird der Stream von http://192.168.188.124:1984/stream.html?src=T8210P102013295F&background=false richtig angezeigt (seltsamerweise nicht immer in Safari, aber zuverlässig in DuckDuckGo auf dem Mac).

Der Stream unter rtsp://192.168.188.124:8554/T8210P102013295F wird jetzt auch auf VLC angezeigt (das war in der letzten Version nicht der Fall), aber nicht in Home. Dort dreht sich nur das Zahnrad im Vorschaubild.

Hast du noch eine Idee, woran das liegen könnte?

typhos

@guitardoc Schön, dass das Vorschaubild jetzt passt, danke fürs Testen!

Dass der Stream in VLC jetzt läuft, liegt wahrscheinlich an Korrekturen beim Öffnen und Schließen des Streams, die seit 3.6.2 dazugekommen sind und im Testpaket stecken. Wichtig ist: Die Quelle ist in Ordnung. Das Problem liegt also zwischen yahka und der Home-App.

1. Ton in yahka

Ist bei der Kamera in yahka "Audio aktivieren" angehakt? Dann hängt yahka an das ffmpeg-Kommando einen Teil für den Ton an, und der nutzt den Encoder libfdk_aac. Den hat das ffmpeg von Debian nicht, er fehlt in der Konfigurationszeile aus deinem Test. ffmpeg bricht dann sofort ab, und die Home-App wartet vergeblich auf das Bild.

Im ioBroker-Log steht in dem Fall eine Fehlermeldung von yahka wie:

[Video] ffmpeg exited with code: ... (error)

Zum Testen bitte "Audio aktivieren" ausschalten, speichern und noch einmal in der Home-App auf die Kamera tippen. Kommt dann das Bild (ohne Ton), war es das.

2. RTSP über TCP

Dein Test von gestern lief mit -rtsp_transport tcp, das Standardkommando von yahka hat diese Option nicht. Damit yahka genau den Weg nimmt, den du getestet hast, trag bitte unter "FFMPEG Command Line - Stream" vor "-i", noch diese Zeile ein:

"-rtsp_transport", "tcp",

3. Aufwachzeit

Die Klingel schläft und braucht nach dem Antippen einige Sekunden, bis das erste Bild kommt. Wenn es mit 1. und 2. immer noch nicht geht, mach bitte diesen Test: zuerst den Stream im Browser öffnen, damit die Klingel wach ist, und dann direkt in der Home-App auf die Kamera tippen. Geht es dann, dauert das Aufwachen der Home-App zu lange.

Falls nichts davon hilft

Dann bräuchte ich das Log von yahka während eines Versuchs:

Im Admin unter "Instanzen" bei yahka die Protokollstufe auf "debug" stellen.
In der Home-App auf die Kamera tippen und warten, bis sie aufgibt.
Das Log aus diesem Zeitraum anhängen. Wichtig sind die Zeile "Stream run: ffmpeg …" und die Zeilen mit "FFMPEG:" danach. Dazu bitte die Zeilen von eusec aus derselben Zeit, damit ich sehe, wann die Klingel wach war.

Danach die Protokollstufe wieder zurückstellen, sonst wird das Log sehr groß.

Community Forum

NEWS

Test Adapter eusec 3.x.x

Support us

405

33.1k

84.2k

1.4m