Evu KIt zur Wallbox

[Ozymandias]

@DerNeueDet: Zwangsweise, von außen ist das sonst nur eine Black Box und man hat gar keine Möglichkeit zur Netzwerkdiagnose.
Mit Monitor und Tastatur dran, kann man wenigstens mal pingen und die Netzwerkstati abfragen. Und nach einer kleinen Änderung im Python File hab ich auch eine, wenn auch notdürftige und nicht Updatesichere, vorläufige Lösung. Wäre aber viel schöner wenn das generische SDM630 Modul liefe wie ich es erwarte.

@Bucky2k: Wäre möglich, dass die Satellitenkonfiguration funktioniert hat. Die EVU-Kit Konfig mit korrigierten IP-Adressen im Python tut ja auch. Nur das generische SDM630 Modul funktioniert nicht so wie ich es erwartet hätte.

@All: Sorry wenn mein Ton unangemessen war, aber ich war wirklich total genervt.

[derNeueDet]

Zwangsweise?
Verstehe ich nicht. Ein WR ist eine Blackbox mit einer spezifischen Funktion. Gehst du da auch ran und veränderst die Firmware? Vermute, das machst Du nicht. Würdest Du es dem Hersteller verübeln, wenn er dir dann auf die veränderte Firmware keinen Support mehr gibt?

Auch wenn ich kein EVU Kit einsetze, bin ich mir sicher, daß es mehr als genügend funktionierende Installationen gibt.


VG
Det

[Ozymandias]

@DerNeueDet: Dreimal darfst Du raten warum ich mich für die OpenWB entschieden habe.
Eben weil es kein geschlossenes System ist und es an die individuellen Bedürfnisse anpassbar ist.

Ein WR ist eine Blackbox ...

Du meinst Wallbox, oder woher weisst Du dass auf meinen Victrons (WR) auch Root Zugriff besteht

Auch wenn ich kein EVU Kit einsetze, bin ich mir sicher, daß es mehr als genügend funktionierende Installationen gibt.

Das mag ja sein, aber in meinem gar nicht so speziellen Fall (WB am WLAN, EVU-Kit am wired) hat es nun mal nicht funktioniert und bislang konnte mir auch noch niemand plausibel erklären wie das funktionieren könnte. Da war die Anpassung des Python Files der schnellste Weg.

Inzwischen gibt es aber neue Probleme, die doch wieder auf die Hardware hindeuten. Bevor ich da die Pferde Scheu mache, werde ich aber erst mal zum Oszi greifen und mir ein Bild der Lage machen.

[derNeueDet]

Wow, jetzt kommt auch noch das Oszilloskop zum Einsatz.
Für was brauchst Du das denn jetzt?

Wenn du noch weiter rumbastelst, dann wird es wohl darauf hinauslaufen, dass du irgendwann an dem Zustand bist, dass der Support kostenpflichtig wird.

Was ich ehrlich gesagt jetzt bereits verstehen würde.


VG
Det

[derNeueDet]

]Das mag ja sein, aber in meinem gar nicht so speziellen Fall (WB am WLAN, EVU-Kit am wired) hat es nun mal nicht funktioniert und bislang konnte mir auch noch niemand plausibel erklären wie das funktionieren könnte.

Doch, es gab ein paar Versuche von sehr erfahrenen Usern und auch von den openWB Entwicklern, die du sofort gebügelt hast, anscheinend ohne die Hinweise oder den Zusammenhang zu erkennen oder erkennen zu wollen.
Mehrfaches widersprechen führt dann eben dazu, dass es immer weniger informativ sondern emotional wird.

VG
Det

[Ozymandias]

Hardwareproblem

Nachdem das Ganze gestern auf dem Schreibtisch in einem kurzen Test funktioniert hatte, kam nach dem Einbau in den Schaltschrank die Ernüchterung. Direkt nach dem Einschalten liefen ein paar Frames durch, diese wurde sowohl an der OpenWB (Status) als auch im PE11 in der Paketstatistik angezeigt. Nach ein paar Minuten gingen nur noch die "sent Frames" hoch, es wurden aber keine Antworten mehr vom SDM630 empfangen.
Daraufhin hab ich das Oszi drangehangen und festgestellt, dass ein Signal des RS485 nicht tut. Einen Messfehler kann ich ausschließen, da ich die Probes getauscht habe. (A-/B+ jeweils gegen GND)

