Ich glaube, man muss das Thema etwas breiter betrachten.
Wenn ein Hersteller ein neues System wie HEMS2 als neue Update- und Steuerungsplattform aufbaut, ist das meistens keine kurzfristige Entscheidung. So etwas bindet viele Ressourcen, kostet Geld und wird in der Regel Monate vorher geplant. Häufig steckt dahinter nicht nur ein neues Feature, sondern eine veränderte Architektur: neue Middleware, neue Serverlogik, neue Schnittstellen, andere Kommunikationswege zwischen App, Cloud und Geräten oder ein anderes Regelungskonzept.
Wenn sich die Architektur so stark ändert, ist es oft kein einfacher Patch mehr innerhalb von HEMS1, sondern eher eine neue Hauptversion beziehungsweise eine neue Plattform. Falls bestimmte Produkte, Funktionen oder Schnittstellen in HEMS1 bereits technisch veraltet waren oder nicht mehr zu den neuen Anforderungen passten, gibt es manchmal auch keinen einfachen Weg zurück. Ein Rollback klingt von außen oft simpel, kann aber in der Praxis schwierig sein, wenn App, Cloud, Firmware und Gerätezustände bereits auf die neue Plattform ausgerichtet sind.
Dazu kommt: Moderne Cloud- und Update-Plattformen sind extrem komplex geworden. Es reicht heute oft nicht mehr, nur die Anwendungslogik zu entwickeln. Am Ende läuft diese Software auf einer Betriebsplattform, die selbst wieder viele Abhängigkeiten hat: Infrastruktur, Container, Datenbanken, Netzwerke, Monitoring, Authentifizierung, Lastverteilung, Skalierung und Deployment-Prozesse. Bei Kubernetes-basierten Systemen werden im Deployment, zum Beispiel über Helm Charts, auch Dinge wie CPU, Arbeitsspeicher, Netzwerkverhalten, Timeouts, Skalierung und Healthchecks definiert. Wenn diese Betriebsparameter nicht zur Software passen, kann ein Feature im Test korrekt wirken, im realen Betrieb aber trotzdem instabil laufen.
Bei einem Energiesystem kommt noch eine weitere Ebene dazu. Die Software muss nicht nur technisch deploybar sein, sondern auch mit realen physikalischen Zuständen umgehen: PV-Leistung, Speicherstand, Netzbezug, Einspeisung, Regelgeschwindigkeit, unterschiedliche Hardwaregenerationen und verschiedene Länderprofile. Das ist deutlich anspruchsvoller als eine normale App-Funktion.
Bei vielen Herstellern wird Entwicklungsarbeit außerdem teilweise außerhalb der EU vergeben. Das ist wirtschaftlich nachvollziehbar, weil Entwicklungskosten dort oft niedriger sind. Gleichzeitig ist es aber nicht immer einfach, genügend Senior-Wissen in allen Bereichen zusammenzubringen. Man braucht heute nicht nur klassische Softwareentwicklung, sondern auch Wissen über Infrastruktur, Cloud-Systeme, Security, Gerätekommunikation, Echtzeitverhalten und im Fall von Energiesystemen zusätzlich elektrotechnisches Verständnis.
Selbst mit gutem Projektmanagement ist das eine große Herausforderung. Moderne Software muss nicht nur „funktionieren“, sondern auch sicher, wartbar, updatefähig und robust gegen Fehler sein. Deshalb setzen viele Unternehmen inzwischen auf Ansätze wie DevSecOps, automatisierte Tests, gestaffelte Rollouts, Monitoring und klare Rollback-Strategien. Gerade bei Firmware, Cloud-Steuerung und Energiemanagement wäre ein gestaffelter Rollout vermutlich sinnvoll, weil man Probleme früher erkennt, bevor sehr viele Nutzer gleichzeitig betroffen sind.
Ich würde daher nicht automatisch davon ausgehen, dass Zendure das egal ist. Wahrscheinlicher ist aus meiner Sicht eine Mischung aus hoher technischer Komplexität, Plattformwechsel von HEMS1 zu HEMS2, Cloud- und Infrastrukturabhängigkeiten, vielen unterschiedlichen Gerätekombinationen und vielleicht auch einem nicht ausreichend vorsichtigen Rollout.
Trotzdem bleibt natürlich die berechtigte Frage: Wenn bekannte Probleme auftreten, warum wird das Update weiterhin aktiv angeboten und warum gibt es keine klare Kommunikation oder zumindest eine sichtbare Warnung in der App? Genau da sehe ich den wichtigsten Punkt. Fehler können bei so komplexen Systemen passieren, aber Transparenz und ein sauberer Update-Prozess wären für die Nutzer extrem wichtig.
Ich wollte das jetzt bewusst nicht zu technisch machen, aber vielleicht hilft es dem einen oder anderen, besser zu verstehen, warum solche Plattformwechsel in der Praxis oft deutlich komplizierter sind, als sie von außen wirken.