onBattery Pro PCB

[swingstate]

Mit den Learnings aus der "Plus" Version (Plus weil Ve.Direct + CAN) habe ich mich daran gesetzt und die "Pro" Version genauer definiert.

Mit den zur Verfügung stehenden GPIOs und dem, was die meisten Nutzer meiner Meinung nach als sinnvoll finden würden lande ich bei dieser Board Config:

• ESP32-S3 16MB
• NRF24+
• CMT2300A (Mit SMA Anschluss, somit können Folienantennen als auch externe Antennen gewählt werden)
• 3x Ve.Direct Ports (z.B. 1x Shunt + 2 MPPTs; falls zwei MPPTs durch die Software unterstützt werden)
• 1x Pylontech CAN Bus
• Support für I2C OLEDs, Beispielsweise die 0.96" Displays

Das sähe dann ungefähr so aus:

Wenn ich eine erste Zertifizierung anstreben sollte, dann mit diesem Modell da es universeller ist. Das Plus Modell und/oder eine Basic Version können später folgen - Alles eine Frage der Kosten.

Werde das PCB erst einmal fertig stellen und parallel mit dem TÜV sprechen wie man eine Zertifizierung möglichst kostengünstig angeht, zumal die verbauten Funkmodule eine CE-EMC Zertifizierung haben. Letzteres hat aber wohl nur bedingt Wert, wenn man diese Module in ein neues Produkt einbaut.

Für Huawei und andere AC Charger ist kein weiteres SPI Interface vorhanden. Man kann das wohl mit SPI IO Expandern angehen, aber da warte lieber ob sowas (IO Expander) in der Software supported werden wird.

[alexseuf]

Anstelle des aktuell von der Software nicht unterstützen 2. Ve Bus stecker fände ich ein JK BMS Interface sinnvoller.

[alexseuf]

Die Huawei AC Lader Schnittstelle könnte man ja als Steckkarte auf der Erweiterungsstiftleiste später nachschieben. Sind auf der Rückseite Bohrungen im Gehäuse vorgesehen damit man dort das zuvor besprochene hutschienenhalter Rastmodul von Reichelt anschrauben kann?

[schlimmchen]

Anstelle des aktuell von der Software nicht unterstützen 2. Ve Bus stecker fände ich ein JK BMS Interface sinnvoller.

Ich bin hier eigentlich nicht involviert, aber ich kann dir sagen, dass das möglich wäre. Die VE.Direkt-Schnittstelle ist seriell, und auch das JK BMS spricht seriell.

Eine wirkliche Verbesserung wäre es, wenn es einen RS485 Port gäbe, wie auf dem OpenDTU Fusion v2 Board.

[alexseuf]

Ve direkt ist aber 5 v seriell und JK BMS ist 3,3v seriell? Oder bringe ich da was durcheinander.. wobei es für JK BMS auch rs485 Adapter gibt so das ein rs485 Port auch hier Vorteile bringen würde.

[schlimmchen]

Naja, auf das Spannungsniveau des ESP32 musst du es eh bringen. Ob das hier integriert ist, weiß ich nicht. Würde ich aber erwarten. Ich vermisse das auf dem OpenDTU Fusion Board, also einen ADUM1201 (pro serieller Schnittstelle). In meinem Setup ist der "extern".

[swingstate]

Ich bin hier eigentlich nicht involviert

Mach doch mit?!
Am Ende müssen Soft- und Hardware ja zusammen laufen.

Das JK BMS & Ve.Direct über die gleiche 3-PIN Schaltung laufen können hatte ich auch so verstanden. Als problematisch sehe da nur die Batteriespannung, sofern der Anwender diese anschliesst.
Daher würde ich diesen Ansatz, JK oder Ve.Direct über den selben Port laufen zu lassen, nicht wählen. Ich lasse mich da aber gerne eines Besseren belehren.

Ich hatte mir den ISL3178E schon näher angeschaut, bin da aber noch unentschlossen. Was wäre denn der Anwendungsfall? Sichere Anbindung des JK BMS? Könnten wir damit dann auch die Huawei AC Charger Anwender bedienen? Das wiederum würde einen Konflikt bringen, wenn man ein JK BMS und einen AC Charger nutzen möchte. Daher ist es wohl sinnvoller beides getrennt zu belassen?

Hierzu mal eine generelle Frage - Könnte der onBattery Code so erweitert werden, dass über eines der SPI Interfaces ein Master/Slave Setup laufen kann? So dass man dann nur jeweils einen CS (Chipselect) PIN pro CAN Interface definieren muss.

Beispielsweise so:

Da könnte dann ein MCP2515/TJA1050 für die AC Charger herhalten, ein weiterer Transceiver für das JKBMS und der Dritte im Bunde wären entweder CMT oder NRF?

Alternativ dazu ließe sich das SPI Interface mit einem MCP27S13 erweitern. Das müsste aber auch in der Software unterstützt werden.

Bzgl. Hutschiene, wenn es dieses Projekt über die Ziellinie schafft wird es auch einen Hutschienenadapter geben. Modularisierung fände ich auch cool. Das wird dann nur noch aufwendiger.

auf das Spannungsniveau des ESP32 musst du es eh bringen.

Alle 4-PIN JST Ports haben einen ADUM1201 dahinter.

[swingstate]

Den Aufwand in der Software kann ich nicht abschätzen. Könnte vergleichweise einfach sein, könnte super lästig werden.

Hättet Du Interesse und Kapazität Dir das näher anzuschauen?

Der Transmitter und der Receiver müssen dann dauerhaft eingeschaltet bleiben, weil für RXEN und TXEN kein GPIO mehr zur Verfügung steht?

Im aktuellen Entwurf habe ich einen MAX485 Transceiver, dessen 4 PINs RO, REN, DI, DE alle an den ESP angebunden sind. A, B und GND gehen zum grünen Schraubklemmenanschluss. Passt das soweit?

Ich würde einen Multiplexer einbauen. ... Wird das klar aus einer textuellen Beschreibung, was gemeint ist?

Denke schon. Das könnte wohl auch einfach über DIP Schalter von außen zugänglich realisiert werden, so dass man den Kasten nicht immer aufschrauben muss. Ob bzw. wie es mit nur einem Umschalter gehe recherchiere ich mal.

So lässt sich TX aktivieren/deaktivieren ... Wie denn?

Die 3 Jumper PINs an jedem JST dienen als einfache Brücke und sitzen hinter dem jeweiligen Adum. PIN 1 = unbelegt, zum parken des Jumpers. PIN 2 an VIB des ADUM, PIN 3 am JST PIN 3. Über PIN 2 kann man dann den GPIO einfach abgreifen. PIN 2 und 3 verbunden ergeben die TX Verbindung.
Ist vielleicht auch eine Designfrage, ob man es so macht dass die Zuordnung der PINs über ihren Platz auf dem PCB klarer erkennbar ist oder ob man alles auf 1 - 2 Stiftleisten packt. Letzteres wirkt wohl aufgeräumter und könnte in der Fertigung etwas günstiger werden.

Was ist der grüne Header ganz links?

3 PIN steckbarer Schraubklemmenanschluss. Philosophie dahinter ist, damit muss nicht an der DTU geschraubt werden sondern davor (Kabelenden in den Schraubklemmenstecker).

Wie bekommt das Ding Strom? Nur über die USB-Buchse? Kein Schraubterminal?

Don't call it Ding. 😬 Aktuell über einen AMS1117-3.3 via USB-C, ausgelegt auf 1A.

Der ESP hängt direkt am USB und kann darüber programmiert werden?

Ja.

[swingstate]

@schlimmchen konntest Du Dir schon Gedanken zu den o.g. Punkten machen?

[stefan123t]

Hierzu mal eine generelle Frage - Könnte der onBattery Code so erweitert werden, dass über eines der SPI Interfaces ein Master/Slave Setup laufen kann? So dass man dann nur jeweils einen CS (Chipselect) PIN pro CAN Interface definieren muss.

Each bus has three CS lines to drive up to three SPI slaves.

Den Aufwand in der Software kann ich nicht abschätzen. Könnte vergleichweise einfach sein, könnte super lästig werden.

Hättet Du Interesse und Kapazität Dir das näher anzuschauen?

