Solarakkus kriegt man zwar problemlos geladen von der Solaranlage oder dem Balkonkraftwerk. Aber wie geben sie ihre gespeicherte Ladung wieder ab? Woher wissen sie, welche Leistung die Geräte im eigenen Haushalt gerade benötigen? Im Podcast mit den Redakteuren Marvin Stratmann, Sven Hansen und Christof Windeck von c’t und heise+ erklären wir, was die Leistungsabgabe so problematisch macht und wir geben viele Tipps, wie man seine Akkus zu einem guten Einspeiseverhalten bringt.

Prinzipiell gibt es vier Möglichkeiten: Eine manuelle Steuerung über Wenn-Dann-Regeln oder Zeitpläne, eine Regelung über Zwischenstecker, eine Regelung per Zangenmessgerät im Verteilerschrank und eine Regelung per Lesekopf auf dem Stromzähler. Alle vier haben ihre ganz eigenen Vor- und Nachteile, auf die wir eingehen – und wir erklären, warum die offiziellen Smart Meter, die man für einen dynamischen Stromtarif benötigt, nicht zur Akkuregelung geeignet sind.

Christof und Marvin haben Leseköpfe ausprobiert: das Interessante am Fritz!Smart Energy 250 ist seine reichweitenstarke Funkanbindung per DECT an eine Fritzbox, aber Christof konnte die Daten nur innerhalb der Fritz-Welt nutzen, nicht gut zur Regelung eines Akkus. Marvin hat seinen Lesekopf – ein IOmeter mit ebenfalls reichenweitenstarkem 868-MHz-Funk – daher in die Smart-Home-Plattform Home Assistant eingebunden, ihm standen so mehr Möglichkeiten zur Verfügung.

Auch bei den Zangenmessgeräten kommt es vor allem in Mehrfamilienhäusern darauf an, wie die Messdaten zum Akku gelangen. Aber auch die Einbaukosten spielen eine Rolle. Wir diskutieren verschiedene Möglichkeiten und lassen viel Praxiserfahrung einfließen. Die Zwischendosen wiederum kosten wenig und sind sowieso meist in Funkreichweite des Akkus im Einsatz. Ihre Nachteile liegen woanders, vor allem messen sie natürlich nur die eingesteckten Geräte und können prinzipiell nichts Festverdrahtetes wie Ofen oder Licht erfassen.

Sven berichtet schließlich von seinem Test von vier aktuellen Solarspeichern, Modelle von Growatt, Marstek, Solakon und SunEnergyXT mit jeweils eingebautem Wechselrichter und Kapazitäten von zwei bis fünf Kilowattstunden.

Zu Gast im Studio: Marvin Stratmann, Sven Hansen, Christof Windeck
Host: Jörg Wirtgen
Produktion: Tobias Reimer

► Die c’t-Artikel zum Thema auf heise+ (Paywall):

Stromverbrauch im Haushalt smart messen und Kosten senken

(XXL-)Speicher für Balkonkraftwerke im Test

Stromzähler auslesen per Fritzbox: Lesekopf Fritz!Smart Energy 250 im Praxistest

IR-Leseköpfe in Home Assistant: Digitalen Stromzähler einfach auslesen

► auf Select (Paywall):

Energie-Durchblick

Energiepumpen

Stromzähler-Lesefritze

Energiemonitor

► c’t Magazin
► c’t auf Mastodon
► c’t auf Instagram
► c’t auf Facebook
► c’t auf Bluesky
► c’t auf Threads
► c’t auf Papier: überall, wo es Zeitschriften gibt!

(jow)

Beim Vibe Coding delegieren Entwickler die technische Umsetzung – Syntax, Boilerplate, Logikstrukturen – fast vollständig an ein Large Language Model. Menschen agieren nicht mehr als Autoren einzelner Codezeilen, sondern geben nur noch das gewünschte Verhalten und die Architektur der Anwendung vor. Doch wie sieht es in der Praxis mit den Kosten für ein solches Projekt aus? Stefan Müller, Titelautor der neuen iX 6/2026, erklärt, worauf man achten muss.

Wie kann man grob gesagt Tokenbudget und Kosten für ein Projekt mit Vibe Coding überschlagen?

