Mein Cerbo GX erreicht nach kurzer Zeit das VRM Portal nicht mehr.
Ich weiß auch woran es liegt, nur habe ich keine Ahnung wie/ was ich dagegen tun kann:
Den Cerbo erreiche ich über W-Lan (191.168.178.11), als Grid Meter dient ein Shelly Pro3EM, der Shelly ist auf ein anderes Sub Netz eingerichtet (Shelly:190.167.178.7) und Kommuniziert über Netzwerk Kabel mit dem Cerbo GX (190.168.178.11) dieses Netzwerk Kabel verbindet ausschlieschlich diese beiden geräte, hat also keinerlei Möglichkeit ins weitere Netzwerk/ Internet zu gelangen.
Das VRM Portal wird also über das W-Lan erreicht, was auch anfangs einwandfrei funktioniert, auch erreiche ich den Cerbo aus dem Heimischen Netzwerk ohne Probleme immer.
Nun scheint es aber so das nach einiger Zeit die Netzwerk Verbindung für das VRM Portal über Kabel Priorisiet wird, wie schon geschrieben besteht keine Verbindung über das Kabel zum Netzwerk/ Internet und somit wird das VRM Portal nicht mehr aktualisiert.
Abhilfe schafft für Kurze Zeit wenn ich die Netzwerk Einstellungen, fürs Kabel, auf Automatisch stelle, und Kurze Zeit später wieder auf die Korrekte IP Adresse zurück, danach läuft es ~ einen Tag wieder.
Gibt es irgendwo die Möglichkeit die Priorisierung zu ändern, das erst garnicht versucht wird über Kabel das Portal zu erreichen?
Ich halte nicht viel von Wlan, wo immer es geht bevorzuge ich ich Kabel, es ist Praktisch/ bequem kein Kabel zu verlegen, mehr aber auch nicht, wenn es zuverlässig sein soll geht kein Weg über Kabel.
Und so ist es auch hier, Cerbo und Shelly liegen 1,5m auseinander, die Zuverlässigkeit der Steuerung ist gegeben (Kabelgebunden).
Um die geräte auch per Kabel in meinem Netzwerk zu haben wären weitere Kosten(Kabel, Switch), vor allem Arbeit, von nöten, um ein Kabel durch den Keller zu Ziehen.
Und hier setzt die Bequemlichkeit ein, die “zuverlässigkeit” von W-Lan reicht mir völlig um Einstellungen vorzunehmen, und Daten abzurufen.
Danke für den Tipp, habe als getaway die 0.0.0.0 eingegeben, mal schauen obs morgen auch noch funktioniert.
wenn ich als Netzwerkadmin sowas lese, sorry, aber da rollt’s mir die Fußnägel auf.
Sowohl bei der vorgestellten Netzwerkkonfiguration, als auch bei dem “genialen” Vorschlag von Victron!
@coolheizer
Im IPv4 Bereich gibt es 3 Adressbereiche, die für private Netzwerke reserviert sind:
Klasse C: 192.168.0.0/16 → 192.168.0.0 bis 192.168.255.255 = 65.536 Adressen
Klasse B: 172.16.0.0/12 → 172.16.0.0 bis 172.31.255.255 = 1.048.576 Adressen
Klasse A: 10.0.0.0/8 → 10.0.0.0 bis 10.255.255.255 = 16.777.216 Adressen
Näheres dazu hier.
Die von Dir gewählten Adressbereiche gehören so zu sagen zum Internet, weshalb Konnektivitätsprobleme vorprogrammiert sind.
191.168.0.0/14 ist ein Adressbereich, der offenbar an TIM Brasil vergeben ist und 190.167.0.0/16 scheint Claro, einem Telekommunikationsunternehmen in der Dominikanische Republik zu gehören.
Konfiguriere Dein Netzwerke richtig, dann kann man schauen, ob und ggf. was warum nicht funktioniert…
Zum Thema Gateway 0.0.0.0:
So wirklich falsch ist das nicht, als Gateway eingetragen hat das quasi die Bedeutung von “es ist kein Gateway vorhanden”. ABER!!! Es ist N I E eine gute Idee ein Netzwerkgerät “einfach mal so” über 2 verschiedene NICs mit dem gleichen Subnetz zu verbinden, auch hier sind Konnektivitätsprobleme die Folge, das auszuführen würde zu lange dauern, aber die Suchmaschine Eures Vertrauens kann Euch da beraten…
Victron sollte hier lieber von vornherein die Plausibilität der Konfiguration prüfen und auf solche Bastellösungen verzichten.
Edit: Okay, wenn ich das changelog nochmal lese, steht da nur “a WiFi and an Ethernet network connected at the same time…” von gleichem Subnetz steht da nichts. In der Wirklichkeit hat’s das hier aber schon x Mal gegeben, dass das gemacht wurde und zu Problemen geführt hat.
Ich bin absolut kein Profi was Netzwerktechnik angeht.
Aber so wie ich das im Vorfeld der Anpassung der FW verstanden habe, hat das mit dem Gateway den Hintergrund, das im Venus OS normalerweise LAN die höhere Priorität hat und man mit diesem manuellen Eingriff eben dem WLAN das Vorrecht gibt.
Neben der Konstellation die @coolheizer hat, gibt es im Bootsbereich noch die, das das GX Gerät per LAN mit dem Plotter (MDF) verbunden ist, das GX Gerät aber darüber kein Internet bekommt und man somit dieses zusätzlich per WLAN mit einem anderen Netzwerk verbinden muss.
Ja, das steht ja auch so im changelog.
Wie ich im “Edit” schon schrieb, war ich etwas vorschnell, auf den ersten flüchtigen Blick sah es so aus als meinten sie man könne jetzt beide Schnittstellen mit dem gleichen Subnetz verbinden. Dort steht aber nur dass beide Schnittstellen gleichzeitig verbunden sind, von gleichem Subnetz steht da nichts. Dann kann man das natürlich machen, aber nur eine NIC darf einen Gateway konfiguriert haben.
Wie gesagt 0.0.0.0 als Gateway bedeutet, es ist keiner da und das ist dann völlig korrekt.
Zur Erklärung:
Ein Gateway ist sozusagen der “Ausgang” aus dem privaten Adressbereich(Heimnetz)/das Tor zu anderen Netzwerkbereichen - für die meisten Privatanwender “das Internet”.
Deshalb ist in kleinen Netzwerken, wie das, was die meisten wohl zu Hause haben dürften, der Router (wie z.Bsp. die FritzBox) auch das Gateway, schließlich geht’s da “raus aus dem Heimnetzwerk”.
ich hatte das gleiche Problem nach einen Venus Update von 3.5x auf 3.6x.
Das VRM Portal konnte plötzlich nicht mehr erreicht werden, da der DNS Name nicht mehr aufgelöst werden konnte.
Mit dem Gateway Eintrag 0.0.0.0 geht es zwar wieder, es scheint aber nun so, dass nun der der NTP Sever über WLAN nicht mehr erreicht wird. Bei mir driftete die Uhrzeit weiter weg, bzw zeigte Fantasiewerte die zu keiner Zeitzone gehören.
Um nicht noch mehr Zeit mit der Fehlersuche zu verbringen, hab ich als Workaround das Grid Meter VM-3P75CT von Ethernet auf VE.Can umgestellt, was mit dem Shelly 3 EM natürlich nicht geht.
coolheizer Den Shelly 3 EM hatte ich auch mal als Grid Meter getestet, jedoch war es mir mit 1 Meßwert pro 1- 1,5sec zu langsam, wenn auch der Anschluss per WLAN aus der Hausverteilung ans GX Gerät schon sehr smart war.
Ein Problem mit dem VM-3P75CT mit den Ethernet/CAN Bus Buchsen auf der Frontseite sei hier noch kurz erwähnt:
Die Hausverteilungen die ich kenne haben nur Kabeleinführungen in den inneren/hinteren Verdrahtungsbereich, jedoch nicht in den vom Kunden erreichbaren vorderen Bereich. Sprich man muss irgend ein Weg finden das Ethernet/CAN Kabel aus der Hausverteilungen zu bringen, notfalls mit sägen und bohren.
Nicht jeder Kunde ist begeistert wenn seine Hausverteilung manual modifiziert. Das ist bei Shelly EM schöner gelöst, da sind die LAN Anschlüsse im hinteren Verlandungsbereich, wo man auch Zugang zu den vorgesehenen Kabeleinführungen hat.
Das die LAN/VE.Can Anschlüsse beim VM-3P75CT vorn sind war auch direkt mein erster Kritikpunkt als ich die ersten Bilder der Prototypen gesehen habe.
Leider wurde eine Änderung nicht vorgenommen.
Ich finde das auch doof.
Idealerweise hat man neben dem Zähler noch ein paar TE frei sodass man dort nur den Abdeckstreifen etwas bearbeiten muss.
Oder wenn man es extra hübsch machen will, setzt man da eine RJ45 Buchse als REG daneben um hinter die Abdeckung zu kommen.