[Ozymandias]

@DerNeueDet:

Doch, es gab ein paar Versuche von sehr erfahrenen Usern und auch von den openWB Entwicklern, die du sofort gebügelt hast, anscheinend ohne die Hinweise oder den Zusammenhang zu erkennen oder erkennen zu wollen.

Das ist so nicht richtig. Natürlich habe ich versucht die Hinweise nachzuvollziehen, was aber aufgrund der resetteten Konfig nicht mehr mit der Originalhardware möglich war. Die Frage wie die Annahme zustande kommt der RasPI würde ein Paket an eine Subnetzadresse an eth0 auch über wlan0 mit völlig anderem Subnetz verschicken, wurde ebenfalls nicht plausibel beantwortet. Ich habe es allerdings getestet und per Ping keine Verbindung zustande bekommen was nach meinen Kenntnissen über Netzwerkstacks auch plausibel ist.
Nach einem sachdienlichen Hinweis von LutzB hab ich das Netzwerk ja dann auch zum laufen gebracht. Allerdings halte ich das SW-Modul Generisch SDM630 nachwievor für nicht funktional, zumindest nicht so wie ich es erwarten würde.
Ich entwickle jetzt seit 30 Jahren Software und Hardware im industriellen Umfeld bei einem großen deutschen Elektronikkonzern und hab schon TCPIP Stacks in IOT Devices debuggt. Da gehe ich mal davon aus, dass ich auch eine gewisse Expertise habe und nicht jedem Stökchen dass ins Forum geschmissen wird hinterherlaufe.

[openWB]

Das mag ja sein, aber in meinem gar nicht so speziellen Fall (WB am WLAN, EVU-Kit am wired) hat es nun mal nicht funktioniert und bislang konnte mir auch noch niemand plausibel erklären wie das funktionieren könnte. Da war die Anpassung des Python Files der schnellste Weg.

Ist ein sehr spezieller Fall und dieses Setup wird explizit nicht unterstützt.

Da aber ein Paypal Fall offen ist und die Retoure ausstehend ist sollte der Rest ohnehin hinfällig sein.

[derNeueDet]

Die Frage wie die Annahme zustande kommt der RasPI würde ein Paket an eine Subnetzadresse an eth0 auch über wlan0 mit völlig anderem Subnetz verschicken, wurde ebenfalls nicht plausibel beantwortet.

Ich glaube nicht, dass das jemand behauptet hat.
Das Subnetz 192.168.193.x wird je nach vorhandener Anbindung entweder an das eth0 oder an das wlan0 Interface als 2. IP Adresse gebunden.
Die Bridge zwischen WLAN Geräten und LAN gebundenen Geräten macht deine Fritz Box. Bein internen Netz auf jeden Fall, beim Gastnetz hab ich das noch nicht getestet. Und es ist ihr dabei egal, ob die IPAdresse 192.168.178.x ist oder 192.168.193.x . Mehrfach von unterschiedlichen Personen genannt, aber anscheinend nicht durchgerungen.

Wenn du jetzt einen natürlich möglichen Hardware Fehler gefunden hast, dann ist es genau das was schon von Anfang an gesagt wurde. Kit zurück an openWB zur Überprüfung.

Auch wenn die jetzt evtl. auch schon einen Hals haben, da der bisher dort aufgelaufen Aufwand wesentlich höher war als notwendig.

Ich bin mir aber auch fast sicher, dass sie die Box und das EVU Kit zurück nehmen würden und dir den Kaufpreis erstatten. Dann kannst Du an anderer Stelle noch mal eine für Dich besser geeignete (funktionierende) Lösung beschaffen.

VG
Det

[Ozymandias]

Ich glaube nicht, dass das jemand behauptet hat.

Sinngemäß schon.

Mehrfach von unterschiedlichen Personen genannt, aber anscheinend nicht durchgerungen.

Funktioniert aber nicht und wurde auch sinngemäß vom admin (openWB) so betätigt:

Ist ein sehr spezieller Fall und dieses Setup wird explizit nicht unterstützt.

