adding RS485 Pylontech support (to free up a CAN controller)

[gitisgreat2023]

Here one can find python code for accessing Pylontech batteries via the RS485 interface.
Is someone willing to port this to c and integrate it in OpenDTU-OnBattery?
See the PDF file, which describes the protocol Pylontech uses for the RS485 interface.

This could free up the CAN controller of the ESP32. That could then be used for other devices. For example an ethernet controller or enabling to use CMT2300A with Huawei and Pylontech.

[Manos1966]

does the CMT2300A not work with Pylontech CAN?

can one not hook up more devices to CAN?

[Manos1966]

@gitisgreat2023 I am not sure about this....
Have you tested a HMS/HMT (CMT2300A) and a Pylontech via CANbus and it does not work?

Because I remember writing in the Wiki:

• Using the Huawei AC charger in combination with the CMT2300A radio board is not supported at the moment.
• The MCP2515 is hardcoded to SPI 2
• The CMT2300A uses 3-Wire half duplex SPI communication. Due to this fact it currently requires a separate SPI bus. If you want to run the CMT2300A module on the same ESP32 as a NRF24L01+ module or a PCD8544 display, make sure you get a ESP which supports 2 SPI busses. Currently the SPI bus host is hardcoded to number 2

However, Pylontech CAN does not require an MCP2515 , it uses a SN65HVD230 CAN-Board instead.
(The MCP2515 CAN bus module consists of a CAN bus controller and a CAN bus transceiver.
The SN65HVD230 CAN bus module is only CAN bus transceiver )

[gitisgreat2023]

No, I didn't because the software is the issue.
The ideal solution would be that the SPI busses aren't fixed anymore. Then a Huawei, a Pylontech and HMS could be used together. So even without a NRF24L01+ and/or a PCD8544 it isn't even possible, that 3 combination.

[Manos1966]

OK, but IF you have not tested it, HOW can you say there is an issue using HMS/HMT (CMT2300A) and a Pylontech via CANbus with SN65HVD230 CAN-Board?

[alexseuf]

ich denke ihr sprecht auf englisch ein bischen aneinander vorbei...
ich habe die Idee so verstanden:
es wird nach einer Lösung für gleichzeitigen Betrieb von

• Pylontech-akku;
• HMS/HMT (CMT2300A) => da HM1500 nicht mehr neu produziert werden...
• und Huawei AC-charger

gesucht was heute nicht möglich ist wg. der festen codierung "MCP2515 is hardcoded to SPI 2"

Der Workaround wäre dann

1. den Pylontech über RS485 anzusprechen (womit würde dieser dann auch mehr Daten als über CAN mitteilen könnte z.B. min und max Zellspannungen) Pylontech über RS485 ist aber bisher in der SW nicht impementiert und es liegt nur das oben verlinkte Beispiel in Pyton vor
2. den Huawei über die dann frei gewordene ESP32 onboard CAN ansprechen, (nicht mehr über MCP2515)(wofür die huawei Sw-Library aber vmtl. geändert werden müsste)
3. der dann nicht mehr für den MCP2515 benötigte SPI Bus könnte so wie bisher auch für den CMT2300A verwendet werden.

Ich hoffe ich habe das richtige verstanden und verstehbar wiedergegeben..

[Manos1966]

Hi @alexseuf
Ah, ich verstehe jetzt! 🤦‍♂️ (hoffe ich).
Ich bin kein Programmierer, ich kann mich nur an die Diskussionen die ich gelesen habe, erinnern. Kurz zusammengefasst (OHNE GEWAERLEISTUNG, hoffentlich erinnere ich mich richtig...):

• Der Pylontech CANbus ist nicht das Problem. Es macht kein Unterschied ob es auf RS485, oder CANbus kommuniziert (Deswegen konnte ich verstehen warum er so auf die Pylontech fokusiert ist)
• Der MCP2515 ist Sender und Receiver, aufgrund des hohen Ressourcen-Verbrauchs braucht sein eigenes SPI. Man kann es also nicht weg von SPI 2 bewegen!
• Die richtige Loesung waere das CMT2300A auf SPI 1 umzuschreiben.
• Die CMT2300A Library ist nicht ganz compatibel mit dem restlichen Code von tnobody und obwohl es in der Vergangenheit diskutiert wurde, niemand hat bis heute die notwendigen Anpassungen gemacht.
• Der Code fuer das CMT2300A ist Teil der OpenDTU (ohne Battery). Daher Aenderungen unterliegen nicht hier, sondern beim "OnBattery" Team.

Ich habe das Thema irgendwo in die Wiki geschrieben, kann mich aber nicht erinnern.
Gefunden: https://github.com/helgeerbe/OpenDTU-OnBattery/wiki/Device-Profiles#spi-bus

[skippermeister]

Ich sehe hier 2 Möglichkeiten zur Realisierung.

1. es gibt den CAN Controller auf einem fertigen Board mit I2C oder mit Serial Kommunikation.

Z.B. https://www.seeedstudio.com/I2C-CAN-Bus-Module-p-5054.html

Das Board hat einen Atmega168PA als Interface. Dieser übernimmt auf der einen Seite die I2C oder Serial Kommunikation zur Host CPU (ESP32) und auf der anderen Seite zum MCP2515 über SPI. Der Treiber hierzu ist im github verfügbar. Jetzt müsste nur noch der Treiber im Pylontech Modul ausgetauscht werden. Das ist ein wenig Aufwand, aber kein Hexenwerk. Dann würden lediglich 2 GPIO Ports benötigt. Und das könnten wg. I2C auch die des Displays sein, sofern über I2C angesteuert.

2. Alternativ die Kommunikation zur Pylontech über RS485 realisieren. Ich habe das bei mir bereits seit 6 Monaten sehr stabil am laufen. Hierfür werden 2 oder 3 GPIO Ports (RX, TX und TX Enable) benötigt. Allerdings habe ich eine stark modifizierte OpenDTU-onBattery Version. Mein Ladegerät ist ein über CANbus gesteuerter Meanwell NPB-48-1200 Lader. Dazu ist auch das Huawei Modul von mir ersetzt. Ich habe viele Änderungen im C++ Code und im WebUI gemacht.

[alexseuf]

#In der WebGUI wird der Pylontech mit umfangreichen Status Informationen angezeigt, inkl. Einzelzellen. Diese Daten liefert der Pylontech Akku nicht über den CAN Bus.
Außerdem wird der Meanwell Charger sehr detailliert angezeigt.

Kannst du hiervon eventuell mal zwei Bilder hochladen.. das klingt sehr gut

[skippermeister]

Hier ein paar Bilder

[skippermeister]

Schaltplan und Platine als PDF sind in meinem Fork unter docs zu finden

[alexseuf]

als Plyontech Rs485 Pinbelegung sind mir z.B. die foglende bekannt:

in deinem Stromlaufplan legst du aber Pin4 & 5 auf GND? #
Was ist denn die Idee dahinter?

