add "Zusätzliche Nutzung" to README

Notizen.md

@@ -490,6 +490,12 @@ TODO und weitere Gedanken:
 
 - LDO für 3.3V ist nicht mehr verfügbar.
 - Subraum-Logos?
+- Rotation der Komponenten bei JLC checken und ggf anpassen
+  https://github.com/INTI-CMNB/KiBot#notes-about-the-position-file
+- Bei den Dingen mit Offset bei JLC (Wannenstecker, Stiftleisten) ein eigenes Package machen, wenn ich nix besseres finde.
+
+- Bekomme ich den KF250T doch in 3D? Angeblich kann KiBot das von EasyEDA laden (aber ggf nur für Blender)?
+  https://github.com/INTI-CMNB/KiBot#lcscjlcpcbeasyeda-3d-models
 
 - Von LCSC separat bestellen:
   - KF250T (weil bei JLCPCB nicht genug verfügbar und ist sinnvoll, die Platine erst zu testen)

README.md

@@ -120,6 +120,54 @@ e.g. with suitable slots in the case instead of making a complete hole for the b
 how well touch is working.
 
 
+Zusätzliche Nutzung
+===================
+
+- Existierendes UI benutzen:
+  - Animationen auf den LEDs abspielen, wenn es grad keiner nutzt. Ebenso mit dem Display. Es muss natürlich in den normalen Modus
+    schalten, sobald eine Taste gedrückt wird oder Touch-Event. Und evtl wollen wir schon die meiste Zeit die Temperatur anzeigen,
+    aber die Ringclocks können ja auch Animationen und zeigen trotzdem meist die Zeit an. Das sollte sozial zu klären sein.
+  - Display und Touch können noch weitere Dinge mit steuern. Wie man das so umsetzt, dass es praktikabel ist, wäre zu klären
+    (also z.B. keine ewig tiefen Menüs für Dinge, die mit dem SPS Display angenehmer gehen würden).
+  - Ich fände es sinnvoll, für so Dinge ein API über MQTT und UDP oder so bereitzustellen. Details müsste man sich noch überlegen.
+- Platinen semi-dauerhaft "ausleihen":
+  - Wir werden 30pcs bestellen, aber nur 10-14pcs brauchen. Der Rest kann anderweitig genutzt werden, solange sie als Ersatzteile
+    erhalten bleiben. Das gleiche gilt für die Display-Platinen, von denen wir 10pcs bestellen.
+  - TODO: Spezifizieren, welche Modifikationen ok sind, z.B. welche Lötjumper gesetzt werden dürfen, ohne dass man das später
+    rückgängig machen muss.
+  - Firmware ersetzen ist ok, weil wir haben absichtlich MCUs, die ohne spezielle Hardware programmierbar sind.
+- Auch die für die Heizung genutzten haben noch Kapazitäten für weitere Nutzung:
+  - Siehe oben für mehr Details zu den verfügbaren Pins und siehe Schaltplan für kreative Nutzung abseits des offensichtlichen,
+    z.B. die Digitaleingänge als Ausgang nutzen.
+  - 3 IOs komplett ungenutzt (aber Beschaltung beachten), z.B. WS2812, DS18B20 oder I2C
+  - 4x Reed-Eingang, wenn nicht für Fenster genutzt.
+  - Der Wannenstecker kann im Prinzip genutzt werden, wenn kein Display dran hängt, aber nicht nach draußen legen, weil da ist
+    keine Schutzbeschaltung dran. Wenn du das vorhast, nimm bitte ein dediziertes Board. Wenn ein Display dran ist, kann man nur
+    noch was mit an den I2C hängen, aber dafür ist dann kein Stecker vorgesehen.
+  - Firmware muss bleiben, aber wir können Features in der allgemeinen Firmware ergänzen. Der Plan ist, dass man per Modbus-Register
+    umstellen kann, welche Features aktiv sind.
+  - Im Zweifel bitte vorher nachfragen. Bitte nichts ins Gehäuse einbauen, ohne das abzusprechen!
+- WS2812-Signal: Es war noch eine Leitung frei.
+  - An sich ist es für die Heizungen komplett ungenutzt und die fungieren nur als Repeater.
+  - Für wenige LEDs kann das erste Heizungsboard den WS2812 bespaßen. Wenn mehr Datenrate gebraucht wird, kann man einen ESP32 o.ä.
+    pro Raum deployen. Da wäre ganz gut, wenn der ein API im Netzwerk bereitstellt, falls wir den WS2812-Ring für Auto-Discovery Dinge
+    mitnutzen wollen. Und umgekehrt können wir discovern, wie viele LEDs zwischen den Boards hängen. An sich ist der WS2812 aber
+    erstmal unabhängig vom RS485.
+- Weitere Bus-Teilnehmer: Der RS485 Bus kann bis zu 32 Teilnehmer (weil darüber die Transceiver teuer werden). Solange du dich an 
+  in paar Spielregeln hältst, kannst du dich mit dran hängen.
+  - TODO: Spielregeln definieren, z.B. sinnvoller Transceiver, Doku zu Adresse und wo (z.B. Wiki), Sicherung wenn mit an den 24V dran,
+    Protokoll (sehr kleines Modbus Subset ist ausreichend; nur reden wenn gefragt), keine Stichleitungen, was sonst noch beachten beim
+    Anschließen (z.B. 24V ausmachen und wie klemmt man sich an, z.B. Wago)
+  - RS485 kann man mit jedem UART sprechen. Manche können den zusätzlichen Enable-Pin selbst steuern, aber wenn der MCU halbwegs
+    schnelle Interrupts hat, geht das normalerweise auch über einen GPIO (z.B. vollkommen problemlos auch mit ATmega).
+  - Die zentrale Steuerung wird voraussichtlich in Python geschrieben sein und auf vogon laufen, d.h. kann ergänzt werden. Sie sollte
+    aber auch ein API bereitstellen, damit man einfach von anderer Software aus mit Geräten am RS485 Bus reden kann.
+- Weitere Busse: Ein Netzwerkkabel hat 4 Pärchen und wir brauchen erstmal eins. Da kann nebenbei noch DMX oder differentielles WS2812
+  mit drauf. Oder ein weiterer RS485, wenn es Bedarf gibt (z.B. mehr Baudrate und dafür weniger zuverlässig oder weil wir die 31+1
+  Teilnehmer aufgebraucht haben). Einzige Bedingung wären, die anderen Signale nicht stören (d.h. differentielles Signal nutzen) und
+  im Wiki dokumentieren (und falls es auch an vogon dran soll und in den gleichen Container, dann da an die Spielregeln halten).
+
+
 Sonstiges
 =========