Klimatechnik / Industrie
Mollier h,x
Klimatechnik in der Hand der Ingenieure
In zwei Monaten brachten wir das Mollier h,x-Diagramm für robatherm auf iOS und Android in den Markt. Anschließend haben wir App und Backend über zehn Jahre betreut und betrieben. Eine Lebensspanne im AppStore vom 17. Februar 2013 bis zum 30. Juni 2023, mit ehrlichem End-of-Life statt Festhalten aus Tradition.
Zeitraum
2013 - 2023
Rolle
Konzept, Entwicklung, Betrieb
Stack
6 Komponenten
Ausgangslage
Warum eine App für ein 100 Jahre altes Diagramm?
Das Mollier h,x-Diagramm ist seit den 1920er-Jahren das Standardwerkzeug der Klima- und Lüftungstechnik. Es zeigt den thermodynamischen Zustand feuchter Luft und bildet die Grundlage jeder Berechnung in der Raumlufttechnik. robatherm hatte eine etablierte Windows-Anwendung dafür, doch Vertrieb, Engineering und Kundengespräche fanden längst auf der Baustelle, beim Architekten oder im Meeting statt. Gefragt war ein mobiles Pendant, das nicht „auch noch“ funktioniert, sondern in der Werkzeugkiste der Ingenieure ankommt.
Abgrenzung
Windows-Tool vs. Mollier h,x App
| Windows-Anwendung | Mollier h,x App |
|---|---|
| Nur am Schreibtisch verfügbar | iOS und Android, überall einsatzbereit |
| Diagramme bleiben lokal | Synchronisation zwischen Geräten über REST-Backend |
| Wetterdaten manuell pflegen | 280+ Klimadatensätze (IWEC, RMY, deutsche Klimazonen) |
| Eingaben ohne Live-Vorschau | Visualisierung von Luftströmen, Zustandsänderungen, Behaglichkeitsfeld |
| Tool für Engineering | Tool für Engineering, Vertrieb und Kundenpräsentation |
Vorgehen
Vier Phasen über zehn Jahre
Spezifikation & Backend
REST-API in vier Iterationen entworfen (Februar bis August 2013): Benutzer, Diagramme, Login, Wetterdaten. Java/Tomcat-Service mit Jersey JAX-RS und JAXB, MySQL über JNDI-DataSource. Zusätzlich ein Mitarbeiter-Backoffice mit ZK Framework für die Pflege von Wetter- und Userdaten.
Mobile-Clients
iOS-Client zunächst in Objective-C mit CorePlot für die Diagramm-Darstellung, AppStore-Release am 17. Februar 2013. Anschließend Android-Pendant in Java mit AndroidX und dataBinding-MVVM. Auf Android entstand eine eigene Renderer-Klasse auf Canvas-Basis, weil keine Library die Mollier-Spezifika abbildete. Synchronisation zwischen den Plattformen über das gemeinsame REST-Backend.
Modernisierung 2017
Vollständige Portierung des iOS-Clients von Objective-C auf Swift, Update auf XCode 9 mit CorePlot 2.3. Die Backend-Architektur bleibt unverändert, das REST-Interface ist abwärtskompatibel. Die App profitiert von den neuen iOS-Features ohne Bruch in der Datenhaltung.
Betrieb & End-of-Life
Über neun Jahre kontinuierlicher Betrieb des Backends. Let's Encrypt mit acme_tiny für die automatisierte Zertifikatserneuerung, regelmäßige MySQL-Dumps, Pflege der Wetterdaten. Kontrollierte Einstellung der App im AppStore am 30. Juni 2023, gemeinsam mit dem Kunden entschieden.
Architektur
Drei Clients, ein Backend
Zwei native Apps und ein Mitarbeiter-Backoffice teilen sich denselben REST-Service. Die Geschäftslogik liegt zentral, die Plattform-spezifische UX bleibt erhalten.
Tech Stack
Schlüsselentscheidungen
Cross-Plattform durch REST-Backend
Statt einer plattformübergreifenden UI-Lösung wurden zwei native Apps gebaut, die sich denselben REST-Service teilen. Die Wartung der Geschäftslogik konzentriert sich auf eine Stelle, die plattformspezifische UX bleibt erhalten.
Objective-C zuerst, Swift später
Zum Marktstart 2013 war Swift noch nicht produktionsreif. Der erste iOS-Client lief mit Objective-C stabil im Markt. Der Wechsel auf Swift kam mit dem 2.0-Update 2017, als die Sprache reif war und das Toolchain-Update sich rechnete.
Eigener Diagramm-Renderer auf Android
Auf Android gab es keine Charting-Library, die das Mollier h,x-Diagramm mit Behaglichkeitsfeld, Luftströmen und Zustandsänderungen abbilden konnte. Wir haben einen eigenen Renderer auf Android-Canvas-Basis gebaut und ihn per Strategy-Pattern für Display und PDF-Generierung (iText) wiederverwendet.
Offline-first auf beiden Plattformen
Beide Apps speichern alle Diagramme lokal: Android via ORMLite in SQLite, iOS via Core Data. Die Synchronisation zum Backend läuft auf Android über Retrofit und RxJava, auf iOS über die nativen Netzwerk-APIs. So bleibt die App auf Baustelle und im Funkloch voll bedienbar.
REST mit XML statt JSON
XML war zur Konzeptionszeit das Austauschformat der bestehenden Windows-Software. So blieb die mobile Lösung kompatibel, ohne eine zweite Datenpipeline aufbauen zu müssen. Auf Android übernimmt XStream das Marshalling, auf iOS SwiftyXML, im Backend JAXB.
Eigenes Backend statt Cloud
Volle Datenhoheit für Kunden- und Diagrammdaten und volle Kontrolle über Verfügbarkeit und Patches. Der eigene Server lief über die gesamten zehn Jahre stabil mit minimalem Wartungsaufwand.
ZK Framework für das Backoffice
Für die Mitarbeiter-Oberfläche zur Pflege von Wetterdaten und Usern haben wir ein etabliertes Java-Web-Framework verwendet, statt ein zweites Frontend-Projekt aufzusetzen. Das Backoffice ist Teil des Tomcat-Deployments und nutzt denselben REST-Service.
DAO-Pattern statt ORM
Schlanke Klassenstruktur, schnelle SQL-Kontrolle und keine ORM-Magie zwischen Code und Datenbank. Das Schema bleibt vorhersehbar, Migrationen sind einfach.
Let's Encrypt mit acme_tiny
Kostenfreie automatisierte TLS-Erneuerung über ein schlankes Python-Skript. Über Jahre hinweg kein manueller Eingriff für Zertifikatswechsel nötig.
Funktionen
Was die App in der Hand des Ingenieurs konnte
Vom interaktiven Mollier-Diagramm über fachspezifische Zustandsänderungen bis zum PDF-Export für Kundengespräche. Alles auf dem Gerät, alles synchronisiert.
Interaktives Mollier-Diagramm
Das vollständige h,x-Diagramm mit Behaglichkeitsfeld, Luftströmen und Zustandsänderungen. Live auf dem Gerät bedienbar.
Fachspezifische Zustandsänderungen
Erhitzen, adiabatisches und isothermes Befeuchten, Kühlen, Kühltrocknen sowie Rotor-Operationen für Trocknung und Wärme-/Feuchteübertragung.
Wetterdaten als Karte
Über 280 Klimadatensätze weltweit als Pins auf der Karte. Auswahl per Tipp statt Suche in einer Liste.
PDF-Export für Kundengespräche
PDF-Generierung direkt auf dem Gerät, auf Android über iText, auf iOS über die nativen Plattform-APIs. Inklusive Metadaten, Wertetabelle und Versand per E-Mail oder Druck.
Betrieb & Verlässlichkeit
Was zehn Jahre Betrieb möglich gemacht hat
Stabiler Backend-Betrieb
- Über neun Jahre kontinuierlicher Backend-Betrieb (2014 bis 2023) mit minimalem Wartungsaufwand
- Eigene Server-Infrastruktur mit Tomcat hinter HTTPS, kein Drittanbieter-Cloud-Speicher
- Datei-Upload für Wetterdaten im UWF-Format direkt aus dem Backoffice einspielbar
- Mehrsprachiges Datenmodell für Wetterstationen mit Bezeichnungen in DE, EN und FR
Zugriffsschutz & TLS
- Login/Password-Header für alle datenrelevanten Endpunkte
- E-Mail-Bestätigung bei der Benutzerregistrierung über JavaMail
- Vollständige HTTPS-Abwicklung über Let's Encrypt mit automatisierter Zertifikatserneuerung (acme_tiny)
Datensicherung & Versionierung
- Regelmäßige MySQL-Dumps zur Sicherung der Diagramm- und Userdaten
- log4j-Logging auf dem Server für Nachvollziehbarkeit von Zugriffen und Fehlern
- SVN-Versionskontrolle für Backend-Code und Konfiguration
Ergebnis
Was Mollier h,x geleistet hat
- ✓AppStore-Live am 17. Februar 2013, kontrolliert eingestellt am 30. Juni 2023, also über zehn Jahre Lebenszeit
- ✓Verfügbar auf iOS und Android mit synchronisierten Diagrammen zwischen den Geräten und der Windows-Anwendung
- ✓Über 280 Wetterstationen weltweit (IWEC, RMY, deutsche Klimazonen) als Datenbasis für Berechnungen
- ✓Mehrere Major-Releases, davon ein vollständiges Framework-Update auf Swift mit CorePlot 2.3 im Jahr 2017
- ✓Backend, Hosting, TLS und Domain-Verwaltung über die gesamte Lebensdauer durch tarienna verantwortet
- ✓Kontrollierte Einstellung im Einvernehmen mit dem Kunden, nachdem die strategischen Voraussetzungen für die nächste Entwicklungsstufe nicht zustande kamen
Lessons Learned
Drei ehrliche Erkenntnisse
Erkenntnis 1
Industrie-Software lebt von Verlässlichkeit, nicht von Trends.
Über zehn Jahre stabiler Backend-Betrieb mit konservativem Stack (REST, Jersey, MySQL, Tomcat) zeigen, dass eine bewährte Architektur ein Vielfaches an Lebensdauer erreicht als jeder Hype-Stack. Wir hätten 2013 auch auf experimentelle Datenhaltung und WebSockets setzen können. Beides hätte uns 2023 mehr Aufwand gekostet als gebracht.
Erkenntnis 2
Cross-Plattform geht am besten über das Backend.
Zwei native Apps mit gemeinsamem REST-Service waren langfristig pflegeleichter als jede plattformübergreifende UI-Lösung. Die Plattform-spezifische UX bleibt erhalten, die Geschäftslogik liegt zentral. Wartung und Erweiterung passieren an einer Stelle, nicht parallel auf zwei Stacks.
Erkenntnis 3
Wo eine App organisatorisch verortet ist, entscheidet über ihren Erfolg.
Mollier h,x war beim Kunden im Marketing aufgehängt. Damit blieb sie ein Vertriebstool, obwohl die nächsten naheliegenden Schritte (Integration in Klimageräte und IoT, Anbindung an Service-Prozesse) Engineering, Produktmanagement und Service gebraucht hätten. Diese Brücken haben wir trotz Anstoß nicht bauen können. Die ehrliche Konsequenz war 2023 die Einstellung der App, gemeinsam mit dem Kunden entschieden. End-of-Life ist Teil eines verantwortlichen Produkt-Lebenszyklus, kein Versagen.
Auch dein Werkzeug verdient eine zweite Plattform?
Lass uns sprechen. Wir bauen mit dir gemeinsam, was zu deinem Geschäft passt, und betreiben es so lange, wie es dir nutzt.