[skippermeister]

ich nutze kein 1 zu 1 Kabel. Ich Crimpe meine RJ45 Kabel selbst. Aber ich gebe Dir recht, das sollte ich ändern. Auch sollte A und B vertauscht werden. Pin 7 am Pylontech ist A und Pin 8 ist B. Auf meiner Schaltung ist die RJ45 Buchse genau anders herum. Der Schaltplan ist nachträglich entstanden, nachdem ich bereits meine Labor Platine (Lochraster mit Wire Wrap Draht) bereits fertig war.

[Manos1966]

Automatisches Ein/Ausschalten der DC-Leitung zum Hoymiles incl. Softanlauf via Vorwiderstand per MOSFet Transistoren

🤩 🤩 🤩 🤩

[Manos1966]

❓ ❓ ❓ ❓

[skippermeister]

Ja, das hat die Pylontech Batterie 3500 Wh / 48 Volt sind ca. 74 Ah

[Manos1966]

🤦‍♂️ diese verdam... Komma mit drei Stellen!

und ich dachte, du hattest eine Tesla Batterie montiert 🤣 (74.000 Ah)

[alexseuf]

Mein Code ist jetzt komplett hochgeladen. Meine Version hat in der Datei 'paltform_override.ini' mehrere Compiler Switche um Code in der Software zu aktivieren oder zu deaktivieren.

dort hast du für den SDM630 die folgenden Einstellungen getroffen:

Du verwendest dort die GPIO_0 für TX und GPIO_39(input only) für RX: über das GPIO_0 kenne ich die folgendeen Infos (outputs PWM signal at boot, must be LOW to enter flashing mode). Hast du schon mal ausprobiert ob das mit diesen Pins auch problemfrei funkioniert?

[skippermeister]

Ich habe die beiden GPIOs schon in anderen Anwendungen ausprobiert. GPIO00 verwende ich als TX Port, somit ist zwar während der Boot Phase hier durchaus "Datenmüll", jedoch ist das für die Empfangsseite meistens kein Problem. Der GPIO39 als RX und somit Input Signal funktioniert einwandfrei.
Ich verwende in meinem Szenario allerdings die beiden Ports nicht, ich habe es somit für OpenDTU nich nicht getestet.

[alexseuf]

hast du ein lauffähiges binary für einen normalen ESP32 (nicht s3)da, dann würde ich es mal an meinem SDM630 probieren?

[skippermeister]

schau mal https://github.com/skippermeister/OpenDTU-OnBattery/releases/tag/2024.02.04
Nim das factory bin. Beachte, dass Du möglicherweise den Cache Deines Browers löschen musst, da ich ein komplett geänderte WebGUI habe. Bei mir muss ich nach Änderungen an der GUI den Cache des Crome Browsers löschen.

[Manos1966]

Hallo @skippermeister

schau mal https://github.com/skippermeister/OpenDTU-OnBattery/releases/tag/2024.02.04 Nim das factory bin. Beachte, dass Du möglicherweise den Cache Deines Browers löschen musst, da ich ein komplett geänderte WebGUI habe. Bei mir muss ich nach Änderungen an der GUI den Cache des Chrome Browsers löschen.

Ich wurde gerne die zusätzliche Pylontech Informationen und das Graph auf meine "normale" OpenDTUonBattery Version addieren.
Wuerde es reichen, wenn ich die Dateien BatteryStats.h und Display_Graphic.h von deiner Release addieren bzw ersetzen wuerde?
(Der Satz "Diese Daten liefert der Pylontech Akku nicht über den CAN Bus." macht mir ein paar Sorgen...)

[skippermeister]

Beachte, kein RJ45 1 :1 Kabel für die Verbindung zwischen dem SP3485 Modul und der Pylontech nutzen. Mein Schaltplan zeigt die Pinbelegung der RJ45 Buchse auf dem SP3485 Modul. Du musst jeweils A mit A und B mit B der RS485 Ports verbinden.

[Manos1966]

MIST! 😭 😭
Danke, dass du es gesehen hast!
Ich habe den Plan hier gesehen und da war ein MAX3232 🙈
https://github.com/hidaba/PylontechMonitoring

Danke fuer den Link, ich habe eins bestellt.

[Manos1966]

@skippermeister Hmmm... ich brauche etwas Hilfe mit dem Schaltplan:

Bereich A: RJ45 Anschluss hat beide PINS 4+5 auf GROUND?

Bereich B:
Schaltplan:
RO
RE
DE
DI
Breakoutboard:
RX-I
TX-O
RTS

Wie schliesse ich sie an?

[skippermeister]

Anschluß Breakoutboard an ESP32
RO = TX-O verbinden mit ESP32 GPIO16 = rs485_rx
DI = RX-I verbinden mit ESP32 GPIO17 = rs485_tx
/RE DE = RTS verbinden mit ESP32 GPIO4 = rs485_rts
3-5V an 3.3Volt des ESP32 anschliessen !!!
GND an GND des ESP32 anschliessen.

Anschluß Breakoutboard an Pylontech
Beachte: das Breakoutboard kann mit einer RJ45 Buchse bestückt werden. Dann ist vom Breakoutboard Pin 4+5 auf Masse gelegt. In diesem Fall auf keinen Fall ein fertiges 1:1 Kabel verwenden.
Am einfachsten geht es jedoch indem Du einfach wie folgt vorgehst:
Nimm ein RJ45 Ethernet Kabel, schneide es auf die benötigte Länge durch und lege die Adern auf der abgeschnittene Seite frei.
Verbinde

• Breakoutboard A an Pylontech A/CAN RJ45 Pin 7 (das ist 485A)
• Breakoutboard B an Pylontech A/CAN RJ45 Pin 8 (das ist 485B)
• Breakoutboard G einfach freilassen
  Die Pins 1 bis 6 auf der Pylontech Seite unbedingt offen lassen. Masse muss nicht verbunden werden, dass kann Brummschleifen geben und damit Störungen. RS485 ist ein Gegentaktsignal.

[Manos1966]

Vielen herzlichen Dank @skippermeister

Auf /RE DE = RTS waere ich nicht drauf gekommen.
Bin gespannt wie schnell die bestellte RS485 Platine ankommt.... 🤩

Danke auch fuer die Erklaerungen bezueglich der RJ45. Kein Problem fuer mich, ich benutze eine RJ45-Dose 😉

[Manos1966]

Hallo @skippermeister
die Platine sollte morgen kommen, danach kann ich testen (die ESP32 ist bereits vorbereitet).

Kann ich noch etwas fragen?
Ich sehe RS485 Platinen bei Amazon, sie haben aber keine "/RE DE = RTS verbinden mit ESP32 GPIO4 = rs485_rts"
This one has GND, RXD, TXD, VCC only

Kann man sie benutzen, obwohl sie keinen RE DE Anschluss hat?

