README.md

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.

Errata for V1.0

No fix needed

1. Varistor on 24V is more than fast enough but we could add a TVS in parallel for longer life span.
   • Fix if we ever have a dead varistor (or one that has significant leakage current).
2. WS2811 should have 33R series resistance.
   • We do have 27R, which should be close enough.
3. USB host mode might be useful.
   • It was left out because we didn't have enough current available at 5V when that was decided. If we keep that in the next revision, we could consider it again.
   • It might be useful for adding additional hardware but things like BLE and Zigbee are better added via SPI/I2C/UART, which should be easier (unless we have enough uses for low-speed USB to make a generic tunnel, e.g. as an USB-IP device on the other end).
   • What would be needed?
     • Pull CC lines high instead of low at the request of the MCU (needs another pin) but always pull them low by default (for the bootloader).
     • Supply VBUS at the request of the MCU (needs a pin but maybe the same one).
     • Current limit for VBUS, e.g. with PTC fuse.
   • Alternative: External adapter to USB-A that also provides power supply (e.g. using our 5V output on J1 pin 14, which is already fused for 500 mA).
   • Alternative: Attach device inside the case and use a different protocol (I2C/SPI/UART) or attach it to an existing Linux computer (if it doesn't have to run while the room is powered down).

Change for new revision (if we ever have one)

1. WS2811 should have 100R series resistance on VDD.
   • Datasheet sounds like this is optional for 5V so let's hope for the best.
   • Hotfix is unlikely for current PCB so backup plan is to remove the WS2811.
2. WS2812C-2020-V1 datasheet doesn't have the 33R series resistance but we maybe want to add it anyway.
3. Add DCDC to main PCB if we have the space.
   • We could use RT7272, which has an adjustable current limit. That way, we can use a smaller inductor but we will have less current available for external circuits (i.e. adjust the fuses, as well).
4. DCDC could support more current.
   • It was supposed to deliver up to 1.5 A but it only does that up to 20V of input voltage.
   • It can deliver 1 A until 29V of input voltage.
   • It would be good to have 1.5 A with a bit over 30V of input voltage.
   • If you try to draw more current, it will go into shutdown regularly. It gets rather hot so we assume that this is over-temp shutdown.
   • The test was with the bare board so it might be a bit better when it is connected to the main board. However, it will be in a closed case and the 3.3V LDO will generate additional heat so it might be even less.
   • Fix: Use a different DCDC (e.g. RT7272 with synchronous rectifier), add more thermal vias (especially for the diode), maybe thermally decouple the diode from the DCDC IC.
5. Buzzer could be louder.
   • Remove the 2k resistor because it isn't needed. That doesn't make much of a difference so we actually keep it for this batch. The difference is barely noticable when bridging it with a jumper wire.
   • Somehow make it louder, e.g. choose a different one or connect it to 5V.

Hotfix would be useful

1. RS485 common mode range goes from -7V to +12V but the TVS clamps it to -0.7V to 6V.