Evu KIt zur Wallbox

Beitrag von **openWB** » Di Jul 27, 2021 9:58 am

Solltet Ihr beabsichtigen zukünftig diese Kombination nicht mehr zu unterstützen, funktionieren möglicherweise viele Boxen im Feld nach dem Update nicht mehr.

Mir ist keine solche Anwendung bekannt auch wurde diese nicht angefragt.
Der Sinn ergibt sich mir hierfür auch noch nicht so ganz.

Den SDM würde ich ungern wieder aus dem Schaltschrank ausbauen. Bin kein Freund von Dickstromstrippenzieherei. Und was den PayPal Fall angeht: Wo kein Kläger, da kein Richter.

Den dann gerne hinterherschicken. Auf Wunsch gibt es ein Label dafür.

Bei mir leider nicht. Am PE11 kommen keine Pakete für den SDM an. Kann man ja recht gut über die LED's am PE11 nachvollziehen

Nicht in Kombination mit dem PE11.

Ich möchte mit meinen Aussagen keinen Unfrieden stiften. Mein Wunsch wäre, dass wir mal versuchen nachzuvollziehen warum das in der Konfiguration die von LutzB als "von Haus aus lauffähig" beschrieben wird, bei mir nicht funktioniert.

Weil es bei 99,99% der Kunden der Fall ist.

Wenn ich dabei irgendwie unterstützen kann würde ich das gerne tun. (Z.B. über Remote-Zugriff auf meine OpenWB, oder Logs, oder eine Teams Konferenz).

Wie erwähnt, da Rücksendung und Paypal Fall im Gange macht das wenig Sinn.

Wenn gewünscht kann die openWB in dem Fall auch retourniert werden.

JSAnyone · Beitrag von **JSAnyone** » Di Jul 27, 2021 10:43 am

@ Ozymandias
Welche Konfiguration hast du denn jetzt?
Das:

LutzB hat geschrieben: ↑Mo Jul 26, 2021 7:31 pm Es ging um openWB am WLan der FritzBox und dem EVU Kit am Lan der FritzBox.

Oder das:

openWB hat geschrieben: ↑Mo Jul 26, 2021 7:09 pm Ein EVU Kit das am LAN Port der openWB hängt welche dann aber gleichzeitig per WLAN mit dem "HausNetz" verbunden ist funktioniert nicht.

Beides geht ja nicht, oder?

Ozymandias · Beitrag von **Ozymandias** » Di Jul 27, 2021 11:24 am

@JSAnyone:
Die Konfiguration die LutzB beschreibt ist das was ich möchte, und was auch nach eine kleinen Modifikation in einem SW-Modul funktioniert.
Die Konfiguration die openWB beschreibt habe ich auch getestet und die funktioniert Out of the Box, solange man nicht den Reload Button des PE11 drückt.

@openWB:

Mir ist keine solche Anwendung bekannt auch wurde diese nicht angefragt.
Der Sinn ergibt sich mir hierfür auch noch nicht so ganz.

Doch, ich habe diese Kombination explizit hier im Forum angefragt. Vielleicht gibt's da was von Ratiopharm?
Der Einsatz ist z.B. wenn man zur OpenWB kein LAN Kabel hat, zum Zählerschrank aber schon. So ist das bei mir.

Den dann gerne hinterherschicken. Auf Wunsch gibt es ein Label dafür.

Das hätte welchen Sinn? Der SDM ist OK und hat inzwischen einige Kilowattstunden auf dem Buckel. Auf wunsch kann ich natürlich einen neuen SDM ordern und wieder zurückschicken. Die Sinnhaftigkeit dieser Aktion leuchtet mir aber irgendwie nicht ein.

Nicht in Kombination mit dem PE11.

Dann wäre es sinnvoll in der Dokumentation zwischen "LAN-Adapter" und PE11 zu differenzieren. Das gleiche Setup mit PV-Zähler PE11 und SDM230 funktioniert. (zumindest auf der IP-Seite).

Weil es bei 99,99% der Kunden der Fall ist.

Dann wäre es zumindest sinnvoll auf der Shop-Seite irgendwo zu dokumentieren, dass manche Kombinationen eben nicht Plug and Play sind.