Das wird bereits mit dem von LennartF22 implementierten HAL (Hardware Abstraction Layer) für das OpenDTU Fusion v2 Board verfolgt. Dort besteht die selbe Herausforderung beim parallelen Betrieb von NRF24L01+, CMT2300A RF Chips, OLED / ePaper Display und W5500 LAN Adapter über einen gemeinsamen oder gesonderte SPIs.

Das Problem ist aktuell hauptsächlich in der RF24 Bibliothek, da sich diese im Konstruktor nicht einfach auf einen anderen SPI umkonfigurieren läßt:
Siehe u.a. hier tbnobody#1200 und upstream in der RF24 Bibliothek nRF24/RF24#925

[swingstate]

Ich verstehe es so, dass RF24 die Änderungen nicht übernehmen will und einen eigenen Fork vorschlägt. Tbnobody scheint sich auch noch nicht dazu geäußert zu haben, ob der HAL in den OpenDTU code einfliessen kann. Vielleicht sehe ich es falsch, aber klingt für mich wie ein wenig auf der Stelle treten.

[stefan123t]

Nein RF24 würde die Änderungen gerne als custom utility driver übernehmen. Dazu müssten wir die Anpassungen von @LennartF22 in eine passende Form bringen.

nRF24/RF24#925 (comment)

With implementation aside, the HAL concept proposed is not likely to be merged because we already have a bunch of #ifdef soup to satisfy our current HALs. Instead, I would suggest you use our current HAL approach and write a OpenDTU_fusion driver in RF24/utility and just implement the needed changes (see our portability docs). Using our current HAL approach would be more acceptable for merging here.

Darunter hatten wir bereits sinniert wie das zu implementieren wäre. Es hat nur noch niemand sich die Zeit genommen das zu anzugehen.

[alexseuf]

Wenn du dir die Kosten für die dreipolige grüne steckleiste für die rs485 sparen möchtest, könntest du auch dass RS485 Signal auf den RJ45 Stecker mit drauflegen, so wie es viele chinesische Hybrid Wechselrichter / Batterie Hersteller machen.
Z. B. Deye

[swingstate]

Die Idee finde ich sehr gut. Wenn ich als Anwender dann mit meinem JK BMS oder was auch immer daher kommen und 3 lose Kabelenden in der Hand habe, dann muss ich die entweder in einen RJ45 crimpen oder mir einem RJ45 Adapter mit Schraubenschlüssen kaufen. Oder gibts da andere Wege?

[alexseuf]

Du kannst auch ein patchkabel abschneiden und an die kurzen Kabel vom jkbms rs485 Adapter anlöten und mit schrumpfschlauch isolieren.. die käbelchen vom JK BMS RS485 Adapter sind eh so dünn und kurz dass es mit normalen Schraubklemmen auch nicht optimal ist. Und man meist das Kabel auch verlängern muss

Es gibt aber auch RJ45 Adapter mit Kabel und Schraubklemmen

[swingstate]

Der RJ45 M scheint ein guter Kompromiss. Gute Idee!

[alexseuf]

Alle unbenutzten Pins auf eine stiftleiste zusammen mit GND und VCC zu legen, ist keine Option mehr um daran z.b eine Erweiterungskarten für Huawei anzuschließen? Selbst wenn du es nicht nutzt könnt es jemand anders ist noch nutzen..

[swingstate]

Wenn GPIOs übrig bleiben mache ich das.

[swingstate]

Kurzes Update zum Layout -

• RJ45 ist nun ein hybrid Port (RS485 & zweiter CAN Busfür AC Charger). Dadurch schrumpft das PCB wieder etwas.
• Die 3x JST sind weiterhin RX/TX fähig
• Serial (RX/TX) & OLED weiterhin via Pin Header verfügbar.

[Manos1966]

@cobexo Paket ist unterwegs.

[drahdiwaberl]

• RJ45 ist nun ein hybrid Port (RS485 & zweiter CAN Busfür AC Charger). Dadurch schrumpft das PCB wieder etwas.

aber - CAN über SN65HVD230DR, oder?

sprich das Huawei R4850G2 als AC Charger kann mit openDTUonBattery nicht funktionieren weil das MCP2515/TJA1050 über SPI erwartet. oder gibts dazu irgendwo "Entwicklungen"?

danke.

[schlimmchen]

Korrekt. Du hast ja selbst in #999 darum gebeten, dass das möglich wird. Ist es bisher nicht.

[drahdiwaberl]

right. nachdem solche Projekte aber oft noch in irgendwelchen discords und sonstigen kanälen versteckte "branches" haben bin ich mir nie sicher ob es nicht doch schon wo eine Lösung gibt die nicht so bekannt sind.. wie auch dieses pcb hier.. ;)

(mein huawei macht jetzt mal überschussladen in esphome - schön wärs natürlich irgendwann mal alles in einem "system")

[schlimmchen]

nachdem solche Projekte aber oft noch in irgendwelchen discords und sonstigen kanälen versteckte "branches" haben

Guter Punkt. Mir ist aber nichts bekannt.

[cerise21]

RJ45 ist nun ein hybrid Port (RS485 & zweiter CAN Busfür AC Charger)

würde aber bedeuten, dass der RS485 nicht zusätzlich zum Anschluss eines Powermeters verwendet werden kann, wenn das AC-Netzteil aktiviert ist? (Oder habe ich das nicht richtig verstanden?)

[alexseuf]

Hardwaretechnisch spricht bei der doppelbelegung des Steckers nichts gegen eine parallele Nutzung von rs485 und can. Man braucht nur einen rj45 Y-Adapter. Ob das Software technisch auch möglich ist oder durch doppelnutzung von esp32Pins bei der Platine möglich ist weiß ich nicht.
Bei der Auswahl der RJ45 y Adapter darauf achten dass alle Pins eins zu eins durch verbunden sind. Bei vielen Adaptern sind nur vier Pins auf Ausgang 1 und die anderen vier Pins auf Ausgang 2 verbunden.
Hier ein Beispiel von einem dreifach Y-Adapter der bei mir gut am Deye funktioniert. https://amzn.eu/d/1tlCwZI

Beim chinesischen Händler findet ihr aber auch noch günstigere..
Oder baut euch so eine Adapter mit Hilfe z.b von einem Schraubklemmen Übergang einfach selber.

https://a.aliexpress.com/_EHafTtP

[swingstate]

Genau, der Schraubklemmenadapter ermöglicht dann die gleichzeitige Nutzung, sofern die Software da mit macht.

Als Beispiel - 1/2 sind RS485, 4/5 ist CAN

[Sorbat]

Könnte man sich nicht vielleicht auch ein passendes Kabel crimpen? Also ein Y-Kabel? Die Stecker kosten ja nix

[swingstate]

Der Schraubklemmenadapter ist ja im Prinzip ein Y Adapter.

[cerise21]

Hardwaretechnisch spricht bei der doppelbelegung des Steckers nichts gegen eine parallele Nutzung

Ok, danke, ja, die RS485-Signale aus dem Stecker rauszudröseln, bekomme ich hin.

Was ich meinte, bezog sich eher auf diese Aussage:

Ich würde einen Multiplexer einbauen. Der würde dann mit einem Jumper eingestellt werden und würde die Pins für die Pylontech-Batterie und die Pins für den RS485 Transceiver multiplexen. Dann kann man immer nur entweder eine Pylontech-Batterie oder den RS485 Bus nutzen, was in der Praxis vermutlich eh immer der Fall ist. Man legt dann aber nicht zwei oder vier Pins dauerhaft lahm, sondern diese zwei oder vier Pins machen entweder das eine, oder das andere. Wird das klar aus einer textuellen Beschreibung, was gemeint ist?

Man entscheidet sich dann per Jumper entweder für das Netzteil per CAN, oder alternativ für die RS485-Schnittstelle?

[swingstate]

Momentan habe ich beides, RS485 und CAN, angebunden.
Muss jedoch noch getestet werden.

[Manos1966]

Ich bin weiterhin enttäuscht, dass diese Platine keinen Kaffee kochen kann..... 🤣

@swingstate übrigens, gerade aus Hamburg geliefert

[mastertape]

