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.

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.

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:

Und das ist das optionale Display-Board:

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