EVCC <-> SMA - VLAN übergreifende Kommunikation

    Hey zusammen,

    Ich hätte da mal wieder eine Herausforderung. Mit der neuen PV Anlage, eAuto usw habe ich jetzt EVCC (Software für Energiemgmt) auf meinem Raspberry installiert.

    Ich versuche das folgende Szenario so zu beschreiben, dass die Hersteller/Software die involviert sind, eigentlich für die Lösungsfindung nicht zwingend notwendig sind, da es hier um reine Kommunikationswege / MultiCast geht.

    Der Raspberry mit der Software EVCC ist im VLAN 10 (privates Netzwerk)

    Die SMA Komponenten (Wechselrichter und Sunny Home Manager) befinden sich im VLAN 20 (IoT Netzwerk)

    Damit meine Wallbox im Sunny Portal (Administrations-Website für SMA) als neues Gerät erkannt wird, unterhalten sich beide Komponenten wohl über MultiCast.
    Ob das jetzt nur von der Software EVCC oder nur von SMA oder von beiden kommt, konnte ich nicht herausfinden.
    Jedenfalls erkennt das Sunny Portal beim Netzscan diese „Kommunikation“ und zeigt die Wallbox als „neues Gerät“ an. Passt!

    Durch die VLAN-Trennung ist das aber ohne „spezielles Wissen“ offensichtlich nicht möglich.
    Jedenfalls habe ich heute Stunden damit verbracht, das hinzubekommen.
    Resultat: Selbst wenn ich alle Firewall-Regeln und IGMP Snooping deaktiviere, hat das Portal keine Geräte finden können.
    Erst als ich die SMA Komponenten ins gleiche VLAN wie den Raspberry (mit EVCC) gepackt habe, wurde die Wallbox beim Scan sofort erkannt und konnte hinzugefügt werden.
    Gemäß dem Ausschlußverfahren ist also das Problem = Geräte in unterschiedlichen VLANs!

    Nun zur Frage - was muss man wie einstellen, damit diese Kommunikation auch VLAN übergreifend (also zwischen VLAN 10 und VLAN 20) funktioniert.
    Aus meiner Sicht muss sowas doch technisch möglich sein, ohne die Geräte zwingend im selben VLAN zu betreiben.

    Vielleicht hat einer ja das gleiche Konstrukt daheim oder kennt sich so gut mit Netzwerktechnik aus, um hierfür eine Lösung zu haben.

    Vielen Dank im Voraus.

    Wenn es keine Regeln in Deiner Firewall gibt, die Verkehr zwischen VLAN 10 und VLAN 20 verbieten, können prinzipiell alle Geräte beider VLANs miteinander kommunizieren. Mehr Öffnung geht an dieser Stelle dann gar nicht.

    In vernünftig designten Geräten, die über Netzwerke kommunizieren sollen, kann man Zieladressen manuell angeben. Prüfe, ob dies bei Dir möglich ist und trage die jeweiligen Adressen ein.

    In schlecht designten Geräten kann man lediglich "das Netzwerk durchsuchen", und diese Suche ist dann auf das Subnetz begrenzt, in dem das Gerät sich befindet. In so einem Fall hast Du keine Chance, Dein Vorhaben umzusetzen. Du kannst höchsten den Hersteller bitten, ein Firmwareupdate mit entsprechender Funktionserweiterung zu entwickeln.

    Ich habe zwar eine „Block VLAN 20 zu VLAN 10“ Regel (damit die IoT Geräte mein privates Netz nichts ausspähen), aber die hatte ich bei der Fehlersuche ja extra pausiert.

    Ich kann zwar in der Software von SMA eine andere IP als „Direkte Zählerkommunikation“ angeben - dort habe ich die IP vom Rasperry/EVCC eingetragen - aber das hat auch nichts gebracht.

    Andersrum, also EVCC genau sagen, wo sich die SMA Komponente befindet, geht leider nicht

    Mir sind noch zwei andere Sachen eingefallen

    1) Die Ports, an denen die SMA Komponenten hängen, sind bei „VLAN Management mit Tag“ noch auf „alles blockieren“ gestellt.
    Nur der Port vom Raspberry/EVCC steht auf „Alles zulassen“. Könnte das auch Teil des Problems sein? Hab das mit dieser Einstellung nie wirklich kapiert ;)

    2) Guck mal hier: https://my.sma-service.com/sfc/servlet.sh…ationContext=S1

    Das läuft angeblich alles über das SEMP Protokoll. Port UDP 9765. Vielleicht kann ich damit die Paket ausschließlich zum richtigen Empfänger (SMA) schicken und er „erkennt“ endlich das Gerät ;)

    Ich kenne diese Geräte nicht, die Du versucht zu vernetzen, daher kann ich diesbezüglich leider keine genaueren Tipps geben. Die von Dir verlinkte Beschreibung geht ja auch nicht näher ins Detail.

    In Sachen Unifi kann ich Dir aber mit Gewissheit sagen, dass die Werkseinstellungen gar keine Kommunikation zwischen VLANs verhindern. Wenn also sämtliche Firewallregeln gelöscht oder pausiert sind und man 30 Sekunden nach Drücken des "Speichern"-Knopfs gewartet hat, bis das Gateway die neue Konfiguration übernommen hat, wird Dein Netzwerk selbst alles Interne durchlassen.

    Quote from Maddeen

    1) Die Ports, an denen die SMA Komponenten hängen, sind bei „VLAN Management mit Tag“ noch auf „alles blockieren“ gestellt.
    Nur der Port vom Raspberry/EVCC steht auf „Alles zulassen“. Könnte das auch Teil des Problems sein? Hab das mit dieser Einstellung nie wirklich kapiert ;)

    Die Switchport-Einstellungen bestimmen, welche der VLANs am jeweiligen Port erreichbar sind. Für sämtliche Endgeräte sollte dort nativ das Netzwerk ausgewählt sein, in dem das Gerät arbeiten soll, plus "Block all" (also "alles blockieren"). Ports für Switches und AccessPoints werden mit "alles zulassen" konfiguriert, es sei denn, man möchte hier bestimmte Beschränkungen durchsetzen, was im Heimnetz aber nur selten nötig ist.

    Mit Deinem Verbindungsproblem haben diese Einstellungen nichts zu tun, denn die Geräte selbst müssen nur von dem Netz (VLAN) etwas wissen, in dem sie sich selbst befinden. Dementsprechend braucht der Switchport auch keine Infos über andere VLANs bereitstellen. Sobald ein Gerät eine Ressource in einem anderen VLAN erreichen möchte, muss es dazu den Router befragen, der ja alle VLANs kennt. Ansonsten wäre die Firewall im Router ja auch wirkungslos, wenn Kommunikation direkt zwischen Geräten aus verschiedenen VLANs stattfinden würde.

    Was durchaus sein kann ist, dass Deine "Problemgeräte" aus Sicherheitsgründen nur Anfragen aus ihrem eigenen Subnetz entgegen nehmen, also eine eigene Firewall auf ihnen läuft. Das kann aber nur der Hersteller sagen.


    Möglicher Workaround, falls Du die Kommunikation VLAN-übergreifend nicht hinbekommst: Vielleicht kann man im Raspberry VLAN-Tags konfigurieren oder notfalls eine zusätzliche Netzwerkkarte per USB anhängen. In diesem Fall könntest Du den Raspberry sowohl in VLAN 10, als auch in VLAN 20 erreichbar machen.

    Bigdog71 Hatte ich schon aktiviert. Daran lags nicht

    Nutzer666 - bist du dir sicher? Wenn ich das UI korrekt verstehe, ist das schon "build in" in der UDM-Pro. Siehe Screen - rote Markierung.

    Hier werde ich auch mal mit der Einstellung "Forward Unknown Multicast Traffic" rumspielen - gelbe Markierung.

    Wenn die ÜBersetzung des Features korrekt ist, müsste das jedenfalls die Lösung sein, das MultiCast eben nicht gedropt wird sondern so gesteuert, dass es auch dort ankommt, wo ich es brauche.

    100% sicher bin ich mir nicht, jedoch habe ich eben genau diese Probleme, wewegen ich jetzt alle Geräte die Multicast wollen, in das slebe VLAN geworfen habe.


    Kann gut sein, dass die Entwickler da mittlerweile nachgearbeitet haben. Meine Test liegen auch schon einige Zeit zurück.

    AEG - Auschalten, einschalten -> geht

    Kurz:

    UNifi kann kein Multicast Routing. Einzige Ausnahme ist der IMGP Proxy gegenüber dem WAN für IPTV.

    Lang:
    eigentlich das gleiche. Aber diese ganzen IGMP, Flood den Port bei unkown Multicast,
    bezieht sich auf das VLAN selber und eher ob die Switchports den traffic bekommen oder nur
    die die sich auch über IGMP den Multicast "Anmelden".

    Sprich da sind L2 Einstellungen um zu verhindern oder zu ermöglichen das Ports den Traffic bekommen.
    MDNS und nur MDNS hat nen Proxy für Intervlan mit an Board. Das ist aber halt dann auch nur für MDNS
    welcher ggf nachgefiltert werden kann um z.B Drucker zu unterbinden.


    Lösung:
    Ab ins gleiche VLAN
    oder
    Router hinstellen der Multicast Routing machen kann (PIM Dienst auf ner Linux Kiste)

    Würde Persönlich auch den EVCC PI ins gleiche VLAN Stopfen und dann den Vlan Externen zugriff auf die nötigen Dinge erlauben.
    oder da halt ne VLAN Config drauf dengeln und den im "richtigen" VLAN auch lauschen lassen.

    Aber jede wie er will... meins währe es nicht hier (Achtung trigger ducrh Übertreibung) 1000 Schachteln am laufen zu haben.
    zumal ja auch nicht 100% (zumindestens mir) klar ist ob das nacktes Multicast Broadcast ist oder IGMPvX.

    Bzw. wie die Unifi Switche reagieren und ggf. doch anfangen das Multicast auf allen Ports rauszuhauen und
    mann sich dann wundert das alles Langsam ist wenn das Auto Lädt :-) (ja immer noch Übertreibung).

    Aber dem bastelwilligen Netzwerkenden ist nichts zu schwör :-)

    So schauts... leider habe ich auch noch kein 100% klares Feedback, ob diese Integration überhaupt einen Mehrwert bringt außer Verbrauchsstatistiken zu empfangen. Sollte dem nämlich wirklich so sein, geht mir die Statistik am Pöppes vorbei und ich habe lieber ein sauber gekapseltes Netzwerk.

    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.

    iLion - das ist bezüglich der generellen Einbindung des SHM in EVCC.
    Das hatte bei mir ja direkt von Beginn an tadellos funktioniert. Mit VLAN-Trennung, aktiviertem IGMP Snooping und all den anderen sinnvollen Einstellungen, die man NICHT deaktivieren sollte, um Geräte in Betrieb zu nehmen.

    Hier gehts aber um die andere Richtung - von EVCC Richtung SHM - und das hatte nicht funktioniert.

    ABER - deswegen auch "HATTE" - ich kann jetzt noch einen zur Verwirrung drauf setzen und bin gespannt, ob das einer erklären kann ;)

    Ich hatte ja die SMA Komponenten (WR und SHM) ins gleiche VLAN wie EVCC gehoben, um zu gucken, ob es daran lag.
    Dem war ja wohl auch so, weil das SunnyPortal nach dieser Aktion die Wallbox bzw. Smart Appliance SOFORT gefunden und eingebunden hat.

    Da ich aber jetzt den Mehrwert (=keiner) dieser Integration kenne, habe ich gestern die SMA Komponenten wieder zurück ins ordinäre, gekapselte VLAN gepackt. Und jetzt kommts - was glaubt ihr, was NICHT passiert ist?!?

    Genau - die Smart Appliance ist lt. Sunny Portal auch jetzt noch (also fast 24h später) weiterhin aktiv, Status grün usw. (siehe screenshots)
    Mehr kann man damit ja eh nicht machen. Und genau hier ist für meine Netzwerkkenntnisse "Schicht im Schacht". Wie kann sowas sein?

    Wird diese Integration ggf. nur Initial via MultiCast gelöst und danach unterhalten sich die Geräte z.B. auf Basis des Netznamens oder Mac-Adresse?
    Auf Basis der IP kann es ja nicht sein, da sich WR und SHM jetzt wieder im 10.30.0.0 Netz befinden und der Pi mit EVCC im 10.20.0.0.

    Denn ich hatte ja schon vorher extra eine FW-Regel angelegt, die die Kommunikation (in beide Richtungen) zwischen den SMA Komponenten im 10.30.0.0 zum Pi/EVCC im 10.20.0.0-Netz erlaubt.

    Würde mich mal interessieren, ob dazu jemand eine Idee hat.


    Quote from Maddeen

    auf Basis des Netznamens oder Mac-Adresse?

    Erst recht nicht. VLAN A hat von den MAC in VLANb keine Ahnung. UNifi selber kann auch "IP" zwischen den VLAN Routen.
    Fake anzeige ? Von hinten übers Internet Verbunde ? "Rückfall auf Unicast" ? Statt "echten" mutlicast nur sowas
    wie MDNS der einen Dienst Publiziert der MDNS helper den aber nicht sieht (weil er nicht die mdns Adressen nutzt ?)

    Letzten ende habe ich nix was auf Wall/Solar/Wechsel in Namen hört. Daher auch keine Ahnung

    Würde wohl auf dem gateway anfangen und Pakete mitschneiden und mit Wireschark auswerten um rauszufinden was wie
    wohin und letzten endes über welchen Protokoll geschickt wird (also im L2/L3 sinne)

    Alles andere und ohne Saubere Doku ist alles andere wohl auch nur raten auf hohen Level.

    Quote from Maddeen

    Wie kann sowas sein?

    Hat zwar nur bedingt mit dem eigentlichen Thema zu tun, aber solch ein Phänomen hatte ich bei einem Heimkinoverszärker von Denon mit HEOS.

    Ich habe zwei VLANs, einmal Privat und einmal Medien. In Privat sind die PCs, Handys und das NAS. In Medien der besagte Heimkinoverstärker, SAT-Receiver, BluRay-Player, etc. .

    Nach der Neueinrichtung des Netzwerks habe ich versucht, den Heimkinoverstärker mit der HEOS-App auf dem Handy zu verbinden, mit dem Resultat, dass dieser nicht gefunden werden konnte. Erst, nachdem ich das Handy in das Medien-VLAN verbunden hatte, ging es.

    Dann das Handy wieder zurück in das VLAN Privat und die Verbindung der HEOS-App zum Heimkinoverstärker blieb bestehen.

    Erklären kann ich mir das auch nicht, aber seitdem funktioniert es.

    gierig DAS habe ich mir auch gedacht, aber gemäß Mr. Spock, dass wenn man alles ausgeschlossen hat, das unglaubliche wahr sein muss, ist es das. Hab vorhin geladen - Resultat: EVCC macht das was man erwartet und das SuinyPortal ebenfalls - siehe Screenshots. 🤷

    Ist mir jetzt auch egal - hätte sowieso darauf verzichtet, da der Mehrwert nicht gegeben ist.


    Nur zum Abschluss - Nach dem Reboot des SHM war der (positive) Spuk vorbei. ;) Gerät nicht mehr erreichbar.

    Thema kann geschlossen werden, da ich auf Grund des nicht vorhandenen Mehrwerts für mich persönlich, hier keine weiteren Maßnahmen ergreifen werde ;)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login