Hallo Community,
seit gestern hat mein CerboGX keine Verbindung mehr mit VRM.
Es kommt folgende Meldung im Cerbo:
Ich hoffe hier kann mir jemand helfen.
Guido
Hallo Community,
ich habe den CerboGX jetzt so eingestellt, dass, wenn keine Verbindung zum VRM besteht, alle Stunde der Cerbo neu gestartet wird.
Dabei ist mir aufgefallen, dass der Cerbo jedes mal eine neue IP-Adresse (169.254. …)hat, was ich verstehe. Aber er meldet sich auch jedes mal mit einer anderen MAC-Adresse, was ich nicht verstehe. Die Daten sehe ich in meiner FritzBox.
Ich hoffe mir kann jemand weiterhelfen.
Guido
Hallo Community,
beim letzten Neustart hat sich die Fhler meldung verändert:
Für mich sieht das so aus, als wenn der Cerbo eine Verbindung zum VRM aufbauen will, aber VRM nicht antwortet.
Guido
hallo,
mit einer ip, die mit 169.254 anfaengt, kommst du nicht ins internet, ausser du konfigurierst das routing von hand. allerdings bedeutet das wohl auch, dass du keine statische ip-adresse vergeben hast und du keinen dhcp-server im netz hast. hast du den dhcp-server auf deiner fritzbox vieleicht versehentlich deaktiviert?
dann kommst du noch ueber die ip 169.254.1.1 auf die box!
tschuess
Hallo Dieter,
bisher lief die PV-Anlage 1,5 Jahre einwandfrei.
Für den Cerbo habe ich über die FritzBox eine feste IP-Adresse vorgegeben. Siehe erste Zeile.
Es meldet aber immer noch eine 2. Instanz, von der ich gedacht habe, dass sie die IP-Adresse für die Verbindung ins Internet ist.
Über die 192.168.178.42 komme ich immer auf die UI des Cerbos.
Guido
hallo,
die 168er ip ist eine automatisch vergebene adresse, damit man auch dann noch auf das geraet kommt, wenn kein dhcp-server im netz ist.
aber wenn du dich mit ssh am cerbo anmeldest, kannst du feststellen, was los ist:
ip -4 a
route -n
ping -c 5 vrm.victronenergy.com
traceroute -n vrm.victronenergy.com
befehle kann man mit strg-c abbrechen, wenn sie nicht automatisch enden.
tschuess
Hallo Dieter,
ssh war für mich noch Neuland. Aber ich habs soweit hinbekommen, dass ich deine vorgeschlagenen Befehle eingeben konnte:
root@einstein:~# ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 192.168.178.42/24 brd 192.168.178.255 scope global eth0
valid_lft forever preferred_lft forever
6: ap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1450 qdisc mq state DOWN group default qlen 1000
inet 172.24.24.1/24 brd 172.24.24.255 scope global ap0
valid_lft forever preferred_lft forever
8: ll-eth0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
inet 169.254.11.230/16 scope link ll-eth0
valid_lft forever preferred_lft forever
root@einstein:~#
root@einstein:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.178.1 0.0.0.0 UG 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ll-eth0
172.24.24.0 0.0.0.0 255.255.255.0 U 0 0 0 ap0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.178.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
root@einstein:~#
root@einstein:~# ping -c 5 vrmvictronenergycom
PING vrmvictronenergycom (18.157.127.184): 56 data bytes
64 bytes from 18.157.127.184: seq=0 ttl=58 time=10.491 ms
64 bytes from 18.157.127.184: seq=1 ttl=58 time=8.111 ms
64 bytes from 18.157.127.184: seq=2 ttl=58 time=8.505 ms
64 bytes from 18.157.127.184: seq=3 ttl=58 time=8.067 ms
64 bytes from 18.157.127.184: seq=4 ttl=58 time=8.456 ms
— vrmvictronenergycom ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 8.067/8.726/10.491 ms
root@einstein:~#
root@einstein:~# traceroute -n vrmvictronenergycom
traceroute to vrmvictronenergycom (18.157.127.184), 30 hops max, 38 byte packets
1 192.168.178.1 0.430 ms 0.356 ms 0.482 ms
2 80.69.193.14 6.094 ms 6.095 ms 5.850 ms
3 52.95.218.253 6.266 ms 5.491 ms 5.733 ms
4 52.95.218.252 9.057 ms 9.481 ms 8.572 ms
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * *^C
root@einstein:~#
Mir sagt das jetzt nicht viel. Ich hoffe es bringt Licht ins Dunkle.
Guido
Hallo Dieter,
da ich als neuer User nicht mehrere Links in meinem Post haben darf, habe ich bei vrm.victronenergy.com im letzten Post jeweils die Punkte durch Sternchen ersetzt.
Guido
hallo,
also dein netzwerk funktioniert wohl problemlos, wieso du also probleme mit dem vrm hast, kann ich dir nicht sagen.
eine moeglichkeit waere noch, dass unterwegs daten verloren gehen. du kannst bei ping mal noch den parameter -s groesse (1024 bis max 65535) benutzen, ob es dann fehlermeldungen gibt. allerdings kann es sein, dass du keine antwort mehr bekommst, wenn die groesse groesser als die maximale packetgroesse ist. das funktioniert naemlich nicht mit allen system.
du kannst auch das -c n mal weglassen, dann laeuft der befehl endlos lange.
tschuess
Hallo,
Ich habe noch ein paar Versuche mit dem ping gemacht:
root@einstein:~# ping -c 100 -s 24000 vrmvictronenergycom
PING vrmvictronenergycom (18.157.127.184): 24000 data bytes
24008 bytes from 18.157.127.184: seq=0 ttl=58 time=37.339 ms
24008 bytes from 18.157.127.184: seq=1 ttl=58 time=37.382 ms
24008 bytes from 18.157.127.184: seq=2 ttl=58 time=37.528 ms
.
.
.
24008 bytes from 18.157.127.184: seq=99 ttl=58 time=37.344 ms
— vrm.victronenergy.com ping statistics —
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max = 36.652/37.653/38.748 ms
root@einstein:~#
root@einstein:~# ping -c 10 -s 25000 vrmvictronenergycom
PING vrmvictronenergycom (18.157.127.184): 25000 data bytes
25008 bytes from 18.157.127.184: seq=0 ttl=58 time=39.096 ms
25008 bytes from 18.157.127.184: seq=1 ttl=58 time=41.337 ms
25008 bytes from 18.157.127.184: seq=4 ttl=58 time=39.021 ms
25008 bytes from 18.157.127.184: seq=5 ttl=58 time=37.788 ms
25008 bytes from 18.157.127.184: seq=6 ttl=58 time=38.853 ms
25008 bytes from 18.157.127.184: seq=8 ttl=58 time=39.189 ms
— vrm.victronenergy.com ping statistics —
10 packets transmitted, 6 packets received, 40% packet loss
round-trip min/avg/max = 37.788/39.214/41.337 ms
root@einstein:~#
Bis zu einer Paketlänge von 24000 bytes funktioniert es noch sehr gut. Ab 25000 treten dann Fehler auf.
Im Moment zeigt mein CerboGX wieder die Fehlermeldung #155.
Und Dieter, vielen Dank für die bisherige Unterstützung.
Guido
hallo,
wenn bei ping daten verloren gehen, ist das normalerweise ein zeichen, dass eine leitung ueberlastet ist oder etwas nicht stimmt.
sind nur die pingzeiten extrem hoch, ist das ein sicheres zeichen fuer eine ueberlastung. allerdings ist ohne packetverlust der puffer noch gross genug, damit alle packete uebertragen werden, ansonsten wuerden packete verloren gehen.
du kannst auch einmal ping -c 10000 -f -s 1400 benutzen. das f steht dafuer, dass die packet so schnell wie moeglich versendet werden.
normalerweise werden aber keine packet verschickt, die groesser als die maximal erlaubte groesse im netzwerk sind. sowas kommt normalerweise nur netzwerkuebergreifend vor oder wenn es extra so eingestellt wurde.
du kannst es auch einmal mit der ip 1.1.1.1 und den grossen packeten versuchen, wenn das geht und beim vrm nicht, dann gibt es auf dem weg zum vrm oder beim vrm selbst ein problem damit.
ich habe es gerade einmal mit packeten von 30000 bytes probiert und da hatte ich keine ausfaelle mit dem vrm als ziel.
du kannst also wohl davon ausgehen, dass es bei dir irgendwo auf dem weg ein problem gibt.
du kannst auch einmal versuchen, die ips, die dir traceroute -n liefert entsprechend anzupingen, allerdings antwortet nicht jedes system auf grosse ping-packete.
tschuess
Hallo Dieter und hallo an alle Mitlesenden,
was soll ich sagen, heutemorgen funktionierte die Datenübertragung zum VRM-Portal wieder, ohne dass ich etwas dazugetan hatte.
Da sich hier auf meiner Seite nichts geändert hat, gehe davon aus, dass es am Portal gelegen hat. Vielleicht ist dort am langen Wochenende was schiefgelaufen und heutemorgen, am Anfang der Arbeitswoche, erst aufgefallen und behoben worden.
Allerdings hatte ich bei meiner Internet-Recherche kein weiteren vergleichbaren Problembeschreibungen gefunden.
Ich bin auf alle Fälle erstmal zufrieden, da scheinbar auch keine Daten verloren gegangen sind.
Deshalb zum Schluss nochmal vielen Dank an dich, Dieter, für die Unterstützung.
Guido