öVerfolge das hier mit Hochspannung! Super Idee - ich überlege die ganze Zeit ob nicht eine dieser Schnittstelle multifunktional nutzbar wäre. Vielleicht wäre es ja möglich z.b. Einen Smartmeter IR Lesekopf wie es derzeit in verbindung mit Tasmota genutzt wird noch übers Board ans laufen zu bekommen, So das keine weitere ESP dafür gebraucht wird direkt intern abgegriffen. Es ist mit die wichtigste Verbindung wenn man Richtung Nulleinspeisung gehen will und eine Fehlerquelle weniger - die ganze Kiste könnte somit dann Autark arbeiten.

[swingstate]

Shelly 3em und gut ist. Meine Meinung :)

[Manos1966]

Naja, Hichi oder Systeme die die Daten des Digitalen Stromzaehlers direkt lesen sind meine Praeferenz.
Nur da wo kein Digitaler Stromzaehler existiert, nutze ich Shelly 3em
Grund sind die Kosten (Shelly 3em kostet fast 80EUR mehr).

Ich persönlich hatte enorme Probleme mit Shelly 3em gehabt. Die Unterschiede liegen an cosinf Behandlung.
Hier ist ein Bild vom Stromzaehler der benutzt wird fuer die Test-Installation.
Oben die Shelly 3em, unten Hichi IR
Da sind ein paar Unterschiede zu erkennen... Ich habe die drei Sensoren der Shelly mehrmals umpositioniert (es ist der Grund warum Falsche Werte übermittelt werden), irgendwann habe ich aufgegeben und habe einen digitalen Stromzaehler + Hichi addiert.

[alexseuf]

Hallo manos, habe bei mir das selbe Setup aber so große Unterschiede noch nie gesehen. Kann es sein dass bei deinem Shelly 3 em die Zuordnung von Strom und spannungsmessung nicht passt?.
Aber zurück zum Thema. Die Möglichkeit einen Stromzähler direkt mit dem Energiespeichersystem zu verbinden, hat meiner Meinung nach schon auf die Dauer gesehen,
Stabilitätsvorteile. Nicht umsonst machen das fast alle Hybrid Wechselrichter Hersteller genauso. Klar ich muss dafür ein extra Kabel ziehen, aber wenn irgendwelche sporadischen Störungen auftreten, weiß ich genau wo ich das Problem suchen muss.

[mastertape]

Ich hätte den Platz am Stromzähler ist bei uns im 1. OG drüber ist direkt sie Solaranlage auf dem Dachboden...

Der große Vorteil wäre das in meinen Fall dann die 4 Hoymiles samt akku und Stromzähler über ein Gerät läuft - Autark!

Jedes gerät zusätlich ist eine potentielle Fehlerquelle und wenns wifi oder netzwerk mal rumzickt... geht die nulleinspeisung nich mehr zuverlässig.... Daher wäre das schon interessant.

[stegbth]

Hi @Manos1966 ,
diese Problem hatte ich mit meinem Shelly3EM pro auch.
Ursache bei mir war, wie alex schrieb, dass die Messschellen nicht mit den drei Spannungseingängen oben übereinstimmte.
Nachdem das korrigiert war, passen die Werte.

vg
Thomas

[ottelo9]

@swingstate
Super Arbeit, Hut ab !! Bekommt man die PCB Gerber Dateien + Stückliste (Non Pro Variante) von dir, falls man sich das Board mal selbst bauen will oder willst du es nur zum Verkauf anbieten? Wollte mir jetzt nämlich schonmal alles zusammen sammeln und im Frühjahr umsetzen.

[kloppy1984]

@ottelo9 ich kann dir gern mal meine Platinen Layout schicken / oder dir eine Platine mit ätzen beim nächsten mal...
schreib mich gern über Kleinanzeigen an...

[ottelo9]

@kloppy1984
Danke :) habe nun aber vorhin 2 Platinen von LukasVFL99 über Kleinanzeigen bestellt.

[Tiese]

Hallo @ottelo9,

ich habe dafür ein passendes Gehäuse entworfen, sogar mit Halter für ein Display!

[ottelo9]

Ok das nice :) wo finde ich die 3D Datei und welches Display muss ich nehmen? Lukas hat ebenfalls ein Gehäuse erstellt: https://cults3d.com/en/3d-model/home/opendtu-onbattery-lukas_prints3d

[Tiese]

In mein Gehäuse passt ein 1,3 Zoll Display.
Dateien findest du hier: printables.com.

[quantenquark]

Ahoi zusammen, das ist ein super Projekt!
Ich habe 2x Pytes eBox 48100c, welche ähnlich zu den Pylontech Akkus sind.
Bisher ist ggf. nur die Kabelbelegung für den CAN-Port anders, mein Victron-Händler belegt die Stecker für die eBox extra anders.
Sollte aber dennoch funktionieren.

SMDs löten ist nicht meine Stärke....
Ich wäre daher ebenfalls an einer bestückten Platine interessiert.

Wäre das möglich?

Gruß
Achim

[JayBesDev]

Wow, cool! Das macht mir Hoffnung -
Morgen kommt meine Pytes E-Box 4850-C Batterie :)
Ich nutze ein Fusion-Board und hoffe, dass ich einfach nur CAN anschließen muss und Pylontech Profil auswählen.
Oder @quantenquark wie hast du das angeschlossen und konfiguriert?
Danke und Grüße!

[quantenquark]

Ahoi. Ich habe nur den CAN-Bus an die Pins verbunden und in der Konfig manuell aktiviert.

Hoffe bei deinem Batterietyp wird das CAN-Protokoll vollständig ausgelesen. Bei mir bleiben die Lade/Entladeparameter unberücksichtigt, da wird wohl eine Anpassung im Programm nötig.

[JayBesDev]

Hi @quantenquark , ich habe meine Box mittlerweile in Betrieb und sie wird soweit ausgelesen. Tatsächlich werden einige Parameter nicht ausgelesen, da diese unter einer anderen ID verfügbar sind. Ich habe mal einen Sniffer drangehängt:

@schlimmchen wäre es denkbar eine Unterstützung für Pytes Batterien zu implementieren, da diese wohl doch immer verbreiteter sind...? Das wäre richtig klasse! ;)

[AndreasBoehm]

@quantenquark und @JayBesDev schaut gerne mal in meinem PR vorbei der Pytes CAN support bringt: #1088
Dort findet ihr builds um es direkt auf eurer DTU testen zu können.

[AndreasBoehm]

@JayBesDev Danke für den mitschnitt der CAN Messages, habe deine Daten gerade simuliert und es scheint alles zu funktionieren.

[swingstate]

Werde demnächst 5 Test PCBs bekommen. 2 - 4 gebe ich gerne zum Selbstkostenpreis (welcher noch nicht feststeht) ab.

Specs bis dato:

ESP32 S3 16MB Flash
3x 4Pin JST Ports für Ve.Direct
Hybrid RJ45 mit CAN und RS485
USB-C zum Flashen & Stromversorgung
Schraubklemme als alternative Stromquelle
NRF/CMT Antennenmodule
OLED Header

Wenns soweit ist poste ich weitere Details.

[swingstate]

Nein, bisher nicht bzw. aktuell nicht mehr.

[quantenquark]

Naja, das Pro-PCB tut es in jedem Fall umfangreicher. Bei mir kommt ggf. noch eine separate Batterie und damit auch ein Shunt dazu ;-)
Ich nehme dein Angebot gerne an.

[Snoopy-HSS]

Ich nehme gerne eine Platine zum Testen

[stanpete78]

Wenn noch eine übrig ist, würde ich sehr gerne eine zum Testen bestellen.

[Ralph161065]

Ich würde auch gerne, wenn noch mnöglich, eine Platine nehmen.

[swingstate]

@schlimmchen Du nutzt doch das JK BMS, oder? Könntest Du das PCB dahingehend testen? Genauer gesagt die RS485 Verbindung via RJ45. Das PCB würde ich Dir dann kostenfrei zur Verfügung stellen.

[schlimmchen]

Das kann ich gerne machen! Melde dich bei schlimmchen ät posteo punkt de zwecks Adresse. Danke, dass du dich für mein Feedback interessierst!

[gitisgreat2023]