Wenn gewünscht kann die openWB in dem Fall auch retourniert werden.

Danke für das erfrischende Angebot, aber ich hab ja vor zwei Jahren nicht zufällig die openWB gewählt, sondern weil sie eben unvergleichlich flexibel ist. Wenn man an den Richtigen im Forum gerät, hat man sogar einen guten technischen Support. Mit dem "kaufmännischen" Support bin ich eher nicht so happy. Oder würdest Du "Schick doch einfach alles zurück" als konstruktiven Lösungsansatz bezeichnen?

Beitrag von **openWB** » Di Jul 27, 2021 11:46 am

Dann wäre es zumindest sinnvoll auf der Shop-Seite irgendwo zu dokumentieren, dass manche Kombinationen eben nicht Plug and Play sind.

Nicht Plug and Play sondern nicht unterstützt.

Bucky2k · Beitrag von **Bucky2k** » Di Jul 27, 2021 1:16 pm

Und weiter lese ich in den Beiträgen zahlreich ein "aneinander vorbei Reden".

Können wir uns erstmal darauf einigen, dass

- es um den nicht so unüblichen (wenn auch zu vermeidenden) Konfigurationsfall geht, in dem die OpenWB per WLan an der FB hängt, das EVU Kit in der Verteilung aber hardwired am LAN der FB hängt?

- das zahlreiche Kommentare hier im Thread darauf hinweisen, dass dies Plug&Play funktionieren sollte und zum vorgesehenen Anwendungsfall, wenn wired LAN an der OpenWB nicht möglich ist, zählt?

- das dies bei Ozymandias aber leider nicht Plug&Play funktionierte, ggf bedingt durch einen Hardwaredefekt am PE11?

- der Fall: OpenWB am WLAN der FB, EVU Kit am Raspi-LANport der OpenWB weder von Ozymandias gewünscht, noch als Anwendungsfall seitens OpenWB vorgesehen/unterstützt ist?

Richtig?

aiole · Beitrag von **aiole** » Di Jul 27, 2021 1:59 pm

ergänze:
- und dass der Fall obsolet ist, weil Ozymandias eine Paypal-Rückabwicklung angeschoben hat.

@Ozymandias
Hättest Du eine weniger fordernde, dafür konstruktive Art der Kommunikation gewählt, wäre das hier eine richtig gute Diskussion unter Profis geworden (Dich einbezogen). Deine Frustenergie hättest Du deutlich besser nutzen können.

Ozymandias · Beitrag von **Ozymandias** » Di Jul 27, 2021 2:13 pm

- es um den nicht so unüblichen (wenn auch zu vermeidenden) Konfigurationsfall geht, in dem die OpenWB per WLan an der FB hängt, das EVU Kit in der Verteilung aber hardwired am LAN der FB hängt?

Check! (von meiner Seite)

- das zahlreiche Kommentare hier im Thread darauf hinweisen, dass dies Plug&Play funktionieren sollte und zum vorgesehenen Anwendungsfall, wenn wired LAN an der OpenWB nicht möglich ist, zählt?

Ich habe folgende Setups geprüft:
A) OpenWB an WLAN der FB, PE11 am wired port der openWB -> Funktioniert Plug and Play (Sofern ich nicht vorher den Reload button drücke).
B) OpenWB an WLAN der FB, PE11 am wired Port der FB -> Funktioniert erst nach Änderung der IP-Adresse im Python modul -> Meine Lösung.
Dieser Fall kann Plug and Play nicht funktionieren, da eine Fixe IP im Bereich des eth0 der opwnWB niemals vom Raspi über wlan0 geroutet wird.
C) Generisches SDM630 Modul als EVU funktioniert trotz Eingabe der IP-Adresse für den PE11 und ping möglich von der openWB nicht. Möglicherweise Fehlbedienung, da ich nicht weiß was ich unter /dev/virtualcom ... eintragen muss. Bei Verbindung über einen Socket macht dieser Eintrag m.E. so keinen Sinn.
D) Generisches SDM230 Modul als PV funktioniert auf Anhieb wenn die IP-Adresse des PE11 pingbar ist. Werte sind natürlich vom SDM630, aber im Prinzip funktioniert der Transport.

