@lukasvfl99
Erstmal finde ich es cool, dass Du solche PCBs entwirfst. Ich bin ja auch jemand von denen, die aktuell NUR über das HUAWEI laden, nicht über VICTRON Lader.
Bzgl Deines Entwurfes:
Das CAN-Modul für das Huawei Netzteil besteht ja nicht nur aus dem MCP2515 (das ist der CAN Controller), sondern auch aus ein CAN-Transceiver. Ich verstehe Deinen Entwurf so, dass Du ein Modul wie dieses https://www.az-delivery.de/en/products/mcp2515-can-bus-modul über die Pfostenleiste integrieren willst?
Das Problem dabei: man braucht getrennte Spannungsversorgung für den Transceiver (5V) und den Controller (3,3V). Darum muss man das verlinkte Board ja auch modifizieren. Also müsste man in Deinem Entwurf einen PIN für die 5V Versorgung vorsehen.
@cacu15 ja richtig ich würde so ein Modul verwenden, da ich bis jetzt noch keinen Schaltplan von so einem Modul gefunden habe. Ja das mit den 5V habe ich gesehen und eine Schraubklemme mit den 5V des ESPs belegt.
Hier im Bild noch einmal markiert.
Und so würde die PCB aussehen ohne Buchsenleisten
@erwano Also es gibt schon ein paar wichtige Unterschiede zwischen meinem Ansatz und der Lösung von dem BavarianSuperGuy. Auch wenn sie natürlich das gleiche Problem lösen sollen, das automatisch geregelte Überschuss Laden einer LiFePo4 Batterie mit dem Huawei Netzteil.
1. Mein Regler ist eine C++ Konsolenanwendung für Linux Mini Computer (Raspberry Pi), seine läuft auf ESP8266 Mikrokontrollern und hat eine Web GUI
2. Mein Ansatz erfordert keine Hardware Manipulation (Leiterbahn auftrennen und 5V Leitung ziehen) nur ein CAN Adapter mit Linux support (USB-to-CAN geht auch)
3. Meine Software verwendet kein periodisches Polling des Power Werts vom Energy Meter. Mit einem kleinen Berry Script, das auf dem Tasmota Smart Energy Meter ("Volkszähler") läuft - geht nur mit ESP32 Version von Tasmota - sendet das Energy Meter Script nur neue Power Werte an den Raspberry Pi, wenn es eine Mindeständerung gibt, d.h. die Hysterese um den Regler zu entlasten findet direkt am Stromzähler statt.
Ich habe auch bewusst auf UDP Pakete für die Kommunikation zwischen Energy Meter und Linux Software gesetzt, weil diese extrem leichtgewichtig sind und sich deshalb gut eignen für so eine Event basierte Regelung. Im Endeffekt wird dadurch die durchschnittliche Reaktionszeit des Reglers auf dem Raspberry Pi besser und der Netzwerk Overhead trotzdem weniger, verglichen mit periodischem HTTP Polling oder MQTT wie es in fast allen anderen, mir bekannten Systemen, eingesetzt wird (OpenDTU-onBattery, BavarianSuperGuy, NodeRed + HomeAssistent/IOBroker, etc.)
@cacu15 @energygeek oder ich mache das so, habe nämlich das passende Schematic gefunden.
Ich habe da gar keine Erfahrung, brauche daher etwas Zeit, um mir das anzusehen. Mache ich am Wochenende.
Erstes Feedback:
Für das NRF24L01+ Modul habe ich zwischen + und GND einen Kondensator (220 uF) gelötet, um die Versorgungsspanung zu stabilisieren. Sonst hatte ich sehr viele Re-Transmits. Often wird sogar eine Kombination aus einem kleinen (10 nanoF) + 1 größeren Kondensator (100 - 400 uF) einzusetzen. Könnte man das auf dem Board gleich vorsehen?
Ebenso wird ein Kondensator oft für die Stabilisierung der Versorgungsspannung des ESP empfohlen.
Wenn ich das richtig sehe, dann planst Du, den CAN-Transceiver für den Pylontech direkt als SMD Device auf das PCB zu löten? Ich selbst habe gar keine SMD-Lötausrüstung und könnte das daher gar nicht ohne weiteres nutzen. Für mich wäre es daher einfacher, wenn man auch dieses Modul einfach über eine Stiftleiste auf das PCB steckt. Aber das gilt nur für mich 😉 Un es braucht dann auch mehr Platz auf dem PCB.
@cacu15 Moin. Danke, kannst dich dann ja noch einmal melden.
Ja den Kondensator könnte ich direkt auf dem Board platzieren und verschalten. Möchtest du lieber einen oder beide Kondensatoren haben, und wenn beide dann parallel oder in Reihe?
Und was für einen Kondensator für den ESP und wo zwischen?
Richtig auf Grund der Größe würde ich eigentlich gerne so gut wie alles SMD löten, vielleicht sogar direkt beim Hersteller machen lassen. Ist die Frage in wie weit ihr das gerne möchtet (relay board, can für pylontech, can für Huawei)
@lukasvfl99 Also zu erst mal, ich finde es Klasse, dass du PCB designs für OpenDTU on Battery machst, weil ich glaube zuverlässige kompakte Platinen machen das System nochmal deutlich attraktiver, hinsichtlich dem Aufwand für Aufbau und Installation der Hardware und auch der Stabilität. Auf lange Sicht will man ja weg kommen von Breadboards, unsauberen Lochplatinen, Wackelkontakt anfälligen Kabelverbindungen & Co.
Ich fürchte auch das SMD PCBs zum selbst Bestücken für viele eher eine Hürde sind bzw. wahrscheinlich ist es gar nicht unbedingt leichter SMD Bauteile sauber aufzulöten als eine Lochrasterplatine mit Stiftleisten und Breakoutboardmodulen selbst zu machen, wenn man nur Basic Lötausrüstung zur Verfügung hat.
Mich würde interessieren, was es braucht an PCB Files + Bauteillisten, sodass man seine Wunschplatine samt Bestückung bei diversen Online Anbietern bestellen kann und eine fertige Platine zu gesendet bekommt.
Kennt sich da jemand aus, ist das möglich? Gibt es solche Angebote? Ist das deutlich teurer als unbestückte Platinen?
Für OpenDTU (ohne Battery) gibt's meines Wissens schon kleine Anbieter, die betriebsbereite Platinen für vertretbare Preise verkaufen.
Weil ich denke eben, dass so eine Lösung den allermeisten Helfen würde und auch viele Bereit wären dafür Geld zu Bezahlen, wenn sie eine funktionierende fertige Platine bekommen und nur noch verkabeln und einrichten müssten.
@energy-geek ich hatte überlegt zwei verschiedene Designs zu machen. Einmal alles über SMD und einmal alles mit Stiftleisten. Wenn das von euch abgesegnet ist würde ich Mal beide Designs beim Händler hochladen und gucken was das preislich für ein Unterschied ist. Das Ding ist auch das man immer 5 Stück bestellen muss.
Ich hab auch schon überlegt die PCBs zu bestellen (unbestückt) und Zuhause zu bestücken. Das passende Equipment hätte ich da.
@lukasvfl99 Konkret zu den Bauteilen
Also die meisten verwenden direkt am NRF nur einen 100uF Elko (funkt gut, kann ich bestätigen). Ein kleinen 10nF (wahrscheinlich Keramik Ka), wenn dann parallel zu dem größeren Elko, kann man machen, braucht man glaub nicht aber kann bestimmt nicht schaden.
An der 5V Hauptstromversorgung (zwischen 5V und GND) würde ich auf jeden Fall noch einen großen Puffer Elko (mind. 470uF oder so) hinmachen. Die Frage ist auch was für ein Anschluss man nehmen sollte. Also einfach +/- Lötpads, eine typische Hohlstecker Buchse für Netzteile oder sogar ein USB Typ-C Anschluss, ich würde es abhängig machen davon ob eins erheblich teurer als das andere ist oder ob das nur Cent Beträge Unterschied sind. Wenn es eine elektrisch unkomplizierte Lösung für einen einfachen Verpolungsschutz gibt (vllt mit paar Dioden oder so, bin da kein Experte) wäre das ein nettes feature ist aber nicht ganz so wichtig.
Bei Pylontech CAN und Huawei CAN wär schon gut wenn die vollständig auf der SMD Platine sitzen und nur die nötigen Anschlüsse (CAN-High, CAN-Low, etc.) mit schraubklemmen oder so rausgeführt werden. Genau so das NRF24L01+ Funkmodul, wenn's geht komplett in SMD drauf + (mini) SMA Koaxial Antennen Anschluss.
Bei dem Relais wäre es natürlich am besten, stattdessen einen Optokoppler in SMD Format auf die Platine zu machen. Hier im Forum hat schonmal jemand bestätigt, dass es hervorragend funktioniert. Da dann auch wieder nur die zwei Slot Detekt Leitungen fürs Huawei Netzteil mit Schraubklemmen raus führen.
Das sind spontan die wichtigsten Punkte die mir eingefallen sind, bin aber kein Experte im Bereich Schematics & PCB Design.
Noch ne Frage zum Schluss, wie ist eigentlich der ESP32 selbst integriert auf der Platine? Gibt's den gesamten Mikrocontroller auch einfach als SMD Bauteil oder hast du evtl vor, das einfach über einen Art Sockel für die Pinleisten zumachen, so dass man die üblichen ESP32 Entwicklerboards (wie z.B. NodeMCU) aufstecken kann. Weil da müsste man ja auch wieder aufpassen mit der Kompatibilität (Pinout, Pin Anzahl, DevModul Breite) verschiedener Entwicklerboards.
VLG
@energy-geek Danke schon mal für die vielen Infos. Wird erledigt mit den Kondensatoren. Poste heute ein Update dazu.
Wie macht ihr das denn bis jetzt mit der Spannungsversorgung? Ich würde einfach über den USB-Port des ESP32 Nodemcu gehen. Oder reicht das nicht?
Zwecks Antenne ich glaube Kosten und Nutzen, wäre es am einfachsten das Modul per Stiftleiste auf die Platine zu bringen.
Hast du einen Link zu dem Optokoppler Artikel?
EDIT: Das ist der bisherige Entwurf mit eingefügten Kondensatoren.
@pv-maix du meintest mal, Slot Detect mit Optokoppler an statt Relais klappt gut. Könntest du ein paar Details dazu ausspucken?
Was für ein Optokoppler Bauteil hast du verwendet (Link, Datenblatt)? Wie sieht die Anschlussverdrahtung aus? Vorwiderstand nötig?
Das wäre super hilfreich für das Platinen Design, wenn man das klobige Relais weglassen kann.
Hallo zusammen
mein Projekt ist mittlerweile auch weitgehend abgeschlossen. Sehr stark inspiriert von diesem Thread, aber doch etwas anders.
Hier ein kurzer Umriss der Komponenten:
- 105Ah EVE Grade A 16s DIY Akku (ist mir lieber als ein fertiger Pylontech o.ä., ich habe gerne die volle Kontrolle über alle Parameter und komplette Wartbarkeit)
- JK BMS mit 1A Balancer
- Huawei r4850
- Soyosource Wechselrichter
Einen DC Laderegler verwende ich nicht, der Speicher wird bei mir ausschließlich AC über eine vorhandene große Dach PV geladen.
Das ganze wird über einen ESP32 Controller mit extra designtem Board gesteuert.
Folgende Schnittstellen bietet mein Board, alles über steckbare Schraubklemmen:
- 5V Versorgung
- ESP32 D1 mini board steckbar
- UART und BLE zum JK BMS (aktuell nutze ich aber nur BLE)
- CAN zum Huawei (sn65hvd230 tranceiver)
- Optokoppler zum Schalten des Slot Detect am Huawei (aktuell nicht verwendet, wegen zu hohem Standby Verbrauch)
- Schnittstelle zu einem 5V 20A Relais Board (damit schalte ich das Huawei stattdessen AC seitig ab)
- RS485 zum Soyosource für dynmische Einspeiseregelung
- Galvanisch getrennter UART zum Soyosource um Daten auszulesen
- Steckplatz für NRF Modul (aktuell von mir nicht verwendet, wollte mir aber die Option offen halten, auch einen Hoymiles zu verwenden)
Wie auch sonst einiges an dem Projekt, ist auch das Gehäuse meines Controllers 3D gedruckt.
Softwareseitig setzte ich für meine DIY Projekte am liebsten auf ESPHome, da hiermit die Integration in mein Smarthome System (Homeassistant) am einfachsten und "nahtlos" ist. Daher habe ich mich auch hier für ESPhome entschieden. Eine Komponente zum Steuern und Auslesen des Huawei habe ich noch selbst geschrieben, alles andere gab es schon "fertig":
https://github.com/mb-software/esphome-huawei-r4850
Die Lade- und Einspeiseregelung ist ebenso wie sämtliche Überwachungsfunktionen und SOC/SOH Berechung etc. im ESP32 und ESPHome realisiert, somit kann das System auch unabhängig vom Smarthome Server arbeiten und - viel wichtiger - im Falle eines Fehlers abschalten.
Das ganze läuft jetzt seit einigen Wochen im Testbetrieb, seit einer guten Woche durchgehend im Produktivbetrieb. Ich bin sehr zufrieden, meine Netzeinspeisung ist seit dem bei 0,0 bis 0,1kWh pro Tag.
Falls jemand etwas ähnliches bauen möchte, ich hätte noch 3 PCBs mit bestückten SMD Komponenten meines Boards übrig (-> PN)
cool, dass Du schon eine Integration des Huawei in ESPHome geschrieben hast. Ich habe auch angefangen, zumindest die Ladelogik nach ESPHome auszulagern, weil ich da auch meinen Stromzähler über einen IR Lesekopf auslese und auch eine Consolen-Integration für den Pylontech gebaut habe, um den Status der einzelnen Zellen lesen zu können. Aktuell steuere ich das Huawei aber noch der REST API von OpenDTU.
Ich hatte auch überlegt, das Huawei über ESP Home zu steuern, weil ich auf meinem OpenDTU ESP nicht genug Anschlüsse frei habe, um den ESP per Ethernet statt WLAN zu integrieren. Dein Modul bringt mich dem schon einen Schritt näher.
mein Bild wäre:
1 ESP mit OpenDTU, der für das Einspeisen zuständig ist und an dem der Hoymiles und der Pylontech Akku (CAN Interface) hängen
1 ESP mit ESPHome, der für das Laden inkl. Akkumgmt und Stromzähler zuständig ist. da würde dann das Huawei dran hängen und der Pylontech mit der Consolen-Schnittstelle
beide ESPs mit Ethernet, die mit statischer IP am gleichen Switch hängen.
P.S. : Dein Board wäre für mich spannend, wenn es denn stattdessen D1 für einen Ethernet fähigen ESP gebaut wäre (Olimex ESP POE, ETH 01 o.ä.).
@lukasvfl99 Hallo Lukas, vielen herzlichen Dank für deine Mühe und spontanen Anpassungen. Bzgl. der Spannungsversorgung wäre es für mich ok, wenn wir das über den USB Port machen. Bzgl. der zwei "Produktionslinien" ( SMD-fertig bestückt; vs. Steckerleistenplatine zum selber bestücken) finde ich eine gute Idee.
Leider reichen meine Elektronikenntnisse nicht aus, um zu erkennen, ob das aktuelle Layout alles das widerspiegelt, was der ursprüngliche Entwuf (L I N K ) vorsah, also die Anbindung an Pylontech via SN65HVD230, Anbindung Huawei via MCP2515, Anbindung Hoymiles via NRF 24L01+, Slot Detect Schaltung des Huawei via z.B. Optokoppler.
Wenn alle diese Punkte berücksichtigt sind, dann bin ich sehr interessiert und stehe gerne als Testpilot zur Verfügung.
Ich könnte mir auch vorstellen, dass wir im Rahmen unseres Maker Space eine größe Anzahl an Platinen benötigen würden. Meld dich gerne, sobald du Preise kennst und es losgehen kann.