[skippermeister]

Ich habe meine Version in den letzten Tagen erweitert und unterstütze jetzt auch diese TTL zu RS485 Modul Adapter. Diese Module erzeugen das /RE DE Signal selbst. Immer wenn die TX Leitung aktiv wird wird automatisch /RE DE auf senden aktiviert.
Ich lade in den nächsten tagen meine neue Version hoch.
Es gibt dann auch für mein "my_very_special_board" ein json file. Da kannst Du erkennen, wie das Modul ausgewählt wird. Einfach in der Sektion Battery den Parameter rs485_rts weglassen. Der Parser im Modul PinMapping.cpp setzt dann das Strukturelement batteriy_rts auf -1 und das Modul PylontechRS485Receiver stellt den Serial Treiber so ein, dass er mit den beiden PINs RX und TX im Halbduplex Mode arbeitet. Der Vorteil dieses Modules sehe ich in den bereits vorhandenen TVS Dioden und den beiden rückstellenden Sicherung, also der eingebaute Schutz vor Überspannungen.

[skippermeister]

schau nach "my_very_special_board Pylontech via RS485 Type2" in dem file "my_very_special_board.json". Der Type2 ist das TTL zu RS485 Modul

[skippermeister]

Ich weiss nicht wie schnell die Logik des Modules von TX auf RX umschaltet. Ich habe das Modul selbst nicht mit meiner Pylontech Batterie getestet. Die Plyontech braucht ein paar Millisekunden bis sie auf einen Request der OpenDTU antwortet.

[hhoebel]

Keine Sorge - genau dieses Modul arbeitet bei 9600 Baud sehr gut damit zusammen. Ich verwende das mit ESPHome und meinem Akku ohne Probleme.

[Manos1966]

Die Post ist heute nicht gekommen 🤮 😡
Ich bestelle auch die anderen ohne /RE DE Signal denn ich sicher bin, sie werden auf jedem Fall morgen geliefert.

[Manos1966]

Hi @skippermeister

First Test with the red RS485 Platine (die eine, die du mir empfohlen hast)

Ich habe zwei neue US5000 aus dem Karton raus geholt.
Ladestand 50% (erwartungsgemäß).

Beide Batterien angeschlossen mit dem kurzen CAN Kabel
Eingeschalten wie bei der Anleitung, beide sind korrekt hochgefahren und sind abgestimmt.

Ich glaube die OpenDTU zeigt die Daten von nur eine Batterie.
Wuerde ich sogar behaupten, war zu erwarten, wie soll die OpenDTU die RS485 Daten der zweiten Batterie empfangen, wenn nur das CANbus Kabel angeschlossen ist. Oder muss ich vielleicht noch etwas anschliessen? (ich glaube nicht, dass die + und - Anschlüsse einen Unterschied machen wurden)

Config Version 0.1.27
Firmware Version / Git Hash 7628217
PIO Environment my_very_special_board
Firmware Update Up to date!

[Manos1966]

Hallo @hhoebel

klingt Super! Danke fuer die Info!

• eine RS485 Parallelschaltung kann ich sofort zusammenbauen.
• wie hast du "unterschiedliche Adressen" definiert?

welche SW nutzts du um die RS485 auszulesen?

[hhoebel]

Die Adressen habe ich über die DIP-Switches des Akkus eingestellt - so wie man es auch für CAN machen muss (Adresse 1 für die erste Batterie, Adresse 2 für die zweite). Ich lese mittels eines separaten ESP32 mit ESPHome mit einer angepaßten Version von hier aus: https://github.com/syssi/esphome-pace-bms
ACHTUNG: diese Software ist für das PaceBMS-Modbus-Protokoll (ich habe mein BMS am RS485 darauf umgestellt - das wird bei Original-Pylontech-Akkus wohl nicht möglich sein). Pylontech kann die Software nicht - hier ist mir keine Software für ESPHome bekannt (nur Python-Skripte). Die Meldung in einigen Foren bzgl. Pylontech und gleichzeitiger Nutzung von CAN und RS485 können auch darin begründet sein, das bei Pylontech RS485 und CAN auf einer RJ45-Buchse zusammen liegen. Wenn man da einfach mittels Standard-Ethernet-Kabel mit dem Wechselrichter verbindet, liegt unter Umständen GND auf RS485-Pins - dann funktioniert RS485 natürlich nicht mehr. Insofern besser mit selbst gecrimpten Kabel testen.

[Manos1966]

Vielen Dank fuer die schnelle Antwort @hhoebel

Die Meldung in einigen Foren bzgl. Pylontech und gleichzeitiger Nutzung von CAN und RS485 können auch darin begründet sein, das bei Pylontech RS485 und CAN auf einer RJ45-Buchse zusammen liegen. Wenn man da einfach mittels Standard-Ethernet-Kabel mit dem Wechselrichter verbindet, liegt unter Umständen GND auf RS485-Pins - dann funktioniert RS485 natürlich nicht mehr. Insofern besser mit selbst gecrimpten Kabel testen.

Das ist Gold-Wert, danke! Ich werde es testen und berichten 🤞 Das waere eine (fast) Perfekte Loesung!
(ich benutze eigene Kabel bzw. RJ45 Dosen 😉 )

Ich werde aber leider nicht Schlau mit der Adressierung meiner Test-Batterien (zwei US5000 Pylontech).
Ich finde nichts diesbezueglich in der Anleitung :cry

[skippermeister]

Nach meiner Recherche sollte eine Kopplung über die Link Ports auch mit der RS485 Kommunikation funktionieren. dabei ist die Master Batterie über RS485 an die OpenDTU anzuschließen (meine Version unterstützt RS485 Pylontech). Die Slave Batterie werden per Daisy Chain per Link Kabel über die Link Ports verbunden. Laut Beschreibung von Pylontech sollen RS485 Adresse dann automatisch vergeben werden. Angefangen von Adresse 0 (Master Batterie), dann Slave 1 Adresse 1, Slave 2 Adresse 2 usw.
Die Adressschalter am ADD Switch sollen alle auf Adresse 0 stehen.
Angeblich soll man aber auch die Adressen über die Schalter gezielt vergeben können.

Aber jetzt kommt das eigentliche Problem. Meine Software Version unterstützt derzeit nur eine Adresse und zwar die Adresse 2, auf die die Pylontech Batterie im Standalone Modus (Nur eine Master Batterie) antwortet,. Die DIP-Switche stehen dabei auf Adresse 0, dennoch reagiert die Batterie auf Adresse 2.

Ich arbeite aktuell an einer Version die mehr als eine Pylontech Batterie unterstützt. Ich habe allerdings noch keine Idee wie ich die einzelnen Batterien zur Anzeige bringe. Und ich habe keine 2. Batterie um das ganze auch zu testen.

[Manos1966]

