Nochmal eine Ergänzung zum "Refresh Problem" beim Fully und iobroker.vis zum Nachdenken.

Anwendungsfall: Der Bildschirm wird automatisch nach 120s Inaktivität ausgeschaltet und dann händisch nach ca. 15 min wieder eingeschaltet.

Ich habe hier zwei Tablets zum direkten Vergleich, die auf dieselbe Vis zugreifen.
Beim älteren Nexus 10 läuft Android Webview v.60. Beim händischen Aufwecken wird die Vis im Fully nach ca. 1s unbemerkt aktualisiert und das Tablet lässt sich problemlos bedienen. Soweit alles gut.
Beim neuen Samsung Tab A (T510) ist Android Webview v.77 vorinstalliert, noch tiefer downgraden geht nicht. Beim händischen Aufwecken wird die Vis angezeigt und auch die darauf befindlichen Werte aktualisiert. Nach ca. 5s kommt aber in der Mitte eine kleiner weißer Kreis und ein Timer zählt runter 5...4...3...2....1... und bei 0 wird die gesamte Seite aktualisiert. In dieser Zeit lässt sich die Vis nicht bedienen. Es gibt am oberen Rand keinen Ladebalken, wie es z. B. bei einem Refresh durch Fully geschieht.
Auf beiden Tablets ist die derzeit aktuellste Fully v1.40.1 installiert.

Ich schlussfolgere daraus, dass bei diesem Refresh mit dem Kreis und ohne Ladebalken die Ursache tatsächlich in der aktuelleren Android Webview liegt.

Für mich ist ein Tablet mit dem Refresh Problem nicht benutzerfreundlich und daher nicht praktikabel.

Eine Lösung, die ich sehe, ist die Screensaver Funktion von Fully. Die klappt super und die Vis wird beim Aufwecken immer sofort und aktuell angezeigt. Diese Lösung hat allerdings auch Nachteile. Das Tablet verbraucht mehr Strom, was für mich noch ok ist, da sich der Verbrauch in Grenzen hält. Beim Nexus 10 habe ich allerdings im Probelauf von ca. 6 Wochen festgestellt, dass das Display einen Gelbstich bekommen hat, was nicht gut ist. Ich vermute das kommt daher, dass das Display nur gedimmt wird und permanent an ist und dadurch vielleicht der Verschleiß hoch ist. Andererseits ist das Nexus 10 auch schon ein paar Jahre alt, wurde aber kaum benutzt.

Habt ihr ähnliche Erfahrungen gemacht?
Oder habt ihr vielleicht einen anderen Lösungsansatz für dieses Problem?

Was mir noch einfällt: Dieser Kreis mit dem Countdown kommt doch von der Vis, oder? Vielleicht lässt sich da noch eine Lösung finden.

@glasfaser
Das werde ich mal ausprobieren und dann hier eine Rückmeldung geben.

Ich vermute aber mal, dass das Verhalten das gleiche sein wird, da die TCP Verbindung abläuft und der Stream auf der VIS dadurch stoppt. Die Kameras senden nämlich nur bei einer Bewegungserkennung, wodurch mehrere Stunden kein Stream gesendet wird. Ist aber nur eine Vermutung.

Startet bei dir auch der Stream auf der VIS wieder automatisch, wenn der Kamera-Stream mind. 60min gestoppt wurde?

Hallo zusammen,
ich habe ein Herausforderung, bei der ich einfach nicht mehr weiterkomme.
Wie kann ich (per Skript) ein einzelnes Widget statt der gesamten View aktualisieren lassen?

Ich habe einen Videostream, der aber nicht permanent läuft. Sobald der Kamera-Stream stoppt, stoppt auch der VIS-Stream. Wenn der Kamera-Stream weiterläuft, dann startet der VIS-Stream nicht mehr. Erst wenn ich die gesamte View neustarte (bzw. die Website refreshe), dann läuft der VIS-Stream weiter.
Ich habe ein Objekt/Variable in iobroker, dass auf true oder false gesetzt wird, wenn der Stream startet oder stoppt. Dieses Objekt könnte als Trigger für ein Skript genutzt werden.

Ich weiß, dass ich das Widget z. B. alle 100ms Refreshen lassen kann, aber das funktioniert nicht und schießt die Kamera mit diversen neuen Anfragen zu und sieht auch nicht mehr flüssig aus. Ist also keine valide Option.

