Custom UPS Gen6

Der normale Betrieb der UPS Gen6 war mehr oder weniger unspektakulär. Die Probleme fingen erst an, als ich beschlossen hatte, den Raspberry Pi 3B+ nicht mehr unter Debian laufen zu lassen, sondern HAOS (Home Assistant Operating System) als Betriebssystem zu verwenden.

Den Ausschlag dazu gab die Idee, die Phasenumschaltung der Keba Wallbox P30 nicht ecvv zu überlassen, sondern mittels HA Skript zu steuern. Für diese Entscheidung gibt es handfeste Gründe. Evcc unterstützt zwar prinzipiell die Umschaltung der Phasen von 1 nach 3 und umgekehrt, aber die Entwickler weigern sich standhaft, die dabei notwendigen Pausen einzuhalten. In Folge geht der Capri in Störung und muss mittels Stecker ziehen/stecken wieder zur Räson gebracht werden. Der Klassiker dabei: Evcc sagt, die Zeiten müssen von der Wallbox automatisch eingehalten werden, Keba sagt, dafür ist eindeutig der Controller, also evcc zuständig. Deadlock.

Also mache ich es selbst und nutze dafür Home Assistant (HA).

Die Steuerung der Phasen war relativ schnell erledigt, dann ging es an den Einsatz der UPS in Verbindung mit dem HAOS RPi...

Damit HA auf I2C Slaves zugreifen kann, muss ein bisschen im Getriebe des Betriebssystems gerührt werden, denn solche Hardwarezugriffe werden von HAOS einfach erst mal unterbunden. Als der Zugang klappte, hat die UPS plötzlich die Zusammenarbeit verweigert und nicht mehr auf Zugriffe reagiert. Ein paar Versuche später ließ sie sich auch nicht mehr in den OTA Modus versetzen -> gebrickt - Mist!

Meine Versuche, den Hersteller zu einer kulanten Regelung im Sinne von rettenden Binaries oder nur dem notwendigen Bootloader zu überreden, scheitern an NDAs (non disclosure agreement) mit dem Chiphersteller des auf der UPS verwendeten Controllers IP5389 und sonstigen Hinderungsgründen.

Eine wohl noch funktionierende UPS Hardware auf dem Tisch liegen haben und keine Firmware dafür zu bekommen kann ich nicht ausstehen, also habe ich mich dazu durch gerungen, die Firmware in Eigenregie nachzubauen (unterstützt von Gemini).

Die nächsten Tage habe ich mit dem Durchgangsprüfer, einer Kopflupe auf der Stirn und einem elektronischen Mikroskop in der Hand verbracht. Da die Platine der UPS mindestens 4-lagig aufgebaut ist, sind Signale teilweise an einem Via in der Innenlage verschwunden, Raten ist angesagt. Gemini hat mich tapfer immer wieder mit Testprogrammen versorgt, die ein spezielles Signal wackeln ließen, so dass mit dem Oszilloskop Signalverfolgung möglich war. So ist sukzessive das Grundgerüst der Firmware entstanden.

Eine Konversation mit dem Chefentwickler bei 52PI, dem Hersteller der UPS Gen6, hat mich in eine Sackgasse geschickt und ich habe aufgrund einer Andeutung, woher der STM32F411 die Daten des IP5389 bekommt, eine halbe Woche lang vergeblich versucht, die I2C Verbindung zwischen dem IP5389 und dem STM32 herzustellen. “Geholfen” hat dabei eine Application Note von Injoinic (Hersteller des IP5389) in der beschrieben wird, mit welchem Voodoo man den Chip dazu überreden kann, die LED Pins temporär auf I2C umzuschalten. Nach gefühlt 200 Versuchen per Programm und Kontrollmessungen an einer zwischenzeitlich gekauften zweiten UPS Gen6 war dann endlich klar: Die von 52PI eingesetzte Variante des IP5389 hat definitiv kein I2C Interface. Der Chip kommuniziert nicht mit dem STM32, liefert keine Daten und wird nicht gesteuert sondern arbeitet mehr oder weniger unabhängig als intelligenter Powerbank Controller. Die einzige mögliche Interaktion zwischen STM32 und IP5389 erfolgt über den KEY Eingang des IP5389. Hierüber kann der STM32 den IP5389 stoppen und starten.

Untermauert wird diese Erkenntnis durch die Tatsache, dass ziemlich alle Parameter, die den Betrieb der UPS als Solche ermöglichen - im wesentlichen Spannungen und Ströme der verschiedenen Ein- und Ausgänge - mit dedizierten Sensoren (INA219, INA138) oder Widerstandsnetzwerken an den STM32 heran geführt werden.

Das Original der UPS hat noch ein paar Gimmicks an Bord, die mich nicht interessieren. Dazu gehört ein minimalistischer Python Interpreter, der es dem Nutzer erlaubt, eigene Skripte auf dem STM32 auszuführen. Mir war nur wichtig, alle Register des Originals mit Leben zu erfüllen, so dass die von 52PI zur Verfügung gestellten Skripte und Programme auch mit meiner custom Firmware ordentlich zusammen arbeiten.

Da der Programmierzugang zum STM32 über einen 10-poligen FFC-Sockel erfolgt, der neben GND, 3,3 V und 5 V noch den UART des STM und ein paar IOs zur Verfügung stellt, habe ich als Gimmick ein OLED Display und als echten Mehrwert eine PWM Ansteuerung eines Lüfters, z.B. Noctua NF-A9 5V PWM, zusätzlich implementiert.