@skippermeister
Du kannst mir kompilierte Versionen zum testen schicken, ich helfe wo ich kann.
Ich kann auch selber kompilieren, habe ich aber wenig vertrauen an meine Faehigkeiten...

Darstellung
Ich wuerde es mir so vorstellen: Man muss selber die Anzahl Batterien die man hat, angeben.
Auf Basis dieser Zahl, wirst du die entsprechende Zahl "Batterie Fenster" aufmachen.

[hhoebel]

Das scheint laut Manual des US5000 gar nicht notwendig zu sein. Die Batterie, die mit dem Wechselrichter kommuniziert, wird wohl auf Master gesetzt und vergibt die Adressen an die anderen Batterien. Ich würde es einfach ausprobieren. Beim US2000 gab es das wohl auch schon, allerdings hatte der auch noch eine manuelle Möglichkeit - der US5000 wohl nicht.

[Manos1966]

🤞

[Manos1966]

@hhoebel Many Thanks again for your comments!
I was not planning to test it after reading the posts at the other forums....

IT WORKS! Both RS485 and CANbus (two separate OPENDTUS) at the same time! 🤩

Ich bin nicht sicher, dass es eine Moeglichkeit gibt, mit der CANbus Verbindung zu erkennen ob eine oder zwei Batterien angeschlossen sind. Ich finde es merkwuerdig, dass das Ladestromlimit--Entladestromlimit 160.0 A ist (anstatt 100A ).

@skippermeister

Meine Software Version unterstützt derzeit nur eine Adresse und zwar die Adresse 2, auf die die Pylontech Batterie im Standalone Modus (Nur eine Master Batterie) antwortet,

Ich habe zwei US5000 gekoppelt und deine SW funktioniert. Dann gehe ich davon aus, dass meine Master Pylontech weiterhin auf die Adresse 2 antwortet.

[hhoebel]

Am CAN werden die Daten gekoppelter Batterien miteinander kombiniert. Wenn z.B. der State of Charge bei einer Batterie 15% ist und bei der anderen 25%, dann übermittelt CAN 20%. Ebenso werden Charge/Discharge current limit addiert - bei mir verdoppeln die sich mit 2 Batterien. Die Anzahl der Batterien selbst werden aber meiner Kenntniss nach nicht übertragen, da für den Wechselrichter nicht notwendig. Über RS485 kann ich dagegen sogar die Parameter des BMS jedes einzelnen Akku verändern.

[Manos1966]

Hallo @skippermeister

nur ein Update bezueglich deiner Version die auch die "TTL zu RS485" Platine unterstutzen kann:
Funktioniert Einwandfrei! 👍 VIELEN DANK!

Anbei Bild mit "Heemol 5 Stück TTL zu R485 Level Converter" Platine (5 Stueck fuer 6,70EUR bei AMAZON 👍 )

[skippermeister]

Ich limitiere derzeit auf maximal 2 Batterien, Master und eine Slave. Das Limit kann in default.h auf 5 erhöht werden, kostet allerdings RAM und das initiale Json Objekt zum Setup des WebGUIs wird größer.

[Manos1966]

@skippermeister
👍 Wenn du die Test Version fertig hast, schick mir den Link.
Die zwei US5000 habe ich da stehen 😉
und jeweils eine Type A sowie Type B RS485-Version 😉 😉

[Manos1966]

Was wird passieren wenn man eine andere (Pylontech-compatibel) Batterie auf die RS485 Schnittestelle anschliesst? 🤔
(z.B. eine GOBEL)

[hhoebel]

Wenn das BMS der Batterie ein Pylontech-kompatibles Protokoll auf der RS485 spricht (so wie meine), wird es wohl so sein wie bei CAN auch: genauso (bis auf den Namen, der bei mir auf "DELONG" steht, statt auf "PYLON"). Ich würde ja auch testen, bin aber auf CAN unterwegs und habe die RS485 stattdessen an einem separaten ESP32. Wäre aber schon cool nur eine Schnittstelle mit einem ESP32 zu belegen.

[skippermeister]

@Manos1966
Erstes Test Release da4ba3c ist fertig. Kannst Du mal testen.
Die ADD Switche der Batterien sollten alle auf Default stehen, also 0000.
Die Batterien mit dem Link Kabel über die Link Ports koppeln.
An der ersten Batterie (Master) das RS485 Kabel mit der OpenDTU-onBattery (meine Version) verbinden.
Schick mir bitte ein Log File von der Bootphase der OpenDTU bis Du in Log mehrfach ".... [Pylontech RS485] request time x ms, Cmnd: xx mehrfach gesehen hast.
An der Bootphase kann ich dann erkennen, ob beide Batterien erkannt wurden. Hinweis, bei der Initialisierung des PylontechRS485reciever Modules steht dieses Module auf "verbose logging", somit bekomme ich hoffentlich alle Information.

[Manos1966]

Hmmm...
Also,
Console02.txt

• An der ersten Batterie (Master) das RS485 Kabel mit der OpenDTU-onBattery (deine Version) verbunden
• Beide US5000 angeschlossen und korrekt hoch gefahren (= man startet die Master-Batterie, die Slave wird automatisch eingeschaltet)
• Ich hatte Probleme die "ausfuehrliche Protokollierung" eingeschaltet zu speichern (merkwuerdig)
• Die RS485 Daten der MASTER Batterie werden angezeigt NICHT aber die Daten der SLAVE (siehe Bild)
  
  

Ich habe auch folgendes bemerkt: Beim ersten Mal konnte ich die Serial Nummer der Batterie erkennen.
Jetzt nach einem Reboot, sehe ich sie nicht mehr:

[Manos1966]

Sollte ich vielleicht in der Zwischenzeit testen was passiert wenn ich das Parallele RS485 Kabel benutze (beide US5000 mit RS485 angeschlossen)?

[skippermeister]

nicht über RS485 die Batterien untereinander verbinden.
Ich benötige das Log um zu verstehen, was die Initialisierung macht. Es sollte laut Pylontech Protokoll Beschreibung über die Link Leitung funktionieren.

[skippermeister]

Die DIP Schalter von beiden Batterien stehen auf 0000 ? Das ist wichtig, da die Batterien die Adressen untereinander gesteuert von der Master Batterie ausmachen.

[Manos1966]

Ja, beide Schalter sind auf 0000 (die US5000 erkennen Master/Slave automatisch)

Ich mache ein Notebook mit Putty fertig und bringe ich es in die Garage heute Abend.

[skippermeister]

dadurch dass "Single" vor "US5000" steht, wird nur eine Batterie erkannt. Es müsste ansonsten Master oder Slave-1 i der GUI zu finden sein. Es könnte en Timing Problem sein, aber mal schauen was das Log aussagt.

[Manos1966]

@skippermeister
once with Type1 and once with Type2 Platine.
I hoffe ich habe es richtig gemacht. Ich warte auf Anweisung... 🤞

[skippermeister]

