FHEM Zentrale im 19" Baugruppenträger

Begonnen von tante ju, 06 Januar 2017, 00:07:19

Vorheriges Thema - Nächstes Thema

tante ju

Hier möchte ich mal kurz mein Projekt beschreiben, den FHEM-Rechner in eine etwas professionellere Bauform zu bringen.

Als ich vor Jahren mit FHEM anfing, habe ich "mal eben" einen Raspberry genommen, der in einem schicken kleinen Gehäuse steckte und irgendwo im Rack platziert wurde. Ich denke, viele hier kennen das. Im Laufe der Zeit kamen dann Erweiterungen dazu, wie USB Sticks, I2C und Modbus über den GPIO, zusätzliche Spannungsversorgung und so weiter.

Das Ergebnis sieht man in Bild 1. So konnte das nicht weitergehen. Darüber hinaus musste noch was erweitert werden, diese ganzen USB Sticks nerven und auch an der Zuverlässigkeit musste ich was machen und auch Platz für Erweiterungen da sein, die sauber eingebaut werden können.

Also war mir relativ schnell klar, das muß in einen 19" Baugruppenträger mit Bussystem.

Die CPU
Der Markt für CPUs/Rechner im Eurokartenformat (100*160mm) ist überschaubar und ich habe nichts gefunden, was meinem Geschmack entspricht. Also kam eine Adapterplatine zum Einsatz, die in der ersten Version auch einen Raspberry 3 aufnimmt, welcher mit Flachbandkabel angeschlossen wird. Wenn ich die Version zwei baue (für weitere Entwicklungen brauche ich ein Zweitsystem, um nicht immer am "heißen" System basteln zu müssen), dann wird der Raspberry direkt auf eine Buchsenleiste auf der Adapterplatine gesteckt. Die Adapterplatine enthält neben dem Anschluß für den Raspberry, eine Kopie des GPIO-Steckers, für eventuelle Erweiterungen, ein EEPROM für automatische Erkennung und Konfiguration der Treiber im Raspbian (ID-EEPROM), RS485 Treiber, inklusive Richtungserkennung, für einen RS485-Bus, einen OIR (aka Hotplug) Treiber für I2C mit Pegelwandler und einen kleinen Prozessor am I2C, der die LED in der Frontplatte steuert und einen Watchdog enthält, der von FHEM gesteuert wird.
Auf den DIN41612 (VG64) Verbinder a+c liegen (fast) alle GPIO-Signale, der RS485 und der entkoppelte I2C-Bus, sowie 5V und 12V, die von einem Netzteil kommen.

Der I2C Pegelwandler und der RS485 sind da, um diese beiden Busse zu entkoppeln und Spannungen zu wandeln, damit egal, was da anliegt, der Pi nicht zerstört wird (gebranntes Kind). Das ID-EEPROM kam ja mit der HAT-Spezifikation des Pi und das erlaubt es, dem Pi automatisch zu sagen, daß er über die Adapterplatine eine leistungsfähige Spannungsversorgung bekommt und die USB darüber versorgen kann und GPIO17 als Eingang zu schalten ist (da hängt der Watchdog dran). So ist das nicht von irgendwelchen Software-Einstellungen abhängig. Der Watchdog treibt die Kontroll-LED in der Frontplatte und sendet, wenn FHEM nicht rechtzeitig ein Update schreibt, über GPIO17 ein Shutdown-Signal an den Pi. Über shutkey wird der dann neu gestartet. Ich habe diesen Weg gewählt, um sicherzustellen, daß auch der I2C Bus noch läuft, weil FHEM in der Vergangenheit bei Störungen am I2C Bus gerne mal komplett hängengeblieben ist.

Das Netzteil
Das Netzteil ist nichts dramatisches. Es ist ein Meanwell-Schaltnetzteil mit ausreichend Leistung, um den Pi über den GPIO-Slot mit 3A zu versorgen. Eine Platine hat einen Prozessor, der die Spannungen überwacht und nur bei richtiger Spannung Relais zur Versorgung der Busplatine (und der Module) einschaltet, damit nicht ein fehlerhaftes Netzteil alles zerstört. Natürlich lassen sich die Spannungen über I2C auslesen und die Grenzwerte einstellen. :-)

Die Busplatine
Eine Standard 42TE Busplatine 64 polig ist im Baugruppenträger eingebaut, mit 8 Steckplätzen.

RS485/serielle Erweiterungskarte
Auf den Bildern sieht man erstmal den Vorteil der Europakarten: Viel Platz. Ich habe auf einer Karte nur zwei Schnittstellen untergebracht, weil ich zur Zeit nicht mehr brauche und verschiedene Chip-Typen ausprobieren wollte. Also ist da ein I2C Buskoppler drauf, eine 3,3V Regelung aus der 5V Busversorgung (damit der schlappe Pi-Regler nicht benutzt werden muss), einmal ein MAX3107 I2C UART mit GPIOs (die ich nicht verwende), ein SC16IS741 I2C UART, jeweils ein RS485 Bustreiber und ein ATmega.
Der ATmega ist auch über I2C angesteuert und sollte eigentlich die Adressierung der UARTs steuern, damit man mehrere Karten ohne Jumper adressieren kann. Leider geht das für den SC16 nicht so wie gedacht, weswegen ich den Teil für weitere Karten überdenken muß. Darüber hinaus nimmt aber der ATmega auch die Interrupt-Leitungen der UARTs entgegen und man kann über I2C-Register einstellen, auf welchem GPIO die landen. So ist das flexibel den eigenen Ansprüchen anpassbar.
Ich habe die beiden UARTs genommen, weil beide über I2C einsetzbar sind und damit OIR fähig mit den Buskopplern (daß die Software noch kein OIR können, ist eine andere Sache) sind und beide können RS485.
Leider hat es mich einige Nächte gekostet, Fehler im SC16IS7xx Treiber zu fixen, bis es lief und für den MAX3107 musste ich die I2C-Unterstützung erst noch programmieren. Die ist im Standard-Kernel nicht drin. Laufen aber jetzt beide.
Die Stecker sind 4-polig, was mein persönlicher Modbus-Standard ist: 12V, B, A, GND.

Eingebaut
Am Ende sieht man das alles eingebaut und ich finde, das sieht doch wesentlich besser und robuster aus. Ein Einschub ist noch eine Festplatte, auf der das gesamte System läuft, damit die SD-Karten nicht verbraucht werden.

Jetzt kann ich auch wieder an das Rack ohne zu riskieren, daß der Raspberry neu bootet, weil der Mini-USB wieder wackelt und ich habe satt Platz, um weitere Module einzuschieben. Ich denke, ich werde mir noch einen Jeelink als Einschubkarte bauen, damit der auch vom USB-Anschluß wegkommt. Für Homematic bin ich mir noch nicht sicher.

Und darüber hinaus ist mit dem RPi 3 und dem System auf Festplatte und den speziellen RS485 UARTs das System sowas von schnell geworden, verglichen mit dem RPi B, eine wahre Wonne.