From 27041ac422f6cf86414fed6ed3c0b0287abc19cf Mon Sep 17 00:00:00 2001 From: Benjamin Koch <bbbsnowball@gmail.com> Date: Fri, 21 Apr 2023 07:42:17 +0200 Subject: [PATCH] =?UTF-8?q?add=20"Zus=C3=A4tzliche=20Nutzung"=20to=20READM?= =?UTF-8?q?E?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Notizen.md | 6 ++++++ README.md | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 54 insertions(+) diff --git a/Notizen.md b/Notizen.md index bda4144..4d3703e 100644 --- a/Notizen.md +++ b/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) diff --git a/README.md b/README.md index d5df8b3..ad9c220 100644 --- a/README.md +++ b/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 ========= -- GitLab