@schlimmchen
Ich steige von einem Pylontech um auf einem JK BMS.
Kannst du bitte verraten was genau man da einstellen muss um den RS485 Verbindungen via den RJ45 zu nutzen?
Was muss in den pinmapping anders?
zB habe ich jetzt für den Pylontech
rx 18
rxen -1
tx 7
txen -1
(was ist der Unterschied zwischen r/tx und r/ten eigentlich)?

Zweite Frage: kann JK BMS gleichzeitig den RS485 und CAN bedienen? Oder kann nur einer gleichzeitig aktiv sein?
Dritte Frage: Pylontech hat einen soft-start. Hat der JK Inverter BMS das auch? Ich habe irgendwo gelesen dass mittels "discharge enable/disable" man effektiv das gleich erreicht. Sprich: discharge disabled, inverters und charger an AC anschliesssen und an DC natürlich und dann in der app discharge enable. Kannst du das bestätigen?

[swingstate]

Das Mapping für ein RS 485 / Jk BMS sieht für das Pro PCB so aus:

  "rx": 16,
  "rxen": 15,
  "tx": 45,
  "txen": 46

Du musst das eine Ende des LAN Kabels an den RS485 anschliessen, wobei die Adern 1 (Yellow) & 2 (Weiss-Gelb) für das Auslesen der Daten genutzt werden, Die Ader #6 ist auf GND verbunden (nach TIA 568B). Das andere Ende des Lan Kabels dann einfach in den RJ45 auf dem Board stecken und dann das entsprechende Mapping in der Konfiguration der DTU wählen.

Ob das JK gleichzeitig CAN und RS485 kann weiss ich nicht; das hängt mindestens von der Version des BMS ab. Meins hat beide Schnittstellen, ich nutze aber aktuell nur RS485.

Zu discharge enable/disable kann ich nicht mehr sagen, außer dass man damit das BMS eben gut schalten kann.

[swingstate]

Das PIN Mapping sieht soweit so aus - schaut gerne einmal kritisch drüber.

ESP PIN (GPIO)	IC PIN / Function
1	GND
2	3.3V
3	EN
4 (GPIO 4)	CMT CS
5 (GPIO 5)	CMT SDIO
6 (GPIO 6)	CMT CLK
7 (GPIO 7)	Pylontech CAN TX
8 (GPIO 15)	RS485 RE#
9 (GPIO 16)	RS485 RO
10 (GPIO 17)	Ve.Direct / MPPT 2 TX
11 (GPIO 18)	Pylontech CAN RX
12 (GPIO 8)	OLED SCL
13 (GPIO 19)	Not connected
14 (GPIO 20)	Not connected
15 (GPIO 3)	Not connected
16 (GPIO 46)	RS485 DE
17 (GPIO 9)	OLED SDA
18 (GPIO 10)	Ve.Direct / MPPT 2 RX
19 (GPIO 11)	Ve.Direct / MPPT 1 TX
20 (GPIO 12)	Ve.Direct / MPPT 1 RX
21 (GPIO 13)	Ve.Direct / Shunt TX
22 (GPIO 14)	Ve.Direct / Shunt RX
23 (GPIO 21)	CMT FCS
24 (GPIO 47)	NRF IRQ
25 (GPIO 48)	NRF MISO
26 (GPIO 45)	RS485 DI
27 (GPIO 0)	BOOT Switch
28 (GPIO 35)	NRF MOSI
29 (GPIO 36)	NRF SCK
30 (GPIO 37)	NRF CS
31 (GPIO 38)	NRF CE
32 (GPIO 39)	PIN Header - free to use
33 (GPIO 40)	PIN Header - free to use
34 (GPIO 41)	PIN Header - free to use
35 (GPIO 42)	PIN Header - free to use
36 (RXD 0)	Serial RX
37 (TXD 0)	Serial TX
38 (GPIO 2)	Network Status LED
39 (GPIO 1)	Inverter Status LED
40	GND
41	GND

Board Layout so far:

Ich werde davon vorerst 5 ordern, da ich dieses Layout noch nicht getestet habe und sich einiges geändert hat. Wenn die Funktionen gegeben sind und es keine Fehler gibt wird diese Version für die CE Zertifizierung verwendet.

[Snoopy-HSS]

RJ45 Stecker mit LED wäre sicher nicht unpraktisch...

[Snoopy-HSS]

Wenn noch Tester benötigt werden, bekomme diese Woche die Batterien...

[quantenquark]

Ich kann Pytes-Batterien testen. Abzuklären wäre, ob Anpassungen an der Software möglich sind zumal (Stand jetzt) die Lade/Entladeparameter anders als für Pylontech sind.

[schlimmchen]

@swingstate Du solltest meiner Meinung nach nicht versuchen, LEDs zu treiben mit den Signalen der seriellen Verbindung. Falls doch, dann in jedem Fall über MOSFETs. Dann fügst du zwar eine vernachlässigbare Kapazität der Leitung hinzu, aber immerhin belastest du die Signalleitung nicht mit einem Strom.

[swingstate]

Ist aktuell nicht geplant.

[Snoopy-HSS]

Gibt es noch Platinen? Oder Fertige Boards?

[swingstate]

nope, work in progress.

[kloppy1984]

@Snoopy-HSS
Ich hab noch eine fertige mit einen ES32 und zwei MPPT plus Canbus für Pylontech.

[Snoopy-HSS]

Ist dass schon ein S3?

kann man den CAN Bus für alle CAN Batterien verwenden oder was macht ihn so speziell für pylontech?

gibt es hier so was wie PN?

[kloppy1984]

@Snoopy-HSS
Es ist ein normaler ESP32 (ohne S3, hätte es sonst dazu geschrieben).

Es gibt viele Akkus die Das Pylontech Protokoll per RJ45 versenden.
Wie z b. Gobelpower oder Pytes...

Kannst dich hier drüber melden:
Link

[swingstate]

Ein kurzes Update zum oDoB-Pro Board.

Die ersten Boards laufen bzw. werde momentan mit verschiedenen Hardware-setups getestet.

Ein paar Feinheiten werden noch verbessert (Textgröße auf dem PCB, Montagelochabstand zum PCB-Rand); Soweit läuft es aber sehr gut mit einem HM1500 und HMS2000 an Pylontech Batterien. Das JK Interface über den Hybridport läuft ebenfalls, muss jedoch noch etwas intensiver getestet werden. Ein 0,96" OLED hängt auch schon dran.

[swingstate]

Danke @stefan123t, werde ich tun. Was den Vertrieb angeht war ich mir nämlich noch gar nicht sicher welcher Weg der einfachste / beste wäre.

[DerHavey1994]

Hammer PCB @swingstate!

Da nun mit der neuen Firmware sogar schon drei MPPT´s möglich sind, sollte der Shunt Port doch auch für einen MPPT benutzt werden können?

Mein Aufbau besteht aus 3x MPPT sowie Pylontech Batterie an einem HM-1500.

Sobald die PCB´s käuflich zu erwerben sind & auch drei MPPT´s angeschlossen werden können bin ich auch bereit auf dieses PCB upzugraden!

[schlimmchen]

Da nun mit der neuen Firmware sogar schon drei MPPT´s möglich sind, sollte der Shunt Port doch auch für einen MPPT benutzt werden können?

Ja.

[Snoopy-HSS]

Kostenlosen Onlineshop und Dropshipping kann ich dir anbieten...

[stefan123t]

@swingstate hast Du Dich mal mit @markusdd unterhalten, m.E. könnte man die BOM der onBattery Pro PCB mit seinen Erfahrungen beim Design der OpenDTU-Fusion PCBs noch etwas reduzieren / optimieren ?

Der etwas größere Formfaktor des OpenDTU-OnBattery Pro PCBs ist m.E. sinnvoll und gerechtfertigt, da ja auch noch mehr Komponenten für zusätzliche OnBattery-spezifische Features Ihren Platz finden müssen:

• 3x Ve.Direct Ports (z.B. 1x Shunt + 2 MPPTs; falls zwei MPPTs durch die Software unterstützt werden)
• 1x Pylontech CAN Bus
• Support für I2C OLEDs, Beispielsweise die 0.96" Displays

