Hallo, wie kann man in der neuen Android-Kachel-App manuell und sinnvoll den Symcon-Server hinzufügen?
(Ich möchte den Cloud-Connect NICHT nutzen, auch wenn ich laufendes Abo habe!)
http://name.domain.de → geht, aber trotzdem keine Lösung, weil nicht extern erreichbar, Firewall, Proxy natürlich alles nur 443)
In der alten App konnte man einen Host, einen Port und den Haken „Nutze SSL“ eingeben und das hat immer super funktioniert, selbst wenn ich das Netz gewechselt habe. (Verschiedene WLAN, Mobilnetz)
(App und Symcon letzte Stable, SSL-Zertifikat ist offiziell, gültig und wird von der alten App auch akzeptiert!)
Selbst wenn ich den http-Link hinzufüge und die App nutzen will, kommt extrem häufig ein Button „Anderen Server auswählen“ und dann laufen unten irgendwelche Ausgaben und meist bleib es komplett hängen, so dass man die App killen muss und manchmal klappt es nach Wartezeit. Das ist für eine Fernbedienung fürs Haus natürlich sehr unschön. Die alte App war und ist immer sofort einsatzfähig!
Das sollte alles problemlos laufen (zumindest haben wir das eingebaut und getestet ) Wäre es für dich denkbar uns eine Visu (kann auch leer sein) einzurichten und alle Daten an die support@symcon.de zu senden? Dann stellen wir das mal nach und suchen, wo der Fehler ist
PS: Die App präferiert eigentlich, sofern du den „Manuell“ Modus nutzt, diese URL - macht aber einen Fallback auf den Connect Dienst, sofern er an ist. Wenn du diesen niemals nutzen willst, müsstest du diesen quasi deaktivieren. (Braucht du den irgendwie für Alexa o.ä?)
also ich habe gerade die App wieder aufgerufen (letzte Nutzung im Mobilnetz, jetzt zu hause im WLAN) und es kam wieder zu diesem Fehler, siehe Screenshot.
Sieht aus, als würde der Verbindungsaufbau über Connect versucht. Das ergibt aber im WLAN mit manuell hinzugefügtem lokalen Server ja eigentlich keinen Sinn.
Mal abgesehen davon, dass Connect eigentlich auch läuft, weil Alexa-Skill von Euch ja auch dauerhaft funktioniert.
(Ja,aus Richtung Internet ist da eine Fritzbox → Port-Weiterleitung 443 auf eine Opnsense-Firewall mit einem Caddy als Reverse-Proxy → auf die Symcon-Instanz (virtuelles Windows 10 auf Basis exsi) dazwischen. Der DNS wird extern über Dyndns, im WLAN natürlich direkt auf die Maschine aufgelöst.
Klingt kompliziert, aber die Strecke läuft prima, ich komme Remote sowohl auf Webfront und die „alte“ App läuft ja auch fehlerfrei.
Hier ist eher die Frage, warum er nicht direkt auf die 192er Adresse auflöst und verbindet, weil ich zum Zeitpunkt des Screenshots im WLAN war. Das Handy wird den DNS-Cache mit externen IP sicher beim Wechsel ins WLAN verwerfen. Cached Ihr die IP vielleicht irgendwie und verwerft sie nicht beim Reaktivieren der App?
Ich denke @Dr.Niels freut sich über die Connection Logs, die du in den Einstellungen bei der App ganz unten findest. Dann können wir vielleicht mehr sagen, wo der Wurm drin ist. Da die neue App einiges mehr an Magie macht, um die beste Verbindungsstrecke zu ermitteln, als die alte App oder einfach das WebFront (jeweils feste URL), kann es natürlich an allerlei Kleinigkeiten liegen.
Das würden wir tatsächlich ungern tun, da jedes Häkchen Dinge komplizierter macht. Eher würden wir lösen wollen, dass die automatische Erkennung den richtigen Server wählt.
Stellt ihe ein Entscheidungsdiagramn der Magie bereit, damit ich selber erkennen kann, dass und warum die Magie verkackt? Löst nur das Problem nicht. Kann ich die autm Connect Nutzung abschalten und trotzdem Siemens oauth oder alexa über Connect nutzen?
Meine persönliche Meinung:
Den Server in der App richtet man gefühlt einmal im Handy-Leben manuell ein. Ob ich da ein, zwei oder 3 Felder fülle, ist egal. Wir reden ja beim manuellen Hinzufügen über den Expertenmodus, den nur technisch versierte Leute wählen dürften.
Entscheidend ist für mich die Geschwindigkeit, wenn ich die App öffne, weil dann will ich sofort was schalten. Da will ich nicht Sekunden mit Magie vertrödeln. Wenn der Server fest eingestellt ist, könnt ihr einfach so lange Web-Socket-Connects feuern, bis es tut, auch wenn mal eine Verbindung wegen schwachem WLAN verloren geht. Magie probiert dann vielleicht erstmal ein paar Sekunden Connect, scheitert, probiert es zunächst mit, dann ohne https usw. .
Ich bin sehr ungedultig, dann bin ich schon in der alten App wenn das nicht sofort läuft.
Offtopic:
Mich regen die ganzen Hersteller-Apps (Nanoleaf, Philipps Hue, …) einfach total auf, wenn die einen Splash zeigen und erstmal gefühlt 10 Sekunden auf Top-Hardware booten, wenn ich mal schnell ne Lampe einschalten will. Von mir aus gerne 3 hippe Frameworks weniger, sogar hässlicher, aber dafür brutal schneller Start und performance.
Genau deswegen nutze ich IPS und nicht die schrottigen Hersteller-Apps. Es ist ein Lichtschalter. Der soll mir keine animierten tollen wirbelnden Bildchen zeigen sondern verzögerungsfrei einsatzbereit sein. Ich weiß nicht, wer sowas konzipiert. Vermutlich Marketingabteilung … muss toll aussehen.
Das ist mit der Hauptgrund warum ich ipsview nutze. Nix Magie, der ruft die adresse auf die ich will und fertig. Bin ich nicht im wifi bekomme ich ne Meldung.
@paresy
Baut halt x warnungen bei der ersteinrichtung ein aber lasst doch dem user am ende die Entscheidung.
Ich habe es nochmal ein wenig getestet. Wenn ich direkt umschalte, also App öffne, Wechsel UMTS ↔ WLAN – dann laufen unten ein paar Log-Zeilen durch und die App verbindet wieder. Das Problem tritt dann auf, wenn die App nach einer gewissen Zeit erst wieder geöffnet wird.
Vermutung:
Ich nutze ein Samsung S23 und das begrenzt bei Apps im Hintergrund erfahrungsgemäß bezüglich Rechenzeit und Speichernutzung, um Akku zu sparen. Vermutlich ein Energiespar-Problem, indem die WebSocket-Verbindung einfach geschlossen wird. Samsung trickst da mittlerweile ziemlich agressiv wegen den ganzen Apps, die im Hintergrund permanent Verbindungen offen halten und z.B. Werbung nachladen.
Aber beim Öffnen einer App gibt es ja entsprechende Listener, um die Verbindung wieder aufzubauen und genau das funktioniert hier nicht zuverlässig.
Die App zeigt sofort einen Button „anderen Server wählen“ und verbindet nicht neu. Die Connect-Scripte, die sonst unten so blass ablaufen, laufen nicht los!
Wenn ich diesen Button dann betätige, listet die App erst den einzigen Server, dann muss ich das richtige WebFront wählen und danach tut es erst wieder.
Das sind aber viele unnötige Aktionen. Ich habe mich ja bewusst zum manuellen hinzufügen meiner Symcon-URL entschieden und m.E. müsste die App die ganze Zeit versuchen, im Hintergrund neue WebSockets dorthin aufzubauen, bis es funktioniert. Wieso gibt sie auf, tut nichts mehr und zeigt diesen unnötigen Button?
Tatsächlich versucht die App beim erneuten Öffnen sich wieder zu verbinden, aber das schlägt fehl. Möglicherweise versucht sie das zu früh. Dass du danach nochmal in die Serverauswahl musst wundert mich tatsächlich. Dieser sollte eigentlich gleich bleiben… Kannst du mir dazu mal den Debug Log schicken? Den findest du in den Einstellungen der App zum Kopieren und kannst ihn dann hier oder per PM einfügen.
So, danke für das Log! Es wirkt so, als wenn um 10:02 der WebSocket zusammenbricht und der Vorgang des neu verbindens sich dann irgendwie aufhängt. Ich verstehe aber leider nicht ganz warum das so ist. Ich erweitere das Debugging an der Stelle mal ein bisschen.
Prinzipiell wird der Button „Anderen Server wählen“ von Anfang an angezeigt, auch während der Verbindungsprozess noch anläuft. Wenn du beispielsweise weißt, dass der Server nicht mehr erreichbar ist oder sowieso auf einen anderen wechseln möchtest, dann kannst du das darüber tun. Wenn der Verbindungsprozess komplett fehlschlägt, dann kommt ein weiterer Button „Neu verbinden“, der dich mit der aktuellen Visu erneut verbindet.
Aber wie gesagt, das hängt sich bei dir irgendwie auf und ich verstehe noch nicht warum. In der nächsten Beta kommt dann mehr Logging, dann kannst du mir am besten nochmal ein Log schicken.
) Wäre es für dich denkbar uns eine Visu (kann auch leer sein) einzurichten und alle Daten an die 