Hier der Export des Widgets:

[{"tpl":"tplMfdCamSnapshot","data":{"g_fixed":false,"g_visibility":false,"g_css_font_text":false,"g_css_background":false,"g_css_shadow_padding":false,"g_css_border":false,"g_gestures":false,"g_signals":false,"g_last_change":false,"visibility-cond":"==","visibility-val":1,"visibility-groups-action":"hide","asButton":"true","interval":"0","dialog_width":"1200","dialog_height":"760","signals-cond-0":"==","signals-val-0":true,"signals-icon-0":"/vis/signals/lowbattery.png","signals-icon-size-0":0,"signals-blink-0":false,"signals-horz-0":0,"signals-vert-0":0,"signals-hide-edit-0":false,"signals-cond-1":"==","signals-val-1":true,"signals-icon-1":"/vis/signals/lowbattery.png","signals-icon-size-1":0,"signals-blink-1":false,"signals-horz-1":0,"signals-vert-1":0,"signals-hide-edit-1":false,"signals-cond-2":"==","signals-val-2":true,"signals-icon-2":"/vis/signals/lowbattery.png","signals-icon-size-2":0,"signals-blink-2":false,"signals-horz-2":0,"signals-vert-2":0,"signals-hide-edit-2":false,"lc-type":"last-change","lc-is-interval":true,"lc-is-moment":false,"lc-format":"","lc-position-vert":"top","lc-position-horz":"right","lc-offset-vert":0,"lc-offset-horz":0,"lc-font-size":"12px","lc-font-family":"","lc-font-style":"","lc-bkg-color":"","lc-color":"","lc-border-width":"0","lc-border-style":"","lc-border-color":"","lc-border-radius":10,"lc-zindex":0,"icon":"https://camera.abc.de/101/stream","url":"https://camera.abc.de/101/stream","alt":"Garage","text":"","title":"Garage"},"style":{"left":"25px","top":"395px","width":"607px","height":"341px"},"widgetSet":"jqui-mfd"}]

Ursache gefunden.
Ich rufe die VIS über Https auf. Wenn nun ein iframe enthalten ist, dass eine unverschlüsselte Verbindung über Http enthält, dann wird der Aufruf aus Sicherheitsgründen geblockt.

Wenn die VIS über Https aufgerufen wird, dann muss also dementsprechend der Link im iframe auch einen Https Link enthalten.

Jetzt muss ich nur noch eine Lösung finden, ich probiere es mal über einen Reverse Proxy mit Https.

Hallo zusammen,
funktioniert derzeit bei jemandem der Stream in einem iframe in der iobroker.vis?