Besonders die sich daraus evtl. ergebenden Synergien bei einem OpenDTU-OnBattery "Fusion" Pro++ PCB fände ich toll, die z.B. durch eine Wiederverwendung des OpenDTU Fusion PoE HAT's den W5500 für beide Boards nutzbar machen könnte.
Jetzt wo der SPIManager von @LennartF22 auch Eingang in den OpenDTU master Branch gefunden hat, wäre das m.E. ein guter Weg zur Weiternutzung von Elektrokomponenten.

[swingstate]

Hab noch etwas an dem Case gefeilt und eine DTU mit Board & CMT Antenne gefertigt. Passt soweit. Bei Interesse einfach 'ne kurze Mail schicken.

Ein Display lässt sich in dem Case aus Platzgründen nicht nachrüsten.

Reset und Ve.Direct Port 1 haben eine kleine Kerbe zur einfacheren Identifikation.

Für die restlichen 3 Boards die ich noch hier habe entwerfe ich ein Case mit Displayaussparung. Ggfs. montiere ich auch ein 0,96Zoll OLED Display.

[CaCu15]

@swingstate
Wenn Du noch eins von den Boards + Case OHNE Displayaussparung verfügbar hast, dann würde ich das nehmen.

Display brauche ich nicht (und kann ich auch nicht parallel mit einem MCP2515 für das Huawei anschließen). Den MCP2515 selbst würde ich dann wohl in ein separates kleines Hutschienen Gehäuse stecken.
Wenn ich das aus dem 3D Modell des Gehäuses richtig sehe, dann müsste das auch von den Maßen her ganz gut auf meine Hutschiene passen, wenn ich da an der Rückseite/Boden einen HUtschienen-Adapter/Clip anbringe wie z.B: diesen hier:

[swingstate]

Hier mal der Vergleich zu einem Hutschienenmodul. Ich kann Dir ein Gehäuse ohne die Wandhalterungen zu dem Board drucken.

Folienantennen für die HMS/T habe ich aktuell nicht mehr hier. Die müsstet Du Dir ggfs selbst kaufen.

Schick mir gern 'ne Mail.

[rainer667]

Wie schon per Mail besprochen, eins für mich plus Antenne.
Danke Rainer

[Manos1966]

@swingstate sehe ich das richtig? Die "Free GPIOs" und die "OLED Display" geben mir genau die 6 GPIOs die ich brauche, um einen MC2515 (HUAWEI CAN) anzuschliessen? 🤩 👍
(nicht dass ich jemals machen werde... aber "Prinzipien" muss man haben 😆😆😆 )

[swingstate]

Was auch immer du mit den IOs machst. ✌️☺️
Deswegen habe ich sie auf die Pinleisten geführt, dann kann jeder selbst entscheiden.

[tobi0171]

Ohh, interessant. Falls du das, was du natürlich niemals machen wolltest, doch wiedererwartend und auf wundersame Weise klappt, würd mich das auch interessieren..
Meine Versuche mit einem S3 und HU, blieben bislang erfolglos.

[Manos1966]

@tobi0171

Meine Versuche mit einem S3 und HU, blieben bislang erfolglos.

warum denn? 🤔

#1144 (comment)
(im Nachhinein kann man (ich) alles behaupten 🤣 )

[tobi0171]

@Manos1966 danke für den Link. Einmal mit Profis ..👌🏻. Hab meine Wochenendbeschäftigung somit gefunden. Danke dir.

[CaCu15]

Wäre toll, wenn Ihr hier mal ein Feedback gebt, ob das wirklich mit dem Huawei klappt, wenn man auf das Display verzichtet und dazu noch die freien GPIOs verwendet, um das Huawei anzuschließen. Wenn das der Fall ist, dann würde ich auf jeden Fall ein Board nehmen.

[CaCu15]

@swingstate:
Echt Klasse, was Ihr hier so auf die Beine stellt. Ich habe jetzt seit über einem Jahr mein OpenDTU on Battery laufen, aber damals gab es noch nicht so schöne Platinen wie diese hier. Daher aktuell auf einer selbst gebastelten Lochraster-Platine.
Mit dem aktuellen Release von OpenDTU on Battery wird man ja jetzt quasi gezwungen, auf einen ESP32 mit mind. 8MB Flash (z.B. einen S3) umzusteigen, daher überlege ich gerade, ob diese Platine für mich das Richtige wäre.

Mein aktuelles Setup:

• Pylontech (US5000 + US3000), angebunden über CAN
• Laden über Huawei R4850G2. Das Huwaei wird über ein Shelly Pro 2PM ein- und ausgeschaltet (abhängig von Stromanforderung durch OpenDTU)
• Einspeisen über Hoymiles HM600, will ich aber gegen HM1200 austauschen -> aber Funk in jedem Fall über NRF2401+ Modul
• KEINE Victron Geräte aktuell und auch nicht in näherer Zukunft
• KEIN Display aktuell, da ich das nicht wirklich brauche und das mit dem CAN für das Huawei kollidiert - habe eine UI in Home Assistant. Wenn es doch ginge, dann wäre das ein nettes Add-On.
• SmartMeter über Hitchi Lesekopf am Stromzähler . Habe ich aber aktuell an einem separaten ESP, den ich auch nutze, um den Pylontech über Console/RS485 auszulesen.

Für mich sieht es so aus, als ob das alles mit dieser Platine gehen sollte. Nur folgende Fragen:

• Huawei R4850G2 müsste über die freien GPIOs gehen, siehe Post direkt vor diesem. Dann kein Display möglich, ist ja aber für mich wie gesagt nicht schlimm. Korrekt?
• könnte man den Hitchi Lesekopf auch an den RS485 Port hängen, der über den RJ45 herausgeführt ist? Werde da aus dem Post oben. nicht ganz schlau.
• gibt es eine Möglichkeit, ein Relais/Optokoppler anzusteuern, um "Slot Detect" des Huawei anzusteuern? Auch nicht schlimm, wenn nicht, denn aktuell mache ich das auch ohne und schalte das

Sehe ich das alles richtig? Wenn ja, dann wäre ich auf jeden Fall auch an einer Platine interessiert, ggf. auch an einem Gehäuse. Da müsste ich aber die Maße wissen, da ich das auf einer Hutschiene montieren würde und es dafür nicht zu groß sein dürfte. Könnte man ja einfach einen "Universal Huschienen Halter" auf die Rückseite kleben/schrauben o.ä.

[Manos1966]

Hallo @CaCu15 lange nicht gesehen 😄

wird man ja jetzt quasi gezwungen, auf einen ESP32 mit mind. 8MB Flash (z.B. einen S3) umzusteigen

Jaein. Du kannst nicht mehr Updates ueber OTA. Mit Kabel kannst du aber weiterhin deine "alte" ESP32 4MB nutzen.

Huawei R4850G2 müsste über die freien GPIOs gehen, siehe Post direkt vor diesem. Dann kein Display möglich, ist ja aber für mich wie gesagt nicht schlimm. Korrekt?

Korrekt

könnte man den Hitchi Lesekopf auch an den RS485 Port hängen, der über den RJ45 herausgeführt ist? Werde da aus dem Post oben. nicht ganz schlau.

Nein (wie willst du die PowerMeter Daten ueber RS485 lesen, wenn du die OpenDTU-OnBattery installiert hast drauf?)

gibt es eine Möglichkeit, ein Relais/Optokoppler anzusteuern, um "Slot Detect" des Huawei anzusteuern? Auch nicht schlimm, wenn nicht, denn aktuell mache ich das auch ohne und schalte das

Ja, ein GPIO Pin ist frei (siehe meine Post, 6 PINs) fuer HUAWEI.POWER

[swingstate]

Der Manos hat diverse Versionen des Boards daheim. Da könnt ihr euch sicher austauschen. Ich komm gern dazu wenn es weitere Fragen gibt.

[CaCu15]

OK, vielen Dank schon mal.

Wenn man bei der SW aktuell bleiben will, dann muss man früher oder später wechseln, denke ich. Und da dann immer mit einem USB-Kabel anzurücken ist unpraktisch.

