Ich habe die Erfahrung gemacht, dass man sofort entscheiden muss, ob man eine Firmware aktualisieren möchte oder halt nicht, solange sie im "Stage Rollout" ist. Ignoriert man die Meldung, dann kommt sie erst regulär wieder, wenn die endgültige Freigabe erfolgt ist.
Die Alternative hat DoPe auch benannt. Kann man mit dem Controller 10.1.85 auch so machen.
Ich konnte gerade eben einen bestellen.
Da ich auch evcc mit Sunny Home Manager 2.0 und zwei SMA Wechselrichtern und einer Drittanbieter-Wallbox nutze, verwirren mich die Aussagen wie "Andersrum, also EVCC genau sagen, wo sich die SMA Komponente befindet, geht leider nicht"
Das ist z.B. das Template für die Einbindung des Sunny Home Managers aus der evcc-Dokumentation:
meters:
- name: my_grid
type: template
template: sma-home-manager
usage: grid
host: 192.0.2.2 # IP-Adresse oder Hostname
Gleiches findet man für die Wechselrichter, die per Modus angesprochen werden müssen. evcc verwendet den Sunny Home Manager als Messstelle für Verbrauch und Einspeisung und die Wechselrichter für die Messung der Erzeugung. Ohne die Werte kann auch keine angepasste Überschussnutzung an der Wallbox oder anderen Verbrauchern erfolgen.
SMA nutzt Multicast, daher muss an dem genutzten Netzwerk IGMP Snooping deaktiviert sein. Die Wallbox kann dann als Verbraucher zusätzlich von evcc im Sunny Portal genutzt werden.
Ähnliche Antwort, wenn Du einen 3D-Drucker besitzt, gibt es bei Printables eine kostenlose Vorlage.
Entweder liegt es an deinem verwendeten AP oder Einstellungen.
Unabhängig davon ist halt auch Roaming ein Problem. Klar mag es an den Einstellungen liegen. Deswegen teste ich ja seit Wochen immer wieder neue Konfigurationen. Ich finde es nur traurig, wenn seit Monaten Beta-Firmware für die Geräte vorliegt, Unifi aber keine Anstalten macht aus diesen Finale Versionen zu machen. Heute habe ich die Release-Notes zur neuen Firmware für die Switches durchgesehen. Da sind ja z.B. auch viele Fehler behoben worden.
Schau Dir mal IPv64.net an. Dort gibt es den Cloud Router, mit eingeschränktem Traffic-Volumen auch erst einmal kostenfrei. Der sollte Dein Problem eleganter (und vielleicht auch sicherer) lösen.
Also bei mir ist der Fels in der Brandung zu Sand zerbröselt. Ich habe über das Haus verteilt vier Access-Points und das Thema Roaming treibt mich immer noch in den Wahnsinn. Dabei habe ich schon etliche Optionen (Band Steering, Fast Roaming, BSS Transition, etc) immer mal wieder aus- und eingeschaltet um zu schauen, ob sich etwas verbessert. Teilweise verlieren die Geräte das WLAN, ich lande dann im LTE-Netz nur um dann bei manueller Auswahl des WLAN stabil an der gleichen Stelle Netz zu haben. Einmal hatte ich vor kurzem sogar den Effekt, dass sich kein Gerät in das WLAN eingewählt hat, wenn ich nach Hause gekommen bin. Da hatte ich UAPSD ausprobiert. Der Controller sagt aber, die Dichte der Geräte über die Fläche wäre gut. Es sind alles Apple-Geräte auf dem aktuellsten Softwarestand. Und seit der letzten finalen Firmware aus dem letzten Jahr sind ja auch einige EA-Versionen für die 6er-Geräte gekommen, die aber nie RC oder Stable wurden. Dabei stehen ja auch in diesem Thread die Release-Notes mit etlichen behobenen Fehlern. Ich habe aber bewusst im Moment nur offizielle Firmware auf den Geräten. Auf noch mehr Experiment habe ich keine Lust. Parallel suche ich ja noch nach der Ursache für die WLAN-Call-Probleme.
Rückmeldung nach einigen Tagen. Alle Maßnahmen haben nichts gebracht. Ich höre weiterhin in den Gesprächen die jeweiligen Partner perfekt, diese mich nach einer unbestimmten Zeit abgehackt. Aktueller Stand auf dem iPhone iOS 18.6.1. Allerdings brachte diese Aktualisierung ja auch nur Änderungen bei der VO2max-Berechnung über die Apple-Watch.
Sieht aus als ob Du eine Diskussion zu einem anderen Thema kaperst ...
Warte eben, der Thread begann mit der Aussage:
habe hier in den letzten Wochen extreme Probleme beim WLAN Call. Bis vor einigen Wochen gab es hier keine Probleme.
Und hier wurde darüber debattiert, ob WLAN Call überhaupt eingeschaltet ist oder nicht und ob das WLAN Signal stark ist.
Da ich ebenfalls große Probleme mit dem WLAN Call habe, habe ich gesucht und diesen Thread gefunden. Bevor ich halt einen neuen Thread aufmache, nutze ich den vorhandenen und offensichtlich noch nicht mit einer Lösung versehenen.
Aber egal. Was ich bisher bei mir nun gemacht habe ist in den QoS-Einstellungen noch "Wi-Fi Call" hinzuzufügen, im WLAN alle Optionen abzuschalten, wie Bevorzugung von 5 Ghz, Roaming Optionen, usw. und zuletzt die Netzwerkeinstellungen meines iPhone zurückzusetzen. Nun muss ich die nächsten Telefonate abwarten.
Die Bandbreite wird es nicht sein. Ich habe einmal eine VDSL 250/50 Leitung und einmal Glasfaser 100/100. Es liefen auch keine Uploads zum betreffenden Zeitpunkt. Ach so, die Lastverteilung zwischen den beiden Leitungen habe ich auch noch auf Failover gestellt, dass nun nur die VDSL verwendet wird.
Letzten Endes war der Abstand zwischen Telefon und U6 Pro nur wenige Meter in einem freien Raum, der U6 Pro hängt mittig im Raum unter der Decke.
Gibt es hier weitere Ideen? Ich habe seit einiger Zeit das gleiche Problem. UDM Pro mit Unifi OS 4.3.6, Network 9.3.45, U6 Pro (Firmware 6.6.77) im Wohnbereich, in dem die Probleme in der Regel auftauchen. Weiterhin gibt es im Obergeschoss noch einen U6 Pro und einen U6 Mesh und im Kellergeschoss einen U6 IW, die ebenfalls alle die Firmware 6.6.77 nutzen. Telefon ist ein iPhone 13 Pro Max mit iOS 18.6.
Meine Gesprächspartner sagen, dass ich mich während des Gesprächs von jetzt auf gleich wie ein Roboter anhöre, während ich jedoch die Gegenseite perfekt höre. Die legen dann meistens auf und nach einem erneuten Gesprächsaufbau geht es dann ein paar Minuten, bis das ganze wieder anfängt. Habe leider keinen Zeitpunkt, ab wann das nicht mehr zuverlässig funktioniert hat. Ich bin bei der Telekom Kunde und das Mobilfunknetz ist bei mir auf dem Land im Haus schlecht, so dass WLAN Call immer die funktionierende Rückfalloption war.
Es sind genau 3 mit jeweils 2 unterschiedlichen Modemcodes.
Es sollten 4 sein, STD, MDM1, MDM2 und MDM3.
Nein, beide WAN sind auf DHCPv6. Ich habe aber festgestellt, dass bei der Aktivierung von IPv6 auf einem meiner VLAN dann im Einstellungsbereich des VLAN eine komplette IPv6-Adresse für das Gateway erzeugt wird. Nimmt man ein anderes Netz dazu, ist der Prefix gleich. Also wird wohl schon von der Telekom ein Prefix zugewiesen, aber nicht angezeigt. Denn auch bei aktiviertem IPv6 in den VLAN bleibt die Anzeige beim WAN leer. Vielleicht liegt das daran, dass ich IPv6 schon aktiviert hatte, als das in älteren Controller-Versionen noch nicht zur Darstellung vorgesehen war.
Hallo,
seit Montag habe ich zusätzlich zu meinem VDSL 250-Anschluss bei der Deutschen Telekom auch einen Glasfaseranschluss über MUENET. Meine Dream Maschine Pro ist auf dem letzten Release-Stand (Unifi OS 4.0.6) und Controller 8.3.32. Am WAN1 (Port 9) hängt ein DrayTek Vigor 165, WAN2 (Port 10) ist die Verbindung zum Glasfasermodem. Bei beiden WAN-Anschlüssen ist PPPoE konfiguriert und für IPv6 DHCPv6 mit einer Prefix Delegation Size von 56. Bei der Telekom bleibt in der Spalte zu IPv6 der Eintrag leer. Nur die zugewiesene IPv4-Adresse wird daneben in der IPv4-Spalte angezeigt. Bei MUENET erhalte ich direkt auch den zugewiesenen Prefix angezeigt. Und das ist meine primäre Frage, warum nicht bei der Telekom? Ich habe IPv6 auch deaktiviert, neu aktiviert, keine Änderung. In den Netzwerken ist IPv6 noch nicht aktiviert und WAN2 ist im Moment als Failover konfiguriert. Aufgrund des privaten Adressbereiches und der (bis auf den Upload) schnelleren VDSL-Leitung wollte ich auch keine Verteilung haben. Ist die Delegation Size falsch? Jede Suche hat aber bisher 56 hervorgebracht.
Die Version 7.5.174 wurde auf Release Candidate zurückgestuft, nachdem sie ja eine kurze Zeit offiziell war. Das dürfte hier das Problem sein.
Wenn Du ein Endgerät für WireGuard einrichtest, wird Dir ja eine Konfiguration zum Herunterladen angeboten. In dieser Datei muss man dann die Server-IP-Adresse, die bei wechselnden halt nur Deine aktuelle ist, durch einen DynDNS-Domain-Namen ersetzen. Die so angepasste Konfiguration dann in Dein Endgerät laden. Ich habe auch "nur" ein Telekom-VDSL mit wechselnder IP, nutze aber genau wie LachCraft den DynDNS-Dienst von IPv64.net. Auf der Webseite gibt es eine genaue Anleitung, wie man die UDM konfigurieren muss.
Wenn Du Dich mit Deinem Server im Netz deines Sunny Home Managers befindest, sollte evcc diesen aber bei korrekter Konfiguration direkt über Multicast finden. Eine Anpassung der Adresse oder Port habe ich nicht vorgenommen. Für meine beiden relevanten Systeme verwendet ich jeweils eine eigene Ubuntu Server 22.04 LTS Installation unter Proxmox VE 8.0. evcc ist über das Repository installiert und kann auch aus anderen VLAN über evcc.local:7070 aufgerufen werden. Proxmox ist in meinem Default-Netzwerk, in dem sich auch die UDM Pro befindet. Im Switch ist nichts geblockt, alle VLAN dürfen an den Server. In den Einstellungen der VM habe ich dann nur noch das VLAN-Tag im Netzwerk eingetragen, dass für mein IoT-Netzwerk benötigt wird.
In meinem Fall hat es gereicht, die Server für openHAB und evcc (jeweils ein eigener Server) in das IoT-Netzwerk zu verschieben, in dem auch die SMA-Wechselrichter und der Sunny Home Manager sind. Allerdings habe ich zur Zeit auch noch keine weiteren Firewall-Regeln, über die von Ubiquiti voreingerichteten hinaus, aktiviert. Die Kommunikation klappt dadurch. Als beide Server in einem anderen VLAN eingerichtet waren, ging auch nichts. Das Sonos-Problem ist aber auch mit der letzten Aktualisierung auf 15.6 nicht besser geworden. Handy (iOS) geht, Rechner (macOS) nicht.
Ja, übertragen ist es so bei mir konfiguriert. Bzgl. Sonos habe ich vorhin in den WLAN-Einstellungen z.B. noch Multicast Enhancement aktiviert. Die App auf dem iPhone ging vorher schon und geht immer noch. Die App unter macOS findet weiterhin kein vorhandenes Sonos-System.
Ich hatte drei Regeln, die man in vielen Tutorials findet, im "LAN in" ergänzt:
Accept: Established/Related
Drop: Drop Invalid State
Accept: Allow Main VLAN Access To All VLAN (alle privaten Netzbereiche)
Allerdings habe ich diese Regeln für die Fehlersuche schon länger pausiert. Der Rest ist Unifi-Standard, sowie der Network-Controller die Regeln anlegt. Regeln, um irgendetwas zu unterbinden, wollte ich erst anlegen, wenn alles funktioniert.
Hallo an alle,
meine UDM Pro läuft im Moment mit Unifi OS 3.1.14, Network ist 7.4.162, und der Switch, an dem u.a. die Probleme existieren ist ein USW Pro 48 PoE mit der Firmware 6.5.59. Es geht im wesentlichen zur Zeit um den SMA Sunny Home Manager 2.0 und nebenbei auch um mein Sonos-System. Das Default-Netzwerk habe ich als 192.168.1.0/24 (VLAN 1) eingerichtet, ein IoT-Netzwerk ist als 192.168.2.0/24 (VLAN 2) konfiguriert und die Endgeräte der Familie im 192.168.3.0/24 (VLAN 3). SMA möchte IGMP-Snooping aus haben, was auch auf allen Netzen so konfiguriert ist. Multicast DNS ist für alle Netze an.
Im Netzwerk befinden sich noch zwei (virtuelle) Linux-Server mit openHAB 3.4 und passendem Binding und EVCC. Eigentlich wollte ich beide Linux-Server gerne im Default-Netzwerk haben. Dann erreiche ich zwar Standard-Geräte über ihre IPs in den anderen Netzen, aber der Sunny Home Manager wird nicht erreicht. Verschiebe ich die Linux-Server in das IoT-Netzwerk, wird sofort eine Verbindung hergestellt. Ich muss also ein Problem mit dem Routing der Multicast-Pakete zwischen den VLAN haben. Ich ging ja davon aus, dass das Problem von Unifi mittlerweile gelöst war.
Ähnliches scheint sich mit den Sonos-Lautsprechern abzuspielen. Die sind im Moment im IoT-Netzwerk. Die iOS-Sonos App kann die aus dem Familien-Netzwerk erreichen. Die macOS-Desktop App dagegen findet kein Sonos-System. openHAB kann die Lautsprecher aus dem Default-Netzwerk ebenfalls nicht erreichen, aus dem IoT-Netzwerk dagegen schon. Daher hatte ich bisher den Linux-Server mit einer Netzwerk-Karte im Default-Netzwerk und mit einer zweiten Netzwerk-Karte im IoT-Netzwerk. Dieses Vorgehen half aber nicht beim Sunny Home Manager.
Den Sunny Home Manager habe ich jetzt seit drei Wochen und seit dem suche ich das Netz nach Lösungen ab. Viele Treffer zeigen aber Probleme, die bis zu drei Jahren alt sind und teilweise noch die USGs oder Unifi OS 1.x betreffen, passen also gar nicht mehr.
Sachdienliche Hinweise werden jederzeit aufmerksam entgegengenommen. 
