Standby-Verbrauch habe ich nicht gemessen.
Der Pylontech entleert sich nicht. Ich schalte auch nichts ab und das lief den Winter durch. Der Akku bleibt bei 20%. Es gibt da m.E. kein Problem das man Software seitig lösen müsste
Bzgl. HM 1500 möchte ich auf den anderen Hoymiles Thread und die Infos hier verweisen:
Sollte man zumindest kennen
@arch86
Ich habe einen HM600 statt eines HM1500. Aber sonst vergleichbar. ICh habe nicht gemessen, aber auf keinen Fall ist der Akku in 2 Tagen von 20% SoC auf 5% SoC runter. Ich schalte allerdings das Huawei AC seitig ab, der Inverter ist aber immer an. Bei mir verliert der Akku über 2 Tage ca. 1%-Punkt an SoC.
@MalteS: Du hast doch bei Dir auch das Laden über einen SmartSolar im Einsatz, richtig? Vermutlich produzieren die daranhängenden Module selbst in der dunkelsten Zeit genug, um wenigstens den Eigenverbrauch der Anlage zu decken und darum hast Du das Problem nie?
Was aber etwas gefährlich ist: Bei mir ist der SoC Verlauf bei < 15 % nicht mehr wirklich linear. Da war der Akku sehr plötzlich (innerhalb von 1h) von 10 oder 12% auf nur noch 5% und forderte sofortiges Laden an. Die "Notladung" realiere ich gerade auf ESPHome, was ich eh' auf einem separaten ESP habe. Dort frage ich dann alle paar Minuten den Akkuzustand ab. Wenn darin sofortiges Laden anfordert wird, dann lade ich unabhängig von PV Überschuss auf einen vorher festgelegten SoC-Zielwert. Ist fast fertig, aber wegen anderer Projekte komme ich gerade nicht dazu, das fertig zu programmieren.
Das kann man aber genau so gut in Node Red oder so jeder anderen Umgebung implementieren, die REST oder MQTT kann.
Möglich. Aber viel kommt da an Tagen wo Schnee auf den Modulen liegt nicht 
Ich habe selbst da keine Entladung beobachtet und gelegentlich auf mein Node Red Dashboard geschaut. Das zeigt mir die letzten 6h an. Da gab es nichts zu sehen.
Ich versuche eine Steuerung in PHP für einen Huawei AC zu programmieren. Dabei stelle ich mir die Frage, wie richtig geladen werden muss. Der Huawei lässt sich dynamisch mit V und A ansteuern. Als Ladespannung arbeite ich mit 55,2 V.
Je nach PV Überschuss steuere ich dann die Ladeleistung dynamisch, von etwa 3 A bis 20 A, bei konstant 55,2 V. Der Überschuss kann zwischenzeitlich durch Wolken/Sonne stark schwanken. Sind solche Spitzen schädlich für den LiFePo4 Akku, wenn es also zum Beispiel einen Sprung von 3 A auf 20 A gibt (Sonne kommt hervor) oder anders herum 20 A auf 3 A runter (Wolken)? Sollte man die Spitzen besser abfedern, in dem man zum Beispiel von 3 A auf 20 A in mehreren Schritten hochregelt bzw. abregelt?
Gleiche Fragestellung für den Huawei 4850G2: Sind solche (kurzen) Ladesprünge für die Ladeelektronik o.ä. schädlich?
Wie steht es mit dem Entladen des Akkus? Klassiker wie Kochherd oder Bügeleisen, die zwischendurch immer wieder kurzzeitig hohe Leistung für einige Sekunden anfordern, um die Temperatur zu halten, und dann wieder stark abfallen. Wenn der Akku dann per OpenDTU immer wieder kurzzeitig Lastspitzen gegenregeln muss - ist das für LifePo4 Akkus und/oder Hoymiles WR schädlich?
Wäre prima, wenn dazu jemand relativ leicht verständliche Erklärungen parat hätte. Danke schon mal!
@arch86 Die Variante A des Huawei Adapters funktioniert bei mir auch. Die Masse-Leitung ist hier schraubbar ausgeführt. Sonst sehe ich keine Unterschiede
Mein Akku ist da! Das System läuft jetzt! Sobald ich die provisorische Phase durchlaufen haben und das System fix ist, poste ich hier meinen Bericht und Bilder... 
Vielen Dank an alle hier! Insbesondere an @maltes für die Initiative und Dokumentation, @Alex_S für die Platine und Unterstützung und ohne Deine detaillierte Antworten @CaCu15, hätte ich es gar nicht angefangen. Merci beaucoup!
Jetzt noch ein lustiges Thema... Anmeldung...
Ich möchte natürlich nicht dass einen Elektriker hier erscheinen muss, das wäre eine Katastrophe. Im MaStr. gibts drei Möglichkeiten:
Die erste zwei: bei der Einheit den drop down for Speicher auswählen:
a) Solaranlage und Speicher sind zusammen
b) Solaranlage und Speicher sind getrennt
Dann doch auf der Startseite
c) Einheit registrieren
Welche gibt am wenigsten "trouble", a) oder b) oder c)? Oder soll ich es gar nicht anmelden?
Da ich zwei räumlich getrennte kleine Solaranlagen habe, habe ich beschlossen, auch auf das AC-Laden eines Pylontech mit dem Huawei-Netzteil umzusteigen.
Geplante Konstellation:
Die OpenDTU-onBattery liest den Stromzähler aus und regelt das Huawei-Netzteil zum Laden des Pylontech und einen Hoymiles HM-600 zum Entladen des Akkus bzw zum Einspeisen in das Hausnetz.
Später werde ich ggfs ein eigenes Pythonprogrämmchen schreiben, das das Auslesen aller Komponenten übernimmt und das Huawei und den HM-600 regelt. (Falls ich mit dem eingebauten Regelverhalten der OpenDTU-onBattery nicht zufrieden sein sollte.)
Über kleinanzeigen.de habe ich mir eine OpenDTU-onBattery zugelegt und mit dem Verkäufer ausgehandelt, dass er den zusätzlichen CAN-Bus für das Huawei R4850G2 draufbaut.
Inzwischen ist alles da, und ich versuche als erstes, die Kommunikation mit dem Huawei zu testen.
Problem a)
Der Verkäufer hat mir netterweise die passenden Kabel samt Stecker mitgeliefert, leider passen die Stecker mehr recht als schlecht auf die Buchsen des Huawei-Adapters und rasten auch nicht ein. Inzwischen ist mir auch eine Litze am Stecker (also vom Kabel, das von der OpenDTU-oB kommt) für den Huawei-CAN-Bus abgebrochen.
Wo kann man genau passende Stecker für den Huawei-Adapter auftreiben? Weiß jemand wie der genaue Typ heißt und wo man ihn bekommt? Und vermutlich braucht man eine spezielle Crimpzange, um die Litzen in den Inlets dieser Stecker festzupressen?
Problem b)
Weder vor dem Bruch der Litze noch nachher bei improvisierten Verbindungen hat die OpenDTU-onBattery Kontakt mit dem Huawei bekommen. Egal, wie herum ich die beiden Litzen gepolt habe. In der OpenDTU-Oberfläche war das Huawei freigeschaltet, in der Console wird immer ausgegeben:
21:16:41.516 > [HuaweiCanClass::loop] Data request error
21:16:42.106 > RX Period End
21:16:42.230 > All missing
21:16:42.277 > Nothing received, resend whole request
21:16:42.294 > TX AlarmData Channel: 40 --> 15 83 82 19 76 80 12 57 44 80 11 00 65 F8 A1 1C 00 00 00 00 00 00 00 00 78 D0 E3
21:16:42.323 > RX Period End
21:16:42.494 > All missing
Auffällig ist noch, das diese OpenDTU-oB merklich langsamer als meine bisherige OpenDTU-oB (ohne Huawei.Anschluss) reagiert. Und eben habe ich testweise die Sendeleistung von "Low (-12 dBm)" auf "High (-6 dBm)" gestellt, und seitdem kann ich die OpenDTU-oB nicht mehr erreichen. Auch nicht nach Aus- und wieder Einstecken des USB-Ladenetzteils, um die OpenDTU-oB gründlich zu resetten.
Ich bin kein Hardware-Mensch und habe derzeit keine Ahnung, wie ich weitermachen soll. Laut Digital-Multimeter liegen an den CAN-Kabeln von der OpenDTU-oB her ca. 0.4V an, d.h. die Kabel sind wohl in Ordnung, und die OpenDTU-oB schickt auch irgendwelche Pegel auf die Leitungen.
Hat jemand einen Ratschlag, was ich testen/kontrollieren/... sollte?
Oder kaufe ich besser einfach nochmal eine weitere OpenDTU-oB mit Huawei-Anschluss? (Angebote willkommen ;-))
Herzlichen Dank schon mal fürs Lesen und drüber Nachdenken ...
@forum2023 Versuch mal die Frequnz des CAN Bus controllers umzustellen
Inzwischen weiß ich, warum ich die OpenDTU-oB gestern Abend nicht mehr im WLan erreichen konnte. Aus mir unbekannten Gründen hat sie einen "General-Reset" hingelegt und alle - wirklich alle - Einstellungen verloren.
Per Smartphone habe ich sie als eigenen Hotspot wieder gefunden und wieder ins WLan eingehängt und die mir geläufigen Einstellungen in Security und MQTT wieder eingetragen.
Jetzt wird es aber schwieriger. Im Device manager steht unter "Selected Profile" nichts und in der Liste der "Active" Pins stehen überall -1, außer bei "Display" (4x 255 und 1x 0) und bei "Eth" (0, 0, false, 23, 18, 0, -1, 0). "Battery", "CMT", "Huawei", "LED", "Nrf24" und "Victron": alles -1.
Setze ich das "Selected Profile" auf "Generic NodeMCU 32", dann tauchen immerhin Einträge für "Battery", "Huawei", "Nrf24" und "Victron" auf.
Ich hoffe, das passt dann so?
Ich habe jetzt beide Kabelpolungen mit jeweils beiden Frequenzen (8MHz und 16MHz) durch, aber weiterhin kein Kontakt mit dem Huawei, ausschließlich 0.0-Werte in der Anzeige und weiterhin
11:04:30.379 > [HuaweiCanClass::loop] Data request error
BTW: Die OpenDTU-oB-Version, die der Verkäufer draufgespielt hat, ist:
SDK Version v4.4.6-dirty
Config Version 0.1.27
Firmware Version / Git Hash 2024.01.26
Chip Model ESP32-D0WD-V3
Chip Revision 3
Ich vermute deine Pins stimmen nicht. So schaut das bei mir aus.
Ich kompilie das aber so in die Firmware. Du wirst ein pinmux file erstellen müssen. Da habe ich aber keine Ahnung wie das geht. Sollte aber im Wiki stehen
Schaut nahezu gleich aus.
Laut Wiki ist das einfach nur ein JSON-File. So eines habe ich von Lukas sogar noch herumliegen. Aber um das zu meiner Hardware passende Mapping zu erzeigen, müsste ich zum einen die neue OpenDTU-oB zerlegen und dann zum anderen dann noch fähig sein, anhand der Verdrahtung zu erkennen, welchen Pin wohl was sein wird - und spätestens das wird mich wohl überfordern.
Am besten schreibe ich nochmal den Verkäufer an und hoffe, dass er diesmal antwortet.
@forum2023
Was für einen CAN-Controller benutzt DU denn? Ist das ein MCP2515? Hat Dein Verkäufer da auch die nötigen Umbauten für die korrekte Versorgungsspannung vorgenommen? Siehe dazu https://forums.raspberrypi.com/viewtopic.php?t=141052. Oder nutzt Du ein CAN Modul von Joy-IT, wo man schon 5V und 3,3V getrennt versorgen kann?
Falls nein: Dann wird Dein CAN vermutlich nur mit 3,3V versorgt und das entspricht NICHT der CAN Spezifikation. Das KANN zwar funktionieren, ist aber nicht sicher.
Der Verkäufer hat netterweise gleich geantwortet und mir die Mappingdatei zukommen lassen. Ich spiele sie gerade ein und schaue, was passiert. ;.-)
Kann ich das irgendwo in der Weboberfläche nachschauen? Oder muss ich dazu die Hardware zerlegen?
Wenn ich mal davon ausgehe, dass der Verkäufer NICHT für Dich extra ein eigenes PCB entworfen hat, auf dem der Controller direkt integriert ist, dann müsstest Du ein separates kleines Board haben, dass etwas aussieht wie auf dem Foto unten. An den beiden Schraubklemmen müsste der CAN zum HUAWEI angeschlossen sein.
Wenn Du so ein Board einsetzt, dass musst Du entweder 1 Variante haben, bei dem als Versorgungsspannung 1 mal 3,3V und 1 mal 5V angeschlossen werden kann (Joy-IT Board).Die beiden PINS sind meist mit "VCC" und "VCC1" beschriftet. Wenn Du nur 1 PIN hast, der "VCC" heißt, dann muss das Board entsprechend der Anleitung unter dem Link oben modifiziert werden, damit der CAN die korrekte Spannung bekommt.
Ferner wäre noch wichtig, dass der Terminationswiderstand auf dem Board aktiv ist (dazu einen Jumper auf die Stiftleiste an der unteren Platinenkante setzen). Ein CAN Bus muss an beiden Enden durch einen Abschlusswiderstand abgeschlossen werden.
P.S: Die Stecker am Huawei sind vom Tyo JST-SM - dafür braucht man in der Tat eine spezielle Crimp-Zange. Man kann aber auch
auf die Adern, die vom Controller kommen, je eine Dupont-Buchse aufkrimpen. Die kann man dann auch einzeln auf die beiden Kontakte in dem Stecker aufstecken. Das ist aber eher keine dauerhafte Lösung (und man muss jedes Mal auf die Polung achten, damit man CAN-H und CAN-L nicht vertauscht)
den Stecker am Huawei einfach abschneiden und die Adern direkt verbinden oder einen anderen Stecker aufkrimpen, den man zur Hand hat.
Ich kann auf dem Board keinen Hersteller finden, aber es sieht praktisch genauso aus wie das auf deinem Foto. Insbesondere dass die Pfostenleiste links wie bei dir nur GND und VCC enthält. Allerdings geht eine rote Litze vom Basisboard auf die Rückseite des Can-Boards und ist irgendwo mittig aufgelötet und dann großflächig mit weiß isoliert. Insofern scheint diese manuelle Modifikation gemacht zu sein.
Der Abschlusswiderstand für den CAN Bus fehlt, da werde ich in meiner PC-Kramskiste nach einem passenden Jumper suchen.
Mit dem Mapping File habe ich noch etwas Schwierigkeiten.
Unter "Einstellungen" -> "Konfigurationsverwaltung" wähle ich in der mittleren Zeile links "Pin Mapping", dann wähle ich die passende Datei über "Datei auswählen" aus, der Dateiname wird Mitte rechts dargestellt, und dann klicke ich auf den Button "Wiederherstellen".
Die DTU tut irgendetwas und dann gehe ich zu "Einstellungen" -> "Hardware". Überraschenderweise sind da weiterhin die alten vier Default-Profile auszuwählen, aber nicht die neuen drei aus der neuen Mappingdatei.
Wie kann ich eines der neuen Mappingprofile aus der mapping.json aktivieren?
Neue Mapping-Datei: Das Wiki klingt fast so, als sollte das pure Hochladen der Datei reichen, d.h. der Button daneben ("Restore" bzw "Wiederherstellen") wird wohl nicht gebraucht?
Just select "Pin Mapping (pin_mapping.json)" in the recovery section.
When the file is uploaded the ESP performs a reboot. This is required as the pin settings could have changed within the file. [...]
To change the device profile, navigate to the "Device Manager" and selected the appropriate profile. You can see the current (Active) and the new (Selected) in assignment in the table below the combobox.
(Wenn ich aber zum Device Manager gehe, sind da weiterhin die vier Default-Profile und keines der neuen aus der mapping.json.)
Erfreuliche Neuigkeiten, seit gestern spät abends funktioniert die Kommunikation mit dem Huawei endlich. (Ich hätte es gestern auch gleich geschrieben, aber das Forum war anscheinend außer Gefecht.)
Im Endeffekt habe ich die DTU nochmal über OTA mit der v4.4.6-dirty neu geflasht, und dann ließ sich das Pin-Mapping-JSON aktivieren.
An die Profis hier - @MalteS und @CaCu15 - welche Version der OpenDTU-oB würdet ihr empfehlen? Ist die v4.4.6-dirty noch gut, oder sind neuere besser? (Mein Verkäufer meinte, dass bei der ganz aktuellen störende Bugs reingerutscht wären?)
| 2024.03.07 funktioniert bei mir prima seit zwei Wochen. Huawei R4850, HM-1500, US5000. |
@forum2023
ICh bin ganz sicher KEIN Profi. Zu den Unterschieden zwischen den OpenDTU oB Releases kann Malte sicher mehr sagen, er entwickelt da ja selbst mit.
Bzgl. Version aber folgendes: "4.4.6-dirty" ist die SDK-Version. Wichtiger wäre, dass Du Deine Firmware-Version/Git Hash angibst. Das SDK ist ja nur die Basis, auf der dann die eigentliche SW entwickelt wird. Sicher können da auch Fehler eingebaut werden, aber die OpenDTU spezifischen Unterschiede finden sich erst in der Firmware-Version. Es kann dann sehr viele OpenDTU Versionen geben, die alle auf demselben SDK aufbauen.
Die Liste der OpenDTU oB Releases und die Unterschiede finden sich auf https://github.com/helgeerbe/OpenDTU-OnBattery/releases. Die Releases sind immer nach dem Schema YYYY-MM-DD benannt. Ich bin aktuell noch auf 2024.01.26, werde aber wohl bald mal auf das aktuellste Release upgraden, weil Malte gerade den PR https://github.com/helgeerbe/OpenDTU-OnBattery/pull/767 gestellt hat, den ich gerne einsetzen würde.
Ich mache in der Regel nicht jeden Update gleich mit, sondern warte eher, bis es eine Änderung gibt, die für mich auch relevant ist. Und dann plane ich auch Zeit für den Update und Test ein. Da die HW-Konstellationen und damit die Nutzungsmuster bei den Nutzern ja recht unterschiedlich sind, kann man nicht davon ausgehen, dass ein neues Release bei mir gleich nahtlos läuft.
Z.B. lade ich ausschließlich über ein Huawei Netzteil, ich habe keinen SolarCharger angeschlossen. Das ist bei den meisten Nutzern anders...
@forum2023
ICh bin ganz sicher KEIN Profi. Zu den Unterschieden zwischen den OpenDTU oB Releases kann Malte sicher mehr sagen, er entwickelt da ja selbst mit.
Bzgl. Version aber folgendes: "4.4.6-dirty" ist die SDK-Version. Wichtiger wäre, dass Du Deine Firmware-Version/Git Hash angibst. Das SDK ist ja nur die Basis, auf der dann die eigentliche SW entwickelt wird. Sicher können da auch Fehler eingebaut werden, aber die OpenDTU spezifischen Unterschiede finden sich erst in der Firmware-Version. Es kann dann sehr viele OpenDTU Versionen geben, die alle auf demselben SDK aufbauen.
Die Liste der OpenDTU oB Releases und die Unterschiede finden sich auf https://github.com/helgeerbe/OpenDTU-OnBattery/releases. Die Releases sind immer nach dem Schema YYYY-MM-DD benannt. Ich bin aktuell noch auf 2024.01.26, werde aber wohl bald mal auf das aktuellste Release upgraden, weil Malte gerade den PR https://github.com/helgeerbe/OpenDTU-OnBattery/pull/767 gestellt hat, den ich gerne einsetzen würde.
Ich mache in der Regel nicht jeden Update gleich mit, sondern warte eher, bis es eine Änderung gibt, die für mich auch relevant ist. Und dann plane ich auch Zeit für den Update und Test ein. Da die HW-Konstellationen und damit die Nutzungsmuster bei den Nutzern ja recht unterschiedlich sind, kann man nicht davon ausgehen, dass ein neues Release bei mir gleich nahtlos läuft.
Z.B. lade ich ausschließlich über ein Huawei Netzteil, ich habe keinen SolarCharger angeschlossen. Das ist bei den meisten Nutzern anders...