Wenn ich den Stream im Browser direkt öffne (z. B. http://10.0.0.100:8099), dann klappt das wunderbar.
Sobald ich aber im selben Browser die VIS öffne, in der die URL in einem iframe eingefügt ist, dann kommt kein Stream, so als wäre das iframe gar nicht da. Eine Gegenprobe mit der Tagesschau (https://www.tagesschau.de/multimedia/video/video-805945~player_branded-true.html) ist wiederum erfolgreich.

Ich weiß nicht mehr weiter, woran das liegen kann. Vielleicht hiermit (!?):
https://support.mozilla.org/de/kb/website-erlaubt-firefox-nicht-die-seite-anzuzeigen?as=u&utm_source=inproduct

Nochmal eine Ergänzung zum "Refresh Problem" beim Fully und iobroker.vis zum Nachdenken.

Anwendungsfall: Der Bildschirm wird automatisch nach 120s Inaktivität ausgeschaltet und dann händisch nach ca. 15 min wieder eingeschaltet.

Ich habe hier zwei Tablets zum direkten Vergleich, die auf dieselbe Vis zugreifen.
Beim älteren Nexus 10 läuft Android Webview v.60. Beim händischen Aufwecken wird die Vis im Fully nach ca. 1s unbemerkt aktualisiert und das Tablet lässt sich problemlos bedienen. Soweit alles gut.
Beim neuen Samsung Tab A (T510) ist Android Webview v.77 vorinstalliert, noch tiefer downgraden geht nicht. Beim händischen Aufwecken wird die Vis angezeigt und auch die darauf befindlichen Werte aktualisiert. Nach ca. 5s kommt aber in der Mitte eine kleiner weißer Kreis und ein Timer zählt runter 5...4...3...2....1... und bei 0 wird die gesamte Seite aktualisiert. In dieser Zeit lässt sich die Vis nicht bedienen. Es gibt am oberen Rand keinen Ladebalken, wie es z. B. bei einem Refresh durch Fully geschieht.
Auf beiden Tablets ist die derzeit aktuellste Fully v1.40.1 installiert.

Ich schlussfolgere daraus, dass bei diesem Refresh mit dem Kreis und ohne Ladebalken die Ursache tatsächlich in der aktuelleren Android Webview liegt.

Für mich ist ein Tablet mit dem Refresh Problem nicht benutzerfreundlich und daher nicht praktikabel.

Eine Lösung, die ich sehe, ist die Screensaver Funktion von Fully. Die klappt super und die Vis wird beim Aufwecken immer sofort und aktuell angezeigt. Diese Lösung hat allerdings auch Nachteile. Das Tablet verbraucht mehr Strom, was für mich noch ok ist, da sich der Verbrauch in Grenzen hält. Beim Nexus 10 habe ich allerdings im Probelauf von ca. 6 Wochen festgestellt, dass das Display einen Gelbstich bekommen hat, was nicht gut ist. Ich vermute das kommt daher, dass das Display nur gedimmt wird und permanent an ist und dadurch vielleicht der Verschleiß hoch ist. Andererseits ist das Nexus 10 auch schon ein paar Jahre alt, wurde aber kaum benutzt.

Habt ihr ähnliche Erfahrungen gemacht?
Oder habt ihr vielleicht einen anderen Lösungsansatz für dieses Problem?

Was mir noch einfällt: Dieser Kreis mit dem Countdown kommt doch von der Vis, oder? Vielleicht lässt sich da noch eine Lösung finden.

@Damian411
Problem gelöst, ich habe den iobroker neu installiert und nun funktioniert es. Offenbar hing irgendetwas in meiner Installation. Genauer gesagt funktioniert es nicht, wenn ich iobroker in Proxmox als LXC betreibe, als VM läuft es nun.

Nun werde ich mal nach Beispielen für iobroker-VIS suchen.

Vielen Dank !

@apollon77
Das ist ja das Seltsame, die Netzwerkverbindung vom iobroker zum Robonect funktioniert einwandfrei. Der Ping funktioniert und ich habe auch den MQTT Adapter mit dem Robonect erfolgreich getestet. Diverse andere Adapter können auch ganz normal mit ihren Geräten kommunizieren.
Im Tcpdump auf dem iobroker sehe ich, dass der Robonect Adapter seltsamerweise kein einziges Paket, also auch keinen Ping, an die von mir hinterlegte Ziel-Adresse "10.0.10.15" sendet.

VG Damian

@braindead
Ich habe die 0.0.10 aus der latest Repo installiert.
Gibt es bei iobroker noch irgendeine Möglichkeit, um den Adapter zu debuggen?
Ich gehe aufgrund des Fehlerbildes avon aus, das es kein Netzwerkproblem ist.

@braindead
Ich habe nur die IP-Adresse ohne sonstige Angeben eingetragen: "10.0.10.15".
Robonect ist vom iobroker aus per Ping erreichbar, hier sehen ich auch im Tcpdump die Einträge. Die kommunizieren auch problemlos über MQTT.
Der Robonect Adapter sendet allerdings keinen Ping an die o. g. IP Adresse.
Den Adapter habe ich auch schon neu installiert und MQTT deaktiviert, leider ohne Erfolg.

Hallo, ich wollte diesen Adapter testen, nach der Ersteinrichtung erhalte ich allerdings folgende Fehlermeldung:
"(897) No connection to lawn mower. Check network connection."

Im Tcpdump auf dem iobroker sehe ich, dass die Robonect Instanz kein Paket in Richtung Ziel-IP sendet.
Die Instanzen von anderen Adaptern funktionieren und senden zu ihren Geräten fleißig Pakete hin und her.

Hat jemand eine Idee, woran es liegen könnte? Oder wo ich weiter troubleshooten kann?

VG Damian