[gelöst] Eigenartig Motioneye Verhalten nach Bookworm Upd

[Pedder007]

@haselchen @Armilar @dp20eic was habe ich da nur losgetreten!?

Also ich denke hier ist was für jeden dabei und das meine Systeme immer ALLE up-to-date sind und man nicht auf root rum-hobelt, dass habe ich spätestens auch hier im Forum nochmal gelernt, wobei das für mich auch immer schon klar war.
Aktuell kann ich den Bullseye Container ja noch eine Weile updaten und mein ganzes Setup, bis auf evtl. der blöde Saugroboter und der Rasenmäher, kommt hier auch weitestgehend gut ohne Cloud klar. Ich treibe was solche Dinge angeht auch netzwerkseitig schon entsprechenden Aufwand (Unifi mit USG Pro 4 Gateway) mit eigenem IOT VLAN und ggf. zusätzlicher Definitionen, welche Einzelclients oder Gruppen hier nicht mit dem WWW sprechen dürfen, bzw. ggf. gar nicht aus dem VLAN heraus kommen.
Die Awareness dazu ist bei mir über viele Jahre berufsseitig gewachsen und wir hatten hier, in einem 5-Personen Haushalt, bisher noch nicht einen einzigen Malware oder Pishing Fall, weil ich es hier auch ununterbrochen predige

Also für mich ist alles gut und evtl. können wir am 18.ten ja in Solingen darüber sprechen

PS.
Und @liv-in-sky , ich werde das auch mal mit einer Neuinstallation versuchen. Entsprechender Bookworm Container steht schon

[haselchen]

@pedder007 sagte in Eigenartiges Motioneye Verhalten nach Bookworm Update:

@haselchen @Armilar @dp20eic was habe ich da nur losgetreten!?

Genauso sollte ein Thread sein.
Vernünftige Erklärungen , Sichtweisen...
So macht Gedankenaustausch Spass!

Mit Solingen muss ich meine Frau noch überzeugen

[Armilar]

@pedder007 sagte in Eigenartiges Motioneye Verhalten nach Bookworm Update:

Also für mich ist alles gut und evtl. können wir am 18.ten ja in Solingen darüber sprechen

Ich habe es auf dem Plan, kann es aktuell aber noch nicht zu 100% zusagen. Aber schön wär's

[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

hakova created this issue in motioneye-project/motioneye

closed Please update installation instructions for Debian 12 bookworm #2780

[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

[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