Bzgl. Hitchi Lesekopf: OK, klar, habe ich nicht richtig nachgedacht. Der Hitchi Lesekopf hängt ja einfach an einem Seriellen Port, braucht also einfach RX,TX sowie Masse und +5V. Das ist doch eigentlich dasselbe wie bei den VICTRON Ports. Da ich davon aktuell keinen brauche, müsste ich doch einen davon nehmen können. Aber selbst wenn das nicht geht, dann ist's nicht schlimm, weil ich das dann einfach so lasse, wie es aktuell ist: auf einem separaten ESP unter ESPHome.

[Manos1966]

Es geht nicht. Es gibt keine SW die das interpretieren kann....

Aber warum machts du nicht dein Leben einfacher? Such bei eBay Kleinanzeigen nach
"IR Infrarot Lesekopf für Smartmeter Stromzähler Tasmota" in Koeln.
Fuer 25EUR+3EUR hast eine IR Tasmota mit WiFi inkludiert. Die steckst am Stromzaehler, logst du sie im WiFi und du kannst sie per HTTP+JSM von der OpenDTU direkt abfragen.
😉

[schlimmchen]

Das ist doch eigentlich dasselbe wie bei den VICTRON Ports.

Ich habs leider noch nicht ausprobieren können, aber ich verstehe das genau so.

Es geht nicht. Es gibt keine SW die das interpretieren kann....

Nochmal: Ich habs nicht ausprobiert, aber nach allem was ich verstehe, schickt der Hichi lediglich das SML des Stromzählers über die serielle Leitung, und das können wir sehr wohl interpretieren. Daher war ich so frech die Option auch mit "Hichi TTL" zu benennen:

Ich warte noch darauf, dass das jemand bestätigt oder widerlegt, dass es funktioniert, aber ich gehe schwer davon aus.

[Manos1966]

Obwohl, in Wirklichkeit, ich glaube nicht, dass jemand wird die Batterie, Victron, OpenDTU so Nah am Stromzaehl;er um eine Drahtkommunikation zu nutzen... Ausserdem, eine WiFi Verbindung wird trotzdem gebraucht fuer die OpenDTU. (????? 🤔 wir koennten ein komplett "off-Grid" System haben 🤩 )

[Manos1966]

Ich warte noch darauf, dass das jemand bestätigt oder widerlegt, dass es funktioniert, aber ich gehe schwer davon aus.

@schlimmchen Ich habe einen Hichi IR Lesekopf uebrig (nackt). Was/wie soll ich probieren?

[schlimmchen]

Ich hab auch einen bestellt gestern Abend. Du lötest Drähte an, steckst sie an einen ESP32, nutzt 3V3 als VCC, und machst ein passendes pin mapping und wählst die entsprechende Option aus im PowerMeter Menü.

[CaCu15]

Genau, ich hätte jetzt auch gedacht ,dass man das über ein passendes PIN-Mapping regeln kann.

In der PinMapping.cpp gibt es zumindest 2 defines für den RX und TX PIN des Powermeters:

#ifndef POWERMETER_PIN_RX
#define POWERMETER_PIN_RX -1
#endif

#ifndef POWERMETER_PIN_TX
#define POWERMETER_PIN_TX -1
#endif

Also müsste man Einträge mit den Namen POWERMETER_PIN_RX und POWERMETER_PIN_TX einfügen, wo die GPIOs drin stehen, an die man den Hichi angeschlossen hat (also die, die mit der entsprechenden VIctron der Platine verbunden sind).

Cool übrigens, dass das jetzt über PIN-Mapping konfigurierbar ist, als ich da vor ca. 1 Jahr nach gesucht habe, da waren die PINs noch hard coded.

@Manos1966
Die Logik, um das SML / ORBIS Protokoll zu interpretieren, dass der Hichti "spricht, steckt schon in OpenDTU oB drin, siehe
sml.cpp und PowerMeterSml.cpp

[CaCu15]

Obwohl, in Wirklichkeit, ich glaube nicht, dass jemand wird die Batterie, Victron, OpenDTU so Nah am Stromzaehl;er um eine Drahtkommunikation zu nutzen

Hi Manos, doch, genau das habe ich 😀 . Mein ganzer Aufbau mit Akku, Hoymiles, OpenDTU + NRF, Huawei Charger etc. steht in einem 19-Zoll Rack direkt unter unseren Hausanschlusskasten im Keller. In dem Rack habe ich (neben dem ESP mit OpenDTU) einen 2. ESP mit ESPHome, der den Stromzähler per Hichi-Lesekopf ausliest, die Leitung ist ca. 1m lang. Außerdem ist da auch direkt die Erdungsschiene für das ganze Haus, sodass ich da die Akkus + Inverter auch einfach mit einem 16qmm Kabel erden kann.
Neben dem ANschlusskasten habe ich eine separat über einen FI/LS abgesicherte Steckdose, an die das Rack angeschlossen ist und über die sowohl das Huawei den Ladestrom zieht als auch der Inverter einspeist.

[cerise21]

@swingstate
Ist das Pin-Mapping in Deinem Beitrag vom 18.04. für die aktuelle PCB-Version noch gültig?
Wie ist die genaue Typbezeichnung des verwendeten ESPs?
Gibt es ein Schaltbild für das PCB, um zu sehen, wo welche Bauelemente angeschlossen sind?
Ich überlege, wie @Manos1966, @CaCu15, etc., wie das Huawei am besten anzuschließen ist.
Dafür war mein Plan, den CMT von der Platine runterzulöten und die Pins für den Anschluss eines MCP zu nutzen (dafür wäre ein Schaltbild gut; hängt da noch weitere 'störende' Beschaltung dran?).
Einfacher, dann aber ohne Display, ist wahrscheinlich @Manos1966 Lösung mit den Display-Pins und den vier freien GPIOs.
Sind diese GPIOs 39-42 beliebig als Input oder Output nutzbar?
(Im Espressif ESP32-S3 datasheet sind diese im default boot mode F0 als MTCK/DO/DI/MS bezeichnet und nicht beliebig konfigurierbar. In MUX function F1 wären sie frei konfigurierbar. In welchem function mode befinden wir uns?)

[swingstate]

Es ist ein ESP32-S3-WROOM-1(N16R8). Ich besitze kein 4850G2 Netzteil bzw. ist dies nicht mein use case. Daher habe ich das nie getestet und möchte zur möglichen Anbindung auch keine, wohlmöglich falschen Aussagen, treffen.

Das CMT Modul ist direkt angebunden, ohne etwas dazwischen.

[swingstate]

Zwecks Doku und für alle interessierten.

Pin Mapping:
onBattery Pro 1.7 Mapping v6.json

Das Case, Ober und Unterseite, zum drucken.

OB Pro 1.7 case.zip

Ich habe noch 4 Boards hier, 2 davon mit Case und Folienantenne. OB es dann weitere Boards geben wird kann ich aktuell nicht sagen. Bei Interesse einfach eine kurze Mail, Details weiter oben.

[cerise21]

@swingstate

Mein Exemplar des PCBs läuft jetzt mit Victron MPPT (Port1), Hoymiles (NRF), Pylontech (CAN) und SDM3-Powermeter (RS485). :-)
Eine sehr schöne Platine und ein somit sauberer Aufbau — Danke.
Der Anschluss des Huawei (via OLED Display -Pins und Free GPIOs, gemäß @Manos1966) steht noch aus.

Zusätzlich zur Pinmapping-Datei wäre es (da kein Schaltbild veröffentlicht wurde) noch schön, wenn das Pinout sämtlicher Anschlüsse des PCBs zusammengefasst beschrieben wäre, um den Anschluss von Komponenten ohne vorkonfektionierte Kabel zu erleichtern.
Ausserdem hätte ich noch eine Zuordnung der GPIOs (pinmapping) zu den Ports und deren Pins benötigt.

Mit Hilfe von Multimeter-Piepser und diversen Datenblättern ist die folgende Doku entstanden:
Port[1-3].Pin1 links, bei Blick auf die Kontakt-Spitzen.

Port[1-3]:

-                                   adum.5(gnd)  - port1.1  - mppt1.1(gnd)
- victron.rx:  14 <- adum.2(voa) <- adum.7(via) <- port1.2 <- mppt1.3(tx)
- victron.tx:  13 -> adum.3(vib) -> adum.6(vob) -> port1.3 -> mppt1.2(rx)
-                                   adum.8(vdd2) - port1.4  - mppt1.1(gnd)