Eine Korrektur aus den Logs:
der Befehl "get_firmware_info" antwortet doch richtig, hatte ich falsch gelesen.

[Pylontech RS485]::get_firmware_info REQUEST & GET Module 2
[Pylontech RS485]:send_cmd frame=~20024696E00202FD2A
[Pylontech RS485] ver: 20, adr: 02, cid1: 46, cid2: 00, infolength: 12 info:
02 01 03 00 06 09
[Pylontech RS485] CommandValue: 2, Manufacturer Version: '1.3'
[Pylontech RS485] Main Line Version: '0.6.9'

Und ich meine, dass der Type 2 nicht sauber funktioniert. Das erkenne ich im Log hier dran:

[Pylontech RS485] Battery not responding, check cabling or battery power switch
[Pylontech RS485] response time 1007 ms, Cmnd: 44
00 [Pylontech RS485] response time 0 ms, Cmnd: FF
00 [Pylontech RS485] response time 0 ms, Cmnd: FF
usw...

[Manos1966]

Und ich meine, dass der Type 2 nicht sauber funktioniert.

sie kosten 1/15 des Preises der Type1 Platine 😢

[Manos1966]

Schau mal hier https://github.com/ClassicDIY/PylonToMQTT/tree/main
Da gibt es eine Python Software die das wohl kann über RS485 mehrere Pylontechs im Master/Slave Betrieb abzufragen.

Diese Loesung ist RS232_Wiring, kein RS485

[skippermeister]

Bist Du Dir sicher? Ich habe mir den Code angesehen. Da ist das asynchrone Consolen Protokoll nicht implementiert, sondert das RS485 Protokoll. Er verwendet dazu anscheinend das TTL zu RS485 Modul (Type 2).
Wenn Du Deine TTL zu RS485 Platine (Type 2) an RX und TX vom ESP32 anschießt, sollte es funktionieren.

[Manos1966]

https://github.com/ClassicDIY/PylonToMQTT/blob/main/README.md

Ich lese hier nur 232

[Manos1966]

Ich habe ein Raspi mit RS485 + CANbus hier, vielleicht werde ich damit mehr Glück...

[Manos1966]

Uebrigens, hier ist die Erklaerung, warum die Pylontechs mit 2 anfangen.

[Manos1966]

Deine Master Batterie US5000 hat die Software Version 1.3. Meine US3000C hat die Software Version 1.8

Welches Baujahr ist deine US3000c ?

[Manos1966]

Jetzt habe ich auch die Plus- und Minus-Kabeln zwischen der Batterien angeschlossen.
Master

Slave

[Manos1966]

Die Unterschiede beim Reimaining Capacity sind richtig. Die Master lief einen halben Tag alleine.

[Manos1966]

ich sehe gerade "Temperature (BMS)" in der Status Anzeige ist falsch. der Wert muss durch die Anzahl der Batterien geteilt werden. Kommt im nächsten Release.

Hmmm... Schwierig!
Angehnomen, man hat vier Batterien angeschlossen. Eine Batterie hat Probleme und das BMS ueberhitzt.
Die Temperatur durch die Anzahl Batterien zu teilen wurde eine viel niedrigere Temperatur anzeigen als tatsaechlich der (Not)fall ist.

Persoenlich, wuerde ich lieber die hoechste Temperatur von allen BMS und Cells sehen wollen. Faehlt etwas auf, dann kann ich durch die einzelnen Batterien blaettern und die Situation erorten.

Ich suche jetzt meinen Notizen bezueglich A Lade Limits, es ist etwas komplizierter weil es verschiedene Arten von Verkablung zwischen der Batterien gibt.

[Manos1966]

Hmmm ich gucke die Konsole:

Nach dem Neustart, jede Menge
00 [Pylontech RS485] response time 1 ms, Cmnd: FF
00 [Pylontech RS485] response time 0 ms, Cmnd: FF

Ich warte jetzt, wie lang es dauert, bis die Situation sich verbessert hat....

[Manos1966]

circa 5 Minuten nach dem Neustart beruhigt sich die Situation und keine Fehler mehr...
Console Log gleich

[Manos1966]

was bedeuten die: 42, 44, 92?
circa 5 Minuten nach dem Neustart (ich habe das ausfuehrliche Log eingeschaltet) beruhigt sich die Situation und keine Fehler mehr...

03 Console Log.txt

[skippermeister]

42, 44, 92 sind die Befehlsnummern. 42 fragt z.B. alle analogen Werte ab. Die Befehls-Struktur findest Du unter "get analog values" in der Protokoll Beschreibung.

Ich hatte das Fehlerbild bei mir auch mal. Das Ergebnis war ein fehlerhafter SI3485 Chip auf dem RS485 Modul, der Lesefehler verursacht hatte. Ich hab den Baustein gegen einen MAX3485 getauscht, dann war wieder Ruhe. Bei mir läuft die RS485 Kommunikation jetzt seit über 6 Monaten stabil.

Wie sieht Dein Kabel aus ? Hast Du auf der Pylontech Seite eventuell ein RJ45 Kabel mit allen 8 Leitungen angesteckt und auf der Adapter Platine nur die beiden A/B Leitung. Somit könnten die Signalleitungen vom CAN Bus einstreuen. Ich habe ein Kabel mit selbst gebaut, welches nur auf der Pylontech Seite die beiden Leitung A/B an den RJ45 Stecker führen.
Und mein Kabel ist ca. 50cm. lang.

[Manos1966]

Anstatt wenig nutzliche Situationen raten zu versuchen, rate lieber das sechser im Lotto, dann hast du mehr davon 🤣
"Auf der Pylontech Seite ein RJ45 Kabel mit allen 8 Leitungen angesteckt und auf der Adapter Platine nur die beiden A/B Leitung."
Genau 🤣 und 2m lang
Das erklaert aber nicht warum, 5 Min spaeter, die Situation beruehigt sich 😉

[Manos1966]

In der Status Ansicht habe ich einige Werte der einzelnen Batterien summiert. Das ist für "Capacity", "Remaining Capacity", "Current" und "Power" sicherlich richtig. Aber für die "Recommended Charge limit", "... Discharge limit" und "Max. charge limit", "Max discharge limit" Werte nochmals zu überlegen. Die Kabel zwischen den Batterien sind für 100 oder 120 A ausgelegt.
Bei anderen Werten, wie z.B. minimale und maximale Zellspannungen bilde ich min und max Werte über die angeschlossenen Batterien.
Wie siehst Du das ?

Also...

ich sehe gerade "Temperature (BMS)" in der Status Anzeige ist falsch. der Wert muss durch die Anzahl der Batterien geteilt werden. Kommt im nächsten Release.

Hmmm... Schwierig!
Angehnomen, man hat vier Batterien angeschlossen. Eine Batterie hat Probleme und das BMS ueberhitzt.
Die Temperatur durch die Anzahl Batterien zu teilen wurde eine viel niedrigere Temperatur anzeigen als tatsaechlich der (Not)fall ist.
Persoenlich, wuerde ich lieber die hoechste Temperatur von allen BMS und Cells sehen wollen. Fehlt etwas auf, dann kann ich durch die einzelnen Batterien blättern und die Situation erörtern.