Ein Token-Budget-Modell, kurz TBM, stützt sich auf viele verschiedene Faktoren. Daher ist ein pauschaler Überschlag naturgemäß etwas schwierig, zumal Softwareprojekte sehr unterschiedlich ausfallen können. Mit einem Topmodell wie Opus 4.6 oder 4.7 liegen wir bei professionellen Projekten eigentlich immer in einem Größenrahmen von 3.000 bis 15.000 Euro – oft auch deutlich darunter, je ausgebuffter die Softwareentwickler sind, die das Modell mit konkreten Vorgaben steuern. Ein Projekt, das über diese Schwelle hinausgegangen wäre, habe ich bisher nicht erlebt. Das TBM habe ich auch als Internetrechner veröffentlicht.

Was sind die größten Kostentreiber beim Vibe Coding?

Das ist einerseits die menschliche Vorarbeit bei der Spezifikation des Projektes. Je durchdachter ein Pflichtenheft ist, desto besser können sich KI-Agenten daran entlanghangeln. Wenn Anforderungen und ihre Umsetzung vage bleiben, kann es schnell teuer werden.

Andererseits entscheidet die Modellqualität: Wenn wir auf den Open-Source-Bereich festgelegt sind, explodieren die Token-Budgets schnell. Das hat nicht zwangsläufig hohe Kosten zur Folge, weil der Tokenpreis pro Million mit der geringeren Modellqualität ja ebenfalls sinkt (wobei Modelle wie DeepSeek V4 selbst diese Logik gerade durchbrechen). Dafür gehen die Personalkosten hoch – wegen des permanenten Nachbesserns und „Reparierens“ des entstandenen Codes. Das ist auch ein versteckter Kostentreiber: Wenn die Softwareentwickler dabei frustriert werden, finden weitere Einsätze dieses Ansatzes zukünftig weniger Akzeptanz.

Im Fall von Open-Source-Modellen würde ich den KI-Einsatz stark limitieren und nur punktuell im Entwicklungsprozess unterstützen lassen – zum Beispiel für einfache Tests oder das Schreiben von Boilerplate anhand konkreter Beispiele und Referenzen.

Wann ist der maschinell generierte Code wirtschaftlich besonders sinnvoll?

Ich finde maschinell generierten Code besonders sinnvoll, wenn schnell Ergebnisse benötigt werden – wenn die Frage nach dem „Wie“ gar nicht so relevant ist, sondern das Resultat im Vordergrund steht. Vibe Coding wird Unternehmen darüber hinaus auch in Zukunft in die Lage versetzen, eigene Softwarekomponenten zu erstellen, ohne auf große Lösungen mit unzähligen Funktionen zurückgreifen zu müssen. Der Vendor-Lock-in bricht langsam, aber sicher auf. Parallel dazu können Software-Manufakturen mit Vibe Coding Kundenbedürfnisse abseits ihres Tagesgeschäfts erfüllen und so neue Zielgruppen erschließen.

Stefan, vielen Dank für die Antworten! Einen Überblick, wie man Tokenbudget und Kosten für Vibe Coding schätzt, gibt es in der neuen iX. Außerdem zeigen wir, was die KI-gestützte Entwicklung in IT-Beratungen und Softwarehäusern kostet – und befassen uns damit, was KI-Gateways als Tools für Kostenkontrolle leisten können. All das und viele weitere Themen finden Leser im Juni-Heft, das ab sofort im heise Shop oder am Kiosk erhältlich ist.

In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(axk)

Was haben dicke, gelbe Bücher mit autonomem Fahren zu tun? Mehr als man denkt, wenn es nach dem Fraunhofer-Institut für Offene Kommunikationssysteme (FOKUS) und der pdm solutions GmbH geht. In einem sechsmonatigen Forschungsprojekt haben die beiden Partner nach eigenen Angaben einen Proof of Concept abgeschlossen, der kuratierte Standortdaten aus dem Verzeichnis „Das Telefonbuch“ für moderne Fahrerassistenzsysteme (ADAS) nutzbar machen soll. Der Prototyp wurde auf dem Branchentreff des Verbands Deutscher Auskunfts- und Verzeichnismedien (VDAV) in Berlin präsentiert.

Im Zentrum steht die am Fraunhofer FOKUS entwickelte Software SADAS (Support for Advanced Driver Assistance Systems). Sie soll die Verzeichnisdaten in den sogenannten „Digitalen Stadtzwilling“ integrieren – ein virtuelles Abbild des Straßenraums. Konkret identifiziere das System laut Fraunhofer Orte mit besonders schutzbedürftigen Verkehrsteilnehmenden, etwa Kindergärten, Spielplätze oder Schulen, und gleiche diese Informationen in Echtzeit mit Fahrtroute und Fahrzeugposition ab.

