Monatsrückblick Oktober 2026 ist online!

[Joel]

@Ephi Danke für deine Hilfe, kein Problem.
Edit: Komischerweise habe ich nun mal unter Remote probiert die Zugangsdaten zur cloud, wo meine Assisten-Lizenz liegt einzugeben und der Verbindungstest sagt "Verbunden"!?
Hatte aber bis jetzt keine Auswirkung, die DP sind weiter nicht da...

@Bluefox: Ich denke da muss sich nochmal ein Entwickler drum kümmern und das anschauen.
Danke!

[Joel]

Hallo,
evtl. braucht die App eine Bewegung nach außerhalb des Radius und ein Eintreten? (was bei der alten App nicht so war.)
Nach der Rückkehr und Verlassen und EIntreten fand ich das in den DP vor:

Die Zeitstempel entsprachen der Zeit der Rückkehr!

Nur so eine Vermutung...?

[Ephi]

@Joel sagte:

Hallo,
evtl. braucht die App eine Bewegung nach außerhalb des Radius und ein Eintreten? (was bei der alten App nicht so war.)
Nach der Rückkehr und Verlassen und EIntreten fand ich das in den DP vor:

Die Zeitstempel entsprachen der Zeit der Rückkehr!

Nur so eine Vermutung...?

Sieht so aus. Bei meinen weiteren Tests heute hat Geofence bislang einwandfrei funktioniert.

[Bluefox]

@PRO84 sagte:

@Bluefox sagte:

@PRO84 sagte:

@Bluefox sagte:

@PRO84 sagte:

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 auf https://xxx.ddnss.de:8082

Erst 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

[PRO84]

@Bluefox sagte:

@PRO84 sagte:

@Bluefox sagte:

@PRO84 sagte:

@Bluefox sagte:

@PRO84 sagte:

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 auf https://xxx.ddnss.de:8082

Erst 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

Mit einem Browser geht der remote Zugriff problemlos. Ich weiss nicht was ich noch ausprobieren könnte…

Ich habe bei den Remote-Einstellungen:
Typ: eigene URL
URL: http://meineDynDNSAdresse:8082 (natürlich die korrekte Adresse)
Login: „gleicher User wie lokal“
Password: „gleiches Password wie lokal“

BTW: sollen wir das nicht per Mail diskutieren um diesen Thread nicht noch länger zu machen? Sobald das Problem gelöst ist könnten wir das hier wieder veröffentlichen…

[Joel]

@Ephi

@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?

[Ephi]

@joel

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

[Joel]

@Ephi
Super, danke, hab ich nun auch mal deaktiviert. Ich beobachte...

[Bluefox]

@Joel sagte:

@Ephi

@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

[Joel]

@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

[Ephi]

Ephi sagte:

@bluefox

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.

@bluefox

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.

[stenmic]

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

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

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

[Bluefox]

@stenmic sagte:

<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?

[stenmic]

@Bluefox sagte:

@stenmic sagte:

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

[PRO84]

@Bluefox sagte:

@PRO84 sagte:

@Bluefox sagte:

@PRO84 sagte:

@Bluefox sagte:

@PRO84 sagte:

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 auf https://xxx.ddnss.de:8082

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

[Bluefox]

@PRO84 sagte:

@Bluefox sagte:

@PRO84 sagte:

@Bluefox sagte:

@PRO84 sagte:

@Bluefox sagte:

@PRO84 sagte:

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 auf https://xxx.ddnss.de:8082

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

[PRO84]

@Bluefox sagte:

@PRO84 sagte:

@Bluefox sagte:

@PRO84 sagte:

@Bluefox sagte:

@PRO84 sagte:

@Bluefox sagte:

@PRO84 sagte:

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 auf https://xxx.ddnss.de:8082

Erst 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?

[Joel]

@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!

[Bluefox]

@stenmic sagte:

@Bluefox sagte:

@stenmic sagte:

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

[stenmic]

@Bluefox da muss ich wohl noch ein bisschen warten :) heute morgen wurde auf 2.3.2 aktualisiert.