- das dies bei Ozymandias aber leider nicht Plug&Play funktionierte, ggf bedingt durch einen Hardwaredefekt am PE11?

Das muss man differenzieren. siehe oben. Der Hardwaredefekt betrifft die RS485 Seite des PE11. Die IP-Seite scheint bis auf das nicht funktionierende Webinterface (Seiten werden nur teilweise und sehr verzögert dargestellt) über PC (Chrome/Edge) OK. Webinterface von Android(Chrome) und vom Raspi Browser läuft einwandfrei. Auch der Transport der Modbus-Pakete läuft wie oben beschrieben, das lässt sich an den LEDs des PE11 erkennen und die Pakrete werden im Webinterface des PE11 gezählt.
Bei längerer RS485 Verbindung (2m) und mit Terminator (120Ohm) am RS485 geht RS485 nicht, der PE11 zählt die Pakete Richtung SDM aber dieser antwortet nicht, da das RS485 nur auf einer Leitung durchkommt. Bei kurzen Kabellängen funktioniert es (sporadisch).

- der Fall: OpenWB am WLAN der FB, EVU Kit am Raspi-LANport der OpenWB weder von Ozymandias gewünscht, noch als Anwendungsfall seitens OpenWB vorgesehen/unterstützt ist?

Das wäre für mich recht umständlich. (Hilti, Klappspaten, ...). Funktioniert aber Plug and Play und ist in der Beschreibung auch so beschrieben.
(Für die Bedienung der openWB spielt es keine Rolle, ob diese über WLAN oder LAN angebunden ist und der PE11 wird im Subnetzbereich des LAN eth0 erwartet. Das wäre m.E. der normale Plug and Play Fall.)

Ozymandias · Beitrag von **Ozymandias** » Di Jul 27, 2021 2:31 pm

@aiole:

ergänze:
- und dass der Fall obsolet ist, weil Ozymandias eine Paypal-Rückabwicklung angeschoben hat.

Ja ich habe PayPal eingeschaltet. Wir können die ganze Diskussion natürlich von Neuem beginnen, wenn die Hardware komplett ausgetauscht ist. Wir können aber auch professionell weiter machen. Für meinen etwas schärferen Ton habe ich weiter oben im Thread ja bereits um Verzeihung gebeten.
Im Übrigen ist soeben der ausgetauschte PE11 und der SDM120 (oben hab ich irrtümlich 230 geschrieben) angekommen.
Vielen Dank erst mal für die flexible und schnelle Reaktion.
Ein kleiner Kritikpunkt bleibt insofern, als dass ich nach den Aussagen hier im Forum eher nicht damit gerechnet hatte, das das wirklich so wie von mir gewünscht klappt. Hat es aber.
Ich werde den PayPal Fall schließen, sobald ich die Hardware getestet habe.

Hättest Du eine weniger fordernde, dafür konstruktive Art der Kommunikation gewählt, wäre das hier eine richtig gute Diskussion unter Profis geworden (Dich einbezogen). Deine Frustenergie hättest Du deutlich besser nutzen können.

Mea maxima Culpa. Vielleicht ist das ja trotzdem noch möglich? Wie gesagt stelle ich meine Expertise gerne für Rückfragen zur Verfügung.

HSC · Beitrag von **HSC** » Di Jul 27, 2021 2:59 pm

Im Übrigen ist soeben der ausgetauschte PE11 und der SDM120 (oben hab ich irrtümlich 230 geschrieben) angekommen.

Zur Einrichtung des SDM120 (als PV- Modul?) kannst Du mal ins Wiki schauen. Dort habe ich einiges dazu eingestellt, zwar noch nicht 100% komplett...
Wenn Fragen sind, einfach melden.
VG

derNeueDet · Beitrag von **derNeueDet** » Di Jul 27, 2021 3:07 pm

B) OpenWB an WLAN der FB, PE11 am wired Port der FB -> Funktioniert erst nach Änderung der IP-Adresse im Python modul -> Meine Lösung.
Dieser Fall kann Plug and Play nicht funktionieren, da eine Fixe IP im Bereich des eth0 der opwnWB niemals vom Raspi über wlan0 geroutet wird.

