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

[Pedder007]

@liv-in-sky so, ich habe das nun auch so hinbekommen, wobei ich im Container irgendwie noch eine zusätzliche 'Kinke' hatte.
Meine Berechtigungsstruktur gab es nicht her, dass motioneye sein motion.pid file im Ordner /run ablegen durfte.

Ich habe meinen entsprechenden Workaround dann mal hier:
https://github.com/motioneye-project/motioneye/issues/2780#issuecomment-1789318667
für 'Gott und die Welt' dokumentiert.

Jetzt läufts, auch nach Container-Neustart und ich kann meine Bookworm Umgebung schön aktuell (und sicher ;-) ) halten.

Achso: Und das Geflacker ist damit tatsächlich beseitigt :-) :+1:

[crunchip]

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

Achso: Und das Geflacker ist damit tatsächlich beseitigt

Hab ich doch gesagt

[maloross]

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

Falls jemand diese Entscheidung trifft, hätte ich sicherlich einige Ratschläge zur Vorgehensweise und zu den Einstellungen

Nutze ebenfalls Motioneye und bin auch nicht mehr ganz so zufrieden damit, daher probiere ich Shinobi aus.
Die Containerinstallation läuft, Bild einwandfrei, ich scheitere aber tatsächlich an der Einbindung in VIS-2. API mit voller Zugriffsberechtigung erstellt, iFrame nach folgendem Schema eingerichtet:

http:// Shinobi-Container:32780 / [API] / embed / [Group-ID] / [Monitor-ID]

Angezeigt wird mir jedoch nur ein graues Feld, wo habe ich den Fehler oder welche Einstellungen muss ich anpassen?

[Armilar]

@maloross

Unter Home/Monitore:

werden die Monitore aufgelistet

unter "Copy Stream URL" ziehe ich die URL für den Browser
Wenn die im Browser aufgerufen werden kann, ist sie auch im VIS nutzbar

[maloross]

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

unter "Copy Stream URL" ziehe ich die URL für den Browser

Danke - hatte erst nicht funktioniert, dann habe ich festgestellt, dass als Stream Type "Poseidon" eingestellt war. Jetzt läuft es.
Sieht in der Grundeinstellung ganz gut aus, werde jetzt einmal mit den Einstellungen experimentieren.

[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.