Vielen Danken für die Antworten.
Da bei mir ja gar nichts in der Konsole erscheint, spricht das auch für ein defekten CAN Transceiver oder was meint ihr?
Wenn Du die Verbindung zum ESP32 schon geprüft hast, dann ist das zumindest eine Möglichkeit. ZUmindest in dieser CAN Transceiver ja recht günstig, da kann man auch auf Verdacht 1-2 zusätzliche für Tests / als Ersatzteil bestellen.
Nutzt Du die GPIOs der Default-Konfiguration, d.h. 27 für RX, 14 für TX? Falls nein: Sind die gewählten PINs für Datenempfang bzw. -versenden geeignet? Evtl. nochmal andere GPIOs ausprobieren.
Ich Nutze die Default Belegung, RX auf 27 und TX auf 14.
Ich kann mir vorstellen, dass ich vllt beim anlöten des PIN Headers zu lang mit dem Lötkolben drauf war oder zu hohe Temperatur verwendet hab, sodass das Teil schon vor der eigentlichen Verwendung Schaden genommen hat
Bei den Teilen ist auch TX und Rx gerne vertauscht. Schau dir mal die Platinen Beschriftung oben und unten an
Und: die Batterie im Web Interface ist angeschaltet?
Nur um sicher zu sein, kann mir jemand bestätigen, dass dieses Bauteil vom richtigen Typ ist, für die Kommunikation mit Pylontech Batterie?
https://www.ebay.de/itm/123372757472
Das wäre Super
VLG
Genau so ein Modul habe ich zumindest auch.
Und ich kann Malte's Tipp noch unterstreichen: Auch bei meinem Modul ist die Beschriftung auf Ober- und Unterseite widersprüchlich: Der PIN, der auf der Oberseite mit CTX ist, ist auf der Unterseite CRX.
IIRC ist die Beschriftung auf der bestückten (Ober-)Seite die korrekte.
Danke für die viele Tipps und Verifikation des Bauteils. Bei mir sind die Ober und Unterseite einheitlich beschriftet und ich habe trotzdem auch schon durch tauschen des Pin Assignments von CTX und RTX ausgeschlossen, dass es verkehrt herum vom mir angeschlossen wurde.
Im Webinterface aktiviert hab ich die Batterie natürlich auch.
Hab jetzt ein neuen Transceiver bestellt und hoffe dass es dann klappt sonst bin etwas ratlos
Ich hab jetzt mal mit dem Huawei Netzteil weitergemacht, hatte die CAN Verbindung vor ein paar Wochen in einem Testaufbau eigentlich schon erfolgreich getestet. Hatte das Modul modifiziert mit dem Leiterbahnen aufkratzen Ding. Der Jumper für den Abschlusswiderstand ist drauf.
Jetzt habe ich ständig Verbindungsabbrüche, 80% der Zeit ist das Netzteil im OpenDTU Webinterface rot, ab und zu wird die Verbindung kurz wieder hergestellt, manchmal hält es lang genug um schnell Ausgangsspannung und Strom manuell einzustellen. Allgemein ist das aber absolut unzureichend. Auf der Konsole kommen auch die ganze Zeit Nachrichten, dass Request vom Netzteil nicht beantwortet werden.
Ich habe eigentlich nichts an den Daten Kabeln verändert seither und bin schon wieder ziemlich ratlos woran es liegen könnte, wenn nicht an einem möglicherweisen doch nicht so gut funktionierendem Netzteil (Kleinanzeigen gebraucht gekauft). Slot Detect scheint übrigens anstandslos zu gehen nur die CAN Kommunikation mal wider nicht 
Habt ihr die JST SM Stecker verwendet oder abgezwickt und verlötet?
@energy-geek welche opendtu on battery version nutzt du? Versuche Mal das letzte Release aus dem Juli zu nutzen und schau Mal, ob die Verbindung dann stabiler bleibt. Seit den August Versionen hab ich Probleme mit der Verbindungsstabilität. Hab das auch als issue geöffnet und malte hat einen Tipp gegeben, den ich aber aktuell nicht testen kann, da ich in den Schweizer Bergen bin ;-). Schaue mir das nächste Woche Mal an, aber das wäre auf jeden Fall einen Versuch wert für dich, um die grundlegende Stabilität zu testen. Ein weiterer Tipp ist, einen Kondensator zur Stabilisierung der Spannungsversorgung des can Moduls zu installieren, um ein evtl nicht ausreichend gutes USB Netzteile auszugleichen. Meine Erfahrung ist, dass can und insb das schalten von Slot detect per relais schon relativ viel Strom braucht und somit evtl die Spannung für die ESP Versorgung etwas einbricht. Das wurde bei mir mit dem Kondensator deutlich besser.
PV: 4 BKW mit Hoymiles hm-600, 2x430w bifazial, 6x410w Glas/Folie (über openDTU angebunden)
Klimaanlage als Heizung:
- Daikin Perfera 2,5 kW (vorhanden)
- Multisplit Daikin 3MXM52 mit 2x Perfera 2.0 und 1xStylish 3.5 (vorhanden)
Brauchwasser-Wärmepumpe Ariston Nuos Primo 240 hc (vorhanden)
Hausautomation/Messung: io-broker auf thinclient (angebunden: Hoymiles, Smart-WB, Daikin-Cloud, Volkszähler, Shellys, Huawei Batterieladegerät, JK-BMS)
Speicher: Nulleinspeisung AC gebunden mit 6,5 kWh LFP 16S (CALB, Huawei, JK-BMS, Hoymiles) (vorhanden)
Ok Danke für deine Tipps, das probiere ich direkt mal aus mit der älteren Firmware. Es beruhigt mich direkt zu wissen dass ich nicht der einzige mit diesem Problem (oder ähnliches) bin, weil manche Dinge lassen sich gut analysieren bei anderen bin ich mir komplett unsicher ob der Fehler in meinem Aufbau, in kaputten Teilen oder tatsächlich auch in der Software liegt.
Das mit dem Kondensator hört sich schon logisch an, ist am Funkmodul ja auch sehr empfehlenswert, da muss ich sagen ärgert es mich aber auch das solche Kondensatoren nie oder immer zu klein dimensioniert auf die Teile drauf gemacht werden. Ich verwende einen ESP32 WROOM mit USB-C und dazu das offizielle Raspberry PI 4 Netzteil mit 5.3V bis 3,5A oder so, also wenn das keine ausreichend stabile Spannungsversorgung ist, dann weiß ich halt auch nicht.
@indie Du hattest tatsächlich Recht. Danke für die Hilfe.
Mit der Firmware vom July tritt so gut wie kein Verbindungsproblem mehr auf zwischen Netzteil und openDTU. Sehr krasser Kontrast zum neusten Release. Hätt ich nie gedacht, dass sich so schnell solch grobe Schnitzer in die Releases schleichen aber gut open source work in progress halt.
Kann jemand was zum automatischen Modus für die Netzteil Regelung sagen, also welche Einstellungen ihr da verwendet für die Spannungen. Habe das eben kurz probiert, hat aber gar nicht reagiert also die Netzteil Leistung wurde nicht verändert von dem Regler und blieb einfach konstant, auch wenn es 100W mehr Überschuss gab der in die Batterie geladen werden sollte.
@energy-geek freut mich, dass das geholf hat bzw. auch, dass es immer mehr Nutzer mit Problemen ab den August Versionen gibt. So wird die Wahrscheinlichkeit, dass das gefixt wird, deutlich erhöht :-).
Nutze auch den wroom mit USB c und hatte jeweils deutliche Verbesserung in der Stabilität, nachdem ich 220yf Kondensatoren hinzugefügt hatte (einfach einen Zehnerpack bestellt, dann hab ich immer einen auf Lager ;-)). Hab sie dann bei 4-5 ESP32 installiert und jeweils deutliche Verbesserungen gehabt.
Nutze die Leistungssteuerung von on battery nicht (sondern über ein Skript aufm iobroker), daher kann ich zum zweiten nichts beitragen...
PV: 4 BKW mit Hoymiles hm-600, 2x430w bifazial, 6x410w Glas/Folie (über openDTU angebunden)
Klimaanlage als Heizung:
- Daikin Perfera 2,5 kW (vorhanden)
- Multisplit Daikin 3MXM52 mit 2x Perfera 2.0 und 1xStylish 3.5 (vorhanden)
Brauchwasser-Wärmepumpe Ariston Nuos Primo 240 hc (vorhanden)
Hausautomation/Messung: io-broker auf thinclient (angebunden: Hoymiles, Smart-WB, Daikin-Cloud, Volkszähler, Shellys, Huawei Batterieladegerät, JK-BMS)
Speicher: Nulleinspeisung AC gebunden mit 6,5 kWh LFP 16S (CALB, Huawei, JK-BMS, Hoymiles) (vorhanden)
Im Grunde sind das keine Verbindungsabbrüche.
Das Problem ist das das Netzteil alle Werte einzeln schickt und man muss sie schnell abholen sonst werden die Nachrichten durch die nächste Nachricht überschrieben. Die Anzeige wird aber nur zurückgesetzt wenn eine bestimmter Wert empfangen wird.
Nachdem im Moment alles an Funktionen in einer großen Schleife läuft kommt die Routine die diese Werte abholt zu selten zum Zug. Das heißt es gehen Werte vom Netzteile verloren
Werte setzen geht davon unabhängig immer.
Ich habe hier die Kommunikation mit dem Netzteile als eigenen Thread implementiert. Das scheint zu laufen ich versuchte aber noch zu verstehen warum ich gelegentlich mal einen Neustart sehe. Da wollte ich noch etwas weiter untersuchen bevor ich das als Pull request bereitstelle
https://github.com/MalteSchm/OpenDTU-OnBattery/tree/huawei_interval_fix
Wenn ich die Maximal Spannung und Maximalstrom vom Netzteil manuell einstelle im Webinterface, dann geht das Netzteil immer zuerst aus und erst nach 30 Sekunden oder so geht es wieder an und gibt die eingestellte Leistung aus. Das ist extrem hinderlich, geht dass auch ohne zwischendrin Pause machen, kann das Netzteil auch einfach im laufenden Betrieb die Ausgangsleistung anpassen bis das neue Ziel erreicht wird.
Wie kann man per HTTP POST die Ausgangsleitung des Netzteil während dem Betrieb ändern, um die Nulleinspeisung zu realisieren?
Wenn ich die Maximal Spannung und Maximalstrom vom Netzteil manuell einstelle im Webinterface, dann geht das Netzteil immer zuerst aus und erst nach 30 Sekunden oder so geht es wieder an und gibt die eingestellte Leistung aus. Das ist extrem hinderlich, geht dass auch ohne zwischendrin Pause machen, kann das Netzteil auch einfach im laufenden Betrieb die Ausgangsleistung anpassen bis das neue Ziel erreicht wird.
Wie kann man per HTTP POST die Ausgangsleitung des Netzteil während dem Betrieb ändern, um die Nulleinspeisung zu realisieren?
Hi @energy-geek, ja, das geht.
Ich mache das aktuell schon über MQTT. Da sind die korrekten Topics
/huawei/cmd/limit_online_current
und
/huawei/cmd/limit_online_voltage
Es geht aber auch über REST, die REST API Dokumentation ist an der Stelle nciht ganz aktuell - dieser Request fehlt z.B. in der Doku komplett (es ist nur der GET aufgeführt). Aber aus dem Code kann man das ganz gut "reverse engineeren". Habe ich gerade eh' gemacht, da ich meine eigene Ladelogik in in ESPHome und nur mit REST (ohne MQTT) baue.:
Um die Leistung (bzw. Spannung und Stromstärke) des Huwei zu ändern, muss man den folgenden HTTP Request schicken:
POST http://<FQDN / IP von OpenDTU>/api/huawei/limit/config
Headers:
Content-Type: application/x-www-form-urlencoded Authorization: Basic base64(<user>:<password>)
Body (in x-www-form-urlencoded, also <key>=<value> Format):
data="{"online":true,"voltage_valid":true,"voltage":52,"current_valid":true,"current":1}"
Die Attribute natürlich entsprechend belegen. Analog Dialog in der UI:
Die API Dok auf https://github.com/helgeerbe/OpenDTU-OnBattery/blob/development/docs/Web-API.md zeigt ganz gut, wie man das mit CURL umsetzt.
Die Werte musst Du aus dem PV Überschuss berechnen aus P = U * I -> bei U fix auf z.B. 52 V ergibt sich also I = PV-Überschuss / 52. Dann wird der PV-Überschuss genau verbraucht. Genau so funktioniert meine eigene Ladelogik.
@cacu15 Vielen Dank für deine Ausführliche Antwort, das werde ich mir auf jede Fall mal genauer ansehen und etwas rum experimentieren. Ich denke ich werde die Ladelogik irgendwie mit einem Python Script als Daemon oder Systemd Service umsetzen auf meinem kleinen Linux Homeserver, dort läuft auch iobroker + influx + grafana für die Statistiken.
Ich weiß es sehr zu schätzen, dass hier im Forum so viel und schnell geantwortet wird, denn trotz meiner zahlreichen Erfahrungen mit solchen Elektro Bastel Projekten würde ich ohne Hilfe ewig brauchen um das alles vernünftig zum Laufen zu kriegen.
VLG