Wir wechseln das Forum am 14.11.24 auf die Forensoftware Discourse. Zwischen Montag Abend und Dienstag Nachmittag wird das Forum deaktiviert. Danach sind wir hoffentlich mit neuem Forum inkl. der vorhandenen Beiträge wieder am Start! Hier zum Forenbeitrag!
Hallo zusammen,
ich habe beim Bau des Speichers einen kleinen Controller entwickelt, den ich hier einmal kurz vorstellen möchte, falls es jemand in irgendeiner Form gebrauchen kann. Ich denke, dass es in DIY-Akku-Scene wichtig ist, zu teilen.
Getauft habe ich das Projekt „Battery safety controller“ kurz BSC. Der Controller ist bei mir hauptsächlich dazu da die Daten vom BMS zu überwachen und für den Wechselrichter aufzubereiten inkl. Laderegelung. Zusätzlich kann er z.B. die Temperatur von jeder einzelnen Busbar/Zelle überwachen. Im Gefahrenfall kann z.B. ein Leistungsschalter ausgelöst werden. Es ist für mich eine zweite Sicherungsebene neben dem BMS.
Der Link zum github Projekt der Firmware: https://github.com/shining-man/bsc_fw
Im Projekt-Wiki habe ich einmal mit einer kleinen Doku begonnen. Bei entsprechendem Interesse kann ich diese auch ergänzen. Dort sind dann auch (ältere) Screenshots der Weboberfläche zu sehen.
Was kann der BSC:
• Er kann Daten von bis zu 7 Bluetooth BMS und bis zu 3 seriellen/RS485 BMS überwachen
• Überwachen kann er bisher Spannungspegel (Gesamt, Zelle) und den Verbindungsstatus zum BMS
• Er kann bis zu 64 DS18B20 Temperatursensoren auswerten
• Wechselrichterkommunikation über CAN; Der BSC kann z.B. auch die Ladeleistung drosseln abhängig von der Zellspannung oder dem Zelldrift
• 4 Digitale Eingänge um z.B. der Schaltzustand von Schützen oder Leistungsschalter zu erkennen
• 6+1 Relais; z.B. um Leistungsschalter auszulösen oder Lüfter zu steuern, …
• MQTT
Alle Funktionen sind frei über eine Weboberfläche parametrierbar.
Unterstützte Geräte
Bluetooth:
- NEEY aktive Balancer (Hier können über die Weboberfläche auch die Settings eingestellt werden)
- JK-BMS (Alpha; bisher nur mit einem Device getestet)
Serial:
- JBD-BMS
- JK-BMS
- Seplos-BMS
- Daly (in arbeit)
Wechselrichter
- DEYE, Solis (vmtl. alles was auch Pylontechs unterstützt)
- Victron
Zum Testen und anschauen läuft es auch auf einem Standard ESP32 Dev Board (z.B. WROOM-32), nur ohne CAN, DIs, DOs.
Viele Grüße
Shining Man
Liste Sammelbestellung: https://docs.google.com/spreadsheets/d/1f79U_N3olWYk3Cxmrt1rXbqDJv2RF7Rbs7cSoV90W7A
Github Firmware: https://github.com/shining-man/bsc_fw
Discord BSC: https://discord.gg/bPK2HeYhEv
Echt Wahnsinn 😎
Mein Kollege und ich startete diese Woche die Planung / Ideenfindung für ein ähnliches System mit mehreren NEEYs und Solax X3 G4 Anbindung. Bei der Suche nach Ideen zum umbauen der NEEYs von BLE auf direkt UART zum Glück auf diesen Thread gestoßen 😉
Ist zwar vom Aufbau ein bisschen anderes aber das meiste scheint mit dem tollen Projekt schon gelöst zu sein.
Gerne lasse ich meine Input da bzw im Github.
Was ich gerne anbieten kann, ist das Testen von mehreren NEEYs 😉 Die sind gerade im Zulauf und bei uns kommen 7 Stück zum Einsatz :angel:
BG Manuel
Ich habe die neue PCB jetzt einmal gepusht.
https://github.com/shining-man/bsc_hw
Wer möchte kann den Stromlaufplan und Layout kritisch nach Fehlern anschauen.
Fehler/Feedback zum Redesign hier oder in den discussions auf github.
https://github.com/shining-man/bsc_fw/discussions/11
Nicht alle Funktionen sind zu 100% ausgetestet. Z.b. habe ich keine 5 BT BMS um das ganze bei voller Kommunikationslast zu testen.
Da habe ich Mal eine Idee für dich.
Bei deiner Kenntnis dürfte es kein Problem sein, dir BT BMS Dummies zu programmieren..... Die letztendlich aus nichts anderem bestehen als der BT Kommunikation, BMS seitig, plus ein oder zwei Werte, die du durch Tastendruck im "BMS" ändern kannst. Programmieren musst du das nur einmal, halt die Hardware mit BT. Auf diese Art kannst du die gesamte vielfache Kommunikation testen, wobei die ein echter Akku mit BMS genügt. Die weiteren "BMS" sind nur Dummies.
Damit haben ich im Beruf Profis düpiert..
Für die Integration eines Messystems in eine riesige Lagerverwaltung hatte ich nur 2 Tage vorgesehen. Die anderen hatten 14 Tage angesetzt, und wollten dafür von uns Geld haben.
Ich habe die vereinbarte Kommunikation nach Pflichtenheft für beide (!) Seiten von meiner Softwarabteilung als Simulatoren programmieren lassen, damit konnte ich selber von beiden Seiten aus testen ;-).
Den Simu für unser System haben wir an den Kunden geliefert.... 6 Wochen vor Liefertermin, ab da konnte der Kunde also schon testen, ohne uns, bzw ohne echte Messung, aber mit allen Abläufen. Was die auch reichlich getan haben, fertig geworden sind die trotzdem nicht.
Als die endlich fertig waren, sind wir dann hingefahren.... Aufgestellt, eingeschaltet, Kommunikation verbunden.... In 2 Stunden. Ausgepackt, eingeschaltet, läuft.
Abends sind wir dann heimgefahren...
Gekostet hat das ganze 3 Tage Software bei uns... Nur für die beiden Simus, die Kommunikation mussten wir ja eh machen. Gespart haben wir die Vorortkosten 2 Mann 14 Tage, die bei konventioneller Vorgehensweise angemessen waren.
Ich bin kein Amateur, aber ich lerne trotzdem noch.
Bürokratie schafft man nicht durch neue Regeln oder Gesetze ab.
SOC ist ein NTCV Parameter
@carolus Ich habe sowas auch schon im Kopf gehabt. Nicht nur für BT, sondern für sämtliche Schnittstellen. Doch bisher habe ich den Aufwand dennoch gescheut, da die freie Zeit leider endlich ist. Noch dazu kommt, dass sich damit nicht die Eigenarten der BMS oder Balancer mit einbeziehen lassen. Kürzlich haben wir z.B. beim Testen festgestellt, dass sich beim JK-BMS die Berechnung der Cheksumme ändert, wenn nur wenige Zellen eingestellt sind. Ich denke, dass dies ein Fehler im JK Protokoll ist.
Aber ich finde den Gedanken im Grundsatz gut, und werde ihn im Hinterkopf behalten. Wenn ich einmal Lust dazu habe, werde ich einen Simulator umsetzen.
Du wirst sehen, dass du 70 % der Programmierung schon hast, den gesamten Kommunikationsblock.
Neu ist nur der einfache Händler, der dir Nachricht schickt, solche, wie du sie normalerweise vom BMS bekommst. Natürlich kannst du damit nicht die Eigenheiten der BMS kopieren. Aber du kannst in deinem Programm der Händler prüfen, der fein säuberlich die 5 eingehenden BMS trennt, die Nachrichten verarbeitet und logisch zusammen führt. Dabei kannst du dir wahlfrei auch Fehlermeldungen schicken lassen, was mit normalem BMS garnicht so leicht möglich ist. Wenn du diese Testmöglichkeiten ganz in Betracht ziehst wirst du merken, dass der Simulator seine Zeit wert ist....
Du kannst ja sogar echte und Simulierte BMS gleichzeitig behandeln.... Denk Mal darüber nach.
Wenn du solche Tests auf der Ebene machst, wie man das im Profibereich machen soll, kommst du um den Simulator nichtmal herum.
Ich bin kein Amateur, aber ich lerne trotzdem noch.
Bürokratie schafft man nicht durch neue Regeln oder Gesetze ab.
SOC ist ein NTCV Parameter
Hi,
erst mal Hut ab, gutes Projekt. Da steckt einiges an Potenzial drin,...
Ich bin bisher soweit mir was ähnliches mit 2x ESP8266, diversen Temp-Sensoren/Relais und iobroker zu basteln.
Du schreibst in dem Wiki, dass mit einem "normalen" ESP32 Dev-Board "nur" die CAN-Anbindung sowie die DI/DOs nicht funktionieren.
Da es mir momentan primär darum geht, einen Neey Balancer und 18x DS18B20 per MQTT auszulesen:
Würde das mit einem ESP32 (habe ich hier noch rumliegen) funktionieren?
Also BT und OneWire?
Falls ja, welchen GPIO nimmt dein BSC für OneWire? Oder ist das konfigurierbar?
Hallo,
mal fetten Respekt.
Kann man das schon so bestellen? Oder machst du da noch Änderungen?
Wie kann ich dir mal einen Kaffe, Bier oder sonst was ausgeben? 
Ich freue mich wenn das Projekt auf Interesse stößt und vielleicht noch der ein oder andere es nutzen kann 😀
Um so mehr lohnt sich das Pflegen des Projekts.
@darthpride: Bluetooth und OW-Sensoren genügt dir ein ESP32.
Onewire liegt auf GPIO19. Pullup nicht vergessen;) Ich habe einen 4k7 genommen. Wenn die Leitungen länger sind, kann man auch ggf. einen kleineren nehmen.
Der GPIO des onewire ist nicht via Weboberfläche konfigurierbar. Du könntest ihn dir aber in der defines.h umbiegen, wenn es ein anderer GPIO sein soll.
Da steckt einiges an Potenzial drin,...
Wenn du noch Ideen oder Wünsche hast, einfach hier schreiben oder, was mir lieber ist, ein Issue aufmachen.
Die Issues sind für mich übersichtlicher, gerade wenn es von mehreren Seiten etwas kommt.
@tracer09:
Ich freue mich, wenn das Projekt auf Interesse stößt und es dem ein oder anderen hilfreich ist. Das ist für mich Dank genug:)
Die PCB ist von meiner Seite aus fertig. Weitere Änderungen habe ich nicht geplant.
Wenn jemand Bestückt bestellen will, wäre eine Sammelbestellung sicher eine gute Idee. Ich schaffe es aber aktuell zeitlich nicht, mich darum zu kümmern.
Ich habe beim Layout darauf geachtet das die meißten Bauteile auf der Top-Side sind, damit es z.B. bei JLCPCB bestellt werden kann.
Es gibt ein paar Stellen, da sind alternativ Bestückungen möglich. D.h. nicht einfach alle Bauteile bestücken lassen.
Wenn jemand bestückt bestellen will, dann am besten noch einmal melden, denn dann werde ich eine kleine Tabelle zu den Bestückvarianten machen.
Servus,
habe mal das Layout etwas gereviewt,
bin als Hardwareentwickler tätig und da sind mir noch ein paar Grundlegende dinge aufgefallen, hab die mal schnell zusammengeschrieben.
Coole Idee auf jedenfall, die idee gefällt mir.
Ich würde schonmal 2 oder 3 nehmen... Bestückt natürlich und fertig. Mit meinen Lötkünsten bräuchte ich vermutlich 10 PCB mit einem vielfachen der Teile, um eines benutzen zu können.
@danielm Vielen Dank für dein Review:-) Ich werde mir das ganze einmal in Ruhe anschauen.
Leiterbahnführungen sollten sich ohne Probleme ändern lassen.
Auf 4 Lagen umzusteigen, ist natürlich ein größerer Aufwand, der einige Zeit in anspruch nehen würde.
Die Erfahrungen mit dem ESP32 zeigen, dass er ziemlich große Stromsitzen hat, daher der dicke Elko. In meiner aktuellen PCB, die ich im Einsatz habe, habe ich einen 100µ Elko. Damit funktioniert es auf jedenfall. Was haben die kleineren C's für einen technischen Vorteil bzw. kann ein großer Elko Nachteile bringen?
Siehst du die 5 V Schiene so kritisch? Große Ströme sollten hier eigentlich nicht zustande kommen, da mit den 5V eigentlich nur die DC/DC Wandler für die galvansiche Trennung der Schnittstellen versorgt werden. Plus ggf. die Relais. Dann ist der Strom in dem Bereich doch größer.
Dass ich nicht so viele ESD Maßnahmen getroffen habe, weiß ich. Das ganze Projekt habe ich ursprünglich nur für mich vorgesehen. So ist es jetzt auch schon eine ganze weile im Einsatz. Irgendwann dachte ich mir, vielleicht kann es noch jemand gerauchen. Daraus ist dann dieses kleine Redesign geworden. Der Zeit geschuldet werde ich vmtl. keine riesen Änderungen mehr vornehmen.
Ich schaue einmal was ich ändern kann, und würde es dir dann nocheinmal geben, wenn für dich ok.
Der Umstieg auf vier lagen ist relativ leicht:
zwei neue Lagen rein, eine GND, eine Spannung ( je nach Bereich teilst du das auf in 3V3 5V usw..
dann an den entsprechenden Komponenten ein via setzen.
damit hast du auf top&bottom mehr Platz und kannst da auch besser routen.
Bei den Projekten auf der Arbeit verwenden wir nach Möglichkeite keine Elkos mehr, weil:
brauchen mehr Platz, haben eine begrenzte Lebensdauer (trocknen aus), deutlich schlechterer Innenwiderstand bei steigender Frequenz.
Das heißt, dass hochfrequenze Störungen ( also EMV) mit Kerkos (MLCC) besser bedämpft werden, wie man bei folgendem Bild sehen kann
https://weblogographic.com/difference-between-ceramic
Das Ziel von den Kondensatoren nahe am Bauteil ist es, die Stromimpulse abzufangen, den Strom zu liefern und möglichst wenig Störungen zu erzeugen.
Da sind kerkos einfach besser.
Ich habe eine recht komplexe Platine mit großem STM32, ESP32, Display, Mosfets usw. entwickelt und dabei keinen einzigen Elko benutzt. Alles mit Kerkos.
Für die großen Stromschleifen mit den Spannungsversorgungen ist es das gleiche problem, da erzeugst du magnetische Felder.
wie in diesem Bild:
sind die Strom hin und Rückwege nah aneinander, dann entsteht nur ein geringes Magnetfeld ( grün)
sind die hin und Rückwege weiter weg, dann entsteht ein großes Magnetfeld.
Die Platine wird auch so funktionieren, aber dann KANN es sein, dass irgendwelche anderen Geräte plötzlich andere Funkbetriebene Geräte plötzlich gestört werden.
Dieses "kann stören" muss man als Entwickler möglichst gering machen, damit da möglichst wenig strahlt.
Der CAN-Bus hat z.b. recht steile flanken, da der das signal ja sauber erstellen muss. diese Steilen flanken beinhalten hohe Frequenzen, die sich dann als Störungen ausbreiten können. Das schwierige an EMV ist halt, dass man es nicht sehen, riechen oder fühlen kann.
Das sind dann solche Phänomene wie man sie auch in diesem Forum lesen könnte: nachdem man Gerät XY anschließt, geht das W-Lan des WR nicht mehr.
Was mir noch im Schaltplan aufgefallen ist:
Für "Probleme beim Boot" hast du den CAN_Rx und H_MISO als Pullup/Down vorgesehen, aber die jeweiligen Leitungen, die zu der Peripherie gehen nicht getrennt.
Sprich wenn der CAN-Treiber den Pin auf GND zieht und du ihn auf High ziehst, dann haste im CAN-treiber nen Kurzschluss erzeugt.
Das mag der Chip nicht so gerne.
beim OP würde ich auch noch nen 10uF Kerko hinzufügen, da die eine recht stabile Spannungsversorgung haben wollen.
Generell finde ichs recht schön, dass du beim Schaltplan mit Hierarchie ebenen Arbeitest,
optisch ist das aber so, dass man Schaltpläne von oben nach unten und von links nach rechts liest.
Nach oben Vcc, nach unten GND Symbole.
Hast du größtenteils drin, aber nicht überall.
Ist aber auch Geschmackssache und jeder machts anders. Beispielsweise bei den Relais würde ich es so machen:
Ebenfalls Kondensatoren, da wo die im Layout hinsollen, würde ich im Schaltplan auch verbinden:
Aber wie gesagt, Geschmacks/ Firmeninterne Sache. Wenn die C's kommentiert sind oder man eindeutig sieht, zu was die gehören, dann passt das auch.
Bei den Mosfets, die die Relais ansteuern würde ich noch ans Gate einen 10-20Ohm widerstand zur Strombegrenzung einbauen um den Pin des ESP32 zu schonen. Im Einschaltmoment ist das Gate entladen und muss nun schlagartig voll werden. Dafür "sieht" der Ausgang im ersten moment einen reinen Kurzschluss nach Masse. Um dies etwas zu minimieren und dennoch steile Schaltflanken zu haben empfehle ich einen kleinen Widerstand. Der 100kOhm pull down an den Mosfets würde ich durch 10k ersetzen. 100kOhm sind etwas hoch als Pull down.
Die Terminierung am CAN-Bus mit dem Tiefpass gefällt mir auf jedenfall, das schließt hochfrequente Stürungen kurz.
Vorwiderstand an den LEDs würde ich etwas höher ansetzen, die meisten LEDs sind eh so hell, dass man die gar nicht auf voller Leistung laufen lassen will, das "blendet" erfahrungsgemäß nur.
Schmelzsicherungen kann man verwenden, bei solchen sachen bin ich eher Freund von PTC sicherungen.
Je nachdem welches Netzteil man anschließt kann es sein, dass die Sicherung gar nicht auslösen kann ( Netzteil liefert nicht genug Strom zum abschalten, sondern hält den Strom einfach).
PTC Sicherungen werden warm und damit hochohmig. Sobald der strom geringer wird kühlen die Sicherungen ab und werden wieder hochohmig.
Kann man ändern, muss man aber nicht ( sind auch wieder persönliche vorlieben)
Den 3V3 LM078 würde ich auch an V_IN anschließen, damit belastest du den 5V regler nicht noch zusätzlich. Laut Datenblatt brauch der mindestens 4,75V Eingangsspannung, das finde ich unter Beachtung der Ausgangsspannung von +-0,4% ( also schlimmstenfalls liefert der Regler nur 4,8V) seeeehr knapp.
Für den 5V typ haste auch z.B. eine "max. capacitive load" von 680uF. Da biste schon drüber. Das bedeutet, dass es sein kann, dass der Reglers es nicht schafft anzulaufen, da die Last am Ausgang zu groß ist. ( da leere Kondensatoren viel Strom im Einschaltmoment ziehen).
Der Umstieg auf vier lagen ist relativ leicht:
zwei neue Lagen rein, eine GND, eine Spannung ( je nach Bereich teilst du das auf in 3V3 5V usw..
dann an den entsprechenden Komponenten ein via setzen.
damit hast du auf top&bottom mehr Platz und kannst da auch besser routen.
Bei den Projekten auf der Arbeit verwenden wir nach Möglichkeite keine Elkos mehr, weil:
brauchen mehr Platz, haben eine begrenzte Lebensdauer (trocknen aus), deutlich schlechterer Innenwiderstand bei steigender Frequenz.
Das heißt, dass hochfrequenze Störungen ( also EMV) mit Kerkos (MLCC) besser bedämpft werden, wie man bei folgendem Bild sehen kann
https://weblogographic.com/difference-between-ceramic
Das Ziel von den Kondensatoren nahe am Bauteil ist es, die Stromimpulse abzufangen, den Strom zu liefern und möglichst wenig Störungen zu erzeugen.
Da sind kerkos einfach besser.
Ich habe eine recht komplexe Platine mit großem STM32, ESP32, Display, Mosfets usw. entwickelt und dabei keinen einzigen Elko benutzt. Alles mit Kerkos.
Für die großen Stromschleifen mit den Spannungsversorgungen ist es das gleiche problem, da erzeugst du magnetische Felder.
wie in diesem Bild:
sind die Strom hin und Rückwege nah aneinander, dann entsteht nur ein geringes Magnetfeld ( grün)
sind die hin und Rückwege weiter weg, dann entsteht ein großes Magnetfeld.
Die Platine wird auch so funktionieren, aber dann KANN es sein, dass irgendwelche anderen Geräte plötzlich andere Funkbetriebene Geräte plötzlich gestört werden.
Dieses "kann stören" muss man als Entwickler möglichst gering machen, damit da möglichst wenig strahlt.
Der CAN-Bus hat z.b. recht steile flanken, da der das signal ja sauber erstellen muss. diese Steilen flanken beinhalten hohe Frequenzen, die sich dann als Störungen ausbreiten können. Das schwierige an EMV ist halt, dass man es nicht sehen, riechen oder fühlen kann.
Das sind dann solche Phänomene wie man sie auch in diesem Forum lesen könnte: nachdem man Gerät XY anschließt, geht das W-Lan des WR nicht mehr.
Was mir noch im Schaltplan aufgefallen ist:
Für "Probleme beim Boot" hast du den CAN_Rx und H_MISO als Pullup/Down vorgesehen, aber die jeweiligen Leitungen, die zu der Peripherie gehen nicht getrennt.
Sprich wenn der CAN-Treiber den Pin auf GND zieht und du ihn auf High ziehst, dann haste im CAN-treiber nen Kurzschluss erzeugt.
Das mag der Chip nicht so gerne.
beim OP würde ich auch noch nen 10uF Kerko hinzufügen, da die eine recht stabile Spannungsversorgung haben wollen.
Generell finde ichs recht schön, dass du beim Schaltplan mit Hierarchie ebenen Arbeitest,
optisch ist das aber so, dass man Schaltpläne von oben nach unten und von links nach rechts liest.
Nach oben Vcc, nach unten GND Symbole.
Hast du größtenteils drin, aber nicht überall.
Ist aber auch Geschmackssache und jeder machts anders. Beispielsweise bei den Relais würde ich es so machen:
Ebenfalls Kondensatoren, da wo die im Layout hinsollen, würde ich im Schaltplan auch verbinden:
Aber wie gesagt, Geschmacks/ Firmeninterne Sache. Wenn die C's kommentiert sind oder man eindeutig sieht, zu was die gehören, dann passt das auch.
Bei den Mosfets, die die Relais ansteuern würde ich noch ans Gate einen 10-20Ohm widerstand zur Strombegrenzung einbauen um den Pin des ESP32 zu schonen. Im Einschaltmoment ist das Gate entladen und muss nun schlagartig voll werden. Dafür "sieht" der Ausgang im ersten moment einen reinen Kurzschluss nach Masse. Um dies etwas zu minimieren und dennoch steile Schaltflanken zu haben empfehle ich einen kleinen Widerstand. Der 100kOhm pull down an den Mosfets würde ich durch 10k ersetzen. 100kOhm sind etwas hoch als Pull down.
Die Terminierung am CAN-Bus mit dem Tiefpass gefällt mir auf jedenfall, das schließt hochfrequente Stürungen kurz.
Vorwiderstand an den LEDs würde ich etwas höher ansetzen, die meisten LEDs sind eh so hell, dass man die gar nicht auf voller Leistung laufen lassen will, das "blendet" erfahrungsgemäß nur.
Schmelzsicherungen kann man verwenden, bei solchen sachen bin ich eher Freund von PTC sicherungen.
Je nachdem welches Netzteil man anschließt kann es sein, dass die Sicherung gar nicht auslösen kann ( Netzteil liefert nicht genug Strom zum abschalten, sondern hält den Strom einfach).
PTC Sicherungen werden warm und damit hochohmig. Sobald der strom geringer wird kühlen die Sicherungen ab und werden wieder hochohmig.
Kann man ändern, muss man aber nicht ( sind auch wieder persönliche vorlieben)
Den 3V3 LM078 würde ich auch an V_IN anschließen, damit belastest du den 5V regler nicht noch zusätzlich. Laut Datenblatt brauch der mindestens 4,75V Eingangsspannung, das finde ich unter Beachtung der Ausgangsspannung von +-0,4% ( also schlimmstenfalls liefert der Regler nur 4,8V) seeeehr knapp.
Für den 5V typ haste auch z.B. eine "max. capacitive load" von 680uF. Da biste schon drüber. Das bedeutet, dass es sein kann, dass der Reglers es nicht schafft anzulaufen, da die Last am Ausgang zu groß ist. ( da leere Kondensatoren viel Strom im Einschaltmoment ziehen).
Ich habe die C's, PTC's, R an den FET's eingearbeitet.
Willst du noch einmal kurz über den Stromlaufplan schauen, bevor ich das Layout ändere.
Mit dem ändern auf 4 Lagen habe ich schon einmal begonnen. Mal sehen was dabei rauskommt...