ioBroker auf RPI 3 installiert, WebO antwortet nicht

solargy

@Thomas-Braun
welche Ausgaben des "ip a" Befehles sollte man hier einreichen um auch keine Sicherheitsrisiko für mein Netzwerk darzustellen?

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:xx.xx.xx.xx brd ff:ff:xx:xx:xx:xx
    inet 192.168.178.41/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0
       valid_lft 835833sec preferred_lft 727833sec
    inet 192.168.193.5/24 brd 192.168.193.255 scope global eth0:0
       valid_lft forever preferred_lft forever
    inet6 2003:d4:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 7197sec preferred_lft 1797sec
    inet6 fe80::15a8:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b8:27:xx:xx:xx:xx brd ff:ff:xx:xx:xx:xx

Reicht das aus oder bräuchte man mehr Info?

Vielen Dank!

Thomas Braun

@solargy Komplette Ausgaben bitte.
Mit deinen intern vergebenen IPs kann hier keiner was anfangen.

solargy

@Thomas-Braun

pi@raspberrypi:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:95:65:e9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.41/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0
       valid_lft 833560sec preferred_lft 725560sec
    inet 192.168.193.5/24 brd 192.168.193.255 scope global eth0:0
       valid_lft forever preferred_lft forever
    inet6 2003:d4:ff17:bb00:1415:526f:748d:10f0/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 7197sec preferred_lft 1325sec
    inet6 fe80::15a8:912a:6647:7793/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b8:27:eb:c0:30:bc brd ff:ff:ff:ff:ff:ff

Thomas Braun

@solargy Warum hast du da zwei IPv4 auf dem gleichen Interface?
Was ist 192.168.193.x für ein Netz?
Das andere 192.168.178.x ist deine Fritzbox.

solargy

@Thomas-Braun
Ich habe keine Ahnung woher kommt dieser komplett neuer IP Bereich xx.xx.193.xx.

Thomas Braun

@solargy Ist ja dein Netz, solltest du also kennen.
Von uns kann das keiner wissen.
Da scheinen zwei Geräte IP-Adressen zu vergeben, das ist halt etwas schräg.

solargy

@Thomas-Braun

Komisch...
Interessant ist dass wenn ich von RPI3 Terminal die IP Adresse 192.168.193.5 aufrufe, dann scheint dieses Device zu antworten:

pi@raspberrypi:~ $ ping 192.168.193.5
PING 192.168.193.5 (192.168.193.5) 56(84) bytes of data.
64 bytes from 192.168.193.5: icmp_seq=1 ttl=64 time=0.144 ms
64 bytes from 192.168.193.5: icmp_seq=2 ttl=64 time=0.135 ms
64 bytes from 192.168.193.5: icmp_seq=3 ttl=64 time=0.133 ms
64 bytes from 192.168.193.5: icmp_seq=4 ttl=64 time=0.132 ms
64 bytes from 192.168.193.5: icmp_seq=5 ttl=64 time=0.138 ms

Wenn ich von meinem Rechner gas gleiche in CMD eingebe dann scheint diese Adresse Tod.

C:\Users\ndb\ping 192.168.193.5
Pinging 192.168.193.5 with 32 bytes of data:
Request timed out
Request timed out
Request timed out
Request timed out

Thomas Braun

@solargy Der Windows Rechner ist halt nicht in dem 193er Netz drin.
Und selber kann der Pi sich natürlich pingen. Der kann ja auch die 127.0.0.1 pingen.

solargy

@Thomas-Braun

Danke fuer deine Antwort.
Wie kann es sein dass der RPI in dem 193er integriert ist?
Scheint ja etwas mit der Kombination RPI - Fritzbox schräg zu sein.
Da habe ich keine andere Geraete die IP Addresse vergeben koennen.

Thomas Braun

@solargy
pihole oder sonst irgendwas in einem Docker oder so kaufen?

solargy

@Thomas-Braun
Hallo Alle,

Ich denke mal ich habe die Ursache meines Problemes wo beim "ip a", zwei IP unterschiedliche IP Addresse angezeigt werden, gefunden:

    inet 192.168.178.41/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0
    valid_lft 833560sec preferred_lft 725560sec
    inet 192.168.193.5/24 brd 192.168.193.255 scope global eth0:0

Ich habe mein RPI3 komplett neu mit Raspi OS Lite ausgestattet und erstmal nur ioBroker wie hier ofizielle beschrieben installiert. Da scheint alles einwandfrei zu funktionieren.
Beim "ip a" ergibt sich nur eine 192.168.178.41 IP Adresse.