-                                   adum.5(gnd)  - port2.1  - mppt2.1(gnd)
- victron.rx2: 12 <- adum.2(voa) <- adum.7(via) <- port2.2 <- mppt2.3(tx)
- victron.tx2: 11 -> adum.3(vib) -> adum.6(vob) -> port2.3 -> mppt2.2(rx)
-                                   adum.8(vdd2) - port2.4  - mppt2.1(gnd)

-                                   adum.5(gnd)  - port3.1  - mppt3.1(gnd)
- victron.rx3: 10 <- adum.2(voa) <- adum.7(via) <- port3.2 <- mppt3.3(tx)
- victron.tx3: 17 -> adum.3(vib) -> adum.6(vob) -> port3.3 -> mppt3.2(rx)
-                                   adum.8(vdd2) - port3.4  - mppt3.1(gnd)

CAN/RS485:
RJ45.Pin1 auch links, bei Blick wie auf Port[1-3].

- battery.rx: 18 <- vp230.4(r) <- | vp230.7(canh) <-> rj45.4(can_h)
- battery.tx:  7 -> vp230.1(d) -> | vp230.6(canl) <-> rj45.5(can_l)

- powermeter.rx:   16 <- 3178eibz.1(ro) <- | 3178eibz.6(a) <-> rj45.1(485_a)
- powermeter.tx:   45 -> 3178eibz.4(di) -> | 3178eibz.7(b) <-> rj45.2(485_b)
- powermeter.dere: 46 -> 3178eibz.3(de) ->   3178eibz                       
-                  15 -> 3178eibz.2(/re) ->  3178eibz                       
-                                                              rj45.6(485_gnd)

Entgegen dem Pinout hier, scheinen 485_a und 485_b vertauscht.

Die Systematik der Nummerierung der victron.rx/tx, victron.rx2/tx2 und victron.rx3/tx3 in o. g. Pinmapping-Datei ist mir nicht klar.
Die Nummern (nix, 2, 3) scheinen nicht mit Port[1-3] des PCBs zu korrespondieren.

Die hardware-mäßige Verdrahtung ist aber wohl so, wie in der Liste oben dargestellt.

Das Powermeter-Pinmapping sieht nur einen kombinierten Pin 'powermeter.dere' vor.
Der '/re'-Pin des 3178eibz(2) wird wohl auch via GPIO15 bedient.

Mein Pinmapping, zur Info:
proPCB_pinmapping.json

[cerise21]

Danke für's Pin-Mapping und die weiteren Informationen zu Bauteilen und Beschaltung.

[Manos1966]

@swingstate Ich weiss, was deine naechste Version brauchen wird: zwei Dipswitches (Jumpers meine ich), um jeweils die Stromversorgung des NRF24 und CMT2300 Moduls zu trennen. 😉

[Manos1966]

Hmm.. ich sehe du hast Jumpers fuer die TX PINS 11, 13, 17 auch 🤩
VORAUSGESETZT ich nutze kein VICTRON SHUNT, ich kann sie nutzen.... kann ich den Jumper entfernen und direkt ein Kable auf das jeweils rechte PIN im Bild stecken?

PS: Sehr schoene Platine Christian 🥇

[schlimmchen]

Jain. Wenn der TX Pin am Board bzw. der RX Pin am Victron den falschen Pegel hat, dann ist das ein "remote off" für den Laderegler. Daher sollte man den TX Pin/Jumper immer setzen und auch im Pin Mapping vorsehen, sodass der Pin einen definierten Pegel hat. Wenn der Jumper entfernt wird sodass der entsprechende GPIO abgreifbar wird, dann macht der ADUM1201 den falschen Pegel. Dann bleibt dir nur die TX Leitung im VE.Direkt Kabel zu trennen, damit der Pin am Victron wieder floating ist. Ich hatte das Feedback gegeben, dass der X Pin des Headers für den Jumper einen Pull-Up oder Pull-Down (ich weiß nich mehr, was "richtig" wäre) haben muss, damit der Pin am ADUM1201 Ausgang den richtigen Pegel hat, aber das wurde nicht berücksichtigt scheinbar. Das müsste man auch nochmal in Ruhe bestimmen ob ein Pull-Widerstand ausreicht und wenn ja, ob Pull-Down oder Pull-Up (ich glaube Up). Das ist also leider nicht trivial.

[Manos1966]

Danke @schlimmchen

Dann bleibt dir nur die TX Leitung im VE.Direkt Kabel zu trennen, damit der Pin am Victron wieder floating ist

Einfache Loesung, gut zu wissen, ich befuerchte weniger als 1% der Mitglieder hier ist diese Besonderheit des ADUM bekannt.

Aber vielleicht sollte ich doch erst die GPIO Pins 39,40,41,42 testen. Bei dieser Gelegenheit, weiss du vielleicht etwas diesbezüglich?

Im Espressif ESP32-S3 datasheet sind diese im default boot mode F0 als MTCK/DO/DI/MS bezeichnet und nicht beliebig konfigurierbar. In MUX function F1 wären sie frei konfigurierbar. In welchem function mode befinden wir uns?

[schlimmchen]

Das ist keine Besonderheit des ADUM1201. Der muss einen Pegel am Ausgang einstellen und der entsprechende Input gibt ihn vor. Wenn der nicht definiert ist (floating), dann ist auch der Output nicht definiert.

Zu den boot modes und den genannten GPIOs weiß ich nichts.

[Manos1966]

ich habe es probiert, es funktioniert 🥂
Ich habe beide NRF24 und CMT2300 in der PIN-config ausgeschaltet (zur Sicherheit)
@AndreasBoehm SPIPortmanager Firmware hat daraufhin SPI0 dem HuaweiCAN gegeben 👍
Ich kann den HUAWEI R4850 problemlos sehen!

Initialize Hoymiles interface...
Invalid pin config
Initialize Huawei AC charger interface...
Huawei AC-charger miso = 39, mosi = 40, clk = 42, irq = 9, cs = 41, power_pin = 8
[SPIPortManager] SPI0 now in use by 'Huawei CAN'
Entering Configuration Mode Successful!
Setting Baudrate Successful!
Starting to Set Mask!
Setting Mask Successful!
Starting to Set Filter!
Setting Filter Successful!
Starting to Set Mask!
Setting Mask Successful!
[HuaweiCanClass::init] MCP2515 Initialized Successfully!
done

[swingstate]

aber ein Wechselrichterinterface brauchst Du doch.

[Manos1966]

VIELLEICHT SOLL ICH HIER BETONEN:
DIES IST NICHT DIE STANDART FIRMWARE DIE ICH AM LAUFEN HABE!

Die Frage war, ob die PINS 39-41 funktionieren. Das machen sie 😉 👍

Ich kann auch alles einschalten, NRF,CMT2300, HUAWEI
Die ersten zwei Geraete bekommen eine SPI zugewiesen, das dritte nicht.
Die Geraete Such-Zequenz ist immer

1. NRF
2. CMT2300
3. HUAWEICAN

HIer die Boot Sequenz mit allen drei Geraeten definiert:

Starting OpenDTU
Initialize FS... done
Reading configuration... done
Reading PinMapping... found valid mapping done
Initialize Network... done
Setting Hostname... Configuring WiFi STA using new credentials... done
Initialize NTP... done
Initialize SunPosition... done
Initialize MqTT... done
Initialize WebApi... done
Initialize Display... done
Initialize LEDs... done
Check for default DTU serial... done
done
Initialize Hoymiles interface...
[SPIPortManager] SPI0 now in use by 'NRF24'
NRF: Connection successful
[SPIPortManager] SPI0 already in use by 'NRF24'
[SPIPortManager] SPI1 now in use by 'CMT2300A'
CMT: Connection successful
Setting country mode...
Setting CMT target frequency...
Setting radio PA level...
CMT TX power set to 0 dBm
Setting DTU serial...
Setting poll interval...
Setting verbosity...
done
Initialize Huawei AC charger interface...
Huawei AC-charger miso = 39, mosi = 40, clk = 42, irq = 9, cs = 41, power_pin = 8
[SPIPortManager] SPI0 already in use by 'NRF24'
[SPIPortManager] SPI1 already in use by 'CMT2300A'
[SPIPortManager] Cannot assign another SPI port to 'Huawei CAN'
[HuaweiCanClass::init] Error Initializing Huawei CAN communication...
done
Switch to WiFi mode
Setting Hostname... done
Configuring WiFi STA using new credentials... done
Configuring WiFi STA DHCP IP... done
[DPL::announceStatus] disabled by configuration
WiFi connected