Erkenne das System eine potenzielle Gefahrenzone, soll der Fahrer optische oder akustische Signale über das Dashboard erhalten – und zwar, bevor die Situation im Sichtfeld auftaucht. Künftig sollen diese Warnungen nach Darstellung der Partner auch direkt an Bremsassistenten oder automatisierte Fahrfunktionen weitergereicht werden können. Wie KI-gestützte Assistenzsysteme im Fahrzeug funktionieren und welche Infrastruktur dahintersteckt, zeigt etwa das Forschungsprojekt Central Car Server der TU München, bei dem ein Zentralrechner alle elektronischen Komponenten steuert und neue Funktionen selbst programmiert.

Alternative zu Datensilos großer Plattformen

Standortdaten von Schulen oder Kitas finden sich grundsätzlich auch in den Kartendiensten globaler Tech-Konzerne. Das Fraunhofer-Projekt zielt jedoch ausdrücklich auf eine souveräne Dateninfrastruktur. „Ein zentrales Ziel ist es, bestehende Datensilos aufzubrechen. Das unterstützt auch digital souveräne Systeme“, erklärt Dr.-Ing. Ilja Radusch, Leiter des Geschäftsbereichs Smart Mobility bei Fraunhofer FOKUS und Leiter des Daimler Center for Automotive IT Innovations (DCAITI) an der TU Berlin. Das Ziel digitaler Souveränität steht dabei im Mittelpunkt des Projekts.

Über offene, standardbasierte Schnittstellen sollen Städte und Mobilitätsdienstleister auf den Digitalen Stadtzwilling zugreifen können, ohne sich an die geschlossenen Ökosysteme einzelner Plattformanbieter zu binden. Das soll es zudem ermöglichen, dass nicht jeder Datenanbieter von vornherein sämtliche Qualitätsanforderungen aller – oft noch unbekannten – Datennutzenden erfüllen muss.

Vom Telefonbucheintrag zur Geokoordinate

Eine Herausforderung dürfte die Datenqualität sein. Während für Verzeichnisdienste eine korrekte Postadresse genügt, benötigen Fahrzeuge hochpräzise Geokoordinaten. Radusch nennt ein anschauliches Beispiel: Schulen oder Spielplätze erstreckten sich häufig über ganze Straßenblöcke und grenzten an mehrere Straßen. Würde ein Assistenzsystem pauschal an allen angrenzenden Straßen warnen, käme es schnell zum Gewöhnungseffekt – mit negativen Folgen für die Verkehrssicherheit.

Um die Daten für den Einsatz im Fahrzeug zu veredeln, will Fraunhofer FOKUS mehrere Quellen kombinieren: Informationen aus Verkehrsmanagementzentralen, stationäre Sensoren in Ampelanlagen sowie Sensordaten aus Fahrzeugflotten. Hinzu kommen soll Crowdsourcing über die KI-basierte App Eidos Road Glancr (PDF): Ein handelsübliches Smartphone an der Windschutzscheibe – beispielsweise in Bussen oder Taxis – soll datenschutzkonform Veränderungen im Straßenraum wie Baustellen, neue Verkehrszeichen, Straßenschäden oder verfügbare Parkflächen erfassen. Für seltene oder sicherheitskritische Ereignisse will das Team die Realdaten zusätzlich durch Simulationen in der Open-Source-Umgebung Eclipse MOSAIC ergänzen.

Nach dem nach eigenen Angaben erfolgreichen Proof of Concept wollen pdm solutions und Fraunhofer FOKUS die Zusammenarbeit fortsetzen. Perspektivisch sollen die datenbasierten Digitalen Stadtzwillinge nicht nur Assistenzsysteme ergänzen, sondern auch für automatisiertes und autonomes Fahren nutzbar werden. Andere Hersteller setzen bei der Integration von Fahrerassistenz auf KI-Plattformen wie etwa Google Gemini in Volvo-Fahrzeugen, wo die KI über Fahrzeugkameras Verkehrszeichen und die Umgebung in Echtzeit analysiert. Denkbar seien laut Radusch zudem klassische Telematik-Services wie barrierearme Routen zur nächsten Apotheke oder thematische Stadttouren.

Transparenzhinweis: Heise & Dumrath Medien ist am Herausgeber von „Das Telefonbuch“ beteiligt.

(vza)