Um meine PV Anlage (mit Kostal Plenticore 10 und Kostal SEM) mit der GO-ECharger Wallbox zu integrieren und PV Ueberschuss ins Auto zu laden habe ich auf dem RPI3 auch openWB Software installiert. Die Installation wurde wie hier beschrieben (https://openwb.de/main/wp-content/uploads/2019/07/install_openWB_v2.pdf Ab dem Punkt In der Schell folgendes eingeben) durchgefuehrt.

Wenn die Installation fertig ist dann faengt die Hoelle an. Weder der ioBroker ist in der WebOberflaeche erreichbar noch die openWB WebOberflaeche.

Beim "ip a" scheint die Installation der openWB Netzwerk Aenderungen vorzunehmen/vorgenommen zu haben. Da erscheint diese zwei IP Adresse, wie hier in den vorherigen Threads gezeigt wurde.

inet 192.168.193.5/24 brd 192.168.193.255 scope global eth0:0

Hat jemanden Ahnung was ist passiert geworden?
Oder habt ihr eine Idee wo konnte man mehr Info dazu bekommen.

Vielen Dank!

Thomas Braun

@solargy Die Frage ist halt was da für ein Kram in dem Installer-Skript passiert.

Installier doch mal anders herum. Zuerst ein Debian Buster Lite, dann der openwb-Kram und zuletzt den ioBroker. Dann könnte es funktionieren, der ioBroker fummelt jedenfalls nicht tief im Netzwerksetup herum.

solargy

@Thomas-Braun
Hier ist der openWB Installer-Skript: https://raw.githubusercontent.com/snaptec/openWB/master/openwb-install.sh
Es scheint also der Skript voll mit Checks und Installation Schritte der jeweiligen Software Komponenten zu sein.
Ich habe gestern es anderesrum installiert. openWB zuerst und dann ioBroker. Daher habe ich diesen Thread hier erzeugt.

Ich werde dann mit dem Debian Buster Lite probieren, da mit dem Raspberry Pi OS die aktuelle Problemen erscheinen.
Ist der Debian Buster Lite so unterschiedlich?

Danke nochmal fuer die kompetente Unterstützung!

Thomas Braun

@solargy Nein, ich meinte damit Rasbian OS. Basiert halt auf Debian.

solargy

@Thomas-Braun

Hallo Thomas,

Das ist gar nicht notwendig da ich gestern erstmal openWB auf dem RPI3 hatte und dann den ioBroker dazu einholen wollte. Nach einer unspektakulären Scheiterung habe ich diesen Thread aufgestellt. Es scheint also dass die Präsenz der openWB auf dem RPI3 den ioBroker zu beeinträchtigen. Die openWB fummelt komischerweise im Netzwerksetup herum.

Vielen Dank

Thomas Braun

@solargy Nee, die Installation von dem OpenDingsbums beeinträchtigt das Netzwerksetup, wie mir scheint. Wie sieht denn die Ausgabe von

ip a

unmittelbar nach der Installation von dem Ding aus?

solargy

@Thomas-Braun
Nach der Installation des ioBrokers scheint nur eine IP Adresse zu geben:

inet 192.168.178.41/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0

und nach der Installation der openWB sieht es so aus:

inet 192.168.178.41/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0
valid_lft 833560sec preferred_lft 725560sec
inet 192.168.193.5/24 brd 192.168.193.255 scope global eth0:0

Also die zweite IP Adresse kommt mit dazu. Da fummelt, warum wie immer, die openWB komischerweise im Netzwerksetup herum.

solargy

@solargy
Ich habe den gleichen Thread im openWB Forum gestellt und es kam die Antwort von openWB Support selbst, zittiere: openWB nutzt immer ein eigenes Subnetz um mit den "eigenen" Komponenten zu kommunizieren ohne das ein Setup erforderlich ist (EVU Kit und co..)
Die einzige Variante wie ich es finde, einen LXC Container auf dem RPI3 zu installieren und jeweils ein LXC Container für ioBroker und OpenWB. Leider kenne ich mich nicht aus wie man das ueberhaupt vornimmt. Es scheint dass ich den Holzweg in die ioBroker Welt nehmen muss.

Ich denke mal die Ursache fuer mein Problem ist gefunden, aber nicht geloest, doch diesen Thread kann man, meiner Meinung nach, schliessen.

Vielen vielen Dank!

Thomas Braun

@solargy Das muss sich dann mal jemand mit Ahnung von Netzwerken anschauen. Vielleicht kann man da eine Bridge aufbauen. Oder statische Routen. Aber da habe ich keinen Plan von.

Community Forum

NEWS

ioBroker auf RPI 3 installiert, WebO antwortet nicht

Support us

631

32.7k

82.4k

1.3m