[gelöst] Eigenartig Motioneye Verhalten nach Bookworm Upd
-
@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 istumgestiegen von Proxmox auf Unraid
-
@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 -
@crunchip Die zweite Ist nur Die Alarm Info, und ein Hperlink zur Motioneye Web Ui (zur live Ansicht)
-
@martink setz mal deinen trigger auf "wurde geändert"
umgestiegen von Proxmox auf Unraid
-
@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...konnte ich helfen ? Dann würde ich mich über ein Voting freuen ! (rechts unten)...
-
@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@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
umgestiegen von Proxmox auf Unraid
-
@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
@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 ;-)
...konnte ich helfen ? Dann würde ich mich über ein Voting freuen ! (rechts unten)...
-
@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 ;-)
@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
umgestiegen von Proxmox auf Unraid
-
@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
@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 😎
...konnte ich helfen ? Dann würde ich mich über ein Voting freuen ! (rechts unten)...
-
@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 😎
@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.umgestiegen von Proxmox auf Unraid
-
@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.Ich nutze das ähnlich schon lange.
Mein wget sieht aber so auswget -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.
-
Ich nutze das ähnlich schon lange.
Mein wget sieht aber so auswget -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.
@david-g sagte in [gelöst] Eigenartig Motioneye Verhalten nach Bookworm Upd:
Ich nutze das ähnlich schon lange.
Mein wget sieht aber so auswget -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 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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register LoginSupport us
546
Online32.7k
Users82.6k
Topics1.3m
Posts