UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[FredF]

Bei motioneye scheint es weiterzugehen: https://github.com/motioneye-project/motioneye/releases

[Pedder007]

@fredf danke für den Hinweis, das ist gut zu sehen :+1:

[MartinK.]

Hallo Freunde, ich hänge mich hier nochmal mir rein, da ich nicht noch einen MotionEye Thema eröffnen möchte.

Habe ME in einem Proxmox super am laufen, jedoch gibt es beim Versand von meinem Snapshot über das Blockly Skript immer ein kleines Problem. Der Snapshot wir fast immer erst nach dem zweiten oder dritten mal des auslösen des Triggers erfolgreich erstellt und an Telegram versendet, obwohl ich Timeouts zum kopieren des Fotos von Kamera zu ioBroker gesetzt habe.

Beim ersten Versuch wird mir immer diese Fehlermeldung im Log ausgegeben.

Es scheint so, als ob irgendwo ein Dienst oder Service erst nach dem 2. Versand aufwacht, und die Snapshot.JPG wird dann erst erstellt.

(MotionEye + ioBroker laufen in zwei separaten LXC-Containern)
Hier ist noch ein Screenshot des Blockly

Hat jemand einen Tip für mich ?
Lägere Timeouts helfen auch nicht ?

[crunchip]

@martink mach mal beim exec block mit Ergebnisse
Lass den unteren timeout weg, den brauchst du dadurch nicht.

[MartinK.]

@crunchip Du meinst so ? oder ganz ohne timeout ? Hat leider keine Besserung gebracht.

[crunchip]

@martink den timeout kannst du ganz weglassen
Was ist das für eine 2te telegram Meldung?
Die obere sendet das geholte Bild sobalt es vorhanden ist

[MartinK.]

@crunchip Die zweite Ist nur Die Alarm Info, und ein Hperlink zur Motioneye Web Ui (zur live Ansicht)

[MartinK.]

@crunchip selbst wenn ich es ohne den zweiten Telegram Befehl mache, klappt es immer erst nach der 2. Triggerauslösung

irgendwo hängt das was fest, das es erst beim 2. mal durchgereicht wird

[crunchip]

@martink setz mal deinen trigger auf "wurde geändert"

[MartinK.]

@crunchip sagte in [gelöst] Eigenartig Motioneye Verhalten nach Bookworm Upd:

@martink setz mal deinen trigger auf "wurde geändert"

nee, der Trigger ist nicht das Problem. Das funzt alles, der löst ja laut debug immer zu 100% richtig aus.

Das Problem ist, das scheinbar die Datei nicht beim ersten Durchgang korrekt erstellt / kopiert wird
das besagt zumindest die Fehlermeldung:

Failed sending [chatId - 857222839]: Error: ETELEGRAM: 400 Bad Request: file must be non-empty

Wenn ich dann ein paar mal hintereinander der Trigger auslöse, kommt auch immer das Foto.
Irgendwo klemmt da beim kopieren der Bilddatei auf den iobroker irgendetwas

[crunchip]

@martink sagte in [gelöst] Eigenartig Motioneye Verhalten nach Bookworm Upd:

Das Problem ist, das scheinbar die Datei nicht beim ersten Durchgang korrekt erstellt

dann würde gar keine telegram Nachricht raus gehen, dafür ist ja der Haken drin, dieser sorgt dafür das erst telegram ausgelöst wird wenn Bild vorhanden

@martink sagte in [gelöst] Eigenartig Motioneye Verhalten nach Bookworm Upd:

der Trigger ist nicht das Problem.

ich glaube schon, denn auf wahr wird auch bei aktualisierung getriggert, folglich möglicherweise zu oft, was dann auch zu

@martink sagte in [gelöst] Eigenartig Motioneye Verhalten nach Bookworm Upd:

ETELEGRAM: 400 Bad Request: file must be non-empty

führt

[MartinK.]

@crunchip naja auch ohne Auswahl "senden mit Ergebnis" es das gleiche verhalten, und der gleiche Fehler beim ersten mal Trigger auslösen.

Auch wenn ich den Datenpunkt manuell nur 1x auslöse.
Habe das Skript nochmal neu ein einem separaten Blockly ohne weitere Telegram Implementation aufgebaut, nur das Foto senden, same shit...

Der Fehler muss woanders liegen.
Ich habe das absolut gleiche Blockly 2 Jahre genau so genutzt.. ohne Probleme.
Erst seitdem der ioBroker und MotionEye auf zwei separaten LXC Containern läuft ist es so.

Irgendwo sitzt da noch ein klemmer ;-)

[crunchip]

@martink sagte in [gelöst] Eigenartig Motioneye Verhalten nach Bookworm Upd:

naja auch ohne Auswahl "senden mit Ergebnis" es das gleiche verhalten

da musst du mit timeout arbeiten und da können 1500ms zu kurz sein

[MartinK.]

@crunchip Also nach einigen Test habe ich jetzt heraus gefunden, das es MotionEye in dem CT Container ist, der einfach gefühlt in den Ruhezustand fällt. Sobald ich mich auf der Web UI eingeloggt habe, und die Cam Streams ansehe, klappt auch das Bilder senden zu 100%. Jedes mal !

Auch wenn man auf die Web UI von MotionEye geht, braucht es ca. 2 sek. bis die Streams angezeigt werden. Und das ist genau der Zeitraum wo die Bilder nicht gesendet werden. :-) Wenn ich jetzt noch wüsste, wie ich diese Latenz ausgleichen kann, wäre es perfekt ;-) Ich könnte 2x eine Snapshot anfrage hintereinander stellen, dann würde es gehen.. Wäre aber ein unschöner Workaround 🧐 ... CPU + Speicher Langweilen sich vom MotionEye Container, da klemmt es schonmal nicht . Da muss ich wohl die Proxmox Nerds fragen, schätze ich 😎

[crunchip]

@martink da ich den wget Befehl aus deinem blockly nicht kenne, kann ich dazu nichts sagen, theoretisch kannst du da direkt einen snap der cam holen, dazu brauchst du kein motioneye. Voraussetzung, es gibt wine snap url der cam.

Es gibt keinen Ruhemodus in motioneye, entweder der Dienst läuft oder nicht.
Generell gibt es Probleme mit der Latenz, welches zum Problem führt, das die Bilder zeitversetzt sind, daher wäre ein direkter snap eh sinnvoller.

[David G.]

Ich nutze das ähnlich schon lange.
Mein wget sieht aber so aus

wget -O /opt/iobroker/snapshot/bild.jpg 'http://192.168.99.93/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPhkmUCeI9WG7C&user=******&password=*****&width=3840&height=2160'

Die URL ist natürlich bei dir anders. Macht natürlich Sinn einen Snapshot vom der Cam zu holen anstatt motioneye.

[MartinK.]

@david-g sagte in [gelöst] Eigenartig Motioneye Verhalten nach Bookworm Upd:

Ich nutze das ähnlich schon lange.
Mein wget sieht aber so aus

wget -O /opt/iobroker/snapshot/bild.jpg 'http://192.168.99.93/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPhkmUCeI9WG7C&user=******&password=*****&width=3840&height=2160'

Die URL ist natürlich bei dir anders. Macht natürlich Sinn einen Snapshot vom der Cam zu holen anstatt motioneye.

Dieser Tip hat die Lösung gebracht ! Vielen Dank! Oftmals sieht man den Wald vor lauter Bäumen nicht mehr ;-)

[MartinK.]

@crunchip Dieser Tip hat die Lösung gebracht ! Vielen Dank! Oftmals sieht man den Wald vor lauter Bäumen nicht mehr 😉