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.
• 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).
• 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.
    • Wir müssen mal schauen, ob es realistisch ist, einfach mal 5pcs zum Testen zu bestellen oder ob wir direkt all-in gehen.
    • Bei gekauften Platinen hat man zwar im Prinzip das gleiche Problem und ob man was von Ali in 5 Jahren noch so bekommt ist doch sehr fraglich. Aber bei großer Box mit vielen Jumper-Wires fliegend verdrahtet wird man schon was anderes finden, was gut genug passt.
    • Das ist aber immer noch besser als Custom-Platinen für zentrale Steuerung, weil bei vielen gleichen kann man welche auf Lager haben und einfach tauschen. Es ist halt wirklich nur diese Platine und der USB-RS485 und nicht noch weitere ESP32 oder Raspi oder so, die ebenfalls kaputtgehen könnten.

Main PCB

RP2040 microcontroller (like Raspberry Pico), power supply, terminal block and most of the functions.

FIXME: export PDF of schematic (unfortunately, KiBot only exports the first page)

PDF with rendering of PCB layers

Anschlussklemmen: Es gibt leider kein Bild in richtig herum. Man kippe sie im Kopf um 90 Grad nach links-oben und die Kabel kommen dann von links-oben.

DCDC PCB

Da ich es zunächst mit LDO ausgelegt habe, aber der nicht genug Verlustleistung abkann, gibt es jetzt als Workaround dieses Aufsteckboard als Spannungswandler. Denkt euch die Stiftleisten weg. Dort sind Stiftleisten auf dem Haupt-Board und an denen wird es festgelötet (oder mit Buchsenleisten gesteckt). Die oberen beiden sind nur mechanisch:

FIXME: export PDF of schematic (unfortunately, KiBot only exports the first page)

PDF with rendering of PCB layers

Display PCB

Some of the boards will also get a user interface, e.g. when there is a radiator in a good location for that. We should probably also have at least one dedicated control board for each room in a central location (i.e. most likely not near a radiator).

The hole in the middle will be filled by one of those small, cheap OLED boards:

The OLED and four buttons are the "fallback" user interface. We can make this reasonably useful by providing shortcut actions, e.g. long press on left/right button to set room temperature to 17 resp. 21 °C.

There is a ring of touch areas and a ring of LEDs around the display. If they work as expected, they will be the main user interface: Double-tap a temperature of your choice to set it and the LEDs will be used to display set point and actual value. There will be some text and graphics on the case, e.g. an adhesive label with lines for the sector and temperature values printed on it.

The display PCB has an additional temperature sensor on the outside so it should provide a reasonable estimate of room temperature when it is placed in a central location between hand and eye level.

FIXME: export PDF of schematic (unfortunately, KiBot only exports the first page)

PDF with rendering of PCB layers

We plan to mill holes in the case for LEDs, fasteners, buttons and the display. The outlines are on layer User.4 and that is exported to DXF by KiBot. If touch is working, we should get the board as close to the case as possible (best would be below 0.3 mm but that's not realistic here). If not, we may want to add some spacers and reduce the hole for the display to only the active area. Best case would be that we have the best of both, i.e. touch is working and we can add some small spaces between display PCB and OLED board so we can make the hole small anyway. In either case, we may want to think about a thin layer of transparent PMMA. ahorn would like to have the buttons actuated via a piece of plastic, e.g. with suitable slots in the case instead of making a complete hole for the buttons. We will evaluate this further when we know 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

• PCBA:
  • https://support.jlcpcb.com/article/84-how-to-generate-the-bom-and-centroid-file-from-kicad
  • change header line in CPL to: Designator,Val,Package,Mid X,Mid Y,Rotation,Layer
  • There is more to do, e.g. rotate components to match JLC's expectations.
  • Use KiBot to make it reproducible: nix develop -c time kibot
  • You can use the script generate-pcb-outputs.sh to run KiBot for all PCBs.