💯 🥇

[CaCu15]

Hi Manos, vielen Dank für den Test. Das sieht doch schon mal super aus.

bzgl. Deines Hinweises, dass Du NICHT die Standard-Firmware einsetzt:
Wenn ich das richtig verstehe, wäre das Wichtigste, dass die eingesetzt FW den neuen SPIPortManager einsetzt, damit erkannt wird, ob ein Display oder ein Huawei angeschlossen ist. Der entsprechende PR 1144 ist zwar gemerged, aber anscheinend nicht in Release https://github.com/helgeerbe/OpenDTU-OnBattery/releases/tag/2024.08.18 enthalten, jedenfalls sehe ich da das Feature #1144 nicht in der Liste.

Um das zu nutzen, muss man sich also selbst eine FW aus dem Development Branch bauen, richtig?

@schlimmchen : Kannst Du sagen, ob das Feature #1144 in einem der nächsten Releases enthalten sein wird?

Grundsätzlich scheint mein Aufbau eher ungewöhnlich, die meisten hier laden anscheinend über Victron Solar Charger. Bei mir keine Option, da kein BKW vorhanden, nur ein "große" PV. BKW etwas schwierig wegen Verkabelung.
Vielleicht muss ich dann auch mal dazu übergehen, das Huawei nicht über OpenDTU zu steuern, sondern über einen separaten ESP mit ESPHome. An der aktuellen Lösung gefällt mir aber, dass OPenDTU sehr schnell zwischen Akku Laden über Huawei und Entladen über Inverter umschaltet und dafür sorgt, dass nicht beides gleichzeitig passiert. Wenn man das auf 2 ESPs macht, dann wird das schwieriger/fehleranfälliger.

[schlimmchen]

Kannst Du sagen, ob das Feature #1144 in einem der nächsten Releases enthalten sein wird?

Naja, versprechen werde ich nichts. Aber das ist ja im development Branch drin. Und der Prozess ist schon immer so, dass der development irgendwann in den master ge-merge't wird, dann und dann wird daraus ein Release. Daher müsste man das Feature extra nochmal rausnehmen, weil irgendetwas grundsätzlich ganz kaputt damit ist. Daher... Kannst du schon damit rechnen, dass es Teil des nächsten Release wird.

[CaCu15]

Schon klar, dass Du nichts versprechen kannst. Aber Deine Aussage reicht mir auf jeden Fall. Zur Not kann ich mir ja auch übergangsweise selbst meine FW bauen aus dem Development Branch, bis das in einem offiziellen Release drin ist. Habe ich am Anfang auch gemacht.
Ich will nur nicht so gerne auf längere Sicht einen eigenen Branch aufmachen, den ich dann auf ewig pflegen muss, darum ist es schon gut, wenn da eine Perspektive ist, dass das Feature im Main aufgenommen wird.

[schlimmchen]

Das ist kein Grund, deine Firmware selbst zu bauen. Nimm in diesem Fall jene, die von Github gebaut wird. Schau mal in den Actions bzw. hier an einem konkreten Beispiel, dem letzten Build vom development Branch.

[CaCu15]

Hi Swingstate,   super, vielen Dank für das Bild. Das passt also locker, da ist sogar noch ordentlich viel Platz für die Stecker, die dann nach oben/unten aus dem Gehäuse ragen. Das ist bei meinen aktuellen Hutschienen-Gehäusen eher knapp.    Dann nehme ich gerne Dein Angebot für ein Gehäuse ohne die Wandhalterungen an (die hätte ich sonst vermutlich selbst abgesägt ;-)   Folienantenne brauche ich erstmal nicht, ich habe aktuell einen HM-600 (wird auf HM-1200 umgerüstet). Aber beide dann ja über den NRF2401, nicht über den CMT. Also brauche ich keine Folienantenne. Und da mein Hoymiles keine 50cm von der OpenDTU sein wird (beides im selben Rack montiert), ist der Empfang sicher kein Problem ;-)   Wieviel bekommst Du für das Board + Gehäuse? Kann ich das per PayPal Friends bezahlen?     swingstate ***@***.***> hat am 29.08.2024 13:08 CEST geschrieben:       Hier mal der Vergleich zu einem Hutschienenmodul. Ich kann Dir ein Gehäuse ohne die Wandhalterungen zu dem Board drucken. 25E39281-2508-4106-AC80-25F207728014.jpeg (view on web) Folienantennen für die HMS/T habe ich aktuell nicht mehr hier. Die müsstet Du Dir ggfs selbst kaufen. Schick mir gern 'ne Mail. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>   Mit freundlichen Grüssen Carsten Curdt

[ballermann64]

Hi Swingstate, mit diesem Board scheinst du einen Nerv getroffen zu haben - zumindest meinen! ;-) Ich such seit langem nach einem einfachen, unkomplizierten und stabilen Setup für BKW-"Nulleinspeisung" mit HMS2000, Victron MPPT100/20 und Pytes eBox über Homeassistant auf einem Raspi 4. Das scheint ja mit dem Board unkomplizeirt möglich, oder? Wo und wie kann ich es denn erwerben. Kann auch als Tester und "Multiplikator" dienen (da mehrere Bekannte meine Erfahrungen für neu zu installierenden BKWs nutzen). Freue mich auf deine Antwort! Beste Grüße, Achim

[swingstate]

Zur Pytes eBox kann ich leider nichts sagen, da ich mit dieser Batterie nicht testen konnte. Hier haben aber einige diese Batterie im Einsatz soweit ich weiss. Meld Dich gerne via Mail via [email protected].

[quantenquark]

Ich habe zwei Pytes ebox 48100C im Einsatz und kann auch testen. Ein Board mit CMT Modul wäre ich bereit abzunehmen und Kosten zu übernehmen ;-)

Gruß Achim

[KlausHans]

Nettes Board, wird es Gerber-Dateien, Bom und Bestückungsdoku irgendwann geben?

Wie ist allgemein der Status?

Suche ein Board für Hoymiles HM und HMS-Geräte, die anderen Features brauche ich bisher nicht.

[KlausHans]

Achso, schade.

Betonung liegt auf bisher.

OT: CE ist eine Konformitätserklärung, die kostet kein Geld. Die Konformität kann man auch selbst prüfen und bescheinigen.

[Manos1966]

OT: CE ist eine Konformitätserklärung, die kostet kein Geld. Die Konformität kann man auch selbst prüfen und bescheinigen.

Interessant, meine Infos sagen dass der "Spass" ein paar tausend EUR kostet...
Hast du vielleicht ein paar genauerer Infos diesbezueglich?

Achso, schade.

Ich verstehe nicht warum die Verteilung der GEBER Dateien einen Einfluss auf deine Entscheidung diese Platine zu benutzen machen.

[Hutzelbrot]

https://instrktiv.com/de/ce-kennzeichnung/#:~:text=Die%20Kosten%20einer%20CE%2DZertifizierung,bis%20%C3%BCber%20100.000%20%E2%82%AC%20variieren.

[rs3hc]

Achso, schade.

Betonung liegt auf bisher.

OT: CE ist eine Konformitätserklärung, die kostet kein Geld. Die Konformität kann man auch selbst prüfen und bescheinigen.

Grundsätzlich hast du recht.
Allerdings bist du im Grunde dafür zuständig alles zu dokumentieren und sicher zu stellen, dass auch alles der CE-Zertifizierung entspricht und du alle Unterlagen sofort vorweisen kannst.
Wenn dann ein "Unfall" (z.B. Brand auf Grund des Akkus) passiert, bei dem dein Gerät eine Rolle spielt, nehmen die Dich und dein Büro auseinander.... kann extrem teuer werden.

[swingstate]

Genauso ist es.