ioBroker Visu iPhone Native App
-
Den Fehler hatte ich gestern auch. Ich habe dann „Standort an vis.0 senden“ in den Einstellungen der App deaktiviert. Die beiden unter iot.0.app.devices gelisteten und dort angelegten Koordinaten (die scheinbar in irgendeiner Art fehlerbehaftet dort angelegt werden) habe ich anschließend unter Objekte wieder gelöscht und sie sind seit der Deaktivierung des o.g. Punktes in der App auch nicht mehr aufgetaucht; die Fehlermeldung ist seither auch nicht wieder aufgetaucht. Geofence an sich funktioniert (bei mir) trotzdem (also die Aktualisierung der Datenpunkte true/false unter iot.0.app.geofence).
-
Den Fehler hatte ich gestern auch. Ich habe dann „Standort an vis.0 senden“ in den Einstellungen der App deaktiviert. Die beiden unter iot.0.app.devices gelisteten und dort angelegten Koordinaten (die scheinbar in irgendeiner Art fehlerbehaftet dort angelegt werden) habe ich anschließend unter Objekte wieder gelöscht und sie sind seit der Deaktivierung des o.g. Punktes in der App auch nicht mehr aufgetaucht; die Fehlermeldung ist seither auch nicht wieder aufgetaucht. Geofence an sich funktioniert (bei mir) trotzdem (also die Aktualisierung der Datenpunkte true/false unter iot.0.app.geofence).
-
@Bluefox
das sehe ich gerade in den Logs, ohne das ich nun unterwegs gewesen wäre:iot.0 2026-10-11 19:38:43.116 warn Object of state "iot.0.app.devices.iPhone.latitude" is missing the required property "common.type" iot.0 2026-10-11 19:38:43.114 warn Unknown device data "latitude" with value "xx.768485124115244" iot.0 2026-10-11 19:38:43.112 warn Object of state "iot.0.app.devices.iPhone.longitude" is missing the required property "common.type" iot.0 2026-10-11 19:38:43.107 warn Unknown device data "longitude" with value "xx.149849110661744"Mir sagt das nichts, evtl. hilft es bei irgend einer Analyse?
@Bluefox
das sehe ich gerade in den Logs, ohne das ich nun unterwegs gewesen wäre:iot.0 2026-10-11 19:38:43.116 warn Object of state "iot.0.app.devices.iPhone.latitude" is missing the required property "common.type" iot.0 2026-10-11 19:38:43.114 warn Unknown device data "latitude" with value "xx.768485124115244" iot.0 2026-10-11 19:38:43.112 warn Object of state "iot.0.app.devices.iPhone.longitude" is missing the required property "common.type" iot.0 2026-10-11 19:38:43.107 warn Unknown device data "longitude" with value "xx.149849110661744"Mir sagt das nichts, evtl. hilft es bei irgend einer Analyse?
Dafür gibt es neue Version von iot
-
@Bluefox
Ich kann nun sagen, dass sich die GF-Punkte in den Objekten wieder erstellt haben und das sie sich auch wieder aktualisieren bei mir.
Ob es das iOs-Update war, oder dass ich unter Remote meine Daten (ich habe nur die Assistenten!!! keinen Fernzugriff) eingetragen habe, oder dass ich den Geofence durch Verlassen und Rückkehr an-getriggert habe, vermag ich leider nicht zu sagen...
Danke jedenfalls für die Hilfe!
Joel -
Ich beziehe mich auf deinen Beitrag von heute zu diesem Issue:
https://github.com/ioBroker/Android-And-iPhone-Apps/issues/8
(VIS-2 reloads/reconnects during normal view changes – Safari works correctly)
Hierzu kann ich noch folgendes beisteuern: Das Problem des reloads tritt auch bei Verwendung von iqontrol auf, wenn ich dort einen Dialog öffne. Dann findet ein sofortiger Reload der Seite statt, das Dialogfenster öffnet sich zuvor nur für einen kurzen Moment (unter 1 Sekunde). Nachdem dies passiert ist, lässt sich im Anschluss, nach dem unbeabsichtigten Reload, das Dialogfenster normal öffnen, auch alle weiteren Dialogfenster öffnen dann problemlos, bis die App geschlossen und wieder geöffnet wird. Dann geht es von vorne los. Im Browser tritt dieser Fehler nicht auf. Ich vermute, dass dies dieselbe Ursache hat und somit nicht nur vis-2, sondern auch andere Visualisierungen betrifft, insbesondere auch iqontrol.
Edit: Der Fehler tritt auch mit der neuesten App-Version 2.3.0 noch auf.
Ephi sagte:
Ich beziehe mich auf deinen Beitrag von heute zu diesem Issue:
https://github.com/ioBroker/Android-And-iPhone-Apps/issues/8
(VIS-2 reloads/reconnects during normal view changes – Safari works correctly)
Hierzu kann ich noch folgendes beisteuern: Das Problem des reloads tritt auch bei Verwendung von iqontrol auf, wenn ich dort einen Dialog öffne. Dann findet ein sofortiger Reload der Seite statt, das Dialogfenster öffnet sich zuvor nur für einen kurzen Moment (unter 1 Sekunde). Nachdem dies passiert ist, lässt sich im Anschluss, nach dem unbeabsichtigten Reload, das Dialogfenster normal öffnen, auch alle weiteren Dialogfenster öffnen dann problemlos, bis die App geschlossen und wieder geöffnet wird. Dann geht es von vorne los. Im Browser tritt dieser Fehler nicht auf. Ich vermute, dass dies dieselbe Ursache hat und somit nicht nur vis-2, sondern auch andere Visualisierungen betrifft, insbesondere auch iqontrol.
Edit: Der Fehler tritt auch mit der neuesten App-Version 2.3.0 noch auf.
Laut Rückmeldung im Github-Issue scheint der Reload-Fehler im Zusammenhang mit vis-2 mit App-Version 2.3.0 ja behoben. Der von mir angesprochene Reload-Fehler beim Aufruf eines Dialogfensters in iqontrol wurde mit Version 2.3.0 allerdings nicht behoben. Kannst Du hierzu schon etwas sagen? Danke.
-
@Bluefox
das sehe ich gerade in den Logs, ohne das ich nun unterwegs gewesen wäre:iot.0 2026-10-11 19:38:43.116 warn Object of state "iot.0.app.devices.iPhone.latitude" is missing the required property "common.type" iot.0 2026-10-11 19:38:43.114 warn Unknown device data "latitude" with value "xx.768485124115244" iot.0 2026-10-11 19:38:43.112 warn Object of state "iot.0.app.devices.iPhone.longitude" is missing the required property "common.type" iot.0 2026-10-11 19:38:43.107 warn Unknown device data "longitude" with value "xx.149849110661744"Mir sagt das nichts, evtl. hilft es bei irgend einer Analyse?
Dafür gibt es neue Version von iot
@Bluefox
ich nutze VPN und die lokale Verbindung (kein ioBroker Pro).
Soweit funktioniert die neue App auch ohne Verbindungsprobleme und die jetzige Bedienung ist wesentlich "schöner" als die alte ioBroker Visu App (was das "einzoomen" betrifft).
Das war bisher auch mein Grund die ganz alte ioBroker App zu nutzen (welche auch heute noch die beste "Ansicht" für mich bietet).Leider habe ich zwei Probleme.
Zur Info, ich nutze VIS1, VIS2 kommt aufgrund seiner massiven performance Problemen bei Bindings leider nicht in Frage.- das Widget "Open Street Map" funktioniert nicht.
im Gegensatz zur alten ioBroker Visu, und der noch älteren ioBroker App habe ich diese Ansicht.
in allen Browsern (PCs oder ios Geräten) funktionert es.- Ich nutze viele Json Tabellen von vis-inventwo.
Hier ist eine mit Links auf jpegs aus dem internet.
Der Inhalt der Tabelle sieht z.B. so aus
<img src=\"http://xxx.de/xxxxx/xxxxx/xxxxx/xxxxxx.jpeg\" width=\"140\">Sowohl die "alte" ioBroker Visu und die noch ältere ioBroker App zeigen den Inhalt perfekt an.
Hier das Ergebnis der neuen ioBroker Visu.
in allen Browsern (PCs oder ios Geräten) funktionert es.Hast du dazu eine Idee?
Wenn nicht, bleib ich halt bei der alten ioBroker App, leider ohne die Funktionen zu Matter... - das Widget "Open Street Map" funktioniert nicht.
-
@Bluefox
ich nutze VPN und die lokale Verbindung (kein ioBroker Pro).
Soweit funktioniert die neue App auch ohne Verbindungsprobleme und die jetzige Bedienung ist wesentlich "schöner" als die alte ioBroker Visu App (was das "einzoomen" betrifft).
Das war bisher auch mein Grund die ganz alte ioBroker App zu nutzen (welche auch heute noch die beste "Ansicht" für mich bietet).Leider habe ich zwei Probleme.
Zur Info, ich nutze VIS1, VIS2 kommt aufgrund seiner massiven performance Problemen bei Bindings leider nicht in Frage.- das Widget "Open Street Map" funktioniert nicht.
im Gegensatz zur alten ioBroker Visu, und der noch älteren ioBroker App habe ich diese Ansicht.
in allen Browsern (PCs oder ios Geräten) funktionert es.- Ich nutze viele Json Tabellen von vis-inventwo.
Hier ist eine mit Links auf jpegs aus dem internet.
Der Inhalt der Tabelle sieht z.B. so aus
<img src=\"http://xxx.de/xxxxx/xxxxx/xxxxx/xxxxxx.jpeg\" width=\"140\">Sowohl die "alte" ioBroker Visu und die noch ältere ioBroker App zeigen den Inhalt perfekt an.
Hier das Ergebnis der neuen ioBroker Visu.
in allen Browsern (PCs oder ios Geräten) funktionert es.Hast du dazu eine Idee?
Wenn nicht, bleib ich halt bei der alten ioBroker App, leider ohne die Funktionen zu Matter... - das Widget "Open Street Map" funktioniert nicht.
-
<img src="http://xxx.de/xxxxx/xxxxx/xxxxx/xxxxxx.jpeg\" width="140">
Du versuchst von https Seite die Inhalte von http zu laden. Stimmt das? Warum machst du das? Es ist nicht erlaubt. Gibt es da kein https?
<img src="http://xxx.de/xxxxx/xxxxx/xxxxx/xxxxxx.jpeg\" width="140">
Du versuchst von https Seite die Inhalte von http zu laden. Stimmt das? Warum machst du das? Es ist nicht erlaubt. Gibt es da kein https?
das war tatsächlich das Problem. Mein Skript legte http links an. Nach dem ändern auf https funktionieren die Links auch in der neuen App. Danke für den Hinweis. Wenn du noch eine Lösung für das Open Street Map Widget hättest, wäre ich rundum zufrieden.
-
Kannst du bitte noch etwas zu meinem Remote-Problem (eigene URL) sagen
Ich kann da wirklich nichts sagen. Bei mir geht es, und mir fehlt jegliche Information von euch. Kann sein dass self-signed Zertifikat abgelehnt wird? Ich weiss doch nichts, ob auth oder https eingeschaltet ist, wie sieht URL aus, und und und.
Läuft bei jemandem Remote Access:
- über ioBroker.pro? (Bestätigt - geht)
- über Eigene URL?
Die Informationen habe ich bereits mehrfach geschickt, aber gerne nochmal:
URL: http://xxx.ddnss.de:8082
User und Password wie bei lokal…
Hat in der Vergangenheit mit diesen Einstellungen funktioniert.
Zugriff mit einem Intenetbrowser funktioniert remote.Welche info brauchst du noch?
Wenn ich etwas ändern soll bin ich für jede Info dankbar…Ich sehe immer noch bei dir, dass du ohne http(s):// URL einträgst. Neue App, geht davon aus, dass man Secure ist und fügt vorne
https://ein. Wenn das Bild noch aktuell ist, dann greift app aufhttps://xxx.ddnss.de:8082Erst mal Danke für deinen Support!
Zwischen meinen Screenshots hatte ich geschrieben, das ich „http://„ mit eingegeben habe.Ich komme nicht aus der Netzwerktechnik (wenig Ahnung).
Zu meinem Verständnis:
Gebe ich jetzt vor der URL „https://„ ein?
Reicht es im der WEB-Instanz „verschlüsselte Verbindung“ einzustellen wie hier: (dann komme ich leider auch lokal nicht mehr an die VIS)Wie du siehst brache ich dringend Nachhilfe…
Du musst nicht extra auf https umstellen. Bleibe bei http bitte. Die neue App version zeigt welche URL verwendet wird. Wenn man diese URL im Browser aufmacht, sollte auch funktionieren. Wenn nicht funktioniert, dann ist URL falsch
Kannst du bitte noch etwas zu meinem Remote-Problem (eigene URL) sagen
Ich kann da wirklich nichts sagen. Bei mir geht es, und mir fehlt jegliche Information von euch. Kann sein dass self-signed Zertifikat abgelehnt wird? Ich weiss doch nichts, ob auth oder https eingeschaltet ist, wie sieht URL aus, und und und.
Läuft bei jemandem Remote Access:
- über ioBroker.pro? (Bestätigt - geht)
- über Eigene URL?
Die Informationen habe ich bereits mehrfach geschickt, aber gerne nochmal:
URL: http://xxx.ddnss.de:8082
User und Password wie bei lokal…
Hat in der Vergangenheit mit diesen Einstellungen funktioniert.
Zugriff mit einem Intenetbrowser funktioniert remote.Welche info brauchst du noch?
Wenn ich etwas ändern soll bin ich für jede Info dankbar…Ich sehe immer noch bei dir, dass du ohne http(s):// URL einträgst. Neue App, geht davon aus, dass man Secure ist und fügt vorne
https://ein. Wenn das Bild noch aktuell ist, dann greift app aufhttps://xxx.ddnss.de:8082Erst mal Danke für deinen Support!
Zwischen meinen Screenshots hatte ich geschrieben, das ich „http://„ mit eingegeben habe.Ich komme nicht aus der Netzwerktechnik (wenig Ahnung).
Zu meinem Verständnis:
Gebe ich jetzt vor der URL „https://„ ein?
Reicht es im der WEB-Instanz „verschlüsselte Verbindung“ einzustellen wie hier: (dann komme ich leider auch lokal nicht mehr an die VIS)Wie du siehst brache ich dringend Nachhilfe…
Du musst nicht extra auf https umstellen. Bleibe bei http bitte. Die neue App version zeigt welche URL verwendet wird. Wenn man diese URL im Browser aufmacht, sollte auch funktionieren. Wenn nicht funktioniert, dann ist URL falsch
Ich glaube, ich hab ein paar neue Erkenntnisse:
Wenn ich in einem fremden WLAN bin, welches über die FRITZ!Box mit meinem Haus Netz gekoppelt ist, funktioniert die Visualisierung. Das aktuelle WLAN scheint gar nicht erkannt zu werden und es wird immer die lokale IP Adresse genutzt. -
Kannst du bitte noch etwas zu meinem Remote-Problem (eigene URL) sagen
Ich kann da wirklich nichts sagen. Bei mir geht es, und mir fehlt jegliche Information von euch. Kann sein dass self-signed Zertifikat abgelehnt wird? Ich weiss doch nichts, ob auth oder https eingeschaltet ist, wie sieht URL aus, und und und.
Läuft bei jemandem Remote Access:
- über ioBroker.pro? (Bestätigt - geht)
- über Eigene URL?
Die Informationen habe ich bereits mehrfach geschickt, aber gerne nochmal:
URL: http://xxx.ddnss.de:8082
User und Password wie bei lokal…
Hat in der Vergangenheit mit diesen Einstellungen funktioniert.
Zugriff mit einem Intenetbrowser funktioniert remote.Welche info brauchst du noch?
Wenn ich etwas ändern soll bin ich für jede Info dankbar…Ich sehe immer noch bei dir, dass du ohne http(s):// URL einträgst. Neue App, geht davon aus, dass man Secure ist und fügt vorne
https://ein. Wenn das Bild noch aktuell ist, dann greift app aufhttps://xxx.ddnss.de:8082Erst mal Danke für deinen Support!
Zwischen meinen Screenshots hatte ich geschrieben, das ich „http://„ mit eingegeben habe.Ich komme nicht aus der Netzwerktechnik (wenig Ahnung).
Zu meinem Verständnis:
Gebe ich jetzt vor der URL „https://„ ein?
Reicht es im der WEB-Instanz „verschlüsselte Verbindung“ einzustellen wie hier: (dann komme ich leider auch lokal nicht mehr an die VIS)Wie du siehst brache ich dringend Nachhilfe…
Du musst nicht extra auf https umstellen. Bleibe bei http bitte. Die neue App version zeigt welche URL verwendet wird. Wenn man diese URL im Browser aufmacht, sollte auch funktionieren. Wenn nicht funktioniert, dann ist URL falsch
Ich glaube, ich hab ein paar neue Erkenntnisse:
Wenn ich in einem fremden WLAN bin, welches über die FRITZ!Box mit meinem Haus Netz gekoppelt ist, funktioniert die Visualisierung. Das aktuelle WLAN scheint gar nicht erkannt zu werden und es wird immer die lokale IP Adresse genutzt.Kannst du bitte noch etwas zu meinem Remote-Problem (eigene URL) sagen
Ich kann da wirklich nichts sagen. Bei mir geht es, und mir fehlt jegliche Information von euch. Kann sein dass self-signed Zertifikat abgelehnt wird? Ich weiss doch nichts, ob auth oder https eingeschaltet ist, wie sieht URL aus, und und und.
Läuft bei jemandem Remote Access:
- über ioBroker.pro? (Bestätigt - geht)
- über Eigene URL?
Die Informationen habe ich bereits mehrfach geschickt, aber gerne nochmal:
URL: http://xxx.ddnss.de:8082
User und Password wie bei lokal…
Hat in der Vergangenheit mit diesen Einstellungen funktioniert.
Zugriff mit einem Intenetbrowser funktioniert remote.Welche info brauchst du noch?
Wenn ich etwas ändern soll bin ich für jede Info dankbar…Ich sehe immer noch bei dir, dass du ohne http(s):// URL einträgst. Neue App, geht davon aus, dass man Secure ist und fügt vorne
https://ein. Wenn das Bild noch aktuell ist, dann greift app aufhttps://xxx.ddnss.de:8082Erst mal Danke für deinen Support!
Zwischen meinen Screenshots hatte ich geschrieben, das ich „http://„ mit eingegeben habe.Ich komme nicht aus der Netzwerktechnik (wenig Ahnung).
Zu meinem Verständnis:
Gebe ich jetzt vor der URL „https://„ ein?
Reicht es im der WEB-Instanz „verschlüsselte Verbindung“ einzustellen wie hier: (dann komme ich leider auch lokal nicht mehr an die VIS)Wie du siehst brache ich dringend Nachhilfe…
Du musst nicht extra auf https umstellen. Bleibe bei http bitte. Die neue App version zeigt welche URL verwendet wird. Wenn man diese URL im Browser aufmacht, sollte auch funktionieren. Wenn nicht funktioniert, dann ist URL falsch
Ich glaube, ich hab ein paar neue Erkenntnisse:
Wenn ich in einem fremden WLAN bin, welches über die FRITZ!Box mit meinem Haus Netz gekoppelt ist, funktioniert die Visualisierung. Das aktuelle WLAN scheint gar nicht erkannt zu werden und es wird immer die lokale IP Adresse genutzt.@PRO84 Danke, deine Beobachtung war der entscheidende Hinweis. Das Problem liegt nicht an deinen Einstellungen, sondern an der App.
iOS blockiert in der App unverschlüsselte http://-Verbindungen zu Hostnamen. Zu IP-Adressen sind sie erlaubt. Eigentlich war das in der
App abgeschaltet, aber durch einen Konfigurationsfehler hat iOS diese Freigabe ignoriert.Daraus erklärt sich, was du gesehen hast:
- http://<deine-DynDNS>:8082 wird in der App blockiert, im Browser funktioniert die Adresse.
- Die lokale IP funktioniert, sobald sie erreichbar ist. Das gilt auch im fremden WLAN, das über die FRITZ!Box mit deinem Heimnetz
gekoppelt ist. Deshalb sah es so aus, als würde die App immer die lokale IP nehmen. - Unter Android gibt es diese Einschränkung nicht, deshalb laufen dieselben Einstellungen dort.
Behoben ist es in Version 2.4.2. Damit klappt der Fernzugriff über http:// und deine DynDNS-Adresse.
Bis 2.4.2 da ist, kannst du von unterwegs per VPN ins Heimnetz gehen, z. B. mit WireGuard auf der FRITZ!Box. Dann nimmt die App die
lokale IP, und die funktioniert ja. -
Kannst du bitte noch etwas zu meinem Remote-Problem (eigene URL) sagen
Ich kann da wirklich nichts sagen. Bei mir geht es, und mir fehlt jegliche Information von euch. Kann sein dass self-signed Zertifikat abgelehnt wird? Ich weiss doch nichts, ob auth oder https eingeschaltet ist, wie sieht URL aus, und und und.
Läuft bei jemandem Remote Access:
- über ioBroker.pro? (Bestätigt - geht)
- über Eigene URL?
Die Informationen habe ich bereits mehrfach geschickt, aber gerne nochmal:
URL: http://xxx.ddnss.de:8082
User und Password wie bei lokal…
Hat in der Vergangenheit mit diesen Einstellungen funktioniert.
Zugriff mit einem Intenetbrowser funktioniert remote.Welche info brauchst du noch?
Wenn ich etwas ändern soll bin ich für jede Info dankbar…Ich sehe immer noch bei dir, dass du ohne http(s):// URL einträgst. Neue App, geht davon aus, dass man Secure ist und fügt vorne
https://ein. Wenn das Bild noch aktuell ist, dann greift app aufhttps://xxx.ddnss.de:8082Erst mal Danke für deinen Support!
Zwischen meinen Screenshots hatte ich geschrieben, das ich „http://„ mit eingegeben habe.Ich komme nicht aus der Netzwerktechnik (wenig Ahnung).
Zu meinem Verständnis:
Gebe ich jetzt vor der URL „https://„ ein?
Reicht es im der WEB-Instanz „verschlüsselte Verbindung“ einzustellen wie hier: (dann komme ich leider auch lokal nicht mehr an die VIS)Wie du siehst brache ich dringend Nachhilfe…
Du musst nicht extra auf https umstellen. Bleibe bei http bitte. Die neue App version zeigt welche URL verwendet wird. Wenn man diese URL im Browser aufmacht, sollte auch funktionieren. Wenn nicht funktioniert, dann ist URL falsch
Ich glaube, ich hab ein paar neue Erkenntnisse:
Wenn ich in einem fremden WLAN bin, welches über die FRITZ!Box mit meinem Haus Netz gekoppelt ist, funktioniert die Visualisierung. Das aktuelle WLAN scheint gar nicht erkannt zu werden und es wird immer die lokale IP Adresse genutzt.@PRO84 Danke, deine Beobachtung war der entscheidende Hinweis. Das Problem liegt nicht an deinen Einstellungen, sondern an der App.
iOS blockiert in der App unverschlüsselte http://-Verbindungen zu Hostnamen. Zu IP-Adressen sind sie erlaubt. Eigentlich war das in der
App abgeschaltet, aber durch einen Konfigurationsfehler hat iOS diese Freigabe ignoriert.Daraus erklärt sich, was du gesehen hast:
- http://<deine-DynDNS>:8082 wird in der App blockiert, im Browser funktioniert die Adresse.
- Die lokale IP funktioniert, sobald sie erreichbar ist. Das gilt auch im fremden WLAN, das über die FRITZ!Box mit deinem Heimnetz
gekoppelt ist. Deshalb sah es so aus, als würde die App immer die lokale IP nehmen. - Unter Android gibt es diese Einschränkung nicht, deshalb laufen dieselben Einstellungen dort.
Behoben ist es in Version 2.4.2. Damit klappt der Fernzugriff über http:// und deine DynDNS-Adresse.
Bis 2.4.2 da ist, kannst du von unterwegs per VPN ins Heimnetz gehen, z. B. mit WireGuard auf der FRITZ!Box. Dann nimmt die App die
lokale IP, und die funktioniert ja.Kannst du bitte noch etwas zu meinem Remote-Problem (eigene URL) sagen
Ich kann da wirklich nichts sagen. Bei mir geht es, und mir fehlt jegliche Information von euch. Kann sein dass self-signed Zertifikat abgelehnt wird? Ich weiss doch nichts, ob auth oder https eingeschaltet ist, wie sieht URL aus, und und und.
Läuft bei jemandem Remote Access:
- über ioBroker.pro? (Bestätigt - geht)
- über Eigene URL?
Die Informationen habe ich bereits mehrfach geschickt, aber gerne nochmal:
URL: http://xxx.ddnss.de:8082
User und Password wie bei lokal…
Hat in der Vergangenheit mit diesen Einstellungen funktioniert.
Zugriff mit einem Intenetbrowser funktioniert remote.Welche info brauchst du noch?
Wenn ich etwas ändern soll bin ich für jede Info dankbar…Ich sehe immer noch bei dir, dass du ohne http(s):// URL einträgst. Neue App, geht davon aus, dass man Secure ist und fügt vorne
https://ein. Wenn das Bild noch aktuell ist, dann greift app aufhttps://xxx.ddnss.de:8082Erst mal Danke für deinen Support!
Zwischen meinen Screenshots hatte ich geschrieben, das ich „http://„ mit eingegeben habe.Ich komme nicht aus der Netzwerktechnik (wenig Ahnung).
Zu meinem Verständnis:
Gebe ich jetzt vor der URL „https://„ ein?
Reicht es im der WEB-Instanz „verschlüsselte Verbindung“ einzustellen wie hier: (dann komme ich leider auch lokal nicht mehr an die VIS)Wie du siehst brache ich dringend Nachhilfe…
Du musst nicht extra auf https umstellen. Bleibe bei http bitte. Die neue App version zeigt welche URL verwendet wird. Wenn man diese URL im Browser aufmacht, sollte auch funktionieren. Wenn nicht funktioniert, dann ist URL falsch
Ich glaube, ich hab ein paar neue Erkenntnisse:
Wenn ich in einem fremden WLAN bin, welches über die FRITZ!Box mit meinem Haus Netz gekoppelt ist, funktioniert die Visualisierung. Das aktuelle WLAN scheint gar nicht erkannt zu werden und es wird immer die lokale IP Adresse genutzt.@PRO84 Danke, deine Beobachtung war der entscheidende Hinweis. Das Problem liegt nicht an deinen Einstellungen, sondern an der App.
iOS blockiert in der App unverschlüsselte http://-Verbindungen zu Hostnamen. Zu IP-Adressen sind sie erlaubt. Eigentlich war das in der
App abgeschaltet, aber durch einen Konfigurationsfehler hat iOS diese Freigabe ignoriert.Daraus erklärt sich, was du gesehen hast:
- http://<deine-DynDNS>:8082 wird in der App blockiert, im Browser funktioniert die Adresse.
- Die lokale IP funktioniert, sobald sie erreichbar ist. Das gilt auch im fremden WLAN, das über die FRITZ!Box mit deinem Heimnetz
gekoppelt ist. Deshalb sah es so aus, als würde die App immer die lokale IP nehmen. - Unter Android gibt es diese Einschränkung nicht, deshalb laufen dieselben Einstellungen dort.
Behoben ist es in Version 2.4.2. Damit klappt der Fernzugriff über http:// und deine DynDNS-Adresse.
Bis 2.4.2 da ist, kannst du von unterwegs per VPN ins Heimnetz gehen, z. B. mit WireGuard auf der FRITZ!Box. Dann nimmt die App die
lokale IP, und die funktioniert ja.Danke für die schnelle Info. Das hört sich ja gut an.
Weißt du schon, wann die 2.4.2 circa erscheint? -
@Bluefox
Hat das auch damit zu tun?Ich habe schon immer eine Cam in iqontrol eingebunden. Dort unter Background HTML.
Seit der neuen App sieht das so aus:
Im Browser alles OK und so:
der link ist https.
"https://192.168.178.100:443/cgi-bin/mjpg/video.cgi?channel=0&subtype=1&user=xxx&password=xxx"Oder ist das ein anderes Problem?
Danke! -
<img src="http://xxx.de/xxxxx/xxxxx/xxxxx/xxxxxx.jpeg\" width="140">
Du versuchst von https Seite die Inhalte von http zu laden. Stimmt das? Warum machst du das? Es ist nicht erlaubt. Gibt es da kein https?
das war tatsächlich das Problem. Mein Skript legte http links an. Nach dem ändern auf https funktionieren die Links auch in der neuen App. Danke für den Hinweis. Wenn du noch eine Lösung für das Open Street Map Widget hättest, wäre ich rundum zufrieden.
<img src="http://xxx.de/xxxxx/xxxxx/xxxxx/xxxxxx.jpeg\" width="140">
Du versuchst von https Seite die Inhalte von http zu laden. Stimmt das? Warum machst du das? Es ist nicht erlaubt. Gibt es da kein https?
das war tatsächlich das Problem. Mein Skript legte http links an. Nach dem ändern auf https funktionieren die Links auch in der neuen App. Danke für den Hinweis. Wenn du noch eine Lösung für das Open Street Map Widget hättest, wäre ich rundum zufrieden.
@stenmic Ich habe mir das OpenStreetMap-Widget angesehen. Die Ursache liegt in der App, nicht bei dir.
Das Widget lädt die Kartenkacheln über http://a.tile.openstreetmap.org/…, also unverschlüsselt. Bis Version 2.4.1 hat die App solche http://-Anfragen an Hostnamen blockiert. Grund war ein Konfigurationsfehler, an IP-Adressen ging es trotzdem. Die rosa Fläche auf deinem Screenshot ist die Farbe, die das Widget für Kacheln zeigt, die nicht laden. Deshalb erscheint nur der Marker und keine Karte.
Das ist derselbe Fehler, den PRO84 mit seiner http-Remote-Adresse hatte. Behoben ist er in Version 2.4.2. Damit sollte die Karte ohne weitere Änderung laden.
Zu deinen Bildern in der JSON-Tabelle muss ich mich korrigieren. Weil du lokal bzw. per VPN verbindest, ist deine Seite selbst http://, ein Mischen von https und http war es also wohl nicht. Es war dieselbe Sperre. Mit 2.4.2 würden auch die http://-Links wieder angezeigt.
Bei https:// zu bleiben ist trotzdem die bessere Wahl.
Gib bitte Bescheid, ob die Karte mit 2.4.2 bei dir funktioniert. Aber momentan steht noch 2.4.0 in der Freigabewarteschlange. Wenn 2.4.0 freigegeben wird, dann kommt 2.4.2...
-
<img src="http://xxx.de/xxxxx/xxxxx/xxxxx/xxxxxx.jpeg\" width="140">
Du versuchst von https Seite die Inhalte von http zu laden. Stimmt das? Warum machst du das? Es ist nicht erlaubt. Gibt es da kein https?
das war tatsächlich das Problem. Mein Skript legte http links an. Nach dem ändern auf https funktionieren die Links auch in der neuen App. Danke für den Hinweis. Wenn du noch eine Lösung für das Open Street Map Widget hättest, wäre ich rundum zufrieden.
@stenmic Ich habe mir das OpenStreetMap-Widget angesehen. Die Ursache liegt in der App, nicht bei dir.
Das Widget lädt die Kartenkacheln über http://a.tile.openstreetmap.org/…, also unverschlüsselt. Bis Version 2.4.1 hat die App solche http://-Anfragen an Hostnamen blockiert. Grund war ein Konfigurationsfehler, an IP-Adressen ging es trotzdem. Die rosa Fläche auf deinem Screenshot ist die Farbe, die das Widget für Kacheln zeigt, die nicht laden. Deshalb erscheint nur der Marker und keine Karte.
Das ist derselbe Fehler, den PRO84 mit seiner http-Remote-Adresse hatte. Behoben ist er in Version 2.4.2. Damit sollte die Karte ohne weitere Änderung laden.
Zu deinen Bildern in der JSON-Tabelle muss ich mich korrigieren. Weil du lokal bzw. per VPN verbindest, ist deine Seite selbst http://, ein Mischen von https und http war es also wohl nicht. Es war dieselbe Sperre. Mit 2.4.2 würden auch die http://-Links wieder angezeigt.
Bei https:// zu bleiben ist trotzdem die bessere Wahl.
Gib bitte Bescheid, ob die Karte mit 2.4.2 bei dir funktioniert. Aber momentan steht noch 2.4.0 in der Freigabewarteschlange. Wenn 2.4.0 freigegeben wird, dann kommt 2.4.2...
-
Ephi sagte:
Ich beziehe mich auf deinen Beitrag von heute zu diesem Issue:
https://github.com/ioBroker/Android-And-iPhone-Apps/issues/8
(VIS-2 reloads/reconnects during normal view changes – Safari works correctly)
Hierzu kann ich noch folgendes beisteuern: Das Problem des reloads tritt auch bei Verwendung von iqontrol auf, wenn ich dort einen Dialog öffne. Dann findet ein sofortiger Reload der Seite statt, das Dialogfenster öffnet sich zuvor nur für einen kurzen Moment (unter 1 Sekunde). Nachdem dies passiert ist, lässt sich im Anschluss, nach dem unbeabsichtigten Reload, das Dialogfenster normal öffnen, auch alle weiteren Dialogfenster öffnen dann problemlos, bis die App geschlossen und wieder geöffnet wird. Dann geht es von vorne los. Im Browser tritt dieser Fehler nicht auf. Ich vermute, dass dies dieselbe Ursache hat und somit nicht nur vis-2, sondern auch andere Visualisierungen betrifft, insbesondere auch iqontrol.
Edit: Der Fehler tritt auch mit der neuesten App-Version 2.3.0 noch auf.
Laut Rückmeldung im Github-Issue scheint der Reload-Fehler im Zusammenhang mit vis-2 mit App-Version 2.3.0 ja behoben. Der von mir angesprochene Reload-Fehler beim Aufruf eines Dialogfensters in iqontrol wurde mit Version 2.3.0 allerdings nicht behoben. Kannst Du hierzu schon etwas sagen? Danke.
Ephi sagte:
Ephi sagte:
Ich beziehe mich auf deinen Beitrag von heute zu diesem Issue:
https://github.com/ioBroker/Android-And-iPhone-Apps/issues/8
(VIS-2 reloads/reconnects during normal view changes – Safari works correctly)
Hierzu kann ich noch folgendes beisteuern: Das Problem des reloads tritt auch bei Verwendung von iqontrol auf, wenn ich dort einen Dialog öffne. Dann findet ein sofortiger Reload der Seite statt, das Dialogfenster öffnet sich zuvor nur für einen kurzen Moment (unter 1 Sekunde). Nachdem dies passiert ist, lässt sich im Anschluss, nach dem unbeabsichtigten Reload, das Dialogfenster normal öffnen, auch alle weiteren Dialogfenster öffnen dann problemlos, bis die App geschlossen und wieder geöffnet wird. Dann geht es von vorne los. Im Browser tritt dieser Fehler nicht auf. Ich vermute, dass dies dieselbe Ursache hat und somit nicht nur vis-2, sondern auch andere Visualisierungen betrifft, insbesondere auch iqontrol.
Edit: Der Fehler tritt auch mit der neuesten App-Version 2.3.0 noch auf.
Laut Rückmeldung im Github-Issue scheint der Reload-Fehler im Zusammenhang mit vis-2 mit App-Version 2.3.0 ja behoben. Der von mir angesprochene Reload-Fehler beim Aufruf eines Dialogfensters in iqontrol wurde mit Version 2.3.0 allerdings nicht behoben. Kannst Du hierzu schon etwas sagen? Danke.
Hallo @bluefox
Ich beziehe mich nochmals auf das von mir geschilderte Problem. Kurz zusammengefasst: Es kommt bei mir zu einem Reload der Seite, wenn ich über die App meine mit iqontrol erstellte Oberfläche öffne, sofern ich ein Dialogfenster von iqontrol erstmals öffne. Dann tritt ein sofortiger Reload der Seite ein. Tippe ich dann nochmals zum Öffnen des Dialogfensters auf die entsprechende Kachel, kommt es zu keinem weiteren Reload der Seite mehr. Erst nach Schließen und wieder Öffnen der App tritt der Fehler erneut auf.
Ich habe nun noch folgende weitere Beobachtung gemacht: Der von mir geschilderte Fehler tritt nur auf, wenn ich über die App lokal über die IP-Adresse auf meine Oberfläche zugreife. Bin ich nicht im heimischen Netzwerk und wird die Verbindung Remote über iobroker.pro aufgebaut, tritt der Fehler dagegen nicht auf! Also: Nur im lokalen Netzwerk bei Zugriff über die lokale IP-Adresse (auch bei VPN).
Die neue App-Version von heute morgen (2.3.2) hat übrigens an dem Problem nichts geändert.
Wenn ich über den Browser oder über die alte iobroker-App lokal zugreife, tritt der Fehler nicht auf.
Vielen Dank für deine umfangreichen Bemühungen, die Fehler abzustellen. Ich wäre sehr dankbar, wenn Du hierauf auch eingehen könntest.
Edit: Von Zeit zu Zeit ist im Log des cloud.0 Adapters folgende Error-Meldung zu finden:
Cannot request web pages "http://127.0.0.1:8082/iqontrol/resize": <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>404 Not Found</title> <style> body { background-color: #e0f7fa; color: #007bb5; font-family: Arial, sans-serif; display: flex; justify-content: center; align-items: center; height: 100vh; margin: 0; } .container { text-align: center; } h1 { font-size: 6em; margin: 0; } p { font-size: 1.5em; } a { color: #007bb5; text-decoration: none; border: 2px solid #007bb5; padding: 10px 20px; border-radius: 5px; cursor: pointer; } a:hover { background-color: #007bb5; color: #e0f7fa; } </style> <script> function refresh() { location.reload(); } function goHome() { let href = window.location.pathname; if (href.split('/').length === 3) { const path = href.split('/'); window.location.href = `/${path[1]}/`; } else { window.location.href = '/'; } } // What the document is loaded document.addEventListener('DOMContentLoaded', (event) => { // detect theme, dark or light if (window.matchMedia('(prefers-color-scheme: dark)').matches) { document.body.style.backgroundColor = '#263238'; document.body.style.color = '#eceff1'; } }); </script> </head> <body> <div class="container"> <h1>404</h1> <p>Datei resize nicht gefunden</p> <a onclick="goHome()">Zur Homepage</a> <a onclick="refresh()">Aktualisieren</a> </div> </body> </html> -
Ephi sagte:
Ephi sagte:
Ich beziehe mich auf deinen Beitrag von heute zu diesem Issue:
https://github.com/ioBroker/Android-And-iPhone-Apps/issues/8
(VIS-2 reloads/reconnects during normal view changes – Safari works correctly)
Hierzu kann ich noch folgendes beisteuern: Das Problem des reloads tritt auch bei Verwendung von iqontrol auf, wenn ich dort einen Dialog öffne. Dann findet ein sofortiger Reload der Seite statt, das Dialogfenster öffnet sich zuvor nur für einen kurzen Moment (unter 1 Sekunde). Nachdem dies passiert ist, lässt sich im Anschluss, nach dem unbeabsichtigten Reload, das Dialogfenster normal öffnen, auch alle weiteren Dialogfenster öffnen dann problemlos, bis die App geschlossen und wieder geöffnet wird. Dann geht es von vorne los. Im Browser tritt dieser Fehler nicht auf. Ich vermute, dass dies dieselbe Ursache hat und somit nicht nur vis-2, sondern auch andere Visualisierungen betrifft, insbesondere auch iqontrol.
Edit: Der Fehler tritt auch mit der neuesten App-Version 2.3.0 noch auf.
Laut Rückmeldung im Github-Issue scheint der Reload-Fehler im Zusammenhang mit vis-2 mit App-Version 2.3.0 ja behoben. Der von mir angesprochene Reload-Fehler beim Aufruf eines Dialogfensters in iqontrol wurde mit Version 2.3.0 allerdings nicht behoben. Kannst Du hierzu schon etwas sagen? Danke.
Hallo @bluefox
Ich beziehe mich nochmals auf das von mir geschilderte Problem. Kurz zusammengefasst: Es kommt bei mir zu einem Reload der Seite, wenn ich über die App meine mit iqontrol erstellte Oberfläche öffne, sofern ich ein Dialogfenster von iqontrol erstmals öffne. Dann tritt ein sofortiger Reload der Seite ein. Tippe ich dann nochmals zum Öffnen des Dialogfensters auf die entsprechende Kachel, kommt es zu keinem weiteren Reload der Seite mehr. Erst nach Schließen und wieder Öffnen der App tritt der Fehler erneut auf.
Ich habe nun noch folgende weitere Beobachtung gemacht: Der von mir geschilderte Fehler tritt nur auf, wenn ich über die App lokal über die IP-Adresse auf meine Oberfläche zugreife. Bin ich nicht im heimischen Netzwerk und wird die Verbindung Remote über iobroker.pro aufgebaut, tritt der Fehler dagegen nicht auf! Also: Nur im lokalen Netzwerk bei Zugriff über die lokale IP-Adresse (auch bei VPN).
Die neue App-Version von heute morgen (2.3.2) hat übrigens an dem Problem nichts geändert.
Wenn ich über den Browser oder über die alte iobroker-App lokal zugreife, tritt der Fehler nicht auf.
Vielen Dank für deine umfangreichen Bemühungen, die Fehler abzustellen. Ich wäre sehr dankbar, wenn Du hierauf auch eingehen könntest.
Edit: Von Zeit zu Zeit ist im Log des cloud.0 Adapters folgende Error-Meldung zu finden:
Cannot request web pages "http://127.0.0.1:8082/iqontrol/resize": <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>404 Not Found</title> <style> body { background-color: #e0f7fa; color: #007bb5; font-family: Arial, sans-serif; display: flex; justify-content: center; align-items: center; height: 100vh; margin: 0; } .container { text-align: center; } h1 { font-size: 6em; margin: 0; } p { font-size: 1.5em; } a { color: #007bb5; text-decoration: none; border: 2px solid #007bb5; padding: 10px 20px; border-radius: 5px; cursor: pointer; } a:hover { background-color: #007bb5; color: #e0f7fa; } </style> <script> function refresh() { location.reload(); } function goHome() { let href = window.location.pathname; if (href.split('/').length === 3) { const path = href.split('/'); window.location.href = `/${path[1]}/`; } else { window.location.href = '/'; } } // What the document is loaded document.addEventListener('DOMContentLoaded', (event) => { // detect theme, dark or light if (window.matchMedia('(prefers-color-scheme: dark)').matches) { document.body.style.backgroundColor = '#263238'; document.body.style.color = '#eceff1'; } }); </script> </head> <body> <div class="container"> <h1>404</h1> <p>Datei resize nicht gefunden</p> <a onclick="goHome()">Zur Homepage</a> <a onclick="refresh()">Aktualisieren</a> </div> </body> </html> -
-
-
-
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren AnmeldenSupport us
525
Online33.1k
Benutzer84.2k
Themen1.4m
Beiträge