Alles klar. Das hatte ich nicht gesehen. Und stimmt. Bei mir geht das klassische Webfront auf dem iPad auch nicht mehr. Ich denke aber, dass es sich um das gleiche oder ein ähnliches Problem handelt…
Spannenderweise klappt das Öffnen des klassischen Webfronts auf dem iPad sowohl im Firefox als auch im Opera-Browser.
und noch eine Erkenntnis zur neuen Visu. Wenn ich das Webfront sofort auswähle, klappt der Ladeprozess immer. Wenn ich mit der Auswahl erst einige Sekunden warte, klappt der Ladeprozess nie. Das kann also kein Problem von Safari sein.
…und noch ein Hinweis, der hoffentlich zur Lösung beiträgt:
Normalerweise nutze ich meine komplett selbstgemachte Visu über hook und nutze auch dort den Websocket. Das funktioniert sowohl mit als auch ohne ssl-Verschlüsselung einwandfrei in Safari und auch als Web-App.
Achtung unproduktiver Beitrag:
Ich verfolge das Thema hier nun schon seit November, d.h. seit das Problem aufgetreten ist.
Ich finde es persönlich äußerst dramatisch, dass es trotz kommerzieller Basis der Software den
Entwicklern offensichtlich nicht möglich ist eine zufriedenstellende Lösung herbeizuführen.
Ständig wird auf SSL Webserver usw. abgeschoben. Dass es in dem Kontext aber zu weiterführenden Problemen (Cross Site z.B.) kommen kann ist offenbar egal.
Stattdessen wird an (zumindest für mich) sinnlosen Kachelfirlefanz rumentwickelt, wo ich
keinerlei Innovation erkennen kann. Kümmert euch mal um Systemintegrationen bzw. effizientere Kommunikation oder Dokumentation. Wenn ich Kacheln will gibts Marktbegleiter.
Apropos Markbegleiter, die haben übrigens kein Problem mit neuem IOS…
Die einzigen meines Erachtens produktiven und wirklich nützlichen Innovationen (/Module) kommen von freien (!) Entwicklern aus der Community, die NICHT dafür bezahlt werden.
Bitte nicht falsch verstehen, ich bin seit Jahrzehnten Symcon Fan, habe einige Systeme am laufen und entwickle auch selber auf der Basis. Aber langsam sehe ich das Ende der Fahnenstange, wenn die Entwicklung so weiter geht.
Sorry, musste jetzt mal raus.
NACHTRAG:
Eventuell war ich etwas zu scharf in meinem Statement oben. Es gibt Tage da muss der Druck
in irgendeine Richtung raus und wenn ich dann im Forum ständig irgendwelche Frickelbeiträge und Pfuschereien (die eben auch ggf. weiteren Impact verursachen) lesen muss und vom (bezahlten) Hersteller auch nach Monaten kein konkreter, klarer FAQ Eintrag bzw. saubere Dokumentation zum Thema finden kann, kommt schon etwas Frust auf.
Nach ständigem bohren, meckern und Schuldzuweisungen ist’s ja nun raus:
Aufruf des Webfront über DNS-Name statt IP , fertig.
Na das war / ist doch nicht schwierig und sollte auch von der FritzBox Fraktion anhand sauberer Dokumentation umsetzbar sein.
Zu lange Rede, und eigentlich kurzer Sinn:
Ich erwarte von einem kommerziellen (und deutschen !) Produkt professionelle Kommunikation & vor allem durchgängige Dokumentation.
Schade, dass du so einen Frust schiebst. Ich für meinen Teil bin hochzufrieden mit Symcon und dem was es kann. Ich kenne kaum ein Forum, in dem die Entwickler so präsent sind wie hier. Für jedes Problem wird nach Lösungen gesucht. Und wenn es wie hier einfach länger dauert, weil die Lösung nicht auf der Hand liegt, dann kann ich da gut mit leben. Dafür weiß ich zu genau aus eigener Erfahrung, wie viel Zeit man mit der Suche nach sporadischen oder aus anderen Gründen nicht nachvollziehbaren Fehlern versenken kann.
Ich habe großen Respekt vor der Leistung der Symcon-Entwickler. Sorry, aber das muss auch mal gesagt werden.
Grüße
Jürgen
Ich bin jetzt bei diesem Workaround, aber was ist mit dem nachfolgenden Satz gemeint? Was konkret ist zu tun? Ich kann und werde nix am Netzwerk ändern, geht das dann trotzdem?
IP v4 Adresse ist eingetragen für Autostart, aber das alleine genügt nicht. Was nun?
Versucht gemäß dieser Anleitung und nach 30 Minuten aufgegeben. Beim Starten kommen irgendwelche Meldungen was mit dem Zertikat nicht stimmt, außerdem irritiert der Text in der Anleitung “Damit Browser ein Zertifikat akzeptiert muss IP-Symcon über eine öffentliche Domain zugreifbar und ein von einer anerkannten Zertifizierungsstelle ausgestelltes Zertifikat vorhanden sein.”
Das ist doch alles Mist. Warum funktioniert IPS mit dem inzwischen etliche Monate alten iOS/iPadOS nicht out of the box?
Frag doch mal bei Apple nach, ob Sie auf den Stand von vorher zurück kehren? Der Zwang für verschlüsselte Websockets kommt ja von Apple.
Du kannst ganz ohne Anleitung ein Zertifikat erstellen. Das ist seit einigen Versionen (vmtl. mindestens 9 Monate) in IP-Symcon auf Knopfdruck drin:
Diesem Zertifikat musst du dann manuell in deinem iPad vertrauen.
Damit das automatisch geht, muss es von einer im Browser hinterlegten (das kann man zumindest auf Win, Linux und Android auch selbst) Zertifizierungsstelle signiert sein.
Soll das eine öffentliche Zertifizierungsstelle (die der Browser bereits kennt) sein, muss es zwangsweise eine Domain sein, weil die - insbesondere interne - IP-Adressen nicht signieren.
Danke, Tobias, aber ich komme trotzdem nicht weiter. Ich kann dir Workflows für Chipsimulation programmieren, das Webserverthema ist nicht mein Thema.
Du möchtest eine Secure Verbindung aufbauen. Daher muss der Pfad auch httpS statt http sein. Da Port 443 der Defaultport ist, kannst du dir dann auch die Angabe des Ports sparen. Also sowas wie https://localhost/legacy (vmtl mit / am Ende?)
Danke, das war der Fehler.
Die nächste Hürde ist nun, dass man im Webfront immer die Passwortabfrage bekommt, weil das iPad offenbar über IP v6 verbunden ist und damit die IP v4 Whitelist nicht greift.
Edit: mit manuell installiertem Zertifikat und über https:// lädt das Webfront in Safari immer noch ewig, das hat’s also nicht wirklich gebracht.
Ich habe kein Apple Gerät, daher kann ich das leider hier nicht nachstellen und dich weiter unterstützen.
Ich habe mir zur Bedienung der Verwaltungskonsole, dem Webfront und zur Bearbeitung von Shellys folgenden „Krücke“ gebaut:
Im Proxmoxrechner habe ich eine VM mit Ubuntu-Desktop, einer graphischen Oberfläche und xrdp. Auf dem iPad rufe ich mit RDP die VM auf und habe dort auf dem Desktop einen Link zur Verwaltungskonsole.
Vorteil durch diesen Aufruf der Verwaltungskonsole ist, dass ich per Touch einen Mauszeiger bedienen kann.
Vor dieser Lösung hatte ich Symcon auf einem Windowsrechner und dort die Prokonsole installiert. Aufruf vom iPad war ebenfalls mit RDP.
Vielleicht sollte ich nochmal von vorne anfangen und erklären, was der aktuelle Zustand ist und was ich erreichen möchte.
Bisher lief bei mir das Browser-Webfront auf dem iPad mit Safari als Web-App (sprich Browser als Vollbild ohne URL-Leiste etc.).
Der Grund, das so zu nutzen: eine häufige Anwendung ist bei mir die Darstellung von Diagrammen und bei Verwendung der Webfront-App (die alte App aus dem Appstore) kann man Diagramme nicht im Hochformat anzeigen lassen.
Diese willkürliche Einschränkung mag vor 10 Jahren für Mini-Displays sinnvoll gewesen sein, heute nervt es einfach, das iPad für Diagramme drehen zu müssen wenn der Rest des Webfront für Hochformat ausgelegt ist.
Mit dem aktuelle iOS/iPadOS kann Apps auch im Fenster darstellen, je nach manuell reduzierter Fenstergröße funktioniert es dann (Fenster hat ein Querformat-Seitenverhältnis) oder es gibt die Hochformat-Bitte-Drehen-Anzeige oder Symcon stolpert über die Fenstergröße.
Leider hat die Variante mit dem verkleinerten Querformat-Fenster den Nachteil, dass die normalen Webfront-Listen wegen automatischer Schriftgröße nicht optimal dargestellt werden. Da müsste man also ständig an der Fenstergröße rumbasteln.
Um dieser manuellen Fenstergrößen-Schieberei zu entgehen konnte man bisher das Webfront im Browser darstellen, als Web-App war das im Vollformat und insoweit eigentlich die bessere Alternative zur App. So hatte es bisher funktioniert, vor iOS/iPadOS 26. Mit dem aktuellen iOS/iPadOS 26 lädt das Webfront aber “ewig”, wie oben diskutiert.
Gesucht war nun eine einfache, praxisgerechte Lösung mit den folgenden Randbedingungen:
Das sind mMn keine fancy Spezialwünsche sondern Basisfunktionalität.
Was funktioniert ist die Verwendung eines alternativen Browsers (im Screenshot Firefox), aber eben nicht als Web-App im Vollbild ohne die platzraubende Browserleiste.
Das ist nicht so richtig schön, weil man eben viel Platz auf dem Dsiplay verliert:
Ich würde liebend gerne auf die Browserlösung verzichten, wenn die Webfront-App in der Lage wäre, Diagramme auch im Hochformat darzustellen. Also wenn die bisherige willkürliche Limitierung auf Querformat-Diagramme einfach entfernt würde.
unter Windows im Menü
gibt es vielleicht auch ähnlich unter iOS.
Ich möchte nicht unhöflich wirken, aber solche Lösungsvorschläge helfen wirklich nicht weiter. Es gibt hier spezielle Besonderheiten wie z.B. die Safari-Engine, die auf iOS auch bei anderen Browsern unter der Haube steckt, und andererseits ist die Vollbild-Lösung die bereits erwähnte Web-App, die wie bereits erwähnt ewig lädt (aus Safari erzeugt) bzw. nicht zur Verfügung steht (andere Browser). Extrapolierte Ideen aus anderen Umgebungen werden hier kaum weiterhelfen.
An welcher Stelle hast du denn das Zertifikat auf dem ipad hinterlegt?
So wie von Apple dokumentiert. Aber du scheinst mit deinem https:// Lösungsansatz ohnehin auf dem falschen Pfad zu sein, davon hatte ich mich verwirren lassen. @paresy hatte oben bereits dokumentiert dass das keinen Unterschied macht, das kann ich bestätigen. Es verkompliziert nur das Setup, ohne Vorteile zu bringen.
Der Lösungsansatz geht wie dort dokumentiert über Hostname anstatt IP, das funktioniert und man kann dann auch eine Webapp draus machen, bekommt also eine 1-Klick-Lösung für Vollbild … fast. Es verbleibt dann das Problem mit dem (fehlenden) Auto-Login bei IP v6, man muss leider immer das Passwort eingeben.
Kann dein Router denn keine eigenen DNS Einträge? Sowas wie ‚meinsymcon.volker‘? Hier dann nur eine IPv4 hinterlegen.
Android kann Websocket als Webapp je nach Browser nurnoch über ssl. Dabei ist der Name dann aber egal. Macht echt jeder Hersteller anders. Hier als Nieschenhersteller sich an ALLE größeren Hersteller anpassen zu müssen ist halt echt eine Herausforderung.
Nein, Fritzbox. Ich werde hier am Netzwerk auch nichts ändern, um Workarounds für Symcon zu bauen.