Daher wuerde ich:
MAX Temperature (BMS) 29.9 °C
MAX Temperature (Cells) 13.5 °C
SUMME Recommended charge current limit 160.0 A
SUMME Recommended discharge current limit -160.0 A
SUMME Max. charge current limit (15sec) 200.0 A
SUMME Max. discharge current limit (15sec) -200.0 A

Mit den Summen komme ich persoenlich nicht ganz klar, aber das ist wie Victron es sieht und berichtet. Die Einschraenkungen der Kabeln, werden spaeter manuell beruecksichtigt.
https://www.victronenergy.com/live/battery_compatibility:pylontech_phantom
siehe 4. GX Device Settings und 5. VEConfigure Settings und 9 FAQ
Auch ein wichtiger Satz unter 9. FAQ and Known Issues:
"The maximum charge and discharge current is limited to 25A, but the data sheet tells me the maximum is 100A.
The maximum current is limited to keep the battery healthy and reach the 10 year guarantee. In off-grid, the inverter can draw more than the 25A limit to run the loads, make sure you have sufficient batteries installed to keep the load per battery around this limit."
25A x 48V = 1200W @96% Effizienz = 1152W 😇

[Manos1966]

OK, ich gebe es zu, ich habe es etwas uebertrieben mit 4 OpenDTU Fenster gleichzeitig... 😇

01:39:19.095 > Calling /api/batterylivedata/status has temporarily run out of resources. Reason: "std::bad_alloc".
01:39:19.112 > Calling /api/batterylivedata/status has temporarily run out of resources. Reason: "std::bad_alloc".

Keine Daten mehr...

03 Console Log - Copy.txt

[skippermeister]

Ich habe nochmals alle Logs analysiert. Das fehlerhafte Verhalten

00 [Pylontech RS485] response time 1 ms, Cmnd: FF
... usw ...

erscheint nur mit dem Type 2 RS485 Adapter.

Warum das in der Initialisierungsphase nicht zu sehen ist, kann ich im Software Code erklären. Es tritt dort auch auf, allerdings liest die Software zunächst den seriellen Eingangspuffer solange, bis Hexadezimal 0x7E, das Startsymbol erkannt wird. Das wird in der Frame Parser Routine gemacht.

Später im periodischen Polling wird zwar auch der Eingangspuffer geleert, dies geschieht aber in der Polling "loop" und nicht im Frame Parser.

Warum der Unterschied? Der Frame Parser würde den Scheduler solange anhalten bis ein Zeichen kommt oder ein Timeout (1 Sekunde). In der Polling loop wird das ohne "Blocking" gemacht.

Ich werde in der Polling "loop" das versuchen zu ändern, hab schon eine Idee, aber das Verhalten des Type 2 Adapters ist eine Signalstörung und sollte auf jeden Fall vermieden werden.

Die Störung könnte davon kommen, das der verwendete Chip (MAX485), der kleine 8 polige Baustein und der 14 polige Chip für 5V ausgelegt sind. Die Chinesen haben die Beschriftung der beiden Bausteine abgeschliffen.
Jetzt kannst Du aber nicht einfach mit 5V den Adapter betreiben, dann würdest Du den RX-Pin des ESP32 zerstören. Du müsstest einen Pegelwandler dazwischen setzen.
Der Type 1 Adapter wird direkt mit 3.3V versorgt. Da ist ein SP3485 Baustein drauf und der ist für 3,3V ausgelegt.
Hinweis: MAX485 ist für 5V, MAX3485 und SP3485 ist für 3,3 Volt ausgelegt.

Bitte teste nochmals mit dem Type 1 Adapter und schicke mir ein Log File mit ca. 5 Minuten Laufzeit ab Bootphase.

[Manos1966]

Also, mit dieser Firmware funktioniert Type1 stabil - keine periodische falsche Daten und ich sehe kene FF Fehler mehr.
putty-Type1-RS485-20240306-2.log
Die SerienNummer konnte NICHT gelesen werden (ich habe nichts geloescht)/

Ich benutze das gleiche RJ45v Kabel wie beim Type2.
Falls "Kriegsentscheidend" kann ich ein "nacktes" RJ45 machen.

[Manos1966]

Doch Kriegsenscheidend!
Ich teste das "nackte" Kabel und poste gleich das Log....

[Manos1966]

Mit dem "nackten" RJ45 Kabel, scheint es viel besser zu laufen...
Die SerienNummer wurden gelesen und ich sehe keine Kabel-Fehler mehr im Log.
putty-Type1-Ncable-RS485-20240306-2.log
ich werde jetzt wieder die Type2 Platine mit diesem Kabel testen...
und es war doch das sch...RJ45 Kabel 🤦‍♂️
auch mit Type2 sehe ich keine FF Fehler mehr
putty-Type2-Ncable-RS485-20240306-2.log

[Manos1966]

Jetzt bin ich von einem 2m langes RJ45 Kabel, auf ein 50cm zwei-Pin Kabel umgestiegen.
Ich weiss nicht, ob die 2-Pins, oder die kurze Laenge die Loesung war.

[skippermeister]

mit dem Type 2 Adapter sehe keine Fehler mehr. Das log sieht so aus wie es sein soll.
Mit dem Type 1 Adapter gibt es in der Initialisierungsphase noch sporadische Timeouts. Unter anderem auch beim Abfragen der Seriennummer.
Scheint irgendetwas mit der Art zu tun zu haben, wie der RS485 Transmitter die beiden Leitungen A/B für das "Senden" aktiviert. Das kann ich nur noch mit einem Oszilloskop analysieren. Die Software macht jedenfalls keine Fehler mehr und das Kabel ist jetzt perfekt.
In den Logs kannst Du nach "Timeout" suchen. Es sollte bei Dir früh in der Initialisierung nur einmal auftauchen und zwar bei
get_pack_count REQUEST & GET Module 4 InfoCommand 04
Damit frage ich die Module einzeln ab, ob sie existieren. Ich fange von Module 2 (Master) an und gehe dann per Schleife bis ein Timeout kommt.
Du siehst dann die Meldung "[Pylontech RS485] Found 2 Battery Packs".
Falls da weniger steht, gab es in Deiner Konstellation schon ein Lesefehler.
Ich werte aber für die Anzahl der Batterien nur Deine Angabe aus der WebGUI aus.

Also mit Type 2 Adapter und dem kurzen Kabel scheint aktuell alles OK zu sein. Kannst Du bitte für ein paar Tage zyklisch beobachten und mir feedback geben.