Sehe ich nicht so, die fixe IP ist nicht am eth0 gebunden, so lange die openWB NICHT per LAN angeschlossen ist.

in der atreboot.sh wird die Adresse aus dem Bereich 192.168.193.x an das entsprechend aktive Interface gehängt!!!
Überprüft wird dabei, ob die eth0 einen carrier hat (Kabel an einem Switch reicht dafür!!!)

Code: Alles auswählen

# check for LAN/WLAN connection
echo "LAN/WLAN..."
ethstate=$(</sys/class/net/eth0/carrier)
if (( ethstate == 1 )); then
	sudo ifconfig eth0:0 192.168.193.5 netmask 255.255.255.0 up
else
	sudo ifconfig wlan0:0 192.168.193.6 netmask 255.255.255.0 up
fi

Auf meinem per WLAN angebundenen RASPI4:

Code: Alles auswählen

pi@raspi4:~ $ cat /sys/class/net/eth0/carrier
0
pi@raspi4:~ $ ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether dc:a6:32:1e:4c:cc  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
...


wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.178.64  netmask 255.255.255.0  broadcast 192.168.178.255

wlan0:0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.193.8  netmask 255.255.255.0  broadcast 192.168.193.255
...
pi@raspi4:~ $

nicht wundern, mein Testsystem hat eine andere fixe IP 192.168.193.8 aus dem Bereich

auf meiner openWB, die per LAN angebunden ist:

Code: Alles auswählen

pi@openWB:~ $ cat /sys/class/net/eth0/carrier
1
pi@openWB:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.178.95  netmask 255.255.255.0  broadcast 192.168.178.255
    ...

eth0:0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.193.5  netmask 255.255.255.0  broadcast 192.168.193.255
     ...

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
      ...

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.178.82  netmask 255.255.255.0  broadcast 192.168.178.255
      ...

und wenn ich vom Raspi4 pi Richtung openWB pinge, kann ich das auch über die 192.168.193.x Adresse machen

Code: Alles auswählen

pi@raspi4:~ $ 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=6.13 ms
64 bytes from 192.168.193.5: icmp_seq=2 ttl=64 time=4.34 ms
64 bytes from 192.168.193.5: icmp_seq=3 ttl=64 time=15.2 ms
64 bytes from 192.168.193.5: icmp_seq=4 ttl=64 time=6.94 ms
^C
--- 192.168.193.5 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 4.340/8.142/15.162/4.160 ms
pi@raspi4:~ $ ping 192.168.178.82
PING 192.168.178.82 (192.168.178.82) 56(84) bytes of data.
64 bytes from 192.168.178.82: icmp_seq=1 ttl=64 time=8.18 ms
64 bytes from 192.168.178.82: icmp_seq=2 ttl=64 time=4.08 ms
64 bytes from 192.168.178.82: icmp_seq=3 ttl=64 time=3.26 ms
64 bytes from 192.168.178.82: icmp_seq=4 ttl=64 time=5.51 ms
64 bytes from 192.168.178.82: icmp_seq=5 ttl=64 time=6.82 ms
^C
--- 192.168.178.82 ping statistics ---
6 packets transmitted, 5 received, 16.6667% packet loss, time 9ms
rtt min/avg/max/mdev = 3.263/5.568/8.175/1.785 ms
pi@raspi4:~ $ ping 192.168.178.1
PING 192.168.178.1 (192.168.178.1) 56(84) bytes of data.
64 bytes from 192.168.178.1: icmp_seq=1 ttl=64 time=2.70 ms
64 bytes from 192.168.178.1: icmp_seq=2 ttl=64 time=2.66 ms
64 bytes from 192.168.178.1: icmp_seq=3 ttl=64 time=2.96 ms
64 bytes from 192.168.178.1: icmp_seq=4 ttl=64 time=2.85 ms
64 bytes from 192.168.178.1: icmp_seq=5 ttl=64 time=2.33 ms
^C
--- 192.168.178.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 9ms
rtt min/avg/max/mdev = 2.332/2.701/2.961/0.213 ms
pi@raspi4:~ $

Je nach Anschlussart wird also die IP des Netzes 192.168.178.x an das entsprechende Interface gebunden!

VG
Det

openWB Forum