diff --git a/Notizen.md b/Notizen.md
index 27468a2dfd717b20b712a0d5aa2886a6926dc861..92b5c15ebb5eeb75f9194061606128b758f19aae 100644
--- a/Notizen.md
+++ b/Notizen.md
@@ -118,3 +118,13 @@
- Einziges Problem am INA2180 ist, dass 26V das Absolute Maximum sind. Das ist mir doch etwas knapp. Und wenn wir nur deshalb nicht die Spannung etwas
hoch drehen können, wäre schade.
+
+TODO und weitere Gedanken:
+- Auto-Discovery ginge auch einfach mit Broadcast und Backoff. Parameter wie Backoff Slots und die Wahrscheinlichkeit überhaupt zu antworten stehen mit in dem
+ Broadcast. Es gibt eine maximale Zeit und nach der darf nicht mehr geantwortet werden, damit wieder normale Kommunikation möglich ist. Man setzt ein Flag im
+ Device für "ich kenne dich schon". Das deaktiviert Reaktion auf den Broadcast (ggf optional per Flag in dem Broadcast) und erlaubt dem zentralen Controller
+ einen Reset des Geräts festzustellen.
+- Spulen mit rein zum Motor für langsamere Anstiegszeit / EMV Abstrahlung auf der Zuleitung?
+- WS2812 runter und einfach zwei LEDs mit an den WS2811 - reicht für Debug.
+- Auf den freien Pin 5V legen, aber über Widerstand oder PTC-Sicherung.
+
diff --git a/README.md b/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..06f28d33a596a2bc8d803dc5e9e8f18427e34633
--- /dev/null
+++ b/README.md
@@ -0,0 +1,50 @@
+Heizungssteuerung für den Subraum
+=================================
+
+Jede Heizung bekommt eine von diesen Platinen. Die adaptiert einen Wachsmotor-Stellantrieb
+auf RS485. Die Steuerung läuft im Keller auf einem Linux, z.B. auf vogon.
+
+- Im Prinzip kann die Platine auch zwei Heizungen, aber ich würde lieber die Kabel kurz halten
+ und mehr Platinen verbauen. Am besten in Reichweite von dem Kabel, was am Aktor schon dran ist.
+- Als Gehäuse eine [Aufputz-Verbindungsdose](https://www.spelsberg.de/verbindungsdosen/innenbereich-bis-252/33291201/).
+- Als Protokoll über RS485 z.B. was in der Art von Modbus RTU, aber möglichst einfach halten. Adressvergabe per Taster
+ auf der Platine und dann im Flash speichern, also z.B. Broadcast mit "Setze Adresse x, wenn gerade dein Taster gedrückt ist".
+- RP2040 (Raspberry Pico) als MCU, weil der ist sinnvoller bezüglich Preis und Programmierbarkeit (siehe [Notizen.md](./Notizen.md)).
+- Zusatzfeatures:
+ - WS2811-Repeater (d.h. ein WS2811 mit auf der Platine), da wahrscheinlich eine Ader im Kabel noch frei ist.
+ - 2x Heizung
+ - 4x Fensterkontakt (oder sonstiger Digital-Eingang)
+ - 2x 5V Digital-Ausgang für z.B. I2C, WS2812, DS18B20.
+ - Sofern wir keine anderen Temperatursensoren verbauen, sollten wir 1-3 DS18B20 pro Raum einplanen.
+ - 1x Analog-Eingang
+- Verkabelung zum Rack durch ein dediziertes Netzwerkkabel (d.h. vom RJ45 trennen oder Adapter festkleben) oder ein neues
+ Kabel legen (eher nicht). Eventuell gibt's schon eins für DMX, wo das noch mit rein kann.
+- Anschluss im Gehäuse mit Federzugklemmen. Kabel kommen von oben rein und werden unten angeschlossen, damit genug Luft zum
+ Einführen ist. Fast jede Ader hat eine dedizierte Klemme - nur die Power-Pärchen innerhalb eines Kabels brauchen eine
+ Doppel-Aderendhülse. Keine Wago o.ä. zum Weiterverbinden nötig.
+- Vorteil gegenüber Kabeln zu einer zentralen Steuerung:
+ - Weniger Kabel (aber nicht so viel weniger, dass das alleine zu kleineren Gesamtkosten führt)
+ - Einfacher anzubringen (finde ich) und wir brauchen nirgendwo eine Box für eine Zentrale.
+ - Bidirektionale Kommunikation, d.h. Kabelbruch ist einfacher zu debuggen.
+ - Strom wird gemessen, d.h. wir können das intelligent steuern.
+ - Zentrales Netzteil muss nur den Dauerstrom plus x abkönnen statt den Einschaltstrom pro Heizung.
+ - Eventuell können wir die Dauer-Leistung noch reduzieren durch PWM.
+ - Das könnte man natürlich auch mit zentraler Steuerung machen, aber nicht toll, wenn die ein Pi mit Relais-Board ist
+ oder sonstiges aus ein paar wenigen, fertigen Teilen zusammengestecktes.
+ - Sinnvolle Auslegung bezüglich EMV (Einstrahlung und Abstrahlung) - zumindest ist das der Plan.
+ - Zusatzfunktionen ohne weitere Kabel zur Zentrale, z.B. Fensterkontakte. Auch für weitere Projekte, solange sie sich
+ an ein paar Spielregeln halten.
+ - High-Level Teil kann in einem Linux passieren und das ohne ESP32 als Adapter auf LAN/WLAN, ohne Funk und ohne zusätzlichen Pi.
+ - Heizung im Keller kann mit dran, was man bei einer Steuerung pro Raum vermutlich eher weglässt.
+- Nachteil:
+ - Kosten für die Platine sind pro Heizung statt einmal pro Raum.
+ - Zwar weniger Kabel, aber die müssen den Strom für alle Heizungen abkönnen.
+ - Initial mehr Aufwand (den aber zum großen Teil snowball übernimmt).
+ - Ich finde es so einfacher zu pflegen, aber man kann auch argumentieren, dass es komplizierter ist.
+ - Ersatzteil-Management: Wir werden direkt einige mehr bestellen wollen, weil wer weiß, welche Bauteile fehlen, wenn man
+ in ein paar Jahren Ersatz braucht. Wir brauchen 14, aber bezüglich Bauteil-Preisen dürfte 30 sinnvoll sein.
+
+
+
+
+
diff --git a/img/PCB.png b/img/PCB.png
new file mode 100644
index 0000000000000000000000000000000000000000..d4ae9c3a59719cfff3d3d4b855ff3a24b862d62c
Binary files /dev/null and b/img/PCB.png differ
diff --git a/img/PCB_3D.png b/img/PCB_3D.png
new file mode 100644
index 0000000000000000000000000000000000000000..55573b38c61baf3cb663efc154f1c675ddb61453
Binary files /dev/null and b/img/PCB_3D.png differ
diff --git a/img/csm_33291201_V1_0629111c9b.webp b/img/csm_33291201_V1_0629111c9b.webp
new file mode 100644
index 0000000000000000000000000000000000000000..3736cc5a58d34f81743ae5b185c2479ae8f8a0b2
Binary files /dev/null and b/img/csm_33291201_V1_0629111c9b.webp differ