Bzgl. der FF Lesefehler habe ich eine neue Testversion, welche die Störungen ausfiltert. Nach 100 erkannten Störungen erscheint dann immer eine Warnmeldung im log. Ich will es erst einmal selbst bei mir testen. Es ist noch nicht hochgeladen.

[Manos1966]

Also, ich schliesse Type2 an und lasse ich es laufen 👍

Danke fuer deine Geduld und Beharrlichkeit 🥇

[Solarteur]

Ist meine Zuordnung der Adapter so richtig?

"Type 1"-Adapter

"Type 2"-Adapter

[skippermeister]

@Solarteur : ja die Zuordnung ist richtig.

Hinweis: Ich habe selbst nur eine Batterie und ich verwende sehr erfolgreich und stabil den Type 1. Allerdings habe ich den SP3485 Chip gegen ein MAX3485 Chip umgelötet.

Mit Manos166 hatte ich in den letzten Tagen sehr intensive Tests durchgeführt. Und bei ihm hat sich gezeigt, dass in seiner Konstellation der Type 2 stabil ist. Type 1 hatte gerade in der Initialisierungsphase ein paar Kommunikationsprobleme, die ich mir nicht erklären kann.

So teuer sind die beiden Varianten nicht, kaufe einfach beide und probiere es bei Dir aus.

[sentinel1111]

Wird der Batteriezustand (SOH) über RS485 nicht ausgegeben?

[skippermeister]

@sentinel1111 : nein, der SOH Wert wird leider über RS485 nicht geliefert. da hatte ich mich damals auch gewundert. Aber ist im Protokoll von Pylontech nicht implementiert.

[skippermeister]

Ich lade gerade eine weiteres Release hoch. In einer Single Batterie Konfiguration wird SOC nicht angezeigt, das habe ich korrigiert. Gleichzeitig ist noch ein Software Filter eingebaut, welches Lesefehler am RS485 versucht zu eliminieren.

[Manos1966]

sollte ich lieber ein Test mit dem alten RJ45 Kabel machen?
(dann haben wir Fehler ohne Ende 😜 )

[Manos1966]

Max Cell Temperature in der Gesamtanzeige 👍

Kann es aber sein, dass du keine Max- sondern Durchschnitt-Temperatur der Sensoren bei der Master & Slave Anzeige berechnest?
Master:

Slave:

[Manos1966]

Ich bin sicher du willst das Ergebniss deiner Fail-Safe Routine sehen..
Anbei Log mit altem RJ45 Kabel
Ich habe die DTU nicht neu-gestartet, sondern nur Putty, du muss wahrscheinlich etwas tiefer suchen

putty-Type2-Badcable-RS485-20240307.log

[Manos1966]

Ich teste gerade CANbus + RS485 gleichzeitig
OpenDTU mit CANbus aktiv, danach die OpenDTU mit RS485 (2PIN Kabel) eingeschaltet.

ich hatte 60Sec Keine Aktualisierung der Daten als ich Putty gestartet habe
sowie 60Sek Keine Aktualisierung der Daten als ich Putty gestoppt habe.

putty-Type2-Ncable-CANbus+RS485-20240307.log

[Manos1966]

Die: Werte
Gewünschte Ladespannung (BMS) | 49,305 | V
Empfohlene Ladeschlussspannung | 53,250 | V
Max. Temperatur beim Laden | 60,0 | °C
Min. Temperatur beim Laden | -10,0 | °C

Muessen geprueft werden.

[Manos1966]

Guten Morgen @skippermeister
CANbus + RS485 OpenDTUs liefen die ganze Nacht, keine Probleme 👍 🥂

Eine Kleinigkeit:
97Ah ./. 200ah = 48,5% (Eine Batterie hat 49Ah und die andere 48Ah zur Zeit)

[Manos1966]

Aha! Das erklaert vieles 😄

Bezueglich

Berechnung der Zellentemperaturen: Ich berechne innerhalb einer Batterie die mittlere Zellentemperatur und in der Summe dann die maximale Temperatur dieser gemittelten Zellentemperaturen aller angeschlossenen Batterien.
Wenn Du in der Status Anzeige besser die maximale Temperatur über alle Batterien und Zellen sehen möchtest, kann ich das ändern.

Ich weiss, was ich selber sehen wollen wuerde, bin aber kein "Batterie-Papst" 😄
Wir sollten lieber die Frage im Forum stellen (mittlere vs hoechste Zellentemperatur)

Wenn du die SOC sowieso kalkulierst, dann wuerde ich mindestens eine nach Kommastelle lassen.

Das aber

Die maximal und minimal zulässigen Temperaturwerte zum Laden und Entladen lese ich aus der Batterie mit dem Befehl "get system paramter".

hat mir Sorgen gemacht!
Das ist laut Pylontech eindeutig nicht richtig! Um so schlimmer wenn meine US5000 das so denkt! 🤦‍♂️

[Manos1966]

nur zur Info, die Charge/Discharge curve der US5000
X Axe Temperatur C
Y Axe Amperes
Man koennte erwarten, mein BMS sollte das wissen....

[skippermeister]

Ich war wie gesagt auch sehr irritiert, dass die Batterie andere Werte liefert als im Handbuch stehen. Deshalb achtet mein Lade- und Entlade- Algorithmus darauf, dass nicht diese von Batterie gelieferten Werte als Grenzwert betrachtet werden, sondern falls meine manuell vergebenen Werte den Arbeitsbereich eingrenzen, jene herangezogen werden. Davon abhängig wird das Laden entsprechend abgebrochen bzw. der Wechselrichter ausgeschaltet.

Neues Release ist übrigens hochgeladen, sollte kurzfristig bereitstehen. Kleine kosmetische Änderungen, Max. Temperatur, SoC mit einer Dezimalstelle

[Manos1966]

Deshalb achtet mein Lade- und Entlade- Algorithmus darauf, dass nicht diese von Batterie gelieferten Werte als Grenzwert betrachtet werden, sondern falls meine manuell vergebenen Werte den Arbeitsbereich eingrenzen, jene herangezogen werden. Davon abhängig wird das Laden entsprechend abgebrochen bzw. der Wechselrichter ausgeschaltet.

Respekt! 👍

Ich bin draussen, ich werde die neue Version morgen testen. Brauchst du wieder Logs?

[Manos1966]

@skippermeister ich sehe, die naechste Version ist schon auf dem Weg... 😄

[Manos1966]

2024.03.09 Firmware
Einwandfrei (natuerlich) 😄
Moechtest du auch Log-Dateien?
Master:

Slave:

[skippermeister]

nein, ich benötige keine Log Dateien.

[Seili76]

Ich wollte mal vorsichtig nachfragen, ist es hierüber nun möglich einen Huawei CAN zusammen mit einem Hoymiles HMS/HMT zu betreiben, wenn ich meinen Akku über die RS485 anspreche?
Gibt es generell schon eine Lösung mit der DTU Akku, Huawei und HMS Hoymiles zusammen zu betreiben?

Gruß und Danke

