@wendy2702

Ok, dann bleibt es wohl so...

Danke nochmals für eure Unterstützung

@wendy2702

Hast du bei dir auch Reolink-Kameras verbaut?

@wendy2702 sagte in Bildversand der Kamera per Pushover sehr unzuverlässig.:

Hast du mal bei (https://www.ispyconnect.com/de/cameras) geschaut welche Links deine Kamera denn können soll?

Leider wird meine Reolink W520 hier gar nicht aufgelistet. Die zweite Kamera "TrackMix Wifi" wird zwar aufgelistet, doch es wird der nachfolgende Fehler ausgegeben:

URL: http://192.168.178.189/videostream.cgi?user=iobroker&pwd=Pass1234&resolution=32&rate=0
Antwort: [ { "cmd" : "Unknown", "code" : 1, "error" : { "detail" : "not support", "rspCode" : -9 } } ]

@wendy2702 sagte in Bildversand der Kamera per Pushover sehr unzuverlässig.:

EDIT: die ONVIF Links bei mir sind alle "rtsp" auch wenn request per HTTP erfolgt. Somit laufen die im Browser nicht.

Sieht dies bei dir unter den Objekten auch so aus, also http://192.168.178.188:55/rtsp/h264Preview_01_main?

@wendy2702

Man hat schlussendlich wieder eine Fehlerquelle mehr, die zudem unnötig gepflegt werden muss.
Kennst du den onvif-Adapter von IOBroker? Weisst du, ob dies eher allgemeine URLs sind, die nicht von jeder Kamera unterstützt werden oder sind dies URLs, welche von genau dieser Cam zur Verfügung gestellt werden (und auch funktionieren müssten)?

@wendy2702

Wie ich gerade entdeckt habe, müsste gemäss dem Onvif-Adapter (IOBroker) eine http-URL (http://192.168.178.188:80/rtsp/h264Preview_01_sub) vorhanden sein, doch wenn ich diese URL im Browser bzw. in der VIS aufrufe, erscheint gar nichts (weder eine Fehlermeldung, noch sonst ein Hinweis).
Die URL inkl. Zugangsdaten im Format http://IOBroker:pass1234@192.168.178.55:80/rtsp/h264Preview_01_main zeigt genau dasselbe Verhalten, obwohl der Snapshot mit http://IOBroker:pass1234@192.168.178.55/cgi-bin/api.cgi?cmd=onvifSnapPic&channel=0 einwandfrei dargestellt wird.
Temporär habe ich noch versucht, die Firewall und Antivirus von meinem Win-Tablet zu deaktivieren -> ohne Erfolg.
Füge ich den Stream im go2RTC ein, wird hier mse: stream: 405 Method Not Allowed angezeigt.

Hat noch jemand einen Tipp für mich? Es wäre natürlich ideal, wenn man sich den Umweg über go2RTC sparen könnte...

@bahnuhr

Danke für deinen guten Hinweis und entschuldige meine verspätete Rückmeldung!

Irgendwie scheint doch go2RTC das Problem zu verursachen. Aktiviere ich nämlich in der Reolink-Kamera das http und gebe bei GetHttp den passenden http-Link für den Aufruf des direkten Kamera-Streams an, scheint es (bis jetzt) wie gewünscht zu funktionieren. Einziger kleiner Nachteil: Man muss im Link den Benutzernamen und das Passwort fürs Kamera-Login im Klartext mitgeben. Ich hoffe, dass diese Daten mein privates Netz nicht verlassen werden…
Anbei noch den bei mir funktionierenden Javascript-Code, falls es für jemanden relevant sein sollte:

        httpGet(`http://192.168.178.188/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPhkmUCeI9WG7C&user=IOBroker&password=123456`, { responseType: 'arraybuffer' }, (err, response) => {
            if (err) {
                console.error(err);
            } else {         
                sendTo("pushover.0", { message: varText, sound: varSound, title: varTitel, priority: varPrio, file: { name: varTitel, data: response.data } });
            }
        });

Den Stream für die IOBroker VIS muss ich wohl nach wie vor übers go2RTC führen. Ich nehme nicht an, dass es mittlerweile möglich ist, den rtsp-Stream direkt in der VIS anzeigen zu lassen, oder?

Hallo zusammen.

Ich hoffe, man kann mir hier auf die Sprünge helfen.

Thema: Bild der Reolink-Kamera per Pushover versenden.

Vorher: Raspberry Pi mit angeschlossener Fisheye-Cam und MotionEye. Funktion sehr gut und schnell, Bildqualität eher mager und keine Nachtsicht.
Jetzt: Reolink W520, per go2RTC wird ein Live-Stream in IOBroker-VIS dargestellt und wird zusätzlich für Snapshots verwendet, um beim Klingeln an der Haustür ein Bild per Pushover zu versenden. Dafür wird das Bild zuerst auf dem Raspberry Pi 5 gespeichert, 10 Sek später per Pushover versendet und 15 Sek. danach die Datei noch mit dem korrekten Zeitstempel versehen.
Go2RTC läuft als Docker auf meinem Synology NAS.

Aktuelle Probleme: Oftmals wird kein Bild versendet. Gefühlsmässig geht jetzt noch weniger, als vor meinen "Versuchen"...

Test-Versuche zur Optimierung:

• Unterschiedliche Streaming-Formate, welche im go2RTC ausgewählt werden können.
• Die Zeit fürs Abspeichern erhöht (bevor das Bild versendet wird).
• Den Sub- statt den Mainstream ausgewählt (geringere Bildqualität).
• Die Kamera per LAN angeschlossen.
• Verschiedene Varianten des Stream-Linkes ausprobiert, die ich so im Netz gefunden hatte (Hochkomma, Anführungszeichen, Slash):
  o exec('wget --output-document /opt/iobroker/iobroker-data/Pics/PicHE.jpg 'http://192.168.178.188:1984/api/frame.jpeg?src=Kamera_HE_MainStream'');
  o exec('wget --output-document /opt/iobroker/iobroker-data/Pics/PicHE.jpg "http://192.168.178.73:1984/api/frame.jpeg?src=Kamera_HE_MainStream");
  o «Dieselben Links per http sowie https
• Anderen Speicherpfad (/tmp) ausgewählt.
• Das Bild nicht vom go2RTC-Stream geholt, sondern direkt von der CAM per:
  o http://192.168.178.188/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPhkmUCeI9WG7C&user=IOBroker&password=1234
  o https://192.168.178.188/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPhkmUCeI9WG7C&user=IOBroker&password=1234
  o In den CAM-Settings ist http und https aktiviert.
  o Hiermit scheint es noch unzuverlässiger zu funktionieren, als beim Abholen vom go2RTC-Stream. Teilweise sind die Bildgrössen zwischen 0 und 2KB gross und können nicht geöffnet werden.
• Alle 3 Systeme (Cam, IOBroker, Docker-Container) wurden mehrmals neu gestartet.

Bin ich eigentlich der Einzige, der mit solchen Problemen zu kämpfen hat?

Was könnte man noch versuchen, um das Bild zuverlässig per Pushover zu senden?

@oliverio
Das mit der "select Liste" macht die ganze Sache leider nicht einfacher...
Aber somit bleibt mir nichts anderes übrig, als die überlagerten Widgets für VIS-Änderungen zu verschieben.

Falls sonst noch Tipps bekannt sind, nehme ich dies natürlich gerne noch entgegen...

Man(n) dankt

@oliverio
Danke für deine Rückmeldung.

Wahrscheinlich bringt dies noch nicht ganz den gewünschten Erfolg - oder ich verstehe deine Schilderungen noch nicht genau. Auch wenn mein Bildschirmschoner-Widget gesperrt ist, bleibt es im Vordergrund und überdeckt im Editier-Modus alle anderen Widgets.
Im Prinzip wäre das Ideale, wenn sich das Bildschirmschoner- und Kamera-Widget im Editiermodus rechts neben den anderen Widgets befinden würde und im Normalbetrieb per Anpassung der "Left-Koordinate" mit Verändern der entsprechenden Variable über die restlichen Widgets verschieben würde:

Hierbei zeigt sich jedoch das Problem, dass sich das Widget bei eingetragener Variable (in geschweiften Klammern) stets bei 0px ansiedelt und demnach wieder alle Widgets im Editiermodus überlagert - egal, welcher Wert die Variable in geschweifter Klammer besitzt.

Tag zusammen.

Aktuell werden in meiner Visualisierung bald täglich Änderungen vorgenommen. Dabei stört mich mein schwarzer "Bildschirmschoner" und weitere Widgets, welche ich für die Bearbeitung stets zur Seite schieben muss.
Genauer erklärt, ist folgender Aufbau vorhanden:

• Meine Visualisierung wird mit einem Widget (schwarze Fläche) als Bildschirmschoner überlagert.
• Findet keine Bewegung bei den Bewegungsmeldern statt, wird dieser Bildschirmschoner nach einigen Minuten in den Vordergrund geschoben und überdeckt die restlichen Widget.
• Bei erkannter Bewegung verschwindet der BSS wieder in den Hintergrund.

Dafür ist ein Objekt für den "z-Index" des Widgets definiert und mit geschweifter Klammer im Widget verlinkt worden. Das Ein- und Ausblenden des BSS funktioniert soweit 1A und vermeidet damit das "Einbrennen" der VIS im Tablet-Display.
Das störende daran ist, dass bei jeder Änderung in der Visualisierung dieser Bildschirmschoner (und weitere Widgets wie Kamera usw.) zuerst verschoben werden müssen. Das Verschieben der Widgets mit der Maus bringt dann wieder weitere Probleme mit sich, die hier jedoch keine Relevanz haben.
Die Frage bleibt, ob eine Möglichkeit besteht, das BSS-Widget im Bearbeitungsmodus immer im Hintergrund zu behalten, damit dieses nicht für jede kleine Bearbeitung wieder verschoben werden muss.

Auch das Ausblenden über die "Sichtbarkeit" des Widgets scheint nicht wie gewünscht zu funktionieren.
Als weiteren Versuch habe ich den Bildschirmschoner auf ein separates View verschoben. Hierbei entsteht wiederum der Nachteil, dass wenn es vom Bildschirmschoner auf das Haupt-View wechselt, die Ladezeit relativ lange dauert und die etwas "ungeduldigen" Haus-Bewohner zu lange vor dem Tablet warten müssen.

Wer kennt hier noch eine Alternative? Das ständige Ausschalten und Einschalten über FullyKiosk möchte ich vermeiden, denn auch hier benötigt der Aufwachprozess + Aktualisierung der VIS einfach zu lange...

Gruss & Dank

Auch bei mir bestünde Interesse an einer Möglichkeit, den Videostream von meinem bestehenden Gesichtserkennungsterminal (HHG VILLA AP 1 AS FI) in meiner IOBroker-Visualisierung anzuzeigen. Idealerweise würde das Gateway eine URL zur Verfügung stellen, die in einem Widget eingefügt werden könnte.

Bei HomeAssistant scheint es hier bereits eine Möglichkeit zu geben, obwohl es ein anderes Gateway zu sein scheint:
https://github.com/timniklas/hass-ilifestyle

Für mein Terminal wird wohl das Villa AV-Link Gateway notwendig sein. Wahrscheinlich wird vieles ähnlich sein.
Doch ein Kauf des GWs macht für mich erst dann Sinn, wenn ich dies in den IOBroker einbinden kann. Die Cloud-Zwänge sind heute extrem lästig geworden. Und zudem sind dies sicherheitsrelevante Projekte, die meiner Meinung nach das interne Netzwerk nicht verlassen sollten (Türöffnung).

Wie gross ist denn die Wahrscheinlichkeit, ohne grosses Umflashen zu einer Lösung zu kommen?