@OpenWB: Wäre ja klasse, wenn dieser Fall in irgendeiner Dokumentation explizit erwähnt wäre, genau so wie das "verbot" den Reload-Button zu drücken.
Noch schöner wäre es natürlich, wenn irgendwo dokumentiert wäre wie die Settings sind, damit aus einer kleinen Fehlbedienung nicht gleich eine Retoure wird. Meine Frage nach der Konfiguration des PE11 war ja klar und deutlich formuliert.

Code: Alles auswählen

Also für die Nachwelt:
Werkseinstellung des PE11 mit 3s Reload-Button herstellen. (Wenn's Plug and Play nicht funktioniert).
Parametrieren via Raspi Webbrowser, Chrome und Edge auf PC funktioniert nicht mit der aktuellen PE11 FW. In Werkseinstellung wird die IP für den PE11 per DHCP vergeben, also im Router nach einem "ProtossPE11" o.Ä. suchen.
RS232: 9600,8,N,1 Protokoll Modbus
IP: 192.168.193.15 (für Anbindung über eth0 als EVU-Kit), andere IP (DHCP) ggf. im Modul ../www/openWB/modules/bezug_ethmpm3pm [client = 
ModbusTcpClient('192.168.193.15', port=8899)] anpassen.
Restart des PE11.

Beim SDM630 gemäß Anleitung des Herstellers folgende Settings: 
Addr: 115
Serial: 9,6k,8,n,1

Wenn jetzt noch das generische SDM630 via IP SW-Modul so täte wie ich es erwarte, wäre mein Glück perfekt. Leider gab es ja dahingehend keine weitere Info. Evtl. könnte man das generische Modul auch rausschmeißen (tut m.E. eh nicht) und das EVU-Kit in der Weboberfläche um die IP-Adresse mit Defaultadresse ergänzen.

Ich bin mir aber auch fast sicher, dass sie die Box und das EVU Kit zurück nehmen würden und dir den Kaufpreis erstatten. Dann kannst Du an anderer Stelle noch mal eine für Dich besser geeignete (funktionierende) Lösung beschaffen.

Ja klar, ich schmeiße die Box auf den Elektroschrott weil ein kleines Zusatzteil nicht auf Anhieb so funzt wie ich das gerne hätte. Muss mal grade in den Keller den Dukatenscheißer melken

Also nochmal langsam zum nachvollziehen:
Ich kaufe ein Zusatzteil zu einer seit Jahren in Betrieb befindlichen openWB. Das funktioniert in meiner Konfiguration, die ansonsten seit Jahren keine Probleme machte, nicht "Plug and Play". Also hake ich, da es keine Anleitung gibt, nach und erfahre, viel Widersprüchliches und einiges was ich hier explizit NICHT nachvollziehen kann. Ist so als würde der Support sagen mein Kuli auf dem Schreibtisch ist grün, ich weiß aber dass er schwarz ist.
Dann erhalte ich eine echte Lösung von LutzB die ich binnen Minuten umsetzen kann und schon fluppts.
Zur Verwirrung hat beigetragen, dass der PE11 nicht über Chrome und Edge vom PC aus konfigurierbar ist, was ich zunächst als Defekt interpretiert habe. Da es aber unter Android Chrome und vom Browser der OpenWB funktioniert, gehe ich einfach mal von einem für die Anwendung unproblematischen Fehlverhalten aus. Auf dem Schreibtisch tut das Ganze ja mittlerweile.
Nun ist aber ein echter HW-Fehler im Modul zusätzlich vorhanden, der verhindert, dass eine stabile RS485 Verbindung zustande kommt. Kann ein Wackler (kalte Lötstelle, Haarriss, ...) sein, oder ein Problem mit dem RS485 HW-Treiber.
Egal, der PE11 geht zurück mit der Bitte um Prüfung / Reparatur / Ersatz.

Auch wenn die jetzt evtl. auch schon einen Hals haben, da der bisher dort aufgelaufen Aufwand wesentlich höher war als notwendig.

Stimmt, das liegt aber nicht an mir. Eine einzige Zeile von LutzB hat mein SW-Problem ja gelöst. Der HW-Defekt den ich zusätzlich gefunden habe macht ja ein Rücksenden sowieso erforderlich.
Das zusätzliche HW-Problem kann ja mal passieren, zumal es laut meiner Beobachtung ein Fall ist, der beim Test auf dem Schreibtisch (kurze Kabel, wenig EMV, keine Terminierung der RS485) nicht zwangsweise sofort auffällt.