[Manos1966]

Hallo @Seili76
das "Problem" liegt zwischen Huawei und HMS/HMT,
CAN oder RS485 hat keinen Einfluss.
Mehr hier: https://github.com/helgeerbe/OpenDTU-OnBattery/wiki/Device-Profiles#spi-bus

[Seili76]

Ah Ok. So ganz blicke ich das mit den Bussen nicht ...

Also weiterhin keine Chance Huawei und einen HMT parallel zu betreiben. Schade.

Danke für die Rückmeldung.

[AndreasBoehm]

@Seili76 das ist mittlerweile möglich. Aktuell noch in einer Test version, wäre super wenn du die testen könntest: #1144 (comment)

[Seili76]

@AndreasBoehm
das klingt gut! Ich habe derzeit nur einen HMS 2000 zum testen da und werde mir noch das CMT Modul organisieren.
Danke für die Info!

[Manos1966]

Ich habe ein "enhancement" addiert: Add RS485 Pylontech support #1052

Hallo @skippermeister wir hatten Mal darueber gesprochen, finde ich aber nicht wieder:
Koennte ich meine eigene OpenDTU-OnBattery Version zusammenstellen und den Code PylontechRS485Receiver.h von deiner Seite einfach addieren?
(ich kann mich wage erinnern, es war noch etwas mit der Darstellung, dass angepasst werden sollte?) 🤔

[skippermeister]

Hallo @Manos1966 , so einfach ist das nicht zu realisieren. Die Dateien PylontechRS485Receiver.cpp und die PylontechRS485.h werden benötigt. Diese sind jedoch mit den Modulen Battery, BatteryStats, Pin_Mapping, Configuration, WebApi_Battery, WebApi_config, WebApi_device, WebApi_ws_battery, und den WebViews BatteryView.vue und BatteryAdminView.vue verzahnt. Hier sind viele Anpassungen von mir gemacht worden.
Grundsätzlich ist das in die OpenDTU-OnBattery integrierbar, es ist aber ein größerer Aufwand.
Aktuell habe ich aus beruflichen Gründen keine Zeit dazu. Sorry

[AndreasBoehm]

Das werde ich demnächst angehen, will meine Pytes Batterie auch per RS485 anschließen und schauen ob da mehr Daten als über CAN Verfügbar sind.

[skippermeister]

Zur Info, es gibt ein neues Release von mir. Ich habe die für meine Version relevanten Updates von der originalen OpenDTU und OpenDTU-OnBattery Software übernommen. Bei mir läuft das neue Release aktuelle ohne Störungen. Und ich habe eine neue Parametrierung für die Sunset und Sunrise Funktion hinzugefügt (Einstellungen->NTP->Dämmerungstyp). Die Höhenwinkel der Sonnenstände lassen sich nun individuell für Auf- und Untergang eingeben.

[skippermeister]

@Manos1966 : nein, das Huwaei R4850G2 Modul ist nicht in meinem Fork enthalten. Es ist durch mein Meanwell Modul ersetzt.

[markusdd]

@sentinel1111 und @Matti07 , ich habe mehrere Versionen hochgeladen, unter anderem für das FusionIO V2 Board und andere S3 Boards.

Hinweise für das FusionIO V2 Board: Das PinMapping ist bereits in der Firmware codiert (siehe in platformio.ini). Sowohl NRF24 als auch das CMT Modul ist konfiguriert. Die Pins GPIO15 (RE_N RS485) und GPIO46 (DE RS485) müssen verbunden werden. Der RS485 Serial Treiber steuert nur den DE-Pin des RS485 Chips ISL3178E. Der RS485 Port der Pylontech Batterie wird mit die A/B Anschlüsse des FusionIO Boards verbunden. Am I2C-Bus wird ein SSD1306 OLED Display unterstützt. An GPIO43 (UART_TX) und GPIO44 (UART_RX) wird das erste Victron Device unterstützt. Die Version ist angepasst an das CAN/Iso Shield. An den beiden CAN/Iso Serial Ports können weitere Victron Geräte angeschlossen werden. Am CAN Bus kann ein Meanwell NPB-xxx-xx Netzteil angeschlossen werden. An GPIO39 (RX) und GPIO40 (TX) (JTAG Header TCK/TDO) wird entweder ein SDM oder SML Powermeter unterstützt (SoftwareSerial) An GPIO41 und GPIO42 (JTAG Header TDI/TMS) können MosFETS (über Optokoppler) angeschlossen werden, um die Batterie vom Wechselrichter zu trennen und mit Softstartfunktion anzuschalten. Die beiden LEDs sind konfiguriert.

Bitte mal testen, ich habe selbst kein FusionIO Board

Ich rate dringend davon ab die Pins in die Firmware einzupacken, das geht beim nächsten Update nämlich kaputt.

[skippermeister]

Warum sollte beim Update das PIN Mapping kaputt gehen? Das codierte Pin Mapping sind die default Werte. Wenn Du ein PIN Mapping als JSON File definierst überschreibt es das hart codierte Pin Mapping.
Ich habe bei meinen vielen Tests noch nie das PIN Mapping verloren.
Falls Du also ein JSON File besser und/oder sicherer findest, kannst Du jederzeit eines definieren. Und wer ein anderes verdrahtetes Board nutzt muss eh ein eigenes JSON File definieren. Da ich in meinem Fork erheblich mehr Konfigurationsmöglichkeiten habe, findet der/die jenige Anwender entsprechende Beispiele in meinem my_very_special_board Json File.

[sentinel1111]

@skippermeister Ich teste gerade deine Version und habe noch Probleme.Ich habe dir ein paar Fragen gestellt in deinen Fork.
Vielleicht kannst du drüberschauen bei Gelegenheit.

[markusdd]

Warum sollte beim Update das PIN Mapping kaputt gehen? Das codierte Pin Mapping sind die default Werte. Wenn Du ein PIN Mapping als JSON File definierst überschreibt es das hart codierte Pin Mapping. Ich habe bei meinen vielen Tests noch nie das PIN Mapping verloren. Falls Du also ein JSON File besser und/oder sicherer findest, kannst Du jederzeit eines definieren. Und wer ein anderes verdrahtetes Board nutzt muss eh ein eigenes JSON File definieren. Da ich in meinem Fork erheblich mehr Konfigurationsmöglichkeiten habe, findet der/die jenige Anwender entsprechende Beispiele in meinem my_very_special_board Json File.

du machst dir damit die möglichkeit einfach zunichte mit offiziellen images über die web-ui updaten zu können, du musst dann halt immer explizit für diese config neu bauen. Wenn das ok macht das nix, aber am ende würde ich es dennoch nicht empfehlen weil es auch debugging erschwert, sind am ende andere codepfade.
Wir haben diese erfahrung mit mittlerweile tausenden verkauften Fusion boards auch durch und wir sind von hardcoded pinmapping komplett weg, es macht nur ärger.