Changelog
Every change to data, formulas or methodology is logged here — with its effect on results and its source.
web/seo-texteMethodSERP-Feinschliff beider Sprachen: 79 Seitentitel auf maximal 55 Zeichen gekuerzt (Keyword bleibt vorn, Marken-Suffix haengt das Template an) und 70 Meta-Descriptions auf maximal 158 Zeichen — jeweils redaktionell, die Kernaussage und die Zahlen-Hooks bleiben erhalten.
Titel und Descriptions werden in der Suche nicht mehr abgeschnitten. Einzigartigkeit ueber alle Seiten per Skript verifiziert (0 Duplikate).
SEO-Audit 07.08.2026 gegen den Build-Output; Laengen-Gates 55/158 im Redaktionsskript erzwungen
web/mobileFixMobile-Abnahme aller Seiten bei 390 px (Messwerkzeug: Overflow je Element, Touch-Ziele nach WCAG 2.5.8, iOS-Zoom-Schwelle, effektiv gerenderte SVG-Schriftgroessen): (1) Diagramme bekamen Mindestbreite 600 px mit eigenem Querscroll — die 640er-viewBox skalierte sonst auf 0,56 und renderte Beschriftungen mit ~6,5 px; jetzt ~9 px, dasselbe Scrollmuster wie die Tabellen. (2) Alle Eingabefelder mobil auf 16 px angehoben (Formular-Zahlenfelder 14 px, Slider/Stepper/Segment-Wertfelder 13 px — iOS zoomte beim Fokus in die Seite; Klassenselektoren noetig, Elementregeln verloren gegen die scoped-Spezifitaet). (3) Aufklapper (Rechenschritte, Wertetabellen) von 23 px auf tap-taugliche Hoehe gepolstert; Staedte-Links in Vergleichstabellen per Padding auf 24-px-Tap-Ziel gebracht, ohne die Zeilenhoehe zu aendern. (4) Heatmap-Ticks 9,5 auf 10,5 px.
Stichproben-Audit: alle Seiten SAUBER, kleinste gerenderte Diagrammschrift 8,6 px, keine Unter-24-px-Touchziele mehr, kein iOS-Fokus-Zoom. Vollaudit ueber 150 Seiten folgt gegen den Build.
Eigenes Mobile-Audit-Werkzeug (390x844, CDP); WCAG 2.5.8; iOS-Zoom-Verhalten bei <16 px Eingabeschrift
projekt/toter-codeFixToter-Code-Sweep ueber das Gesamtprojekt (knip + manuelle Verifikation jedes Funds): (1) Kompletter Legacy-Pfad der wave-1-Standortwahl entfernt — der Fallback in der Datenanreicherung war unerreichbar, seit alle 35 Irradiance-Rechner auf dem TMY-Raster laufen (Mengen-Beweis: IRRADIANCE minus TMY = leer); mit ihm fielen das Doppelset IRRADIANCE_CALCULATORS, LOCATION_FIELD/LOCATION_OPTIONS und der wave-Zweig der Quellenanzeige. (2) Drei nie benutzte Rechnerlisten-Exporte, ein nie benutztes inputs-Feld samt InputField-Typ, commitlint-Konfiguration ohne Runner. (3) Acht nur intern gebrauchte Exporte/Typen internisiert (Schema-Einzelexporte, isInRegion, FaqItem, DataSource, Marine-Typen, FolderMeta, LocationsDataset, Meta, TMY_GRID_CALCULATORS). knip.json haelt die zwei verifizierten Fehlalarme fest (fontsource via css-Array, vue-tsc via nuxt typecheck). Nachtrag auf Nutzeranweisung: Alle Markdown-Dokumente entfernt (README, CONTRIBUTING, DEPLOY, DATENBEDARF, docs/spezifikation Teil 1-4); ausserdem die IndexNow-Dublette konsolidiert — das aeltere manifest-basierte Root-Skript entfiel zugunsten des sitemap-basierten (erfasst den Staedte-Rollout automatisch).
knip meldet null Befunde; jede Datei traegt nur noch erreichbaren Code. WICHTIGE ABGRENZUNG: data/irradiance/wave-1.json und scripts/fetch-pvgis.ts bleiben — sie sind die unabhaengige Kreuzvalidierungs-Referenz der TMY-Kette (tmy.spec, poa.spec, Golden r60), kein toter Code.
knip 6.32; jeder Fund einzeln gegen App-, Engine-, Skript- und Test-Verwendung gegengeprueft
tariffs/de + emissions/deDataDatenaudit 06.08.2026 (alle JSON-Datensaetze gegen Primaerquellen): (1) Strompreis-Segmente aktualisiert — Neukunden 23,9 -> 24,7 ct, Grundversorgung 42,8 -> 40,4 ct (StromAuskunft-Index Stand 06.08.2026); Bestandskunden 31,1 ct und EEG-Saetze 7,70/6,66/5,44 ct (H2/2026 nach Degression 01.08.) gegen die Degressionskette VERIFIZIERT und unveraendert. (2) CO2-Verdraengungsfaktor Photovoltaik 650 -> 685 g CO2-Aeq./kWh nach der Primaerquelle UBA CLIMATE CHANGE 11/2026 (Emissionsbilanz 2024, Abb. 8: Netto-Vermeidungsfaktor PV); Bilanzjahr korrekt als 2024 ausgewiesen (eine 2025er-Ausgabe existiert nicht). Durchschnittsmix 344 g/kWh (2025) und Herstellung 400-600 kg/kWp bestaetigt.
Preisvergleichs-Segmente in Rechner 41 aktuell; CO2-Rechner (49) weist auf Verdraengungsbasis ~5 % mehr Vermeidung aus — mit exakt zitierbarer Primaerquelle statt Sekundaerwert. Golden r41 aktualisiert; i18n-Texte (6 Stellen) auf 685 g nachgezogen.
UBA CLIMATE CHANGE 11/2026 (PDF, Abb. 8); UBA-Pressemitteilung Strommix 2025; StromAuskunft/Verivox 06.08.2026; Degressionskette Paragraph 48 EEG
web/stadtseiten-vertiefungMethodBalkonkraftwerk-Block auf allen 447 Stadtseiten (beide Sprachen): senkrechte Suedbruestung als EIGENE Ebenen-Umrechnung derselben TMY-Engine (tiltDeg 90) — Jahresertrag kWh/m2, Anteil am 35-Grad-Optimum und der Dezember-Vergleich, bei dem die Senkrechte das geneigte Modul UEBERTRIFFT (Muenchen 111 %, Kiel 110 % — tiefe Wintersonne). Frageformat-H2 fuer die Long-Tail-Suchintention. Dabei behoben: Die CTAs der englischen Stadtseiten verlinkten fest die DEUTSCHEN Rechner-Slugs — jetzt locale-korrekt aus dem Manifest (pathFor), plus neuer Balkon-CTA mit vorbefuellten Koordinaten. Sitemap-Quelle der Staedte traegt ehrliches lastmod (Abrufdatum des TMY-Datensatzes, 2026-07-30).
Jede Stadtseite gewinnt einen echt standortdifferenzierten Datenblock statt neuer Duplikat-URLs (Tiefe schlaegt Seitenzahl, Recherche 08/2026) und verlinkt in einen dritten Rechner. Sprachbruch der CTAs beseitigt; lastmod-Signal belastbar statt build-datiert.
Gleiche Engine-Kette wie Rechner 23/54; live verifiziert Muenchen/Kiel DE+EN (Zahlen differenziert, CTAs locale-korrekt)
web/trailing-slashFixautoSubfolderIndex: false im Prerender: Der Build schreibt about.html statt about/index.html. Vorher lieferten statische Hosts (Cloudflare Pages) nur die Slash-Variante mit 200 und beantworteten die slashlose Canonical-/Sitemap-URL mit 308 — die Search Console meldete 'Seite mit Weiterleitung' und indexierte nicht (verifiziert im Schwesterprojekt SecPDF). Dabei aufgedeckter Folgefund: Der Sprachumschalter uebersetzte die Regions-Slugs der Sonnenstunden-Hubs nicht (/sun-hours/bayern entstand als materialisierte Duplikatseite) — Umschalter jetzt regionsbewusst, Falsch-Slug-Aufrufe leiten per 301 auf den korrekten Slug.
Datei-Layout, Canonicals, hreflang und Sitemap sagen dieselbe URL-Form (slashlos) — direkte 200er fuer alle Sitemap-URLs auf statischen Hosts, sofortige Crawl-/Indexfaehigkeit. 13.752 interne Links geprueft: 0 mit .html, 0 mit Trailing Slash; 22 Duplikat-Varianten der Regionsseiten beseitigt.
Nitro-Doku (autoSubfolderIndex), Cloudflare-Pages-Serving-Doku (about.html -> /about 200); Beweisfuehrung am Build-Output
web/vizFixDritte Sichtpruefungsrunde mit erweitertem Pruefwerkzeug (erkennt jetzt auch Text, der von LINIEN durchkreuzt wird, per Punktabtastung gegen gestrichene Pfade): globaler Text-Halo fuer frei stehende Diagramm-Labels (hintergrundfarbene Kontur, ausser auf Farbflaechen), 'Jahr 10'-Label der Batteriebank strukturell von der Kurve getrennt, dazu 14 Robustheits-Fixes fuer Extrem- und Minimal-Eingaben: Skalen-Untergrenzen gegen kollabierende Domaenen, Pixelabstand-Filter fuer Achsen-Ticks, Ausweichlogik fuer Linienend-Labels, linksbuendige Y-Beschriftung fuer neunstellige Betraege, Anker-Wechsel an Achsenraendern.
Finale Abnahme gegen den Produktionsbuild: 62 Rechner x drei Wertelagen (Standard/Maxima/Minima) = 186 Seitenzustaende mit NULL Darstellungsfehlern — kein Text verdeckt, nichts abgeschnitten, keine Kollision. Uebrig bleiben ausschliesslich korrekte Engine-Validierungsmeldungen bei physikalisch unsinnigen Extremkombinationen (8 bzw. 9 Faelle).
Chunk-Sweeps gegen den Preview des finalen Builds; Bounding-Box-Messsonde je Restbefund
web/sonnenstunden-hubsMethodHub-and-Spoke-Struktur fuer die Sonnenstunden-Stadtseiten (Recherche 08/2026): Laender-Hub /sonnenstunden bzw. /sun-hours, 16 Bundesland-Seiten und je eine Laenderseite AT/CH (nach Bundesland/Kanton gruppiert, kuratierte amtliche Namen beider Sprachen). Staedte ab 20.000 Einwohnern, je TMY-Rasterpunkt nur der groesste Ort (447 Staedte) — Bezirke mit identischen Zahlen erscheinen bewusst nicht. Englische Slugs lokalisiert (/sun-hours/bavaria), hreflang/Canonical beidseitig, Brotkrume Hub->Region->Stadt, Footer-Einstieg. Indexierung bleibt hinter dem Schalter NUXT_PUBLIC_CITY_INDEX=on (Robots + Sitemap-Quelle gemeinsam geschaltet).
Jede Stadtseite ist in maximal 3 Klicks von der Startseite erreichbar (vorher bis zu 28 ueber Nachbar-Ketten) — die Voraussetzung fuers Crawling. Beim Umlegen des Schalters kommen ~934 indexierbare Seiten in beiden Sprachen dazu, auf rasterpunkt-deduplizierter Datenbasis (Schutz vor Googles Scaled-Content-Politik).
Recherche Hub-and-Spoke/Scaled-Content 08/2026; GeoNames cities500 (kuratierte Regionsnamen); live verifiziert auf Dev (Alternates, Robots, Links)
web/layoutMethodUtility-Bar (38-px-Leiste ueber dem Header mit Kernversprechen + Sprachumschalter) auf Nutzerentscheid komplett entfernt; der Sprachumschalter EN/DE sitzt jetzt rechts in der Hauptnavigation. Damit die Navigation bei 1440 px weiter vollstaendig passt: Marke-Nav-Abstand 40->16 px, Silo-Padding 13->8 px (nachgemessen: 0 px Ueberhang). Nachtrag: Die Navigation haengt LINKS an der Marke, nur der Umschalter rueckt per margin-left:auto nach rechts — mit auto-Rand an der Nav klaffte auf Englisch (kuerzere Labels) ein Loch in der Mitte.
Ein Balken weniger ueber jeder Seite; das Versprechen 'alle Rechner ohne Anmeldung' traegt weiterhin der Footer. Verwaiste utility.*-i18n-Keys entfernt.
Nutzerentscheid 06.08.2026 (Screenshot); Nachmessung per CDP bei 1440/1280/390 px
web/technisches-seoMethodTechnischer SEO-Durchgang (recherchiert, Stand 08/2026): (1) IndexNow-Ping-Skript ergaenzt (pnpm indexnow — liest die gebauten Locale-Sitemaps, pingt Bing/Yandex/Naver-Verbund; Google unterstuetzt IndexNow nicht und laeuft ueber Sitemap + Search Console). (2) GeoNames-Ortsverzeichnis (269 kB gzip, groesster Chunk) aus den modulepreload-Hinweisen genommen — es laedt jetzt wirklich erst beim Fokus der Standort-Eingabe. (3) Keyword-Konsistenz-Audit Slug vs. Titel/H1 ueber alle 124 Seiten: 6 Luecken geschlossen (u. a. 'Sicherung', 'Wire Ampacity', 'Panel', 'Chemistry').
Kritischer Ladepfad je Rechnerseite sinkt um ~269 kB gzip; Bing-Verbund erfaehrt Aenderungen in Minuten statt Tagen; Kopf-Keywords decken die Slug-Queries beider Sprachen vollstaendig. llms.txt und Webmanifest waren bereits vorhanden.
Recherche IndexNow/llms.txt/lastmod 08/2026; Messung am Build-Output (gzip-Gewichte je Chunk)
web/form-url-stateFixZustands-URLs griffen im PRODUKTIONS-Build nicht: Prerenderte Seiten hydratisieren mit der Payload-Route, route.query ist waehrend des Setups leer — jeder geteilte Link und jeder Handoff-Link landete auf den Vorgabewerten. Der Dev-Server hat echte Request-Queries, deshalb ist es jedem bisherigen Browser-Check entgangen. Fix: Query-Anwendung zusaetzlich nach dem Mount (queryValueFor + onMounted-Nachzug).
Geteilte Links, Handoff-Links und alle ?param-Zustaende funktionieren jetzt auch auf der gebauten Seite. Ohne den Fix war das komplette Handoff-Netz in Produktion wirkungslos.
Sichtpruefung 06.08.2026 gegen den Produktions-Output (Port-3001-Preview); Dev/Prod-Differenz per CDP verifiziert
web/vizFixSichtpruefung aller 62 Visualisierungen (Screenshot + programmatische Ueberlappungs-/Clipping-Pruefung je SVG): 12 Darstellungsfehler behoben — abgeschnittene Textzeilen (R1, R7, R42), Label-Kollisionen (R27 Jahressumme, R29 Linienenden, R39 Sperrgrenze, R44 Zonenlabel, R49 Nulllinie), Engine-ASCII in der Anzeige (R13/R21 'mm2' -> lokalisiert 'mm²', R62 'Kuehlschrank' -> 'Kühlschrank'), Label groesser als sein Kreis (R9). Zweiter Durchgang mit Extremwerten (alle Zahlenfelder auf Min/Max): 8 weitere Robustheitsfehler behoben — Skalen, die Gewinnstufen bzw. Faktoren ueber 1 nicht abdeckten (R12 Verlustkette inkl. Doppel-Minus bei Gewinnstufen, R18 Belastbarkeit), aus dem Bild laufende Kurven (R11 Voc), Label-Kollisionen an Achsenraendern (R5, R24), zu schmale Segmente (R19), Legenden-Umbruch ab vier Kandidaten (R33), abgeschnittene Summenzeile (R4).
Alle Viz-Texte vollstaendig lesbar, keine Ueberdeckungen mehr; Einheiten- und Umlaut-Schreibweise einheitlich mit dem Rest der Seite. Golden r62 nur um den Geraetenamen aktualisiert, Rechenwerte unveraendert.
CDP-Sweep ueber alle 62 Rechnerseiten, je Seite Bounding-Box-Pruefung aller SVG-Texte plus Screenshot-Sichtung
engine/series-parallelFixNamenskollision im Handoff Rechner 37 -> 22 behoben: `blockCount` hiess bei Rechner 37 die GESAMTblockzahl (seriell x parallel), bei Rechner 22 die Zahl PARALLELER Straenge — der Link uebertrug per Namensgleichheit die Gesamtzahl als Strangzahl (bei 2s2p: 4 statt 2). Gesamtzahl heisst jetzt totalBlockCount; blockCount ist ein dokumentiertes Echo in Rechner-22-Semantik (= parallelCount).
Der Handoff-Link traegt jetzt die richtige Strangzahl vor. Golden r37 nur um die Umbenennung/das Echo geaendert, Rechenwerte unveraendert. Beispielfall 1s4p war zufaellig richtig — der Fehler zeigte sich erst bei seriell-parallelen Baenken.
Live-DOM-Verifikation beider Faelle; Property-Test auf totalBlockCount umgestellt
engine/parallel-batteryFixStrangsicherungs-Hinweis (Rechner 22) feuert jetzt bei JEDER Parallelschaltung (ab 2 Blöcken statt ab 3). Die alte Schwelle uebertrug die Zweistrang-Ausnahme der PV-Welt (NEC 690.9) auf Batterien — dort ist der Fehlerstrom aber nicht begrenzt: Ein Kurzschluss in einem Block wird schon bei zwei Straengen vom gesunden Block gespeist. ABYC E-11 verlangt Ueberstromschutz an jedem ungeerdeten Leiter ab der Batterie.
Zweiblock-Baenke — die haeufigste Parallelschaltung ueberhaupt — bekamen bisher KEINEN Sicherungshinweis. Zusaetzlich nominalLifetimeYears als Eingabe erschlossen (war unerreichbar, trieb aber Lebensdauer-Output und -Warnung) und Warntext um die Begruendung ergaenzt.
ABYC E-11 (OCPD an jedem ungeerdeten Leiter); NEC 690.9 Zweistrang-Ausnahme gilt nur fuer stromlimitierte PV-Straenge
engine/fridgeFixKuehlschrank-Rechner (55) reicht Anlaufspitze und Dauerlast des Kompressors jetzt als Output-Echos (peakPowerW/continuousPowerW, AC-Watt) an den Batteriekabel-Rechner weiter. Die Zahl stand bisher nur in der Anzeige-Kette (chain.derived) — der Handoff-Link blieb leer, weil er ausschliesslich Top-Level-Outputs liest.
Der Link 'Batteriekabel pruefen' auf der Kuehlschrank-Seite traegt jetzt 225 W Spitze und 45 W Dauer im Referenzfall vor; vorher musste der Nutzer beide Zahlen von Hand uebertragen. Rechenwerte unveraendert (Golden nur um die Echos erweitert).
Gleiche Defektklasse wie die sechs Echo-Fixes vom Audit; live-DOM-verifiziert
engine/battery-cableFixDer Batteriekabel-Rechner (21) hat sechs bisher unerreichbare Felder bekommen — darunter den kompletten PRUEFMODUS (vorhandenes Kabel gegen beide Kriterien testen; optional im Schema, im Formular nicht vorhanden), den zulaessigen Spannungsfall, Material, Leitertemperatur und beide Wirkungsgrade.
Die haeufigste Nutzerfrage dieses Rechners ist nicht 'welches Kabel kaufe ich', sondern 'reicht das, was liegt' — genau dieser Modus war unerreichbar. Referenz: 16 mm2 scheitert an beiden Kriterien (Spannungsfall ueber Limit, Abschaltreserve duenn), 35 mm2 besteht; die Auslegung empfiehlt 25 mm2. Kernrechnung unveraendert: minimale Batteriespannung (294 statt 267 A Spitzenstrom) und Abschaltschwellen-Pruefung.
Referenzzahlen per Engine-Sonde verifiziert
engine/groundingMethodFeinschliff am Erdungs-Rechner (20): FAQ von 6 auf 11 je Sprache (beide IEC-Wege erklaert, k-Wert-Disziplin, Galvanik am Aluminiumrumpf, Grenzen beider Modi), Methodik mit den Referenzzahlen beider Wege (Tabelle 16 mm2 vs adiabatisch 4,42 mm2 bei 1.000 A/0,4 s/k=143). Strukturell ohne Befund: beide Modi vollstaendig bedienbar (visibleWhen), k als Nutzereingabe mit Quellenverweis (B11), Marine-Datensatz gemeinfrei fundiert.
Dritter Rechner des Durchgangs ohne strukturellen Befund (nach 35 und 14) — die Katalog-Schlussrunde vom 03.08. hat hier bereits nach dem heutigen Standard gebaut. Die Doppelweg-Darstellung bleibt das Merkmal: Die Rechnung ERLAUBT den kleineren Leiter, kostet aber den Nachweis; die Seite empfiehlt konservativ.
IEC 60364-5-54 (Systematik; Tabellenwerte als Nutzereingabe), 33 CFR 183 Subpart I (gemeinfrei), ISO-Ausgabestand data/marine/ (verifiziert 03.08.2026)
engine/busbarMethodFeinschliff am Sammelschienen-Rechner (19): Material (Aluminium!) und Umgebungstemperatur als Felder erreichbar; FAQ von 6 auf 11 je Sprache (u. a. warum die Bauartpruefung die verbindliche Antwort ist, Messung des Uebergangswiderstands, Aluminium-Verbindungsproblematik); Methodik mit den Referenzzahlen des Verbindungs-Checks (Schiene 2,7 W gegen 4 W in zwei 50-uOhm-Verbindungen).
Der Kern — Plausibilitaet statt Scheingenauigkeit, Verbindungen statt Schiene — war bereits richtig gebaut; die ehrliche Selbstbeschraenkung (BUSBAR_TYPE_TEST_REQUIRED in jeder Ausgabe) bleibt das Alleinstellungsmerkmal. Aluminium-Schienen waren bisher nicht rechenbar.
IEC 61439 (Bauartpruefung als verbindlicher Weg); Referenzzahlen per Engine-Sonde verifiziert
engine/ampacityFixDer Belastbarkeits-Rechner (18) hat zwei bisher unerreichbare Felder bekommen: die Verlegeart-Kennung (Select der IEC-Buchstaben, reine Ausgabe-Kennung — kein Tabellenschluessel, das Urheberrechtskonzept bleibt unangetastet) und den I_z des naechstgroesseren Querschnitts hinter einem Schalter. Erst damit kann der Sanierungsvergleich seine dritte Option rechnen; ohne Haken bleibt sie unberechnet statt erfunden.
Der Sanierungsvergleich ist die Pointe des Rechners, und seine staerkste Aussage war eingesperrt: Im Referenzfall reicht der naechstgroessere Querschnitt NICHT (21,6 A nach Derating), Entbuendeln dagegen schon (25,3 A) — der dickere Leiter behaelt die schlechten Faktoren, die bessere Verlegung beseitigt sie. Erst rechnen, dann kaufen.
IEC 60364-5-52 Systematik (Faktoren als Nutzereingabe); Referenzzahlen per Engine-Sonde verifiziert
engine/ac-ocpdFixDer AC-Schutzorgan-Rechner (17) hat vier bisher unerreichbare Schema-Felder als Bedienelemente bekommen: die Abschaltzeit (0,4 s Endstromkreis / 5 s Verteilung — sie ordnet den Stromkreis ein; die Impedanzgrenze bleibt zeitunabhaengig, weil der Nachweis ueber die magnetische Schnellausloesung gefuehrt wird), die Phasenzahl, die Nennspannung gegen Erde und das Leitermaterial. FAQ von 6 auf 11 je Sprache, Methodik mit den Referenzzahlen der Rueckrechnung (B16/45 m/2,5 mm2 -> 2,87 / 0,64 / 2,23 Ohm).
Die Seite rechnete stets den Endstromkreis-Fall; fuer Verteilungsstromkreise fehlte die Einordnung samt Plausibilitaetswarnung (>32 A bei 0,4 s). Wichtig und jetzt auch in den FAQ klargestellt: Die Impedanzgrenze haengt NICHT an der Zeitwahl — der Nachweis laeuft ueber das magnetische Ausloeseband (Millisekunden) und ist damit bewusst konservativ fuer beide Zeitvorgaben.
IEC 60898-1 (Ausloesebaender), IEC 60364-4-41 (Abschaltzeiten); Referenzzahlen per Engine-Sonde verifiziert
engine/dc-ocpdFixDer DC-Sicherungsrechner (16) hat seinen PV-Pfad als Bedienelemente bekommen (Isc je String, parallele Strings — vorher lief der NEC-690-Zweig still mit den Vorgaben 11 A / 1 String) und die Koordinationsgrenzen als optionale Schalter: Leiter-Belastbarkeit, BMS-Dauerstrom und das Schaltvermoegen des Geraets (R36-Lehre: kein immer-gesendeter Default als Datenblattwert; ohne Haken wird die Pruefung als offen benannt). Batteriespannung und Norm-Korrekturfaktoren sind erreichbar.
Vier der Schutzpruefungen dieses sicherheitskritischen Rechners waren fuer Formularnutzer nie erreichbar oder liefen auf stillen Vorgaben: Leiterschutz, BMS-Koordination, PV-Pfad und der Schaltvermoegens-Abgleich (2.560 A prospektiv gegen 1.000-A-KFZ-Sicherung — die Kernwarnung der Seite) haengen alle an Eingaben, die es im Formular nicht gab.
NEC 690.8/690.9, IEC 60364; Referenzzahlen per Engine-Sonde verifiziert
engine/voltage-dropFixDer Spannungsfall-Pruefer (15) hat seinen Diskriminator und damit die komplette AC-Haelfte als Bedienelemente bekommen: Stromkreis-Umschalter (DC/AC), Phasenzahl, Leistungsfaktor, 230/400-V-Optionen. Der Reaktanzbelag kommt im AC-Fall aus dem NYY-Katalog zum gewaehlten Querschnitt (als Hinweis benannt; Datenblatt-Schalter hat Vorrang) — die Engine-Verweigerung, ihn zu raten, bleibt unangetastet, ein Formular-Default haette sie untergraben. Dazu Betriebsstunden und Strompreis erreichbar (Verlustkosten) und der Temperatur-Override wie in Rechner 13.
Die AC-Rechnung — ein- und dreiphasig, mit Reaktanz — existierte nur im Rechenkern; kein Nutzer konnte sie erreichen. Referenz dreiphasig: 16 A ueber 25 m in 2,5 mm2 bei 400 V -> 1,24 %. Die Verlustkosten-Uebersetzung (27 W des 6-mm2-Beispiels = ca. 8 EUR/Jahr bei 1.000 h) war ebenfalls eingesperrt.
Reaktanzen data/cables/nyy-cu.json (03.08.2026); Referenzzahlen per Engine-Sonde und Live-Seite verifiziert
web/calculator-formFixSelects mit numerischen Werten (Systemspannung, Normgrenzen, Phasenzahl) kamen aus der Zustands-URL als TEXT in den Formularzustand — z.number() wies daraufhin die gesamte Eingabe zurueck. Derselbe Fehler wie bei den Schaltern (Changelog 05.08.), eine Feldart weiter. Der Formularzustand uebernimmt jetzt den TYPISIERTEN Optionswert, wenn ein Optionseintrag zum URL-Text passt.
Jeder geteilte Link mit einer numerischen Select-Aenderung zeigte 'Die Eingaben sind nicht gueltig' — gefunden beim Freischalten des AC-Zweigs von Rechner 15 (?v=400), betraf aber alle Rechner mit numerischen Selects (u. a. 9, 11, 36, 15).
Sichtpruefung Rechner 15 mit Zustandsparametern am 05.08.2026
engine/ac-wire-sizeMethodFeinschliff am AC-Kettenrechner (14): FAQ von 6 auf 11 je Sprache (u. a. Spannungs-ANSTIEG bei Einspeisung als Umkehrfall der Kette, wann der Reaktanzanteil kippt, Zweck der einstellbaren Netzspannungen), Methodiktext mit Referenzzahlen (11 kW ueber 16/10/4 mm2 -> 0,91 % gesamt) und den drei benannten Normgrenzen. Rechnerisch unveraendert — der zweite Rechner des Durchgangs ohne strukturellen Befund: alle Schema-Felder erreichbar, Katalog-Reaktanz mit benanntem Fallback, Ketten-Warnungen je Glied.
Bestandsaufnahme nach Checkliste ohne Korrekturbedarf am Rechenwerk. Die dreigliedrige Kette mit Teilgrenzwerten bleibt das Alleinstellungsmerkmal — Konkurrenzrechner pruefen eine Strecke gegen einen Pauschalwert.
DIN 18015-1, DIN VDE 0100-520, TAB; Reaktanzen data/cables/nyy-cu.json (03.08.2026); Referenzzahlen per Engine-Sonde verifiziert
engine/dc-wire-sizeFixDer DC-Kabelrechner (13) hat sieben bisher unerreichbare Schema-Felder als Formularfelder bekommen: NEC-690-Zweipfad-Schalter, beide Norm-Korrekturfaktoren, Basis-Belastbarkeit (hinter Schalter — R36-Lehre), Betriebsstunden und die bewusst gesetzte Leitertemperatur. Die Dauer-Fehlwarnung TEMP_ASSUMED erscheint nicht mehr, wenn der Nutzer die Temperatur ueber den Schalter setzt. Rechner 5 und 10 echoen ihre Stroeme unter dem Feldnamen dieses Rechners (Ladestrom bzw. Isc der besten Konfiguration — NEC rechnet vom Isc), damit die Verkettung sie uebergibt.
Fuer NEC-Nutzer existierte der vorgeschriebene Zweipfad (aus 11 A Isc werden 18,9 A geforderte Belastbarkeit) nur in der Engine; die Belastbarkeits-Pruefung konnte nie auf der Seite laufen, und die Temperatur-Warnung widersprach bewusstem Nutzerhandeln. Referenz bewusst gesetzter 70 °C: Querschnitt waechst von 16 auf 25 mm2 — die Warnung verschwindet, die Physik uebernimmt.
NEC 690.8 (Faktoren aus den Engine-Konstanten), IEC 60364; Referenzzahlen per Engine-Sonde verifiziert
engine/bms-sizingFixDie BMS-Dimensionierung (40) prueft die Mindesttemperatur jetzt gegen das TMY-Minimum des Standorts — die Gegenprobe laeuft bewusst AUSSERHALB der Kaltpruefung, weil sie gerade dann greifen muss, wenn die Eingabe zu mild ist und die Kaltpruefung deshalb schweigt. Acht bisher unerreichbare Schema-Felder sind zugaenglich, darunter die BMS-Spitzendaten hinter einem Schalter (ein immer gesendeter Default gaelte als Datenblattwert — R36-Lehre): Die Spitzenfenster-Pruefung konnte fuer Formularnutzer nie laufen.
Die wichtigste Warnung des Rechners (fehlende Tieftemperatur-Ladesperre) hing an einer ungeprueften Temperatureingabe: Wer +5 °C eintrug, bekam in Berlin (TMY-Minimum -7,9 °C) weder Kalt- noch Standortwarnung. Beim Einbau der Gegenprobe zerriss ein Zwischenstand das urspruengliche if/else der Kaltpruefung (LFP-Hinweis waere nur noch ohne Standortdaten erschienen) — im selben Durchgang gefunden und behoben; der Endstand ist getestet.
Standortminima data/climate/design-temps.json (wie Rechner 5/10/11); Referenzzahlen 133 vs 104 A per Engine-Sonde verifiziert
engine/battery-temperatureMethodDas Temperaturmanagement (39) bezieht die Packmasse jetzt aus der Klassen-Kennzahl des Vergleichsdatensatzes (massPerAhKg x Kapazitaet; Schalter fuer Datenblattwerte) statt aus einem geratenen 12-kg-Vorgabewert; die Herkunft wird als Hinweis ausgewiesen. Der Rechner war ansonsten bereits vollstaendig standortgebunden (TMY-Jahresgang, Kennlinien, Ladesperr-Tage) — bei nicht aufloesbarem Standort verweigert er sauber statt still anzunehmen.
Die Masse steuert die thermische Traegheit und damit die Sperrtage-Zaehlung: Fuer 100 Ah LiFePO4 liefert die Klassen-Kennzahl 12,5 kg. Im Berliner Referenzfall bleibt es bei 41 Ladesperr-Tagen (Umgebung 45) — die Kernaussage 'Heizung loest die Sperre, Vergroesserung nicht' traegt unveraendert, steht jetzt aber auf einer belegten statt einer geratenen Masse.
batteries/comparison-specs.json (Klassen-Massen aus Herstellerdatenblaettern); TMY-Temperaturreihen PVGIS-SARAH3
engine/usable-capacityMethodDie nutzbare Kapazitaet (38) bezieht den Kaeltefaktor jetzt aus der Kennlinie der gewaehlten Chemie bei der Temperatur des Aufstellorts (im Freien: Monatsmittel des Standorts; Muster aus Rechner 7/38-Schalter fuer eigene Werte). Vorher standen Faktor (frei, 0,9) und Batterietemperatur (20 °C, erweitert) unverbunden nebeneinander — die R3-Falle. Frost- und Derating-Warnungen nutzen jetzt dieselbe Auslegungstemperatur wie die Kapazitaetsrechnung.
Man konnte -5 °C eintragen und trotzdem mit Faktor 0,9 rechnen — oder umgekehrt. Im neuen Referenzfall (aussen Berlin, Januar, 0,6 °C) gibt die LiFePO4-Kennlinie 86 %, und erst die echte Temperatur loest auch die kritische Frost-Ladewarnung aus, die mit der 20-Grad-Vorgabe nie erschien. Der Umkehrmodus (noetige Nennkapazitaet) rechnet mit demselben Faktor.
Kennlinien data/batteries/chemistries.json; Temperaturreihen PVGIS-SARAH3 TMY; Kern geteilt mit Rechner 3/7
engine/series-parallelFixSechs unerreichbare Schema-Felder des Verschaltungs-Rechners (37) sind als Formularfelder zugaenglich: die drei Misch-Schalter (Kapazitaet/Alter/Chemie — sie steuern Sicherheitswarnungen, gemischte Chemie ist ein Ausschlussfall), die Blockspannung (24-V-Bloecke waren nicht korrekt rechenbar) und die beiden Widerstaende, ohne die die Stromungleichverteilung nie beziffert werden konnte (Schalter-Muster; ohne Datenblattwerte schweigt der Rechner weiterhin bewusst).
Die wichtigste freigeschaltete Zahl: Bei einseitigem Abgriff traegt der erste von vier parallelen Bloecken 80 % mehr Strom als rechnerisch (5/1 mOhm), diagonal abgegriffen 0 % — diese Quantifizierung existierte in der Engine, war aber ueber die Oberflaeche unerreichbar. Ebenso konnten die Warnungen zu gemischten Chemien und ungleichem Alter fuer Formularnutzer nie erscheinen.
Engine-Sonde 05.08.2026 (parallelWiring-Kern, geteilt mit Rechner 22)
engine/peukertFixDer Peukert-Exponent im Rechner 36 steht jetzt hinter einem Datenblatt-Schalter (Muster aus Rechner 7). Vorher sendete das Formular seinen Vorgabewert 1,25 IMMER mit — die Engine hielt ihn fuer einen Datenblattwert, wandte ihn auf jede Chemie an und liess die Annahme-Warnung nie erscheinen. Das Beispiel verzichtet auf den expliziten Wert: k=1,25 IST das Bandmittel der Nasszelle, die Seite zeigt die Annahme jetzt ehrlich.
Bei AGM bedeutete der stille 1,25 fast eine Stunde Laufzeitfehler im Referenzfall (8,41 statt 9,33 h bei k=1,10) — als vermeintlicher Datenblattwert ohne jede Warnung. Genau der Fehler, vor dem der Rechner warnt ('Peukert stumpf anwenden'), nur eine Ebene tiefer: nicht in der Formel, sondern im Formular-Default.
Engine-Sonde 05.08.2026; Baender je Chemie aus den Datenblatt-Bandbreiten der Engine-Konstanten
engine/c-rateMethodFeinschliff am C-Raten-Rechner (35): FAQ von 6 auf 11 je Sprache (u. a. warum Datenblattgrenzen nicht geraten werden, Auswege bei gesprengtem Spitzenfenster in sinnvoller Reihenfolge, Parallelverband-Umrechnung), Methodiktext mit Referenzzahlen (180 A/45 s gegen 200 A/30 s — die Stromhoehe passt, die Dauer nicht). Rechnerisch unveraendert: Der Rechner war bereits vollstaendig — alle Schema-Felder erreichbar, Verweigerungs-Muster ohne Klassenannahmen, Zeitfenster-Pruefung intakt.
Bestandsaufnahme nach Checkliste ohne Korrekturbedarf am Rechenwerk — der erste Rechner des Durchgangs, bei dem die Pruefung nichts Strukturelles fand. Die Verweigerung, Datenblattgrenzen zu raten, traegt die Seite auch redaktionell: Klassenwerte streuen je BMS um ein Vielfaches und waeren genau die Art stiller Annahme, die dieser Durchgang ueberall sonst entfernt hat.
Referenzzahlen per Engine-Sonde und Live-Seite verifiziert
engine/cycle-life-costDataDie Zyklenkosten (34) zeigen die Marktspanne der gewaehlten Chemieklasse als Referenz NEBEN dem eigenen Anschaffungspreis (aus batteries/comparison-specs.json, nur fuer die belegte 12-V-Blockklasse; Preisalter ueberwacht). Die Verweigerungs-Philosophie bleibt unangetastet: Zyklenzahl und Preis sind weiterhin Datenblatt- bzw. Angebotswerte, die Spanne ist nie Rechenwert. Beispiel und Vorgabe von 800 auf 160 EUR umgestellt — das Marktmittel der 100-Ah-LiFePO4-Klasse 08/2026.
Die 800 EUR der 2025er-Spezifikation entsprachen der Markenklasse und ergaben 23,7 ct je durchgesetzter kWh; zum Marktmittel sind es 4,75 ct. Der Unterschied traegt eine Einordnung, die vorher fehlte: Speicherung selbst ist nicht mehr der Engpass der Wirtschaftlichkeit (Spread Netz/Einspeisung ~23 ct) — entscheidend ist der verfuegbare Ueberschuss. Preise unterhalb der Spanne werden als 'Zellqualitaet pruefen' markiert, darueber als Markenaufschlag.
batteries/comparison-specs.json (Einzelhandels-Stichprobe 05.08.2026); Referenzfall-Zahlen per Engine-Sonde verifiziert
batteries/comparison-specsDataNeuer versionierter Datensatz fuer den Chemie-Vergleich (33): Preis, Masse, Volumen, Zyklen und Lade-C-Rate je Chemie (LiFePO4, AGM, Gel, Nasszelle) aus einer Einzelhandels-Stichprobe 05.08.2026 plus Herstellerdatenblaettern; Quartalspflege gemeinsam mit prices/pv-de.json. Die Kandidaten des Rechners kommen jetzt per Schalter aus diesem Datensatz — vorher standen sie mit allen Kennwerten fest in der Beispielrechnung, und keine andere Kombination war erreichbar. Golden-Test friert beide Datensaetze ein.
Der LiFePO4-Preis der Beispielrechnung (3,50 EUR/Ah) stammte aus der 2025er-Spezifikation und war 08/2026 DOPPELT so hoch wie der Markt (119-196 EUR je 100-Ah-Block, also 1,2-2,0 EUR/Ah). Damit kippt die Kernaussage: Fuer 2 kWh nutzbar kostet LiFePO4 jetzt 293 EUR gegen 533 EUR AGM — Lithium ist auch in der ANSCHAFFUNG guenstiger, nicht mehr nur ueber die Lebensdauer (Durchsatz: 3,7 gegen 53,3 ct/kWh, Faktor 14). Der alte Preis haette AGM als Sparoption gezeigt, die es nicht mehr gibt.
Einzelhandel 05.08.2026: LiFePO4 100 Ah 119-196 EUR (winnerbatterien.de, batteriespezialist.de, langzeitbatterien.de), AGM 124-213 EUR (vergleich.org-Stichprobe, solarbatterie.com), Gel 145-174 EUR (versorgungsbatterie.de, langzeitbatterien.de); Gewichte LiTime/ExpertPower/SOLIS-Datenblaetter; Nasszelle ohne belastbaren Anker (breite Spanne, im Datensatz begruendet)
engine/loss-chainFixDie Verlustkette (12) hat sechs bisher unerreichbare Schema-Felder als Formularfelder bekommen — darunter den Round-Trip-Wirkungsgrad der Batterie, ohne den der sichtbare Schalter 'ueber Batterie gefuehrt' wirkungslos war (unerreichbare Vorgabe 1,0 = verlustfrei). Neu ausserdem die Plausibilitaets-Kopplung von Reglertyp und Wirkungsgrad: PWM mit mehr als 90 % wird als Widerspruch benannt (typisch 70-85 %), statt still einen Regler zu rechnen, den es nicht gibt (Muster aus Rechner 3: zwei Felder, dieselbe Physik).
Der Schalter-Defekt war die stillste Form eines toten Bedienelements: sichtbar, klickbar, folgenlos — nur die Engine-Warnung 'ausserhalb des Gueltigkeitsbereichs' deutete darauf hin, und das Feld zum Beheben fehlte. Mit 90 % Round-Trip sinkt der Systemwirkungsgrad des Vorgabefalls von 72,7 auf 65,4 %. Die FAQ beziffern jetzt auch den additiven Fehler der vollen Kette: 69,0 statt 72,7 % — fast vier Punkte, nicht die harmlosen 0,94 des Drei-Glieder-Beispiels.
PVGIS-Konvention multiplikativer Verknuepfung; Wirkungsgradspannen MPPT/PWM aus den Engine-Konstanten (Datenblatt-Bandbreiten)
engine/voc-temperatureFixFeinschliff am Voc-Rechner (11), dem Ursprung der Standort-Gegenprobe: Die Verkettung zu den Rechnern 5 und 10 uebergab die Modulspannung NICHT, weil sie dort moduleVocV und hier vocStcV heisst — alle drei Rechner echoen die Groesse jetzt unter beiden Namen (vierter Fall des Handoff-Echo-Musters). Die Warnschwelle der Spannungsreserve (fest 5 %) ist als erweitertes Feld erreichbar — noetig fuer Hersteller, die Toleranzaufschlaege auf V_oc verlangen. FAQ von 6 auf 11 je Sprache, Methodiktext mit Referenzzahlen (13 statt 14 Module) und ausgewiesenen Grenzen.
Der wichtigste sicherheitskritische Rechner des Katalogs war rechnerisch korrekt, aber in der Kette isoliert: Wer im String-Rechner eine Konfiguration geprueft hatte, musste die Modulspannung hier von Hand neu eintragen — und Uebertragungsfehler an genau dieser Stelle sind der Fehler, den der Rechner verhindern soll.
Voc-Kern geteilt mit Rechner 5/10; Standortminima data/climate/design-temps.json
engine/string-configMethodDie String-Verschaltung (10) prueft die eingetragene Auslegungstiefsttemperatur jetzt gegen das TMY-Minimum des Standorts — dieselbe Gegenprobe wie in den Rechnern 5 und 11, aus dem gemeinsamen Modul des Voc-Kerns; ohne Standortwert wird die Temperatur ausdruecklich als Annahme benannt. Fuenf bisher unerreichbare Schema-Felder sind als Formularfelder zugaenglich: MPP-Strom des Moduls (geht in Pruefung P4 ein), beide Temperaturkoeffizienten und die Norm-Systemspannungsgrenze (die kleinere aus Regler- und Normgrenze gilt).
Ein sicherheitskritischer Rechner nahm seine kritischste Eingabe ungeprueft entgegen: Wer -5 °C eintrug, obwohl der Standort -7,9 °C erreicht, bekam eine Matrix ohne jeden Hinweis — dieselbe Luecke, die bei Rechner 5 am 05.08.2026 geschlossen wurde. Bewusst KEINE automatische Uebernahme (typisches Jahr ist kein Extremjahr; der Auslegende bleibt verantwortlich). Der unerreichbare MPP-Strom bedeutete, dass die Stromprüfung P4 fuer jedes fremde Modul mit dem Beispielwert 10,15 A lief.
Auslegungstiefsttemperaturen data/climate/design-temps.json (PVGIS-TMY-Ableitung); Voc-Kern und Gegenprobe geteilt mit Rechner 5/11
engine/system-voltageDataDie Systemspannungswahl (9) hat fuenf bisher unerreichbare Schema-Felder als Formularfelder bekommen: Kabelpreis je mm2/m, Spitzenleistung, Leitermaterial, Leitertemperatur und Wechselrichter-Wirkungsgrad. Der Kabelpreis — er entscheidet die halbe Empfehlung — war fest auf 0,35 EUR gesetzt; recherchierter Marktanker 05.08.2026 (batterie24.de, H07V-K feindraehtig): 25 mm2 -> 0,256, 50 mm2 -> 0,190 EUR je mm2/m. Neue Vorgabe 0,25 EUR mit Spanne 0,15-0,50 als sichtbare Annahme. Zusaetzlich echot Rechner 4 seine Lasten unter den Feldnamen dieses Rechners, damit die Verkettung Dauer- und Spitzenleistung uebergibt (dritter Fall des Handoff-Echo-Musters).
Der alte Festpreis ueberzeichnete die Kabelkosten um 40 Prozent (Referenzfall 12 V: 140 statt 100 EUR). An der Empfehlung des Referenzfalls aendert das nichts (48 V ohne Altlasten, 12 V mit 240 W Altgeraeten und 150 EUR Wandler), aber nahe der Kippgrenze entschied ein nicht erreichbarer, zu hoher Preis die Empfehlung. Jetzt ist er sichtbar, begruendet und aenderbar.
Einzelhandelspreise H07V-K batterie24.de, abgerufen 05.08.2026 (25 mm2: 6,40 EUR/m; 50 mm2: 9,50 EUR/m)
engine/generator-sizingMethodDie Generator-Dimensionierung (8) zaehlt Defizittage und Tagesluecke jetzt je Tag des TMY-Jahres aus Standort und Anlagengroesse, statt drei Solargroessen schaetzen zu lassen (Solarertrag 1.000 Wh/d, 120 Defizittage, 0,8 Auslegungs-PSH). Die Anlagengroesse traegt denselben Feldnamen wie in Rechner 2, damit die Verkettung sie uebergibt. Vier bisher unerreichbare Schema-Felder (Dauerlast, Ladewirkungsgrad, Systemwirkungsgrad, Modulpreis) sind als Formularfelder zugaenglich; die Schaetzfelder bleiben hinter einem Schalter erreichbar.
Fuer 3.000 Wh/d und 1.200 Wp in Berlin sind es 187 Defizittage statt der angenommenen 120 — dieselbe Richtung wie bei Rechner 45 (aus 5 wurden 146). Die mittlere Luecke sinkt zugleich von 2.000 auf 1.765 Wh, und der Grenzkostenvergleich kippt deutlich zu Gunsten der Module: Break-even 5,3 statt 10,7 Jahre, weil die Schaetzwerte die Generatorstunden unter- und die noetige Modulleistung ueberschaetzten. Tagesaufloesung statt Monatsmittel, weil ein Monat im Mittel decken kann und trotzdem Defizittage enthaelt; Speicheruebertrag zwischen Tagen bleibt ausgewiesene Grenze (Rechner 45).
Stundenreihen PVGIS-SARAH3 TMY (Kette wie Rechner 27/43); Kraftstoffpreis ADAC-Bundesmittel 29.07.2026 als sichtbare Annahme
engine/autonomy-runtimeMethodDie Autonomie-Laufzeit (7) bezieht den Kaeltefaktor jetzt aus der Kennlinie der gewaehlten Chemie — bei Aufstellung im Freien bei der Monatsmitteltemperatur des Standorts fuer den gewaehlten Monat (Schalter-Muster aus Rechner 3/6). Der Wechselrichter-Leerlauf kommt aus dem Geraetekatalog fuer die Klasse der Last (wie Rechner 4) und entfaellt bei reiner DC-Last. Drei bisher unerreichbare Schema-Felder sind als Formularfelder zugaenglich: Peukert-Exponent (Datenblattwert mit Vorrang), Startladezustand und Kaeltefaktor (hinter Schaltern).
Der Kaeltefaktor stand fest auf 1,0 — Zimmertemperatur, unabhaengig vom Aufstellort — und war nicht erreichbar. Im Referenzfall (100 Ah LiFePO4, 100 W, aussen in Berlin, Januar) sinkt die Laufzeit von 7,4 auf 6,3 Stunden (Faktor 86 % bei 0,6 °C); mit AGM sind es 5,2 Stunden. Gleichzeitig sinkt der Leerlauf von pauschalen 20 W auf den Katalogwert 10 W der 1-kW-Klasse — zwei gegenlaeufige Korrekturen, deren Summe die alte Zahl (6,8 h) zufaellig fast traf, aber aus den falschen Gruenden.
Kennlinien data/batteries/chemistries.json; Leerlaufklassen data/appliances/catalogue.json; Temperaturreihen PVGIS-SARAH3 TMY; Peukert-Spannen je Chemie aus den Datenblatt-Bandbreiten der Engine-Konstanten
engine/sizing-fallbacksFixNachpruefung der zehn zuletzt ueberarbeiteten Rechner (47-50, 1-6) gegen den Projektstandard. Behoben: (a) Stille Rueckfaelle — die Rechner 2, 4, 5, 47 rechneten ohne aufloesbaren Standort wortlos mit Annahmewerten weiter; jetzt benennt jeder Rueckfall die Annahme als Warnung (Muster CABIN_PSH_ASSUMED). Rechner 2 fiel dabei sogar auf einen falschen Schema-Vorgabewert von 1,0 statt 1,07 Sonnenstunden zurueck. (b) Rechner 3 meldete im Aussen-Modus ohne Standortwert irrefuehrend 'eigene Angabe'. (c) Rechner 6: Standort- und Monatsfeld waren im Konstantmodus ausgeblendet, wirkten aber auf die Batterietemperatur — beide jetzt immer sichtbar. (d) Rechner 1 uebergab seine Kernzahl NICHT an die Folge-Rechner: Die Verkettung matcht auf gleichnamige Schluessel, der Tagesbedarf hiess im Ergebnis aber anders; jetzt Echo unter dem erwarteten Namen. (e) Vier fehlende Standort-Goldens ergaenzt (r03/r04/r05/r06-site), Beschreibungstexte der zehn Rechner auf das neue Kernmerkmal nachgezogen.
Die stillen Rueckfaelle waren genau die Fehlerklasse, gegen die das Projekt gebaut ist: Ein Nutzer in London bekam von Rechner 2 eine Modulzahl aus erfundenen 1,0 Sonnenstunden ohne jeden Hinweis. Die Verkettungsluecke bedeutete, dass der meistbeworbene Uebergabepfad (Lastprofil -> Modul-/Batterie-/Wechselrichter-Auslegung) seit jeher leere Parameter uebergab.
Systematische Nachpruefung am 05.08.2026: Engine-Sonden ohne Standortreihen, Browser-Gegenproben mit Standort ausserhalb des DACH-Rasters (London), Handoff-Links im Live-DOM
engine/charge-timeMethodDer Ladezeit-Rechner (6) nimmt die Batterietemperatur jetzt aus dem Monatsmittel des Standorts, wenn die Batterie im Freien oder im Fahrzeug steht (neuer Schalter fuer den Aufstellort, Muster aus Rechner 3). Bewusst das VOLLE Monatsmittel, nicht das Mittel der Sonnenstunden: Eine Batterie kuehlt nachts aus und wird morgens geladen — anders als ein Modul, das nur waehrend der Erzeugung warm wird. Ausserdem ist die Ausrichtung der Module im Solarmodus ueberhaupt erst einstellbar; sie stand im Rechenkern fest auf Sued.
Die Vorgabe von 20 °C machte die chemieabhaengige Ladesperre wirkungslos: LiFePO4 darf unter 5 °C nicht geladen werden, NMC nicht unter 10 °C, aber bei 20 °C konnte diese kritische Warnung an keinem Standort und in keinem Monat erscheinen. Im Januar in Berlin liegt das Monatsmittel bei 0,6 °C — die Warnung erscheint jetzt und ist dort der wichtigste Satz der Seite. Die fehlende Ausrichtung war eine unerreichbare Eingabe: Dieselben 400 Wp liefern im Januar nach Osten 193 statt 322 Wh am Tag.
Ladeprofile data/batteries/charging.json (Victron, Trojan, Panasonic, Abruf 03.08.2026); Temperatur- und Einstrahlungsreihen PVGIS-SARAH3 TMY
engine/charge-controllerMethodDer Laderegler-Rechner (5) prueft die eingetragene Auslegungstiefsttemperatur jetzt gegen das TMY-Minimum des Standorts — dieselbe Gegenprobe wie in Rechner 11, mit dem er den Voc-Rechenkern teilt; sie liegt jetzt in einem gemeinsamen Modul. Bewusst KEINE automatische Uebernahme: Bei einer sicherheitskritischen Groesse setzt der Auslegende die Zahl und das Werkzeug prueft sie. Die MPPT-Amortisation rechnet mit dem JAHRESMITTEL der Sonnenstunden des Standorts statt mit festen 3,0; Strompreis und Regler-Aufpreis sind ueberhaupt erst als Felder erreichbar.
Die Spannungspruefung ist der sicherheitskritische Teil dieses Rechners, und die Temperatur dafuer war eine ungepruefte Eingabe: Wer -5 °C eintraegt, obwohl der Standort -7,9 °C erreicht, bekommt jetzt eine Warnung statt einer stillen Fehlauslegung. Bei der Wirtschaftlichkeit wurde ausserdem ein Bezugsfehler korrigiert, der beim Umstellen entstand: Mit dem Auslegungsmonat (Dezember, 1,03 h/d) haette die MPPT-Amortisation 11,0 Monate betragen, mit dem Jahresmittel (3,58 h/d) sind es 3,2. Bei einer Anlage nahe der Fuenf-Jahres-Grenze haette die falsche Bezugsgroesse die Empfehlung gekippt.
Auslegungstiefsttemperaturen data/climate/design-temps.json; Sonnenstunden PVGIS-SARAH3 TMY; Strompreis data/tariffs/de.json (BNetzA/SMARD, Bestandskundenmittel)
engine/inverter-sizingMethodDie Wechselrichter-Auslegung (4) bezieht den Leerlaufverbrauch jetzt aus dem versionierten Geraetekatalog — und zwar fuer die Geraeteklasse, die der Rechner selbst ermittelt (naechstgroessere Klasse; oberhalb der groessten wird NICHT hochgerechnet). Die Sonnenstunden fuer die Umrechnung der Leerlaufverluste in Modulleistung kommen aus dem Stundenjahr des Standorts, im Auslegungsmonat und in Modulebene. Der Modulpreis ist ueberhaupt erst als Feld erreichbar; der Marktdatensatz liefert den Spotwert als sichtbaren Vergleich, NICHT als Rechenwert.
Die Leerlaufbilanz ist das Alleinstellungsmerkmal dieses Rechners — sie ruhte auf drei ungeprueften Zahlen, von denen zwei nicht einmal im Formular standen: 25 W Leerlauf, 3,0 Sonnenstunden, 0,60 EUR je Wp. Die 25 W waren der Katalogwert der 3-kW-Klasse, angewandt auf jede Anlagengroesse. Im Referenzfall (750 W Dauerleistung, also 1-kW-Klasse) sind es 10 W: 240 statt 600 Wh am Tag, 10 statt 25 Prozent des Tagesbedarfs. Die Ersatz-Modulleistung steigt dennoch von 67 auf 77 Wp, weil die Sonnenstunden von 3,0 auf 1,03 fallen — zwei Korrekturen, die einander entgegenlaufen.
Geraetekatalog data/appliances/catalogue.json (Leerlaufklassen 1 kW und 3 kW); Sonnenstunden PVGIS-SARAH3 TMY; Modul-Spotnotierung data/prices/pv-de.json (pvXchange 07/2026, ausdruecklich keine Endkundenpreise)
engine/battery-bankMethodDie Batteriebank (3) bezieht den Kaeltefaktor jetzt aus der Kennlinie der gewaehlten Chemie und — bei Aufstellung im Freien oder im Fahrzeug — die Auslegungstemperatur aus dem Klimadatensatz des Standorts (1-%-Perzentil der Tagesminima, dieselbe Quelle wie Rechner 11). Neuer Schalter fuer den Aufstellort: Drinnen bleibt die Temperatur eine benannte Angabe des Nutzers, weil der Standortwert dort die falsche Zahl waere. Zwischen Kennlinienpunkten wird linear interpoliert, darueber hinaus bewusst NICHT extrapoliert.
Vorher standen ZWEI unabhaengige Annahmen nebeneinander — Mindesttemperatur 10 °C und Faktor 0,90 —, und sie passten nicht zueinander: Die LiFePO4-Kennlinie gibt bei 10 °C 0,95, bei -5 °C dagegen 0,77. Man konnte also eine kalte Temperatur mit einem warmen Faktor kombinieren, ohne dass etwas widersprach. Im Referenzfall (2.400 Wh/d, 2 Tage, 24 V) sind es innen 329 Ah, im Freien in Berlin 403 Ah — 22 % mehr allein wegen der Temperatur. Zugleich loest der Standortwert die kritische Warnung zur Ladesperre aus, die bei der frueheren Vorgabe von 10 °C ausblieb.
Kennlinien data/batteries/chemistries.json; Auslegungstiefsttemperaturen data/climate/design-temps.json (Ableitung aus den PVGIS-TMY-Stundenreihen des projekteigenen 1.155-Punkte-Rasters)
engine/array-sizingMethodDie Modul-Auslegung (2) bezieht Auslegungs-Sonnenstunden und Auslegungstemperatur jetzt aus dem Stundenjahr des Standorts, in der Ebene der eingestellten Module. Vorher stand beides als Vorgabewert im Formular: 1,07 h/d (Berlin, 35 Grad, Dezember) und 20 °C. Neu ist ausserdem die Wahl des Auslegungszeitraums (ganzjaehrig oder nur Sommer); der Auslegungsmonat ist dann der schwaechste Monat dieses Zeitraums. Die Lufttemperatur wird als Mittel der SONNENSTUNDEN gebildet — ein Modul wird nur warm, wenn es liefert.
Die geteilte Groesse dieses Rechners war eine feste Zahl, obwohl sie vollstaendig vom Standort und von der Montage abhaengt. Fuer 2.400 Wh/d ergeben sich in Berlin bei 35 Grad Sued 3.152 Wp (8 Module), flach montiert dagegen 6.683 Wp (17 Module) und bei reinem Sommerbetrieb 1.215 Wp (4 Module) — vorher gab das Formular in allen drei Faellen 8 Module aus. Die Auslegungstemperatur von 6,4 °C statt 20 °C senkt die Modultemperatur von 44,2 auf 30,6 °C und hebt den Systemwirkungsgrad um rund drei Prozentpunkte. Dass die alte Vorgabe fuer Berlin dennoch nah lag, war Zufall: zu hohe PSH und zu warme Luft hoben sich teilweise auf.
PVGIS-SARAH3 TMY-Raster (1.155 Punkte, 2005-2023), kalibriert wie in den Rechnern 23-28; Modultemperatur nach Faiman, relativer Wirkungsgrad nach Huld
web/appliance-listMethodRechner 1 hat ein echtes Geraetelisten-Steuerelement bekommen. Bisher kannte das Formular nur Skalare, also stand dort dauerhaft die Liste der Beispielrechnung — die KERNEINGABE des Rechners war ueber die Oberflaeche nicht erreichbar. Jetzt: Auswahl aus dem versionierten Geraetekatalog (42 Eintraege, nach Kategorie gruppiert), Anzahl, Leistung und Betriebsstunden je Zeile, Tagesenergie unmittelbar daneben, Zeilen hinzufuegen und entfernen. Die Liste steht in der Zustands-URL und ist damit teilbar. Fuer Geraete, die beide Strompfade koennen (Laptop, Router, Fernseher), gibt es die Wahl DC/AC — sie kostet den Wechselrichterverlust.
Rechner 1 IST der Geraetelisten-Rechner und war bis dahin eine feste Beispielrechnung: Wer sein eigenes Fahrzeug oder Haus rechnen wollte, konnte kein einziges Geraet aendern. Er ist zugleich der Einstieg der Dimensionierungskette — sein Tagesbedarf geht in die Rechner 2, 3 und 4. Beispielliste auf Katalog-Kennungen umgestellt, damit das Auswahlfeld sie wiederfindet; das Ergebnis bleibt unveraendert (1.682 Wh/d). Zusaetzlich: Geraetenamen erscheinen jetzt uebersetzt in den Warnungen (vorher 'Die Einschaltdauer von fridge-compressor-230v ...'), und die frueher je Geraet wiederholten Meldungen sind zu einer zusammengefasst, die Anzahl und groessten Posten nennt.
Geraetekatalog data/appliances/catalogue.json (Herstellerdatenblaetter, EU-Energielabel-Datenbank EPREL, Off-Grid-Messreihen; abgerufen 15.07.2026)
engine/price-escalationMethodDie Strompreisentwicklung (50) leitet den jaehrlichen Eigenverbrauch jetzt aus dem Stundenjahr des Standorts und dem Haushaltslastprofil ab, statt ihn als Schaetzfeld mit der Vorgabe 2.000 kWh entgegenzunehmen. Die Eingabe bleibt hinter einem Schalter erreichbar, damit gemessene Werte Vorrang behalten.
Der Eigenverbrauch ist der Faktor VOR jedem Ergebnis dieses Rechners — er skaliert jedes Szenario, jeden Barwert und die Umkehrfrage. Fuer 10 kWp in Berlin mit 4.000 kWh Haushaltsverbrauch ergeben sich 1.650 kWh statt der angenommenen 2.000 kWh (16 % des Ertrags). Alle Barwerte sinken entsprechend um rund ein Fuenftel (flaches Szenario 7.633 statt 9.254 EUR), und die noetige Preissteigerung fuer eine Amortisation in zehn Jahren steigt von 13,95 % auf 17,89 % pro Jahr — eine Verdopplung alle vier statt alle fuenf Jahre. Die Kernaussage des Rechners wird dadurch nicht weicher, sondern schaerfer.
Stundenreihen PVGIS-SARAH3 TMY; Haushaltsprofil HTW-validiert (Rechner 43); Startpreis data/tariffs/de.json (BNetzA/SMARD Q3/2026)
i18n/stepsFixDreizehn Beschriftungen des Rechenwegs fehlten in beiden Sprachen; die Tabelle zeigte den rohen Schluessel. Weil sie in Grossbuchstaben gesetzt wird, las er sich wie eine Beschriftung ('STEPS.ANNUALAVOIDED') statt wie ein Fehler. Neues Gate 3d in check-i18n prueft die Schrittbeschriftungen aus zwei Quellen: `steps.push` im Quelltext und die Schrittlisten der Golden-Dateien.
Betroffen waren die Rechner 7, 12, 21, 33, 38, 44, 46, 48, 49 und 50 — darunter fertig geglaubte. Kein bestehendes Gate sah die Luecke: Die Schluessel entstehen erst zur Laufzeit aus dem Ergebnis des Rechners.
Sichtpruefung am 05.08.2026; Abgleich der Golden-Schrittlisten gegen beide Sprachdateien
web/calculator-formFixSchalterfelder aus der URL wurden als Text ('true') in den Formularzustand uebernommen. Das Schema erwartet einen Wahrheitswert und wies daraufhin die GESAMTE Eingabe zurueck. Das Formular wandelt Zustandsparameter jetzt nach Feldtyp um.
Jeder geteilte Link, in dem ein Schalter steht, zeigte statt eines Ergebnisses 'Die Eingaben sind nicht gueltig' — betroffen war jeder Rechner mit einem Schalter im Rechenschema (48, 49, 12, 33 und weitere). Der Fehler entstand beim Teilen oder Neuladen, nie beim Klicken selbst, und war deshalb im normalen Gebrauch unsichtbar.
Sichtpruefung mit Zustandsparametern am 05.08.2026
engine/co2-savingsMethodDie CO2-Bilanz (49) nimmt den Jahresertrag jetzt aus dem Stundenjahr des Standorts statt aus einem Schaetzfeld (Vorgabe 10.000 kWh). Zusaetzlich laesst sich der sinkende Emissionsfaktor des Strommixes zuschalten: linear fallend bis zu einem Jahr, das der Nutzer setzt — als offengelegte Rechenannahme, ausdruecklich NICHT als Prognose. Zur Einordnung nennt der Rechner die gesetzlichen Marken: KSG § 3 Abs. 2 (Netto-Treibhausgasneutralitaet bis 2045) und EEG § 1 Abs. 2 (mindestens 80 % erneuerbarer Strom bis 2030).
Die Lebensdauerbilanz rechnete 25 Jahre lang mit dem Strommix von heute — die stillste und zugleich folgenreichste Annahme des Rechners. Fuer 10 kWp in Berlin sinkt die Ersparnis im Szenario 2045 von 83.108 kg auf 34.245 kg, also um 59 % (mittlerer Faktor 142 statt 344 g/kWh). Netto bleiben nach Herstellung immer noch 29.245 kg, und die energetische Amortisation bleibt bei 1,42 Jahren — die Aussage ist nicht 'lohnt sich nicht', sondern 'der Nutzen faellt in die fruehen Jahre'. Der Rechner zeigt beide Raender: konstanter Mix als Obergrenze, linearer Rueckgang als Gegenstueck.
Emissionsfaktoren UBA-Datensatz data/emissions/de.json (Ausgabe 2026, abgerufen 01.07.2026); Zielmarken KSG § 3 Abs. 2 und EEG § 1 Abs. 2 (gesetze-im-internet.de, geprueft 05.08.2026); Ertrag PVGIS-SARAH3 TMY
engine/feed-in-revenueFixDer Einspeiseerloes (48) zog den Negativpreis-Anteil und den Deckelfaktor auch dann ab, wenn die zugehoerigen Schalter im Formular auf 'nicht aktiv' standen. Beide Abzuege haengen jetzt an ihrem Schalter; die Annahmefelder erscheinen nur noch, wenn die Regel ueberhaupt gilt.
Im Referenzfall (15 kWp Berlin, Negativpreisregel abgeschaltet) wurden 947 EUR statt 987 EUR ausgewiesen — 4 % zu wenig, ohne dass die Seite den Abzug irgendwo genannt haette. Ursache war das Zusammenspiel zweier Dinge: Formularfelder mit Vorgabewert werden immer gesendet, und die Formel wertete sie ohne Bezug auf ihren Schalter aus.
Sichtpruefung der ausgelieferten Seite am 05.08.2026 (Abweichung zwischen Engine-Sonde und Live-Seite)
engine/feed-in-revenueMethodDer Einspeiseerloes (48) leitet die eingespeiste Menge jetzt aus dem Stundenjahr des Standorts und dem Haushaltslastprofil ab, statt sie als Schaetzfeld entgegenzunehmen. Ebenso die Wirkung des 60-%-Deckels: Sie wird stundenweise gezaehlt (Verlust = Summe dessen, was ueber 0,6 * kWp hinausgeht), statt als Pauschalfaktor 0,94 im Formular zu stehen. Beide Eingaben bleiben ueber Schalter erreichbar, damit gemessene Werte Vorrang behalten. Der Anreicherungszweig musste verkettet werden — dritter Fall dieser Falle nach Rechner 52 und 47.
Der Pauschalfaktor lag deutlich daneben, und zwar zu pessimistisch: Fuer 15 kWp in Berlin kostet die Kappung 1,7 % der Einspeisung (234 kWh in 306 Stunden) statt der angenommenen 6 %. Nach Osten sind es 0,3 % (33 kWh in 76 Stunden). Der Grund ist physikalisch: Die Grenze wirkt auf die LEISTUNG und schneidet nur die Spitze ab; Eigenverbrauch senkt sie zusaetzlich, weil die Grenze am Netzverknuepfungspunkt gilt. Ein Faktor je Anlage kann das nicht abbilden.
EEG § 9 Abs. 2 (Solarspitzengesetz, Leistungsgrenze am Netzverknuepfungspunkt); Verguetungssaetze BNetzA-Datensatz; Ertrag und Stundenreihen PVGIS-SARAH3 TMY; Haushaltsprofil HTW-validiert (Rechner 43)
engine/cost-estimatorMethodDer Angebotspruefer (47) uebersetzt den Angebotspreis jetzt in Euro je Kilowattstunde JAHRESERTRAG — erst diese Zahl macht Angebote unterschiedlicher Groesse und unterschiedlicher Dachlage vergleichbar. Grundlage ist der spezifische Ertrag des Standorts aus der TMY-Kette. Dafuer musste der Anreicherungszweig verkettet werden: `cost-estimator` hatte ein FRUEHES return mit den Marktbaendern, das die TMY-Kette abgeschnitten haette (dieselbe Falle wie bei Rechner 52).
Der Rechner beantwortete bisher nur 'ist der Preis je kWp marktueblich'. Jetzt beantwortet er zusaetzlich 'was kostet mich damit die Kilowattstunde' — und macht sichtbar, dass zwei Angebote mit identischem kWp-Preis je nach Neigung, Ausrichtung und Standort deutlich verschiedene Werte liefern. Die Kilowattstunde ist das, was gekauft wird, nicht das Kilowatt.
Spezifikation Teil 3 Rechner 47; Marktbaender prices/pv-de.json (pvXchange/ISE 07/2026, gueltig bis 03.11.2026); Ertrag PVGIS-SARAH3 TMY
engine/generator-vs-solarMethodDer Generator-gegen-Solar-Rechner (46) leitet die Solarkosten je Jahres-Kilowattstunde aus dem SPEZIFISCHEN ERTRAG des Standorts ab, statt sie als Annahme (1,20 EUR/kWh) entgegenzunehmen: Anlagenkosten je kWp (neues Feld, Vorgabe 1.300 aus prices/pv-de.json) geteilt durch den gerechneten Jahresertrag je kWp.
Die Annahme war standortblind, dabei ist genau der Standort der Umrechnungsfaktor zwischen EUR/kWp und EUR je gelieferter Kilowattstunde. Berlin liefert 1.026 kWh/kWp, damit kostet die Anlage 1,27 statt angenommener 1,20 EUR je Jahres-kWh und die Solar-LCOE steigt von 10,9 auf 11,5 ct. In Suedeuropa mit gut 1.500 kWh/kWp faellt derselbe Wert auf etwa 0,87 EUR — der Generator kostet dagegen ueberall dasselbe, der Standort verschiebt den Vergleich also einseitig.
Spezifikation Teil 3 Rechner 46; Anlagenkosten prices/pv-de.json (pvXchange 07/2026); Ertrag PVGIS-SARAH3 TMY; Kraftstoffpreis ADAC 29.07.2026
engine/offgrid-vs-gridMethodDer Netz-gegen-Insel-Rechner (45) rechnet die Defizittage der Inselanlage aus dem Stundenjahr des Standorts, statt sie als Annahme (Vorgabe 5) entgegenzunehmen — neues Modul calculators/offgrid-deficit.ts mit derselben Dispatch-Kette wie Rechner 43. Neue Felder Standort, Anlagengroesse, Speicher, Haushaltstyp; Gate `overrideDeficit` fuer eigene Betriebswerte.
Die Annahme trug die gesamte Zuverlaessigkeitsaussage — und sie war um mehr als eine Groessenordnung zu optimistisch. Berlin, Haushalt mit 3.500 kWh: 5 kWp mit 10 kWh Speicher ergeben 146 Defizittage im Jahr, 10 kWp mit 20 kWh noch 63, und selbst 15 kWp mit 40 kWh kommen auf 32. Im schlechtesten Monat sind es 23 bis 30 Tage — praktisch jeden Tag im Dezember. Damit steht der Vergleich gegen die SAIDI-Groessenordnung des Netzes (rund eine Viertelstunde im Jahr) erstmals auf gerechneten Zahlen. Sichtbar wird ausserdem, dass mehr Speicher die Wintertage kaum senkt: Wenn der Tagesertrag unter dem Tagesbedarf liegt, verschiebt ein Speicher nichts mehr.
Spezifikation Teil 3 Rechner 45; Dispatch-Kette wie Rechner 43; Einstrahlung PVGIS-SARAH3 TMY
engine/storage-worth-itMethodDer Speicher-Rechner (44) rechnet den jaehrlich verfuegbaren Ueberschuss aus Standort, Anlagengroesse und Haushaltsprofil, statt ihn als Annahme (3.000 kWh) entgegenzunehmen — es ist die dritte seiner drei Schranken. Gate `overrideSurplus` fuer eigene Monitoring-Werte. Ausserdem korrigiert: Die Einspeiseverguetung stand auf 7,78 ct statt auf den verifizierten 7,70. Und die Speicher-Viz zeigte NEUN rohe i18n-Schluessel (viz.sw.*), die jetzt ergaenzt sind.
Die dritte Schranke war bisher blind. Mit gerechnetem Ueberschuss kippt der Rechner in genau den Faellen, in denen es darauf ankommt: 3 kWp bei 5.000 kWh Homeoffice-Verbrauch lassen in Berlin nur 1.362 kWh Ueberschuss — dann bindet nicht die Alterung, sondern die verfuegbare Energie, die Durchsatzkosten steigen von 18,52 auf 24,48 ct und die Marge dreht mit −1,08 ct ins MINUS. Der Speicher kostet dort Geld, statt welches zu sparen; mit der pauschalen Annahme von 3.000 kWh war dieser Fall nicht darstellbar.
Spezifikation Teil 3 Rechner 44; Ueberschuss aus der Stundenkette wie Rechner 43; EEG-Satz BNetzA 01.08.2026
engine/lcoeMethodDer LCOE-Rechner (42) leitet den Jahresertrag aus Standort und Anlagengroesse ab, statt ihn als Eingabe zu verlangen (annualYieldFromSite in payback-inputs.ts, dieselbe Leistungskette wie Rechner 27/28). Eigene Messwerte bleiben ueber einen Schalter moeglich. Ausserdem behoben: Die Speicher-Viz (Rechner 44) zeigte NEUN rohe i18n-Schluessel auf der Seite (viz.sw.*) — gefunden mit einem Scan aller Viz-Komponenten gegen die Locale.
Mit dem gerechneten Standortertrag (10.256 statt runder 10.000 kWh) sinken die Gestehungskosten von 7,72 auf 7,55 ct/kWh — und damit dreht die Kernaussage des Rechners: Die Marge gegenueber der Einspeiseverguetung von 7,70 ct ist nicht mehr negativ, sondern mit +0,15 ct knapp positiv. Einspeisen traegt sich also gerade, verdient aber nichts; der Hebel bleibt der Eigenverbrauch (31,1 ct gegen 7,7 ct). Die Aussage ist standortabhaengig und kippt bei schlechterem Ertrag zurueck ins Minus.
Spezifikation Teil 3 Rechner 42; Ertrag PVGIS-SARAH3 TMY; EEG-Satz BNetzA 01.08.2026
engine/payback-gridMethodDer Amortisations-Rechner (41) rechnet Jahresertrag und Eigenverbrauchsquote jetzt selbst, statt sie als Eingaben zu verlangen: Standort, Anlagengroesse und Haushaltsprofil laufen durch dieselbe Stundenkette wie die Rechner 28 und 43 (neues Modul calculators/payback-inputs.ts). Eigene Zahlen behalten Vorrang und stehen unter den erweiterten Annahmen. Dazu Feld-Hints fuer ALLE Felder — R41 war der einzige Rechner im Katalog ganz ohne.
Die beiden Zahlen bestimmen die Amortisation vollstaendig und waren die einzigen, die der Nutzer raten musste. Berlin, 10 kWp fuer 10.150 EUR bei 31,1 ct: Mit den bisherigen Vorgabe-Literalen (9.500 kWh / 30 Prozent) ergaben sich 7,90 Jahre einfach und 9,12 diskontiert. Gerechnet sind es fuer einen Familienhaushalt mit 4.000 kWh 9,72 / 11,63 Jahre und fuer einen Berufstaetigen-Haushalt mit 3.000 kWh 11,09 / 13,66 Jahre — die Faustzahlen lagen also zwei bis drei JAHRE zu optimistisch, und zwar bei dem Rechner, dessen Aufgabe es ist, genau solche Schoenrechnerei zu entlarven. Der Grund liegt nicht am Ertrag (gerechnet 10.256 statt angenommener 9.500 kWh), sondern an der Eigenverbrauchsquote: gerechnet 16 Prozent fuer den Familienhaushalt und 11 Prozent fuer den Berufstaetigen-Haushalt statt der ueberall zitierten 30.
Spezifikation Teil 3 Kapitel 10; Stundenkette wie Rechner 28/43 (PVGIS-SARAH3 TMY + Haushaltsprofil Spez 9.1 Weg B); EEG-Satz BNetzA 01.08.2026
engine/blackoutMethodDer Blackout-Rechner (62) kennt jetzt die Nachladung: Aus Modulleistung und den Peak Sun Hours des Standorts (site-solar.ts) entsteht je Monat die Frage, ob die Anlage die Notlast traegt — und wenn nicht, wie viele TAGE der Vorrat reicht. Neue Felder Standort und Modulleistung, neue KPI-Kachel, zwei neue Warncodes.
Ohne PV beantwortet der Rechner 'wie viele Stunden', mit PV 'wie viele Monate'. Berlin, 200 Ah LiFePO4, 61 W Notlast: Batterie allein 26,7 h. Mit 400 Wp traegt die Anlage in 3 von 12 Monaten, mit 1.000 Wp in 9, mit 2.000 Wp in 11 Monaten; im jeweils schlechtesten Monat 1,4 / 2,2 / 96,9 Tage. Der Unterschied zwischen Juli und Januar ist damit groesser als jeder Batteriezuschlag.
Spezifikation Teil 3 Rechner 62; Einstrahlung PVGIS-SARAH3 TMY
engine/starlinkMethodDer Starlink-Rechner (58) beziffert jetzt die noetige MODULLEISTUNG fuer den Dauerbetrieb je Monat am Standort, nicht nur den Verbrauch. Grundlage sind die Peak Sun Hours aus dem TMY-Raster (calculators/site-solar.ts) und der Tagesverbrauch an der oberen Bandkante. Neue Felder Standort und Neigung, neue KPI-Kachel, zwei neue Warncodes.
Die Kernfrage lautet 'Starlink autark betreiben', und die Antwort haengt an einer 24/7-Last, die im Dezember auf einen Bruchteil der Einstrahlung trifft. Berlin, Standard Gen 3: 311 Wp im besten, 1.720 Wp im schlechtesten Monat — Faktor 5,5. Mini 140/774 Wp, Flat High Performance 533/2.948 Wp. Damit ist die verbreitete Annahme, ein paar hundert Watt reichten, mit einer Zahl widerlegt.
Spezifikation Teil 3 Rechner 58; Terminaldaten appliances/starlink.json (Hersteller-Spec-Sheets); Einstrahlung PVGIS-SARAH3 TMY
engine/water-pumpMethodDer Brunnenpumpen-Rechner (57) rechnet die Laufzeit einer direkt gekoppelten Solarpumpe aus den Stundenreihen des Standorts: Die Pumpe laeuft, solange die Modulleistung ueber ihrer Aufnahme liegt. Daraus folgen Laufstunden und Foerdermenge je Monat sowie die Jahresmenge. Neue Felder Standort und Modulleistung; die Betriebsstunden-Eingabe bleibt Rueckfall ohne Standort.
Die eigentliche Nutzerfrage lautet nicht 'wie viel Watt', sondern 'wie viele Kubikmeter am Tag' — und die Antwort haengt an einer Schwelle, nicht an einem Mittelwert. Berlin, 2 m3/h bei 234 W: An 800 Wp sind es 15,2 m3/d im besten und 1,6 m3/d im schlechtesten Monat (3.216 m3/a). An 400 Wp faellt die Foerderung im Dezember auf NULL, weil die Anlaufschwelle in keiner Stunde erreicht wird. Zusaetzlich sichtbar: Der Wechsel von 25 auf 32 mm Rohr senkt die Aufnahme auf 205 W und bringt 8 Prozent mehr Jahreswasser.
Spezifikation Teil 3 Rechner 57; Einstrahlung PVGIS-SARAH3 TMY
engine/air-conditioningMethodDer Klimaanlagen-Rechner (56) rechnet Auslegungsfall, Teillastgrad und Betriebsstunden aus den Stundenreihen des Standorts, statt sie als drei Annahmen entgegenzunehmen (neues Modul calculators/cooling-hourly.ts). Die Kuehllast entsteht je Stunde aus Transmission, solarem Eintrag auf der SENKRECHTEN Fensterebene (Perez-Transposition wie in den Ertragsrechnern) und inneren Lasten; die Auslegungslast ist das 99. Perzentil der Kuehlstunden. Dafuer gibt simulateTmyYear die stuendliche POA jetzt optional heraus (collectHourlyPoa).
Die drei Annahmen — 32 Grad Auslegung, 0,5 Teillast, 8 Betriebsstunden — bestimmten zusammen das Ergebnis; der Quelltext nannte den Teillastgrad selbst 'die entscheidende Groesse, leicht falsch angesetzt'. Fuer einen 60-Kubikmeter-Raum mit Suedfenster bei Berlin ergibt die Stundenrechnung 474 Kuehlstunden im Jahr, 5,2 Betriebsstunden je Tag statt 8, Teillast 56 Prozent und einen Auslegungspunkt bei 30 statt 32 Grad — der Tagesverbrauch faellt von 3.250 auf 2.110 Wh. Neu sichtbar: Ein Westfenster verschiebt den Auslegungspunkt auf 34 Grad, weil solare Spitze und Tageshoechsttemperatur zusammenfallen.
Spezifikation Teil 3 Rechner 56; Temperatur und Einstrahlung PVGIS-SARAH3 TMY
engine/fridgeMethodDer Kuehlschrank-Rechner (55) bekommt den Jahresgang: Aus der stuendlichen Temperaturreihe des Standorts entstehen Monatsmittel, daraus der Verbrauch je Monat und der Jahresverbrauch. Der eingegebene Auslegungswert wird gegen den waermsten Monat des Standorts geprueft und bei mehr als 5 Kelvin Abweichung gemeldet. Dabei umbenannt: Das Feld 'location' hiess bisher gleichzeitig Aufstellort (Fahrzeug/Keller) und waere mit dem Koordinatenfeld der Anreicherung kollidiert — es heisst jetzt 'placement'.
Die Auslegungstemperatur war eine reine Schaetzung, und sie treibt den Verbrauch fast linear. Jetzt steht neben der Tageszahl (328 Wh im Referenzfall) der Jahresverbrauch am Standort (75 kWh) — beides sind verschiedene Fragen: Die Anlage bemisst sich am Auslegungsfall, die Stromkosten am Jahr. Eine naive Hochrechnung der Tageszahl haette 120 kWh ergeben, also 60 Prozent zu viel.
Spezifikation Teil 3 Rechner 55; Temperaturreihe PVGIS-SARAH3 TMY (1.155 DACH-Rasterpunkte)
engine/heat-pumpMethodDer Waermepumpen-Rechner (60) rechnet die Ueberschneidung von PV-Ertrag und Waermepumpenstrom stundenscharf, statt sie ueber den Eingabewert daytimeShare zu schaetzen (neues Modul calculators/heat-pump-hourly.ts). Der Waermebedarf verteilt sich per GRADSTUNDEN auf die 8.760 Stunden des TMY-Jahres, Warmwasser gleichverteilt; die Deckung je Stunde ist min(PV_h, WP_h). Damit wechselt der Rechner ausserdem vom alten 12-Staedte-Datensatz wave-1 auf das 1.155-Punkte-Stundenraster, mit dem alle uebrigen Ertragsrechner arbeiten. Der Monatsweg bleibt als Rueckfall ohne Standort.
Die pauschale Annahme hat den Nutzen fast verdoppelt: Fuer 10 kWp und 14.000 kWh Waerme bei Berlin ergibt die Stundenrechnung 25 Prozent Jahresdeckung (Winter 19, Sommer 49) statt der rund 46 Prozent, die der 50-Prozent-Tagesanteil lieferte. Die Kernaussage des Rechners — PV und Waermepumpe laufen gegenlaeufig — steht damit erstmals auf gerechneten statt geschaetzten Zahlen.
Spezifikation Teil 3 Rechner 60; Gradstunden-Methode analog Gradtagzahl; Einstrahlung und Temperatur PVGIS-SARAH3 TMY
engine/ev-chargingMethodDer Ueberschussladen-Rechner (59) rechnet die Ueberschuss-Dauerlinie jetzt selbst, statt sie als Liste zu verlangen. Sie entsteht aus derselben Stundenkette wie Rechner 43: Stundenertrag der Anlage aus dem TMY-Raster des Standorts, davon die Haushaltslast aus dem synthetischen Profil abgezogen, der Rest absteigend sortiert (neues Modul calculators/surplus-curve.ts). Neue Felder Standort, Anlagengroesse, Jahresverbrauch, Haushaltstyp, Neigung und Ausrichtung. Eine GEMESSENE Kurve bleibt moeglich und hat Vorrang; die Warnung 'ist eine Eingabe' erscheint nur noch dann, sonst die neue Simulationswarnung.
Die Kerneingabe des Rechners war ueber das Formular nicht erreichbar: Das generische Formular kann keine Listen, also stand dort dauerhaft die Beispielkurve — jede Eingabe des Nutzers aenderte das Ergebnis nur am Rand. Jetzt rechnet die Seite den konkreten Fall: 10 kWp bei Berlin mit 4.000 kWh Haushaltsverbrauch ergeben 8.606 kWh Ueberschuss in 3.090 Stunden, davon einphasig 8.014 und dreiphasig 5.151 kWh ladbar. Nebenbei korrigiert: Die Einspeiseverguetung stand auf 7,9 ct statt auf den verifizierten 7,7 ct.
Spezifikation Teil 3 Rechner 59; Stundenkette wie Rechner 43 (PVGIS-SARAH3 TMY + Haushaltsprofil Spez 9.1 Weg B); EEG-Satz BNetzA, Stand 01.08.2026
engine/cabinMethodDer Gartenhaus-Rechner (53) leitet den Auslegungsmonat je Saison jetzt AB, statt ihn anzunehmen: Er ist der schwaechste Monat, den die Saison enthaelt, gerechnet aus dem TMY-Stundenraster fuer die eingegebene Dachneigung und -ausrichtung (neue Felder). Die beiden geschaetzten Peak-Sun-Hour-Werte (4,5 Sommer / 0,8 Winter) sind aus dem Formular entfernt und bleiben nur als Rueckfall ohne Standort. Der Solarzweig aus den Rechnern 51/52 wurde dafuer neigungsfaehig gemacht (calculators/site-solar.ts) und um weakestMonth erweitert.
Zwei Befunde, die die alten Annahmen verdeckt haben. Erstens: Der schwaechste Monat der Sommersaison April bis Oktober ist bei geneigter Flaeche der OKTOBER, nicht der April (45 Grad Sued bei Berlin: 2,88 gegen 3,97 Peak Sun Hours) — wer mit April rechnet, legt zu klein aus. Zweitens: Der oft genannte Faktor fuenf zwischen Saison- und Ganzjahresauslegung entsteht nur aus den pauschalen Annahmen; mit Standortdaten sind es 2,5 (298 gegen 752 Wp bei 600 Wh/Tag). Neu sichtbar wird ausserdem, dass eine steilere Flaeche ganzjaehrig deutlich hilft (70 Grad: 673 Wp) und in der Sommersaison fast nichts aendert.
Spezifikation Teil 3 Rechner 53; Einstrahlung PVGIS-SARAH3 TMY (1.155 DACH-Rasterpunkte, 2005-2023)
engine/boat-marineMethodDer Boot-Rechner (52) haengt wie Rechner 51 am TMY-Stundenraster: Die Peak Sun Hours des Auslegungsmonats kommen fuer das WAAGERECHTE Deck aus derselben kalibrierten Kette wie die Rechner 23 bis 28. Der Solarzweig ist dafuer aus van-rv-solar.ts nach horizontal-solar.ts verallgemeinert — Vandach und Bootsdeck sind dieselbe Geometrie, und beide Rechner geben damit fuer denselben Ort dieselbe Antwort. Neu: Auslegungsmonat als Feld, Monatsgang des Ertrags NACH Takelage-Abschlag gegen die Ankerlast, zwei eigene Warncodes. Das Feld 'Sonnenstunden' ist aus dem Formular entfernt (im Schema als Rueckfall belassen).
Die bisherige Vorgabe von 4,5 Peak Sun Hours war faktisch ein Hochsommerwert und galt ganzjaehrig. Im Berliner Revier liefert dasselbe Boot (300 Wp, 35 Prozent Takelage-Abschlag) im Juli 709 Wh am Tag, im Oktober 246 Wh und im Dezember 67 Wh — die Deckung der 24/7-Ankerlast faellt damit von 47 auf 16 auf 4 Prozent. Wer nach der alten Vorgabe auslegte und im September noch draussen war, hatte weniger als die Haelfte.
Spezifikation Teil 3 Rechner 52; Einstrahlung PVGIS-SARAH3 TMY; Regelfakten 33 CFR 183 Subpart I (gemeinfrei), ISO 13297:2020 + Amd 1:2022 als Verweis
engine/van-rvMethodDer Wohnmobil-Rechner (51) haengt am TMY-Stundenraster statt an einer Faustzahl: Die Peak Sun Hours des Auslegungsmonats kommen jetzt aus derselben kalibrierten Stundenkette wie die Rechner 23 bis 28, gerechnet fuer die WAAGERECHTE Dachflaeche (Neigung 0 Grad) — das ist beim Kastenwagen keine Vereinfachung, sondern die Bauform. Dazu der Auslegungsmonat als eigenes Feld (Vorgabe aus dem Reiseprofil) und die Monatsbilanz nach Quellen aus der Spezifikation: gestapelte Balken Solar plus Lichtmaschine je Monat gegen die Bedarfslinie. Das bisherige Feld 'Sonnenstunden im Auslegungsmonat' ist aus dem Formular entfernt — es zeigte weiter 0,8, waehrend das Ergebnis mit dem Standortwert rechnete; im Schema bleibt es als Rueckfall fuer Standorte ausserhalb des Rasters.
Der Jahresgang eines waagerechten Vandachs ist extrem und stand bisher in keinem Rechner: In Berlin liegen zwischen Dezember (0,49) und Juni (5,79) Peak Sun Hours Faktor 12. Damit kippt die Kernaussage des Rechners mit der Jahreszeit — im Juni fuehrt die Solaranlage (810 Wh gegen 486 Wh), im Dezember braeuchte man 1.424 Wp auf dem Dach, um den 30-A-Ladebooster zu ersetzen. Drei neue Warncodes machen Herkunft und Spreizung sichtbar.
Spezifikation Teil 3 Rechner 51; Einstrahlung PVGIS-SARAH3 TMY (1.155 DACH-Rasterpunkte, 2005-2023)
engine/snow-wind-loadFixDer Schnee- und Windlast-Grobcheck (32) unterscheidet jetzt die beiden Tragprinzipien, die die Spezifikation als Vergleich 'Aufdach gegen Aufstaenderung' verlangt: verschraubt dachparallel und aufgestaendert ballastiert. Vorher gab der Rechner auch fuer das 35-Grad-Schraegdach 255 kg Ballast je Modul aus — dort haelt aber der Dachhaken, nicht die Masse. Verschraubt ist die Antwort deshalb die Sogkraft je Befestigungspunkt (455 N) gegen die Auszugskraft des Herstellers; ballastiert bleibt es die Ballastmasse. Die Gegenueberstellung bleibt als eigener Wert erhalten. Dazu: Druck statt Sog wird erkannt (positiver Beiwert verlangte bisher Ballast gegen eine Kraft, die nach unten wirkt), die Leitblech-Abhaengigkeit des Beiwerts ist eine eigene Warnung, und die KPI-Kachel zeigt statt des Ballasts die gesamte Zusatzlast auf dem Dach — 600 kg verschraubt gegen 6.733 kg ballastiert.
Die vier neuen Warncodes und die Modusweiche beheben eine sachlich falsche Ausgabe: Ballast ist am Schraegdach nicht das Tragprinzip. Zusaetzlich weist der Rechner jetzt aus, was EN 1991-1-3:2025 fuer aufgestaenderte PV auf flachen Daechern neu regelt (unsymmetrische Anordnung mit Verwehung hinter jeder Reihe) und dass dieser Grobcheck sie NICHT rechnet — die zugaenglichen Sekundaerquellen widersprechen sich in den Details, und eine benannte Luecke ist bei einer sicherheitsrelevanten Rechnung besser als eine geratene Formel.
Spezifikation Teil 2 Rechner 32; EN 1991-1-3 (Schnee, mu_1 >= 0,8 bei Schneefang und Hindernissen), EN 1991-1-4 (Wind), EN 1990 (Teilsicherheitsbeiwerte); Ausgabestand EN 1991-1-3:2025 recherchiert 04.08.2026
engine/roof-packingMethodDer Dachbelegungs-Rechner (31) bekommt die Reihenabstandskopplung aus der Spezifikation: Im neuen Flachdach-Modus variiert er Aufstaenderung und Reihenabstand GEMEINSAM und rechnet fuer 5 bis 45 Grad Modulzahl, Reihenabstand und Jahresertrag der Gesamtflaeche aus derselben TMY-Stundenkette wie die Rechner 23 bis 28. Der Reihenabstand kommt aus derselben Funktion wie in Rechner 26 (neu geteilt als physics/geometry designCaseSun) — beide Seiten geben damit nachweislich dieselbe Zahl, per Test erzwungen. Die Reihenzaehlung ist am Flachdach geometrisch richtig: Die letzte Reihe braucht keinen Schattenabstand hinter sich. Sechs neue Warncodes, elf neue Tests, FAQ auf elf Fragen je Sprache erweitert.
Beantwortet die Kernfrage jeder Flachdachplanung, die kein kostenloser Rechner stellt: Berlin, 20 x 15 m, schattenfrei 9 bis 15 Uhr — bei 5 Grad Aufstaenderung passen 70 Module aufs Dach, bei den ertragsoptimalen 40 Grad nur 32. Die flache Variante liefert 90 Prozent mehr, obwohl jedes einzelne Modul schlechter steht. Der Flaechenquotient irrt hier um 90 Prozent statt um 11. Verschmutzung und Schnee sind nicht gerechnet und werden als Warnung ausgewiesen.
Spezifikation Teil 2 Rechner 31 (Killer-Feature Reihenabstandskopplung); Reihenabstand nach Rechner 26; Einstrahlung PVGIS-SARAH3 TMY
marine/uscg-33cfr183iDataNeuer Datensatz Bootselektrik (Anhang B7): 33 CFR 183 Subpart I vollständig aus der eCFR-API übernommen — US-Bundesrecht ist gemeinfrei und darf komplett eingebettet werden: Ampacity-Tabelle 5 (15 AWG-Größen × 7 Temperaturklassen), Motorraum-Korrekturfaktoren, Mindestquerschnitte AWG 16/18, Sicherungsabstand 72 Zoll, Erdungs- und Batterieregeln im Wortlaut. Dazu der kostenlos verifizierte ISO-Ausgabestand: 13297:2020 + Amd 1:2022 hat ISO 10133 absorbiert.
Schließt den letzten Datenblocker des Katalogs: B7 ist ohne Normenkauf gelöst — mit gemeinfreiem US-Recht als harter Datenbasis und dem ISO-Stand als Verweis.
eCFR-API (ecfr.gov), 33 CFR 183 Subpart I, Stand 30.07.2026; iso.org (Ausgabestand). Abgerufen 03.08.2026
engine/groundingFixDer Erdungs-/Schutzleiter-Rechner (20) ist neu gebaut: beide IEC-Wege (adiabatisch S=√(I²·t)/k mit k als Nutzereingabe nach Anhang B11, vereinfachte Zuordnung als Faktenregel) mit Handelsgrößen-Empfehlung — und der Bootsmodus, der ihn von jedem Gebäude-Rechner unterscheidet: Galvanik-Risikobewertung aus Rumpfmaterial, Landstrom, Trenner und Erdungskonzept, mit den gemeinfreien CFR-Fakten und dem verifizierten ISO-Verweis. Sieben neue Warncodes (geteilt mit Rechner 52), FAQ 6, Golden r20.
Der letzte Elektrik-Rechner steht — inklusive der Bootsfrage, die Gebäude-Rechner nicht stellen: Was passiert am Landstrom mit Rumpf und Anoden?
Spezifikation Teil 1 Rechner 20 (B7/B11); data/marine/ (03.08.2026)
engine/boat-marineFixDer Boot-Solar-Rechner (52) ist neu gebaut — der letzte Rechner des Katalogs: Takelage-Verschattung als bezifferte sichtbare Annahme (Standard 35 % Abschlag), 24/7-Ankerlast statt Tagesprofil, Batteriebank mit Autonomietagen, und die Galvanik-Warnung als Killer-Feature (kritisch bei Aluminiumrumpf am Landstrom ohne Trenner). Regel-Fakten aus dem gemeinfreien Marine-Datensatz, ISO-Ausgabestand als ständiger Verweis, Takelage-Vergleichs-Viz mit Galvanik-Ampel, FAQ 6, Golden r52.
Der Katalog ist vollständig: 62 von 62 Rechnern implementiert. Beispiel-Kernzahlen: 300 Wp liefern unter Takelage 614 statt 945 Wh (Deckung 41 %), Bank 551 Ah — und die Galvanik-Ampel steht auf KRITISCH.
Spezifikation Teil 3 Rechner 52 (B7); data/marine/ (03.08.2026)
engine/sun-positionFixDer Sonnenstand-Rechner (30) ist neu gebaut und J1 geschlossen: vollständige NREL-SPA-Portierung (Reda & Andreas 2004; Koeffiziententabellen maschinell aus pvlib 0.15.2 extrahiert) mit automatisierter Kreuzvalidierung gegen die pvlib-Referenz — Position < 0,01° an 60 Punkten, Auf-/Untergang < 60 s an 12 Ereignissen (spa-crossval.spec.ts, macht den Build bei Abweichung rot). Ausgaben: sichtbarer und geometrischer Auf-/Untergang, Transit, Tageslänge, drei Dämmerungsstufen, Position zu beliebiger Zeit; Sonnenbahndiagramm mit drei Jahreskurven, Stundenmarken und PVGIS-Geländehorizont. DST-Warncode, FAQ 6, Golden r30.
Die Kategorie Ertrag & Geometrie erhält ihr Linkable Asset: das normfeste Sonnenbahndiagramm mit Standort-Horizont — und die Engine erstmals eine SPA-genaue Referenzkette neben der Cooper/Spencer-Näherung der POA-Rechner.
Spezifikation Teil 2 Rechner 30 (J1); Reda & Andreas 2004; pvlib-python 0.15.2 (BSD-3, Tabellenextraktion + Referenzwerte)
engine/voc-temperatureFixDer Voc-Temperatur-Rechner (11) ist entsperrt und aufgewertet — B1 per Nutzerentscheid als Zwischenlösung: Der Auslegungswert bleibt Nutzereingabe, wird aber jetzt sichtbar gegen das TMY-Jahresminimum des Standorts geprüft (Standortfeld, climate/design-temps mit 1.155 Rasterpunkten). Wärmer als das Standort-Minimum ausgelegt = kritische Warnung; dazu der ständige TMY-ist-typisch-Hinweis. Neue Viz (Voc-Gerade gegen Reglergrenze mit Auslegungspunkt und Standortmarke), KPI „Ohne Korrektur (falsch)“ mit Subs, Hints, metaDescription, FAQ 6 (neu). Zwei neue Warncodes; Golden um die Standortkontrolle erweitert.
Die sicherheitskritische Annahme des Rechners hat jetzt eine eingebaute Kontrolle: Wer −5 °C ansetzt, wo der Standort typisch −10 °C erreicht, bekommt eine kritische Warnung statt eines stillen Normverstoßes — und die eine Modulzahl Differenz zur unkorrigierten Rechnung steht als eigene Kennzahl da.
Spezifikation Teil 1 Rechner 11 (Anhang B1, Zwischenlösung); climate/design-temps.json (03.08.2026)
engine/offgrid-vs-gridFixDer Netzanschluss-vs-Off-Grid-Rechner (45) ist neu gebaut — B8 nach Spez-Beschluss als Nutzereingabe mit Orientierungs-Bandbreiten gelöst (Grundkosten 2.000–5.000 €, Trasse 50–150 €/m, beide als Annahme markiert): Barwertvergleich über die Nutzungsdauer inkl. diskontiertem Batterieersatz, Break-even-Entfernung als Kernzahl, Break-even-Kurven-Viz mit Standort-Marker — und der Zuverlässigkeitsvergleich (Defizittage der Insel gegen BNetzA-SAIDI-Größenordnung) als eigene Warnung. FAQ 6, Golden r45, zwei neue Warncodes.
Die Randlagen-Entscheidung bekommt ihre zwei Währungen: Im Beispiel gewinnt bei 150 m Trasse das Netz; ab der ausgewiesenen Break-even-Entfernung kippt es — und der Rechner sagt ehrlich, dass ein nie ausfallendes Netz eine andere Ware ist als eine Insel mit Defizittagen.
Spezifikation Teil 3 Rechner 45 (Anhang B8)
engine/battery-temperatureFixDer Batterie-Temperatur-Rechner (39) ist neu gebaut — B12/D2 nach Spez-Beschluss als Einbauszenarien mit Bandbreiten gelöst: Jahresgang der Batterie-Tagesminima aus der TMY-Temperaturreihe des Standorts (thermisch gedämpft je Szenario), Ladesperr-Tage aus der Chemie-Sperrgrenze, Kapazitätsfaktor aus der Kennlinie, und der Heizen-oder-größer-kaufen-Vergleich (Heizenergie-Band gegen Mehrkapazität — mit der Aussage, dass Weg B die Sperre NICHT löst). Zweiteilige Viz mit Kennlinie + Jahresgang und Sperrtagen je Monat, drei neue Warncodes, ständiger Größenordnungs-Hinweis, FAQ 6, Golden friert TMY + Kennlinien + Szenarioparameter ein.
Die Kopplung wird sichtbar, die kein Konkurrenzrechner trifft: Nicht der Kapazitätsverlust, sondern die Ladesperre ist das Winterproblem — beziffert in Tagen je Monat am konkreten Standort, mit der Heizung als einzigem Ausweg, der beide Probleme löst.
Spezifikation Teil 2 Rechner 39 (Anhänge B12/D2); batteries/chemistries.json; PVGIS-TMY
engine/starlinkFixDer Starlink-Rechner (58) ist neu gebaut — vierter durch die Datenbeschaffung entsperrter Rechner (Anhang H4): Tagesverbrauch als Herstellerband je Terminal (Standard Gen 3, Mini, Flat HP) aus den offiziellen Spec-Sheets, Winter-Zuschlag der Schneeschmelze als ausgewiesene Näherung (Heizleistung nennt kein Datenblatt; Mini am 60-W-DC-Limit), Nachtlast in Amperestunden als 24/7-Kernzahl, Mini-DC-Vorteil ohne Wechselrichter. Terminalvergleichs- und Tag/Nacht-Viz, vier neue Warncodes (Community-Leerlauf transparent markiert), FAQ 6, Golden r58 referenziert den Datensatz.
Die Dauerlast-Konsequenz wird beziffert: 12 Nachtstunden Standard-Leerlauf kosten ~270 Wh = 22 Ah aus der 12-V-Bank — jede Nacht; drei Schneeschmelz-Stunden addieren ~250 Wh am Wintertag. Beides bildet kein anderer Rechner ab.
Spezifikation Teil 3 Rechner 58; appliances/starlink.json (offizielle Spec-Sheets + Community-Idle, 03.08.2026)
engine/cost-estimatorFixDer Anlagenkosten-Rechner (47) ist neu gebaut — dritter durch die Datenbeschaffung entsperrter Rechner (Anhang B9): Angebotsprüfer, der die PV- und Speicher-Position eines konkreten Angebots gegen die quartalsweise gepflegten Marktbänder legt (1.000–1.500 €/kWp schlüsselfertig, 350–700 €/kWh installiert) und Ausreißer nach oben UND unten markiert — mit Prüfliste statt Lob bei verdächtig niedrigen Preisen; dazu Betriebskosten-Band (1–2 %/a, ISE), Größenklassen-Hinweis unter 10 kWp und Spotpreis-Einordnung. Band-Balken-Viz mit Angebots-Raute, fünf neue Warncodes, FAQ 6, Golden r47 referenziert den Preis-Datensatz.
Der Rechner für den Moment mit drei Angeboten auf dem Tisch: Im Beispiel liegt die PV-Position mit 1.300 €/kWp im Band, der Speicher mit 800 €/kWh 14 % darüber — genau das Nachverhandlungssignal, das kein vermittelnder Rechner geben kann.
Spezifikation Teil 3 Rechner 47; prices/pv-de.json (pvXchange/BSW/ISE, 03.08.2026)
engine/ac-wire-sizeFixDer AC-Kabelquerschnitt-Rechner (14) ist neu gebaut — zweiter durch die Datenbeschaffung entsperrter Rechner (Anhang B4): kaskadierte Anlagenkette HAK → Zähler → Unterverteilung → Verbraucher mit den drei ineinandergreifenden DE-Grenzwerten (0,5 % TAB, 3 % DIN 18015-1, 4 % VDE 0100-520) plus IEC-Profile; Reaktanzbelag je Querschnitt aus cables/nyy-cu.json (X′ = 2πf·L′), Typwert 0,08 Ω/km nur als Fallback mit Warnung; ρ bei Isolierungs-Betriebstemperatur (PVC 70 °C/XLPE 90 °C). Kettendiagramm mit kumulativer Linie, fünf neue Warncodes, FAQ 6, Golden r14 friert Formel und Katalogwerte ein.
Die reale deutsche Prüfaufgabe — drei Teilgrenzwerte statt einem — ist erstmals abgebildet; der Rechner zeigt, welches Glied die Kette reißt, und beziffert den Reaktanzanteil, den reine DC-Rechner unterschlagen.
Spezifikation Teil 1 Rechner 14; cables/nyy-cu.json (Hesselmann NYY, 03.08.2026)
engine/charge-timeFixDer Ladezeit-Rechner (6) ist neu gebaut — der erste durch die Datenbeschaffung vom 03.08.2026 entsperrte Rechner (Anhang B3): Phasenmodell Bulk/Absorption je Chemie aus batteries/charging.json (LiFePO4 datenblattfest 2 h, Blei exponentiell mit Ladeschlussstrom, NMC mit 4-%-Abschaltung), Faustformel als beziffertes Gegenueber, Solarmodus mit klimamittel-kalibriertem TMY-Mitteltagesprofil und Uhrzeit-Ausgabe samt 30-%-Schlechtwetterfall. Viz: zweiachsige SoC-/Stromkurve mit Phasenflaechen und Solar-Hintergrund. Sync-Test bindet Engine-Konstanten an den Datensatz. Vier neue Warncodes. FAQ 6, Golden r06.
Die Kernaussage ist beziffert: AGM 100 Ah mit 20 A von 20 auf 100 Prozent braucht real 5,6 h statt der 4,2 h der Faustformel — die Absorptionsphase (2,4 h) unterschlagen einfache Rechner. Im Solarmodus lautet die Antwort erstmals „voll um HH:MM“.
Spezifikation Teil 1 Rechner 6; batteries/charging.json (Victron/Trojan/Panasonic, 03.08.2026)
batteries/chargingDataNeuer Datensatz Ladekennlinien je Chemie (Anhang B3): Absorptions-/Float-/Storage-/Equalize-Sollwerte, Absorptionszeiten, Temperaturkompensation und Ladetemperaturgrenzen fuer LiFePO4, AGM, Gel, Nassbatterie und NMC-Zelle — je Chemie aus dem Referenzhersteller-Datenblatt (Victron, Trojan, Panasonic), mit Quellenzeile pro Eintrag.
Entsperrt den Ladezeit-Rechner (6) ueber den Konstantstrommodus hinaus: CC/CV-Umschaltpunkt und Absorptionsphase sind jetzt belegt statt geschaetzt.
Victron Datenblatt Gel/AGM + Lithium-Smart-Manual Rev. 21 (01/2026); Trojan „Battery Maintenance“; Panasonic NCR18650B. Abgerufen 03.08.2026
cables/nyy-cuDataNeuer Datensatz Kabel-Kenndaten (Anhang B4): Leiterwiderstand und Induktivitaetsbelag fuer NYY-J/-O (VDE 0276-603), 16 Querschnitte mehradrig (1,5-300 mm²) und 15 einadrig (4-400 mm²), aus dem Hersteller-Produktdatenblatt uebernommen. Der Reaktanzbelag folgt zur Laufzeit als X'=2*pi*f*L'.
Entsperrt den AC-Kabelquerschnitt-Rechner (14): Die AC-Spannungsfallrechnung braucht X' — bisher gab es dafuer keine zulaessige Datenquelle (Normtabellen sind urheberrechtlich tabu, Herstellerdaten nicht).
Kabelvertrieb Hesselmann GmbH, Produktdatenblatt NYY-J/-O nach VDE 0276-603. Abgerufen 03.08.2026
prices/pv-deDataNeuer Datensatz PV-Marktpreise (Anhang B9), ausschliesslich Bandbreiten mit Erhebungsdatum: Modul-Spotpreise je Klasse (pvXchange Juli 2026: 0,075-0,160 EUR/Wp), schluesselfertige Systeme (1.000-1.500 EUR/kWp, Durchschnitt 1.015 EUR/kWp Fruehjahr 2026, BSW-referenziert), Betriebskosten 1-2 %/a und Stromgestehungskosten 6-14 bzw. 4-7 ct/kWh (Fraunhofer ISE 05.05.2026), Heimspeicher 250-450 EUR/kWh Geraet bzw. 350-700 EUR/kWh installiert.
Entsperrt den Anlagenkosten-Rechner (47) mit datierten, quartalsweise gepflegten Marktbaendern statt geratener Punktwerte.
pvXchange Preisindex 07/2026; BSW-Preisindex (zitiert); Fraunhofer ISE Aktuelle Fakten 05.05.2026; Marktbeobachtungen 06/2026
appliances/starlinkDataNeuer Datensatz Satelliten-Terminals (Anhang H4) aus den offiziellen Starlink-Spezifikationsblaettern: Standard Gen 3 75-100 W (Schneeschmelze bis 40 mm/h), Mini 25-40 W (DC 12-48 V, max. 60 W; bis 25 mm/h), Flat High Performance 110-150 W (bis 75 mm/h). Community-Leerlaufwerte getrennt als Schaetzwerte gekennzeichnet.
Entsperrt den Starlink-Rechner (58): Betriebs- und Schneeschmelzangaben sind jetzt Herstellerangaben statt Blog-Schaetzungen; die verbleibende Leerlauf-Unsicherheit ist explizit ausgewiesen.
Starlink Spec Sheets (starlink.com/public-files), abgerufen 03.08.2026; DISHYtech-Messberichte fuer Leerlaufwerte
tariffs/negative-price-hoursDataNeuer Datensatz Negativpreisstunden (Anhang H2): eigene Zaehlung aus der SMARD-Stundenreihe der Grosshandelspreise DE/LU (Filter 4169) — 2024: 457 h, 2025: 573 h, monatsaufgeloest, Vollstaendigkeit dokumentiert (8784/8760 gezaehlte Stunden).
Schliesst den offenen Spezifikationspunkt H2 des Einspeiseerloes-Rechners (48): Der Vergueetungsausfall bei Negativpreisen (§ 51 EEG) rechnet jetzt mit amtlichen Stundenzahlen.
Bundesnetzagentur SMARD (CC BY 4.0), Filter 4169, abgerufen 03.08.2026
climate/design-tempsDataNeuer Datensatz Auslegungstiefsttemperaturen (Anhang B1, Zwischenloesung nach Spez Teil 2): je der 1.155 TMY-Rasterpunkte das Stundenminimum und das 1. Perzentil der Tagesminima (Spanne -31,9 bis -1,0 °C, Median -12,5 °C). Ausdruecklich als assumed-Default gekennzeichnet — TMY beschreibt ein typisches, kein extremes Jahr.
Gibt dem Voc-Temperatur-Rechner (11) eine standortgenaue, sichtbar begruendete Default-Tiefsttemperatur statt eines pauschalen -15-°C-Werts. Die Normfrage (B1) bleibt dokumentiert offen.
Eigene Ableitung aus PVGIS-TMY (JRC), Raster des Projekts, berechnet 03.08.2026
engine/blackoutFixDer Blackout-Rechner (62) ist vervollständigt: Abschaltreihenfolge als Laufzeitbalken je Prioritätsstufe gegen die Ziellinie (rot, wo das Ziel verfehlt wird, mit Gerätenamen je Stufe), Reihenfolge-Zeile. Engine: Echo targetHours. KPI-Subs, Hints (BBK-72-h-Empfehlung, Leerlauf-Anteil, Peukert-Hinweis), metaDescription, FAQ auf sechs Einträge. Neues Golden r62-blackout-de.
Das Ergebnis ist eine durchspielbare Reihenfolge statt einer Einzelzahl: 200 Ah LiFePO4 halten im Beispiel 10,6 h mit allem, 13,9 h ohne Verzichtbares, 21,3 h nur mit dem Unverzichtbaren — das 24-h-Ziel wird sichtbar knapp verfehlt.
Spezifikation Teil 3 Rechner 62, eigene Verifikation vom 03.08.2026
engine/unit-converterFixDer Einheiten-Umrechner (61) ist vervollständigt: Chemie-Vergleichsbalken bei Ah ↔ Wh (fünf Chemien, gewählte hervorgehoben, Spannen-Prozent), Handelsgrößen-Zeile bei den AWG-Modi. BUGFIX: Der Watt-zu-Ampere-Modus lief mangels Spannungsfeld immer in die Validierung — neues Spannungs-Select (12/24/48/230/400 V), nur in diesem Modus sichtbar. Engine: Chemie-Echo. Hints, metaDescription, FAQ auf sechs Einträge.
Die Kernaussage des Umrechners wird sichtbar: Dieselbe „100 Ah, 12 V“-Beschriftung liegt je Chemie gut 15 % auseinander (LiFePO4 1.280, Blei 1.200, NMC 1.110 Wh) — und Watt → Ampere funktioniert jetzt überhaupt.
Spezifikation Teil 3 Kapitel 12, eigene Verifikation vom 03.08.2026
engine/heat-pumpFixDer Wärmepumpen-PV-Rechner (60) ist vervollständigt: Monats-Stapelbalken des Wärmepumpenstroms (PV-gedeckt gegen Netzbezug) mit der Kernzeile Jahres- gegen Winter- und Sommerdeckung. KPI-Subs, Hints (JAZ-Bandbreiten, Tagesanteil, Heizgrenze), metaDescription, FAQ auf sechs Einträge (Tagesanteil-Deckel, Grenzen größerer Anlagen, Warmwasser-Verteilung). Neues Golden r60-heat-pump-de über den versionierten Wave-1-Datensatz (Berlin).
Die Saisondiskrepanz wird je Monat sichtbar statt in einer Jahreszahl versteckt (Beispiel Berlin, 10 kWp auf 4.000 kWh WP-Strom: 46 % Jahr, 43 % Winter, Sommer am 50-%-Tagesanteil gedeckelt; 2.152 kWh bleiben Netzbezug).
Spezifikation Teil 3 Rechner 60, eigene Verifikation vom 03.08.2026
engine/ev-chargingFixDer E-Auto-PV-Rechner (59) ist vervollständigt: Dauerlinien-Visualisierung mit beiden Startschwellen (einphasig 1,38 kW, dreiphasig 4,16 kW) und schraffierter Zwischenzone — der Überschuss, den nur die einphasige Wallbox erreicht — plus Payback-Zeile der Phasenumschaltung. Engine: Echo der sortierten Dauerlinie. KPI-Subs, Hints, metaDescription, FAQ auf sechs Einträge (inkl. Schieflastgrenze VDE-AR-N 4100). Neues Golden r59-ev-charging-de.
Die Kaufentscheidung wird sichtbar: In der Beispielkurve lädt einphasig 7.609 kWh solar, dreiphasig nur 4.746 kWh — die Umschaltung amortisiert ihren 500-€-Aufpreis in 0,6 Jahren.
Spezifikation Teil 3 Rechner 59, eigene Verifikation vom 03.08.2026
engine/air-conditioningFixDer Klimaanlagen-Rechner (56) ist vervollständigt: Kühllast-Rangbalken nach Quellen (Hülle, Fenster, innere Lasten, Lüftung) mit empfohlener Kälteleistung, Bauart-Vergleich Inverter gegen taktend unter Teillast mit wirksamer Leistungszahl. KPI „Empfohlene Kälteleistung“ ersetzt den Fenster-Einzelwert, KPI-Subs, Hints, metaDescription, FAQ auf sechs Einträge. Engine: Echo applianceType. Neues Golden r56-air-conditioner-de.
Die beiden Kernaussagen werden sichtbar: 45 % der Beispiel-Kühllast kommen durchs Südfenster (Verschattung ist der billigste Hebel), und das taktende Gerät verbraucht 23 % mehr als der Inverter (4.473 gegen 3.641 Wh/Tag).
Spezifikation Teil 3 Rechner 56, eigene Verifikation vom 03.08.2026
engine/cabinFixDer Gartenhaus-Rechner (53) ist vervollständigt: Saisonschalter-Doppelbalken (Sommer- gegen Ganzjahresauslegung mit Faktor) und Standzeitkurve gegen die Tiefentladegrenze als Visualisierung, Ladezustand als Prozent-KPI, neue Advanced-Felder (Ladezustand beim Abschließen, Kettenwirkungsgrad), KPI-Subs, Hints, metaDescription, FAQ auf sechs Einträge. Engine: Prozent-Anzeige und Echos (idleMonths, criticalSoc, Selbstentladungsrate). Neues Golden r53-cabin-de.
Die beiden Kernaussagen werden sichtbar: Saisonbetrieb braucht nur ein Bruchteil der Anlage (Beispiel: 190 gegen 1.071 Wp, Faktor 5,6) — und die Standzeitkurve zeigt, ob die Batterie den Leerstand übersteht (AGM, 3 Monate: 91 %).
Spezifikation Teil 3 Rechner 53, eigene Verifikation vom 03.08.2026
engine/van-rvFixDer Wohnmobil-Rechner (51) ist vervollständigt: Quellenvergleich Solar gegen Lichtmaschine mit Bedarfslinie und Booster-Äquivalenz („der Booster ersetzt X Wp Solar“), sichtbare Profil-Ableitung (Autonomietage, Fahrstunden), KPI-Subs, Feld-Hints, metaDescription, FAQ auf sechs Einträge. Engine: Echos travelProfile und dailyEnergyWh. Neues Golden r51-van-rv-de.
Die Kernaussage wird sichtbar: Bei täglich Fahrenden liefert der Ladebooster oft ein Mehrfaches der Solaranlage (Beispiel: 486 Wh gegen 112 Wh, Äquivalenz 868 Wp).
Spezifikation Teil 3 Rechner 51, eigene Verifikation vom 03.08.2026
engine/water-pumpFixDer Wasserpumpen-Rechner (57) ist vervollständigt: Neu ist die Förderhöhen-Aufteilung (geodätisch gegen Reibung) mit dem Rohrsprung-Vergleich — nächster Standarddurchmesser mit neuer Reibung, Leistung und gesparten Watt. KPI-Subs, Feld-Hints (Rauheitswerte, 5.-Potenz-Regel), metaDescription, FAQ auf sechs Einträge. Neues Golden r57-water-pump-de.
Der Vergleich macht die zentrale Anwendungsregel sichtbar: Rohr ist der billigste Wirkungsgrad — die Reibung fällt mit der fünften Potenz des Durchmessers.
Spezifikation Teil 3 Rechner 57, eigene Verifikation vom 03.08.2026
engine/fridgeFixDer Kühlschrank-Rechner (55) ist vervollständigt (Auftakt Anwendungsfälle): Neu ist die Takt-Visualisierung — Laufanteil als Tagesband plus der Vergleich physikbasiert gegen den festen 35-%-Erfahrungswert, mit Wärmeeintrag und Anlaufstrom in der Fußzeile. KPI-Subs, Feld-Hints (UA-Rückrechnung aus Messung), metaDescription, FAQ auf sechs Einträge. Neues Golden r55-fridge-de.
Der Vergleich zeigt den Kern: Der Verbrauch hängt an der Aufstelltemperatur — Sonnen-Van gegen Keller ist beim selben Gerät fast Faktor sechs im Wärmeeintrag.
Spezifikation Teil 3 Rechner 55, eigene Verifikation vom 03.08.2026
engine/parallel-batteryFixDer Parallelverdrahtungs-Rechner (22) ist vervollständigt — damit ist die Elektrik-Kategorie abgeschlossen (14/20 blockiert-bereinigt: R14/R20 bleiben datenblockiert). Neu: die Stromverteilungs-Balken je Block (der meistbelastete rot, Mittellinie) und der Methodenvergleich same-end/diagonal/busbar als Balken. KPI-Subs (inkl. der Lebensdauer-Kostenrechnung), Feld-Hints, metaDescription, FAQ auf sechs Einträge. Neues Golden r22-parallel-battery-de.
Beispiel 4 Blöcke am selben Ende: zweistellige Stromungleichheit, der erste Block trägt den Mehrstrom — diagonal fällt sie auf nahe null, für den Preis eines längeren Kabels.
Spezifikation Teil 1 Rechner 22, eigene Verifikation vom 02.08.2026
engine/battery-cableFixDer Batteriekabel-Rechner (21) ist vervollständigt: Neu ist das Spitzenlast-Spannungsprofil — von der Batterie-Minimalspannung über den Kabelfall zum Wechselrichter, gegen dessen Abschaltschwelle: Das „mysteriöse Abschalten beim Kompressorstart“ wird als Geometrie sichtbar. KPI-Zeile mit Spannung am Wechselrichter und Reserve zur Abschaltung, Feld-Hints, metaDescription, FAQ auf sechs Einträge; Engine echot Minimalspannung und Abschaltschwelle. Neues Golden r21-battery-cable-de.
Das Profil beantwortet den häufigsten 12-V-Mysteriumsfall: Wechselrichter trennt bei halbvoller Batterie — Ursache ist der Kabelfall beim Anlaufstrom, nicht die Batterie.
Spezifikation Teil 1 Rechner 21, eigene Verifikation vom 02.08.2026
engine/busbarFixDer Sammelschienen-Rechner (19) ist vervollständigt: Neu ist die Verlust-Aufteilung als Visualisierung — Schienen- gegen Verbindungsanteil in einem Balken, dazu das Verschraubungs-Äquivalent in Metern Schiene und die Stromdichte gegen den Kupfer-Richtwert. KPI-Subs, Feld-Hints (10–20 µΩ sauber vs. Zehnfaches korrodiert), metaDescription, FAQ auf sechs Einträge (Montage- und Wartungspraxis). Neues Golden r19-busbar-de.
Die Aufteilung macht den Kernpunkt sichtbar: Die Übergangsstellen — nicht das Kupfer — sind regelmäßig der größere Verlust- und Wärmeposten.
Spezifikation Teil 1 Rechner 19, eigene Verifikation vom 02.08.2026
engine/ampacityFixDer Strombelastbarkeits-Rechner (18) ist vervollständigt: Neu ist der Derating-Wasserfall — Tabellenwert und jede Minderungsstufe als Balken, der Betriebsstrom als grüne/rote Linie quer darüber. KPI-Subs (inkl. der Rückwärtsfrage „erforderlicher Tabellenwert“), Feld-Hints, metaDescription, FAQ auf sechs Einträge (u. a. die Sicherungs-Kopplung: abgesichert wird die geminderte Belastbarkeit). Neues Golden r18-ampacity-de.
Beispiel: 40-A-Tabellenwert bei 45 °C und Bündelung → deutlich geminderte zulässige Dauerlast; die Linie zeigt sofort, ob der Betriebsstrom noch hineinpasst.
Spezifikation Teil 1 Rechner 18, eigene Verifikation vom 02.08.2026
engine/ac-ocpdFixDer AC-Automaten-Rechner (17) ist vervollständigt: Neu ist das Schleifenimpedanz-Budget als Visualisierung — zulässige Impedanz als Grenzlinie, aufgeteilt in Quell- und Leitungsanteil, Ist-Punkt grün/rot je Abschaltbedingung, dazu die maximale Leitungslänge als Fußzeile. KPI-Zeile mit Auslösestrom und Maximallänge, Feld-Hints (Wechselrichter-Quellimpedanz, B/C-Halbierung), metaDescription, FAQ auf sechs Einträge (inkl. der Inselnetz-Regel B vor C). Neues Golden r17-ac-ocpd-de.
Die Budget-Darstellung macht sichtbar, warum ein korrekt bemessener Automat an langer Leitung oder schwachem Wechselrichter im Fehlerfall trotzdem nicht auslöst — die Kernaussage der Abschaltbedingung.
Spezifikation Teil 1 Rechner 17, eigene Verifikation vom 02.08.2026
engine/dc-ocpdFixDer DC-Sicherungs-Rechner (16) ist vervollständigt: Neu ist die Auswahl-Leiter als Visualisierung — Bemessungsstrom, erforderliche und gewählte Größe auf einer Stromachse, darüber die Kabel-Obergrenze als rote Linie („die Sicherung schützt das Kabel, nicht das Gerät“) und der prospektive Kurzschlussstrom in der Note. KPI-Zeile auf fünf Kacheln inkl. DC-Spannungsfestigkeit und Kurzschlussstrom, Feld-Hints (AC-im-DC-Verbot, Schaltvermögen), metaDescription, FAQ auf sechs Einträge.
Die Leiter macht die Einbau-Reihenfolge sichtbar: gewählte Größe über dem Bemessungsstrom, unter der Kabel-Belastbarkeit — und das Schaltvermögen gegen den Batteriekurzschluss geprüft.
Spezifikation Teil 1 Rechner 16, eigene Verifikation vom 02.08.2026
engine/voltage-drop-checkFixDer Spannungsfall-Rechner (15) ist vervollständigt: Neu ist die Doppel-Grenzen-Anzeige (deine Auslegungsgrenze gelb, Normgrenze rot, Ist-Balken färbt bei Überschreitung) und das Rückwärtsfragen-Panel — maximale Länge, maximaler Strom und Mindestquerschnitt aus derselben Formel, je nach einer Variablen aufgelöst. KPI-Zeile auf fünf Kacheln inkl. Jahresverlust in Cent und Längen-Spielraum, Feld-Hints, metaDescription, FAQ auf sechs Einträge; Engine echot die Nutzergrenze. Goldens nur additiv erweitert.
Die drei Spielraum-Antworten machen aus der Prüfung ein Werkzeug für die Kabeltrommel vor Ort: Dieselbe Leitung, drei nutzbare Auskünfte statt einem Ja/Nein.
Spezifikation Teil 1 Rechner 15, eigene Verifikation vom 02.08.2026
engine/dc-wire-sizeFixDer DC-Kabelrechner (13) ist vervollständigt (Auftakt Elektrik-Kategorie): Neu ist der Standardgrößen-Vergleich als Visualisierung — Spannungsfall je Größe als Balken gegen die Grenzlinie, die empfohlene Größe markiert, zu dünne rot; die Note benennt, ob Spannungsfall oder Strombelastbarkeit die Größe bestimmt hat. KPI-Zeile auf fünf Kacheln inkl. Verlustleistung und Jahresverlust, Feld-Hints (Hin-/Rückleiter-Faktor-2), metaDescription, FAQ auf sechs Einträge; Engine echot die Grenzwert-Eingabe. Goldens r13 nur additiv erweitert.
Referenz-Golden unverändert (16 mm² empfohlen bei 14,9 mm² rechnerischem Bedarf, 2,8 % tatsächlicher Fall). Die Balkengrafik zeigt, warum die nächstkleinere Größe die Grenze reißt.
Spezifikation Teil 1 Rechner 13, eigene Verifikation vom 02.08.2026
engine/loss-chainFixDer Verlustketten-Rechner (12) ist vervollständigt: Neu ist der Verlust-Wasserfall — jede Stufe der Kette als Zeile mit Rest und Verlust in Watt, die zwei größten Verluste rot markiert, unten die Leistung am Verbraucher; der additive Falschwert steht als Vergleich in der Note. KPI-Subs, Feld-Hints (u. a. die Batterie-Umgehung bei Direktverbrauch), metaDescription, FAQ auf sechs Einträge. Neues Golden r12-loss-chain-de.
Mit den Beispielwerten läuft die Nennleistung durch bis zu elf Stufen; der Wasserfall macht sichtbar, dass die größten Hebel selten die vermuteten sind (PWM-Regler bzw. Batterie-Round-Trip statt Verschmutzung).
Spezifikation Teil 1 Rechner 12, eigene Verifikation vom 02.08.2026
engine/string-configFixDer String-Rechner (10) ist vervollständigt: Neu ist die Konfigurationsmatrix als Visualisierung — jede Aufteilung Reihe × parallel als Zelle, grün/gelb/rot nach den vier Prüfungen (Kältespannung, Normgrenze, heißes MPPT-Fenster, Reglerstrom), die verletzte Prüfung steht in der Zelle, die beste zulässige Konfiguration ist umrandet. KPI-Zeile auf fünf Kacheln inkl. der verbindlichen Spannungsgrenze (Minimum aus Regler und Norm), Feld-Hints mit den Prüf-IDs, metaDescription, FAQ auf sechs Einträge (u. a. Strangsicherungs-Regel ab drei Strängen). Neues Golden r10-string-config-de.
Referenz (8 Module 41,5 V, −15 °C, 250-V-Regler): Die Matrix zeigt die P1-Grenze bei hohen Reihenzahlen (ab 6S überschreitet die Kältespannung 250 V) und markiert die beste zulässige Aufteilung.
Spezifikation Teil 1 Rechner 10, eigene Verifikation vom 02.08.2026
engine/system-voltageFixDer Systemspannungs-Rechner (9) ist vervollständigt: Neu ist die Drei-Spalten-Vergleichskarte nach Spez mit dem Kabelquerschnitt als maßstabsgetreuem (flächentreuem) Kreis je Kandidat — 44 mm² neben 2,8 mm² schlägt jede Tabelle — samt Strom, Kabel-, Wandler- und Gesamtkosten; die Empfehlung ist markiert. KPI-Zeile mit den Querschnitten bei 12 und 48 V und dem 1/U²-Faktor, Feld-Hints (inkl. der Gerätverfügbarkeits-Logik), metaDescription, FAQ auf sechs Einträge. Neues Golden r09-system-voltage-de auf dem Spez-Testfall.
Spez-Testfall (1.200 W, 4 m, 3 %): 44,2 / 11,1 / 2,77 mm² für 12/24/48 V — exakt 16:4:1. Mit 12-V-Altgeräten rechnet die Empfehlung die DC-DC-Wandlerkosten gegen die Kabelersparnis.
Spezifikation Teil 1 Rechner 9 samt Testfall, eigene Verifikation vom 02.08.2026
engine/generator-sizingFixDer Generator-Rechner (8) ist vervollständigt: Kraftstoffpreis-Vorbelegung von 1,75 € auf das verifizierte ADAC-Bundesmittel 2,15 €/l angehoben (wie Rechner 46; Golden wird dadurch neu). Neu: der Grenzkosten-Vergleich der Spez als Visualisierung — Modul-Zubau (einmalig, flache Linie) gegen kumulierte Kraftstoffkosten mit markiertem Break-even. KPI-Zeile auf fünf Kacheln inkl. der Modul-Alternative und des Break-evens, Feld-Hints (u. a. Auslastungs-/Verruß-Hinweis), metaDescription, FAQ auf sechs Einträge. Das Monats-Deckungsdiagramm braucht die Monatsdaten der Solar-Kette — Roadmap.
Mit den Beispielwerten (2.000 Wh/d Lücke an 120 Tagen) steigen die Jahres-Kraftstoffkosten durch die Preiskorrektur um rund 23 %; der Break-even des Modul-Zubaus rückt entsprechend näher. Alle Werte im Golden r08 dokumentiert.
Spezifikation Teil 1 Rechner 8, ADAC-Spritpreisauswertung (abgerufen 02.08.2026), eigene Verifikation vom 02.08.2026
engine/autonomy-runtimeFixDer Laufzeit-Rechner (7) ist vervollständigt: Neu ist der Countdown-Balken mit den drei Last-Szenarien der Spez (nur Kühlschrank / aktuelle Last / alles an) — nach der Hydration mit Uhrzeit-Beschriftung („reicht bis morgen 07:40“). KPI-Zeile auf vier Kacheln inkl. der naiven linearen Laufzeit als Vergleich (Peukert-Ehrlichkeit bei Blei), Feld-Hints, metaDescription, FAQ auf sechs Einträge. Neues Golden r07-autonomy-runtime-de.
Referenz (200 Ah LiFePO₄, 150 W Last + 25 W Wechselrichter-Leerlauf, SoC 100→20 %): Die Szenarien zeigen den überproportionalen Effekt des Abschaltens, weil der Leerlauf konstant weiterläuft. Bei Blei weist die Grafik die Peukert-korrigierte gegen die lineare Laufzeit aus.
Spezifikation Teil 1 Rechner 7, eigene Verifikation vom 02.08.2026
engine/load-profileFixDer Lastprofil-Rechner (1) ist vervollständigt: Die Seite hatte keine Eingabefelder — jetzt sind die Pfadwirkungsgrade editierbar (die Geräteliste kommt architekturbedingt aus der Beispielrechnung, dokumentiert im Hint). Das Beispiel ist ein realistischer Van-Satz aus fünf Geräten mit Katalog-konsistenten Werten. Neu: die Rangliste als Visualisierung (Anteil je Gerät, Annahme-Herkunft markiert, DC/AC-Split) und der Spitzenlast-Dreiervergleich — Anläufe ignoriert / korrekt (größtes Ereignis plus Grundlast) / alle summiert — samt Benennung des spitzenbestimmenden Geräts. Engine liefert dafür AC-Anteil in Prozent, Naiv-Summe und Spitzen-Treiber. Vier KPI-Kacheln mit Subs, metaDescription, FAQ auf sechs Einträge. Golden r01 um die additiven Ausgaben erweitert.
Beispiel-Van (Kühlschrank 80 W getaktet, 6× LED, Laptop, Pumpe, Router): Der Dreiervergleich zeigt die Spanne zwischen „Anläufe ignoriert“ und „alle summiert“ gegenüber dem korrekten Wert — die Auslegungsgröße für den Wechselrichter-Rechner.
Spezifikation Teil 1 Rechner 1, Gerätekatalog data/appliances/catalogue.json (EPREL/Datenblätter, abgerufen 15.07.2026), eigene Verifikation vom 02.08.2026
engine/charge-controllerFixDer Laderegler-Rechner (5) ist vervollständigt: Neu ist die I-V-Kennlinien-Visualisierung nach Spez (Strang-Kennlinie mit überlagerter Leistungskurve, MPP- und PWM-Arbeitspunkt, verlorene Leistung als roter Balken beziffert — die Grafik, die den MPPT-Vorteil erklärt statt behauptet) plus die Voc-Temperatur-Gerade gegen das Reglerlimit mit Standort-Marker. KPI-Zeile auf fünf Kacheln inkl. MPPT-Mehrertrag und Amortisation (mit der ehrlichen „nie“-Antwort bei kleinen Anlagen), Feld-Hints, metaDescription, FAQ auf sechs Einträge; Engine echot die Kennlinien-Bezugsgrößen. Neues Golden r05-charge-controller-de auf den Spez-Referenzen.
Spez-Referenzen reproduziert: 4 × 41,5 V bei β −0,27 und −15 °C → 183,9 V kältekorrigiert (150-V-Regler unzulässig, 250-V-Klasse nötig); MPPT 1.200 Wp an 28,8 V → 40,4 A Ladestrom → 50-A-Regler; PWM-Referenz 69,4 von 100 W = 30,6 % Verlust.
Spezifikation Teil 1 Rechner 5 samt Referenztestfällen, eigene Verifikation vom 02.08.2026
engine/array-sizingFixDer Solarmodul-Rechner (2) ist vervollständigt: Neu ist die Spez-Kerngrafik — Ertrag gegen Bedarf über 12 Monate mit roten Defizit- und grauen Überschussflächen — samt Auslegungsmonat-Schalter: Ein Klick rechnet Modulleistung, Modulanzahl und Defizittage für jeden Monat um (nur PSH-Verhältnisse, client-seitig auf Engine-Echos). Darunter die Wirkungsgradkette als aufgeschlüsselte Balken (sieben Glieder, kein Pauschalfaktor). KPI-Zeile neu mit Systemwirkungsgrad in Prozent, Temperaturfaktor und PWM-Mehrbedarf; Modulgeneration, Mismatch und DC-Kabel als advanced-Felder; Feld-Hints, metaDescription, FAQ auf sechs Einträge. Golden r02 um die additiven Ausgaben erweitert.
Spez-Referenzen: 2.400 Wh/d bei 3,1 PSH und η 0,65 → 1.191 Wp; PWM statt MPPT → 1.445 Wp (+21 %). Beispielstandort (Dezember 1,07 PSH): Dezember-Auslegung ganzjährig autark; die Grafik zeigt beim Monatswechsel die Defizittage — die eigentliche Off-Grid-Entscheidung.
Spezifikation Teil 1 Rechner 2 samt Referenztestfällen, PVGIS-Monats-PSH des Beispielstandorts (abgerufen 29.07.2026), eigene Verifikation vom 02.08.2026
engine/inverter-sizingFixDer Wechselrichter-Rechner (4) ist vervollständigt: Neu ist das Anlaufdiagramm nach Spez (Grundlast, Anlaufspike über der Zeitachse, Dauer- und Spitzenlinie des vorgesehenen Geräts — durchbricht der Spike die Spitzenlinie, färbt sich die Fläche rot: „Wechselrichter schaltet ab“) plus der Leerlauf-Vergleich Dauerbetrieb gegen Nachtabschaltung, beziffert in Wh, Wp und Euro. Das vorgesehene Gerät ist als optionales Feldpaar eingebbar, Lastart und Einschaltstunden sind jetzt Felder, die KPI-Zeile zeigt fünf Kacheln inkl. Leerlaufverbrauch und Abschalt-Ersparnis. Feld-Hints, metaDescription, FAQ auf sechs Einträge. Neues Golden r04-inverter-sizing-de auf den Spez-Referenzen.
Spez-Referenzen reproduziert: 600 W × 1,25 = 750 W Dauer; Spitze 1.200 W (Faktor 1,6); Leerlauf 25 W × 24 h = 600 Wh/Tag = 25 % des 2.400-Wh-Bedarfs — die achtstündige Nachtabschaltung spart 200 Wh/Tag, umgerechnet ~67 Wp bzw. ~40 € Modulkosten (3 PSH, 0,60 €/Wp).
Spezifikation Teil 1 Rechner 4 samt Referenztestfällen, eigene Verifikation vom 02.08.2026
engine/battery-bankFixDer Batteriebank-Rechner (3) ist vervollständigt: Die C-Rate-Gegenprobe (Schritt 5 der Spez) ist jetzt vom Formular erreichbar (Spitzenlast, Regler-Ladestrom, Datenblatt-Raten als Felder) und als zwei eigene KPI-Kacheln sichtbar; dazu die Jahr-10-Nutzenergie als Kachel. Neu: die SoC-Simulation nach Spez — Ladezustand über 14 Tage mit dreitägiger Schlechtwetterperiode (20 % Ertrag) gegen die rote DoD-Grenze, als Doppelkurve heute/Jahr 10: Durchstößt die gealterte Bank die Linie, ist die Knappheit sichtbar, bevor sie eintritt. Feld-Hints, metaDescription, FAQ auf sechs Einträge; Engine echot Tagesbedarf und Autonomie. Golden r03 um die additiven Ausgaben erweitert. Temperatur-Kennlinien-Kurve als zweite Ansicht: Roadmap (braucht die Kennlinien-Anbindung).
Spez-Referenzfälle reproduziert: 2.400 Wh/d, 2 Tage, 24 V, DoD 0,8, f_temp 0,9 → 278 Ah ohne bzw. 347 Ah mit Alterungsreserve 0,8; Blei-Fall 625 Ah (2,25×). Simulation: Bei 2 Tagen Autonomie übersteht die heutige Bank die Schlechtwetterperiode knapp, die Jahr-10-Kurve reißt die DoD-Grenze — die Alterungsreserve wird als Dimensionierungsgrund sichtbar.
Spezifikation Teil 1 Rechner 3 samt Referenztestfällen, eigene Verifikation vom 02.08.2026
engine/bms-sizingFixDer BMS-Rechner (40) ist vervollständigt — damit ist die Batterie-Kategorie abgeschlossen (39 bleibt datenblockiert). Neu: das Blockschaltbild nach Spez (Zellen → BMS → Hauptsicherung → Verteilung; die Sicherung wird rot-gestrichelt, wenn sie fehlt) mit drei Ampeln am BMS (Dauer/Spitze/Laden, Ausnutzung gegen das Datenblatt) und der bewusst andersförmigen Tieftemperatur-Raute — die fehlende Ladesperre ist die wichtigste Warnung des Rechners. KPI-Zeile auf fünf Kacheln inkl. des Nennspannungs-Fehlers, Feld-Hints, metaDescription, FAQ auf sechs Einträge. Engine echot die BMS-Grenzen und Schutz-Flags. Neues Golden r40-bms-sizing-de auf dem Spez-Referenzfall. Die volle Schutzkonzept-Checkliste braucht die Abfrage aller BMS-Schutzfunktionen — Roadmap.
Spez-Referenzfall (12,8-V-System, Entladeschluss 10,0 V, 1.200 W Dauer / 3.000 W Spitze): nötig 133,3 A Dauer und 352,9 A Spitze; die Nennspannungs-Rechnung ergäbe 104,2 A (−22 %) und damit ein zu kleines BMS. Beispiel zeigt bewusst fehlende Tieftemperatur-Sperre und fehlende Hauptsicherung — beide Warnungen im Prerender sichtbar.
Spezifikation Teil 2 Rechner 40 samt Referenztestfall, eigene Verifikation vom 02.08.2026
engine/series-parallelFixDer Verschaltungsrechner (37) ist vervollständigt: Neu ist die Blockraster-Visualisierung (Serie vertikal, Parallelbus gezeichnet, Kennwerte live) und die Systemspannungs-Konsequenz nach Spez als Alternativen-Tabelle — alle Aufteilungen derselben Blockzahl mit Laststrom und relativem I²R-Kabelverlust, die eigene Konfiguration markiert. KPI-Subs (u. a. die Energie-Invariante), Feld-Hints, metaDescription, FAQ auf sechs Einträge. Neues Golden r37-series-parallel-de auf dem 4P-Beispielfall.
Beispielfall (4 × 12,8 V/100 Ah als 4P, 1 kW Last): 12,8 V / 400 Ah / 5,12 kWh, Laststrom 78 A — die Tabelle zeigt daneben 2S2P (39 A, ×4) und 4S (20 A, ×1): gleiche Energie, Faktor 16 bei den Kabelverlusten. Werte identisch mit dem Spez-Referenzfall.
Spezifikation Teil 2 Rechner 37 samt Referenztestfall und Invariante, eigene Verifikation vom 02.08.2026
engine/peukertFixDer Peukert-Rechner (36) ist vervollständigt: Die Engine echot die Kurven-Bezugsgrößen; der Bezugsraten-Umrechner ist jetzt vom Formular erreichbar (Zielrate C10/C5/C1 als Feld). Neu: die Kurven-Visualisierung nach Spez — Kapazität über dem Entladestrom (logarithmisch), Peukert-Kurve gegen die gestrichelte Ideallinie, die Fläche dazwischen als bezifferter Verlust am Betriebspunkt; bei LiFePO₄ fallen beide Kurven sichtbar zusammen. Darunter der Umrechner als Balkenpaar („100 Ah bei C20 = 76 Ah bei C5“). KPI-Zeile auf fünf Kacheln (inkl. verwendetem Exponenten mit Herkunft), Feld-Hints, metaDescription, FAQ auf sechs Einträge. Neues Golden r36-peukert-de auf dem Teil-1-Referenzfall.
Referenzfall (100 Ah C20, 10 A, k 1,25): Laufzeit 8,41 h statt naiver 10 h, effektiv 84,1 Ah (−15,9 %); Umrechnung auf C5: 75,8 Ah — dieselbe Batterie, 24 % kleinere Zahl. Werte identisch mit den bestehenden Engine-Tests.
Spezifikation Teil 2 Rechner 36 und Teil 1 Abschnitt 1.6.1 (Referenztestfall), eigene Verifikation vom 02.08.2026
engine/c-rateFixDer C-Rate-Rechner (35) ist vervollständigt: Die Engine echot Anlaufdauer und Datenblattfenster für die Darstellung. Neu: die Gauge-Visualisierung nach Spez — drei Halbkreis-Anzeigen (Entladen/Spitze/Laden) mit Datenblattzonen (grün bis 80 %, gelb bis 100 %, rot darüber) und Zeiger auf dem Betriebspunkt — plus die Spitzenlast-Zeitprüfung als Balkenpaar (Anlaufdauer gegen Datenblattfenster mit Urteil). KPI-Zeile auf fünf Kacheln mit Subs, Ladegrenzen-Felder ergänzt (inkl. temperaturkorrigierter Grenze), Feld-Hints, metaDescription, FAQ auf sechs Einträge. Neues Golden r35-c-rate-de.
Beispielfall (100 Ah, 50 A Dauer, 180 A/45 s Spitze gegen 200 A/30 s, 30 A Laden): Entladung 0,5 C bei 50 % Ausnutzung, Spitze 1,8 C bei 90 % Stromausnutzung — aber die 45 s überschreiten das 30-s-Fenster: PEAK_DURATION_EXCEEDED. Genau der Fall, in dem reine Stromvergleiche falsch liegen.
Spezifikation Teil 2 Rechner 35, eigene Verifikation vom 02.08.2026
engine/usable-capacityFixDer Nutzkapazitäts-Rechner (38) ist vervollständigt: Die Seite hatte keinerlei Eingabefelder — jetzt voller Feldsatz (Chemie-Auswahl, DoD, Temperatur-/Alterungsfaktor, AC-Anteil, advanced: Blöcke/Batterietemperatur/Wechselrichter). Neu in der Engine: der Umkehrmodus der Spez („3 kWh nutzbar — welche Nennkapazität kaufen?“) mit Auflösung nach C_nenn und dem größten beeinflussbaren Hebel (DoD ist als Chemie-Eigenschaft ausgenommen — sie zu überziehen kostet Zyklenlebensdauer), dazu Prozent-Ausgaben. Neu: der gestapelte Abbaubalken als Visualisierung — jede Stufe multipliziert den Rest, die additive Falschrechnung steht als Vergleichslinie daneben — plus Umkehrmodus-Panel. Vier KPI-Kacheln, Hints, metaDescription, FAQ auf sechs Einträge. Neues Golden r38-usable-capacity-de.
Beispielfall (100 Ah LiFePO₄, DoD 0,8, f_temp 0,9, f_alter 0,8, 50 % AC): 686 Wh nutzbar = 53,6 % der Nennkapazität; additiv gerechnet kämen falsche 43,1 % heraus. Umkehrmodus: Für 3.000 Wh nutzbar braucht es 437 Ah; größter beeinflussbarer Hebel ist die Alterungsreserve.
Spezifikation Teil 2 Rechner 38 und Teil 1 Abschnitt 1.6.2 (inkl. Doppelzählungs-Verbot für Round-Trip), eigene Verifikation vom 02.08.2026
engine/chemistry-comparisonFixDer Chemie-Vergleich (33) ist vervollständigt: Neu ist die Radar-Visualisierung mit überlagerten Chemien (sechs Achsen, jede auf den besten Kandidaten normiert, auswärts = besser, ausdrücklich KEIN Gesamtscore) samt Balkenansicht mit absoluten Zahlen als lesbare Alternative — und der Anwendungsfall-Filter der Spez: Wohnmobil/Gartenhaus/Hausspeicher/Boot blenden die im Fall entscheidenden Achsen ein und begründen die Auswahl. KPI-Subs erklären die Kapazitäts-Spreizung, Feld-Hints (u. a. Temperaturfaktor-Richtwerte aus dem Datensatz), metaDescription, FAQ auf sechs Einträge. Neues Golden r33-chemistry-comparison-de auf dem Beispielfall.
Beispielfall (2 kWh nutzbar, DC-Last): LiFePO₄ 195 Ah / 25,4 kg / 342 € je nutzbarer kWh / 9 ct je Durchsatz-kWh; AGM 333 Ah / 96,7 kg / 300 € je nutzbarer kWh / 60 ct je Durchsatz-kWh. Spreizung 1,71. Die Achsen widersprechen sich absichtlich: AGM gewinnt die Anschaffung, LiFePO₄ den Durchsatz — welcher zählt, entscheidet der Anwendungsfall.
Spezifikation Teil 2 Rechner 33, Datensatz data/batteries/chemistries.json (Herstelleraggregat, abgerufen 15.06.2026), eigene Verifikation vom 02.08.2026
engine/cycle-life-costFixDer Zyklenkosten-Rechner (34) ist vervollständigt: Die Unsicherheits-Simulation ist jetzt vom Formular erreichbar (Skalarfelder Unter-/Obergrenze der Zyklenangabe statt nur des internen Tupels), die Engine liefert die Kosten in ct/kWh, die Durchsatz-Bandgrenzen und die Kurvendaten (Jahresdurchsatz, Anschaffungs-Echo). Neu: die Treppenkurven-Visualisierung nach Spez — kumulierte Kosten über dem Durchsatz, jeder Ersatzkauf ein Sprung, zweite Achse in Jahren, Grenztreppen der Zyklenstreuung, Kalendergrenze-Hinweis. KPI-Zeile auf vier Kacheln (u. a. tatsächlich erreichbare Zyklen statt Datenblattzahl), Feld-Hints, metaDescription, FAQ auf sechs Einträge. Golden r34 um die additiven Ausgaben erweitert (UPDATE_GOLDEN); Referenzwerte unverändert.
Referenzfall (100 Ah/12,8 V, 800 €, 3.500 Zyklen @ 80 % DoD, η 0,94): 3.369 kWh Durchsatz, 23,7 ct/kWh, Band 22,2–33,2 ct bei 2.500–4.500 Zyklen; 250 Zyklen/a → Zyklengrenze bindend nach 14 Jahren. Gegenprobe: 60 Zyklen/a → Kalendergrenze bindet, CALENDAR_LIFE_BINDING.
Spezifikation Teil 2 Rechner 34 samt Referenztestfall (Zyklenzahlen ausdrücklich Beispieleingaben), eigene Verifikation vom 02.08.2026
engine/temperature-correctionFixDer Temperaturkorrektur-Rechner (29) ist vervollständigt: Die Engine liefert die Leistung-über-Temperatur-Kurve (Huld gegen Datenblattgerade, 0–80 °C) und den Montage-Malus zusätzlich in Euro. Neu: die zweiteilige Visualisierung — Kurvenvergleich mit Betriebspunkt und STC-Marke, darunter der Montagevergleich freistehend/aufgeklebt als Temperaturbalken mit Kelvin-Differenz und Jahres-Malus. KPI-Zeile auf fünf Kacheln mit Subs (Verlust ausdrücklich als reiner Temperaturanteil gegen STC-Zelltemperatur), Datenblatt-γ, Betriebsstunden und Strompreis als advanced-Felder, Feld-Hints, metaDescription, FAQ auf sechs Einträge. Neues Golden r29-temperature-correction-de auf dem Spez-Referenzpunkt. Das einstrahlungsgewichtete Standort-Histogramm der Spez braucht die TMY-Anbindung — als Roadmap benannt.
Spez-Referenzpunkt (25 °C Luft, 1000 W/m², 1 m/s): freistehend 55,2 °C/380 W, aufdach/aufgeklebt 68,1 °C/355 W — 12,9 K und 6,6 % Leistung allein durch die Montage; hochgerechnet 24,6 kWh bzw. 7,4 € pro Jahr je Modul (1000 Volllaststunden, 30 ct).
Spezifikation Teil 2 Rechner 29 und Teil 1 Abschnitt 1.5 (Faiman/Huld, PVGIS-Koeffizienten), eigene Verifikation vom 02.08.2026
engine/snow-wind-loadFixDer Schnee-/Windlast-Grobcheck (32) ist vervollständigt: Der wichtigste Hinweis der Spez — Grobcheck, kein Standsicherheitsnachweis — ist jetzt eine dauerhafte Engine-Warnung (NOT_A_STRUCTURAL_PROOF) statt nur Methodik-Text. Die KPI-Zeile stellt der Schneelast die Unterschätzung generischer Rechner gegenüber (Formbeiwert-Abfall trotz Modulen). Neu: das Lastpfad-Schema als Visualisierung (Dachschnitt mit Schnee- und Sogpfeilen, Kräfte an Modul, Befestigungspunkt und Dachhaken angeschrieben, Ballast-Aussage) plus Formbeiwert-Vergleichsbalken; Modulmaße und c_pi als advanced-Felder; Feld-Hints inkl. Urheberrechts-Begründung der s_k-Eingabe; metaDescription; FAQ auf sechs Einträge. Neues Golden r32-snow-wind-load-de auf dem Spez-Referenzfall. Die grün/rot-Bewertung gegen Komponenten-Bemessungswerte braucht deren Kennwerte — Roadmap.
Referenzfall (s_k 1,10 kN/m², 35°, 4 Punkte): korrekt 0,880 kN/m² (μ₁ = 0,8), generisch 0,733 (−17 % Unterschätzung bzw. +20 % Aufschlag), 1.440 N je Modul, 360 N je Befestigungspunkt. Windteil mit Defaults: Sog 1.818 N je Modul, erforderlicher Ballast 255 kg je Modul (c_pe = −1,4 ohne Windleitbleche) — die Ballast-Warnung greift. Werte identisch mit Referenztests R32-01 bis -03.
Spezifikation Teil 2 Rechner 32 (EN-1991-Rechenregeln; Lastzonenkarten bewusst nicht digitalisiert, Anhang B6), eigene Verifikation vom 02.08.2026
engine/roof-packingFixDer Dachbelegungs-Rechner (31) ist vervollständigt: Die Engine echot die Eingabegeometrie und gibt die Flächenbelegung als Prozent aus; die KPI-Zeile stellt dem Packungsergebnis jetzt den Flächenquotienten samt Überschätzung gegenüber (die Rechnung der meisten Konkurrenzrechner). Neu: der maßstäbliche Belegungsplan als Visualisierung — Dachfläche mit Randabstands-Zone, Module als Kacheln, umschaltbar hochkant/quer/gemischt mit Modulzahl je Variante, Startvariante ist die beste. Fugen- und Reihenabstandsfelder ergänzt (advanced; bei Flachdach-Aufständerung gehört der Wert aus Rechner 26 in den Reihenabstand), Feld-Hints, metaDescription, FAQ auf sechs Einträge. Neues Golden r31-roof-packing-de auf dem Spez-Referenzfall. Hindernisse per Klick und die Flachdach-Reihenkopplung aus der Spez brauchen eine Packung mit Aussparungen — als Roadmap in der Methodik benannt.
Referenzfall (Nutzfläche 6,00 × 3,70 m, Modul 1,762 × 1,134 m, 440 Wp): 10 Module hochkant (4,4 kWp), quer 9, Flächenquotient behauptet 11,1 — 11 % zu viel. Werte identisch mit den bestehenden Referenztests.
Spezifikation Teil 2 Rechner 31 samt Referenztestfall, Marktstandard-Modulmaß 2026 (108 Halbzellen, 1134 × 1762 mm), eigene Verifikation vom 02.08.2026
engine/row-spacingFixDer Reihenabstand-Rechner (26) ist vervollständigt: Die KPI-Zeile zeigt jetzt die beiden Differenzierer — den Mittags-Vergleichswert (was Rechner ohne die Auslegungsfall-Frage stillschweigend liefern) und die Ersparnis der Azimutkorrektur — statt Schattenlänge und Sonnenhöhe, die in den Rechenschritten stehen. Neu: die Schattenwurf-Visualisierung nach Spez (Draufsicht mit Zeitregler über den 21. Dezember, Schattenpolygon mit seitlichem Versatz, verschatteter Anteil der hinteren Reihe rot, Stundenbalken 8–16 Uhr grün/rot) plus Seitenschnitt der Auslegungsgeometrie; Feld-Hints, metaDescription, FAQ auf sechs Einträge. Die Engine echot dafür die Eingabegeometrie. Neues Golden r26-row-spacing-de auf dem Spez-Referenzfall.
Referenzfall 48,8° N, Modulkante 1,13 m, 30° Neigung, Auslegung 9–15 Uhr: Pitch 4,29 m, GCR 0,26, Mittagsfall 2,74 m (+56 % Fläche dazwischen), Azimutkorrektur spart 19,9 % Abstand gegenüber der naiven Rechnung ohne cos ΔA (32 % weniger Schattenlänge). Werte identisch mit den Referenztests R26-01/R26-02.
Spezifikation Teil 2 Rechner 26 samt Referenztestfall, Anker A21 (Fachdarstellungen, 28.07.2026), eigene Verifikation vom 02.08.2026
engine/generator-vs-solarFixDer Generator-vs-Solar-Rechner (46) ist vervollständigt: Kraftstoffpreis-Vorbelegung von 1,75 € auf 2,15 €/l aktualisiert (ADAC-Bundesmittel 29.07.2026: E10 2,139 €, Diesel 2,190 €) und der Verbrauch je kWh als sichtbares Feld ergänzt (Datenblatt-Spanne 0,3–0,6 l/kWh). Die Engine liefert jetzt die Kostenkurven über der Jahresenergie (0,2- bis 3-fach) samt Break-even und die Kerngrößen in Anzeigekonvention (ct/kWh, Prozent). Neu: die Break-even-Visualisierung (Solar- und Generatorkurve mit ±40-%-Kraftstoffband, Kraftstoff-Untergrenze als Linie, keine Empfehlung bei Überlappung) und die Hybridkurve mit ehrlicher Ecklösungs-Beschriftung; vier KPI-Kacheln mit Subs, Feld-Hints, FAQ auf sechs Einträge, metaDescription. Neues Golden r46-generator-vs-solar-de.
Referenzfall (3.000 kWh/a, 20 Jahre, 4 % Diskont): Solar 10,9 ct/kWh, Generator 100,9 ct/kWh (Band 66,5–135,3 ct), Kraftstoff allein 86 ct. Empfehlung solar — der Abstand hält auch am pessimistischen Bandrand. Die Hybridkurve meldet die Ecklösung (100 % Solar) als Modellgrenze, nicht als Optimum.
Spezifikation Teil 3 Rechner 46, ADAC-Spritpreisauswertung (abgerufen 02.08.2026), Herstellerdatenblätter zum spezifischen Verbrauch, eigene Verifikation vom 02.08.2026
engine/price-escalationFixDer Strompreisentwicklungs-Rechner (50) ist vervollständigt: Die Engine gibt die Kerngrößen jetzt zusätzlich in Anzeigekonvention aus (nötige Steigerung in Prozent, Barwerte in Euro statt sechsstelliger Cent-Beträge) und echot Startpreis und Zielhorizont für die Darstellung. Der Feld-Default für den Arbeitspreis kommt jetzt konsistent aus dem Tarifdatensatz (Bestandskundenmittel 31,1 ct statt 35 ct Literal). Neu: das Fächerdiagramm (drei Preispfade ab heute, Fläche ausdrücklich als Unsicherheitsbereich beschriftet, KEINE Prognose) mit der Umkehrfrage samt Plausibilitäts-Dämpfer als Panel; vier KPI-Kacheln mit Subs; Feld-Hints; FAQ auf sechs Einträge erweitert. Neues Golden r50-price-escalation-de liest den Startpreis aus dem versionierten Tarifdatensatz — eine Preisrevision macht den Build rot.
Referenzfall: 2000 kWh Eigenverbrauch, 31,1 ct, 20 Jahre, 3 % Diskont → Barwert 9.254 € (0 %), 11.026 € (2 %), 13.259 € (4 %). Umkehrfrage bei 12.000 € Investition und Ziel 10 Jahre: nötig wären 13,95 % pro Jahr (Verdopplung alle ~5 Jahre) — als unplausibel gedämpft. Handverifikation: 0-%-Fall entspricht der Rentenbarwertformel 622 €/a × 14,877 = 9.254 €.
Spezifikation Teil 3 Rechner 50, Tarifdatensatz data/tariffs/de.json (BNetzA/SMARD-Preisanalyse, abgerufen 02.08.2026), eigene Verifikation vom 02.08.2026
engine/co2-savingsFixDer CO₂-Rechner (49) ist vervollständigt: Die Seite hatte keine Eingabefelder — jetzt Feldsatz mit den beiden Spez-Schaltern als sichtbare Segmente: Emissionsbasis (UBA-Durchschnittsmix 344 g vs. Verdrängung 650 g — die Wahl, die das Ergebnis fast verdoppelt) und Produktionsstandort (EU/unbekannt/China → 400/500/600 kg CO₂e je kWp, Fraunhofer-ISE-Spanne). Beide Werte kommen über eine neue Emissions-Anreicherung aus dem versionierten UBA-Datensatz statt aus Literalen. Neu: die Startschuld-Kurve als Visualisierung (Beginn bei minus der Herstellungsemission, Nulldurchgang = CO₂-Amortisation, Band über die Herstellungs-Spanne) und fünf KPI-Kacheln inkl. Herstellungs-Rucksack und Netto-Bilanz.
Referenzfall der Spezifikation reproduziert: 10 kWp, 10.000 kWh/a, UBA-Mix → 3,44 t Vermeidung pro Jahr, CO₂-Amortisation 1,16–1,74 Jahre je nach Standort. Die Methodik weist offen aus, dass die Lebensdauersumme mit konstantem Faktor eine Obergrenze ist (der Strommix wird sauberer).
Spezifikation Teil 3 Rechner 49, UBA-Emissionsdatensatz (data/emissions/de.json), Fraunhofer-ISE-Angabe zur EU-Fertigung, eigene Verifikation vom 02.08.2026
engine/feed-in-revenueFixDer Einspeiseerlös-Rechner (48) ist vervollständigt: Die Seite hatte keine Eingabefelder und kein Beispiel — jetzt vollständiger Feldsatz (inkl. 60-%-Deckel und Negativpreisregel als sichtbare Schalter mit Annahme-Bandbreiten) und die erste TARIF-ANREICHERUNG: Die EEG-Staffeln kommen zur Laufzeit aus dem versionierten Datensatz statt aus Literalen, und das Datenalter speist die Veraltet-Warnung. Neu: der gestaffelte Balken als Visualisierung (jedes Segment mit seinem Satz, Mischsatz, Pauschalsatz-Falle) und fünf KPI-Kacheln.
Referenzfall mit den amtlichen Sätzen 08/2026: 15 kWp → Mischsatz 7,35 ct (10 kWp × 7,70 + 5 kWp × 6,66); der verbreitete Pauschalsatz-Fehler (6,66 ct auf alles) unterschätzt den Erlös um 9,4 %. Deckel-Warntext korrigiert: Er nennt jetzt die 60-%-Leistungsgrenze statt des internen Erlösfaktors.
Spezifikation Teil 3 Rechner 48, BNetzA-EEG-Sätze 08/2026, HTW-Deckelstudie, eigene Verifikation vom 02.08.2026
engine/lcoeFixDer LCOE-Rechner (42) ist vervollständigt: Die Seite hatte bisher GAR KEINE Eingabefelder — jetzt vollständiger Feldsatz inklusive des Diskontsatz-Erklärers (benannte Vorwahlen 0 % / 3 % Anlage / Kreditzins statt nackter Prozentzahl, Spez-Killer-Feature). Die Engine liefert zusätzlich das Diskontsatz-Band 2–6 % (7,10–9,90 ct im Referenzfall) für das Unsicherheitsband der neuen Visualisierung: LCOE-Balken gegen die Referenzlinien Strompreis und Einspeisevergütung, mit der verbreiteten Fehlrechnung (undiskontierter Nenner, −29,8 %) als Geisterlinie.
Mit den amtlichen EEG-Sätzen 08/2026 kippt die zitierfähige Kernaussage: Die Einspeisevergütung (7,70 ct) liegt jetzt UNTER den Gestehungskosten des Referenzfalls (7,74 ct) — jede eingespeiste Kilowattstunde ist ein leichtes Verlustgeschäft, die gesamte Rendite stammt aus dem Eigenverbrauch. Referenzfall der Spezifikation exakt reproduziert (Zähler 12.801 €, Nenner 165.328 kWh).
Spezifikation Teil 3 Rechner 42, BNetzA-EEG-Sätze 08/2026, eigene Verifikation vom 02.08.2026
engine/storage-worth-itFixDer Speicher-Rechner (44) ist an die Kette angeschlossen und ausgebaut: Der verfügbare PV-Überschuss kommt jetzt per Übernahme aus dem stundengenauen Eigenverbrauchs-Rechner (neuer Verkettungswert annualSurplusKwh = Einspeisung ohne Speicher), die Einspeisevergütung folgt den amtlichen EEG-Sätzen 08/2026 (Spread 23,40 ct beim Bestandskundenpreis), und die bisher fehlenden Eingabefelder DoD-Bezug und Round-Trip-Wirkungsgrad sind im Formular ergänzt. Neu: das Spread-Diagramm mit Rentabilitätsdiagonale (Datenblatt-Punkt vs. realistischer Punkt derselben Anlage) und die Drei-Schranken-Ansicht (Datenblatt-Zyklen, kalendarische Lebensdauer, Überschuss).
Der Referenzfall der Spezifikation ist als Golden-Referenz eingefroren und liest die Tarifwerte aus dem versionierten Datensatz: 10 kWh/5.000 € — kalendarische Lebensdauer bindet (27.000 statt 43.200 kWh Durchsatz), Kosten 18,52 ct, realistische Marge 4,88 statt 11,83 ct je kWh (−59 %). Genau die Rechnung, die Verkaufsrechner nicht zeigen.
Spezifikation Teil 3 Rechner 44, BNetzA-EEG-Sätze 08/2026, eigene Verifikation vom 02.08.2026
engine/balcony-solar-tmyDataDer Balkonkraftwerk-Rechner (54) läuft jetzt über das TMY-Stundenraster und löst den offenen Punkt H1 der Spezifikation ein: Der Ertrag senkrechter Brüstungsmontage wird aus den Stundendaten GERECHNET statt geschätzt (Berlin, Südfassade 90°: 731 kWh je kWp — rund 68 % des 45°-Optimums, konsistent mit der Literatur). Neu: stundengenaues Wechselrichter-Clipping an der 800-W-Grenze, Eigenverbrauchsquote aus dem echten Stunden-Dispatch gegen das Haushaltsprofil (gemessen 82 % für 890 Wp auf 3.000-kWh-Familienhaushalt — die bisher angenommene Quote entfällt), unbezahlter Export als eigene Größe, und die Regelwerks-Ampel als Entscheidungsbaum (800 W AC je Wohneinheit, Schuko bis 960 Wp nach DIN VDE V 0126-95, Energiesteckvorrichtung bis 2.000 Wp, Speicher fällt aus der Vereinfachung, Registrierung nur Marktstammdatenregister, 60-%-Deckel gilt nicht — Rechtsstand verifiziert 02.08.2026).
Der Rechner mit dem höchsten Suchvolumen ist damit primär Regelwerks-Assistent mit Steckertyp-Weiche (890 Wp → Schuko ok; 1.335 Wp → Energiesteckvorrichtung nötig) und rechnet die Amortisation ehrlich: Nur der selbst verbrauchte Strom trägt Geldwert (Referenzfall: 166 €/a Ersparnis, 3,0 Jahre Amortisation bei 500 € Systemkosten). Der Aufständerungs-Vergleich beziffert den Brüstungs-Malus (−27 % gegenüber 45°).
PVGIS 5.3 (SARAH3) über Rechner-27-Kette; Rechtsstand BNetzA/Solarspitzengesetz/DIN VDE V 0126-95, verifiziert 02.08.2026
tariffs/deDataEEG-Einspeisevergütung auf die amtlichen Sätze der Periode 01.08.2026–31.01.2027 aktualisiert (halbjährliche 1-%-Degression nach § 49 EEG): Teileinspeisung ≤10 kWp 7,70 ct/kWh (vorher 7,78), ≤40 kWp 6,66 ct (vorher 6,73), ≤100 kWp 5,44 ct (vorher 5,50). Quelle: Bundesnetzagentur-Fördersätze-Tabelle, abgerufen 02.08.2026 — Sekundärquellen, die 7,71/12,23 projizierten, lagen falsch. Hinweis der BNetzA: Der Solarpaket-I-Aufschlag (+1,5 ct) ist beihilferechtlich noch nicht wirksam und daher nicht enthalten. Volleinspeisungssätze (12,22/10,24 ct) sind im Datensatz weiterhin nicht modelliert. Zusätzlich lesen die Golden-Referenzfälle r41/r48 die Tarifwerte jetzt aus dem versionierten Datensatz statt als eingebettete Literale — erst damit wird der Build bei künftigen Datenänderungen tatsächlich rot, wie es der Mechanismus verspricht.
Amortisations- und Einspeiseerlös-Ergebnisse (Rechner 41/48) sinken geringfügig: 1 % weniger Vergütung je eingespeister Kilowattstunde. Golden Files r41-payback-de und r48-feed-in-revenue-de aktualisiert.
Bundesnetzagentur, EEG-Förderung und -Fördersätze (bundesnetzagentur.de), abgerufen 02.08.2026
engine/self-consumption-tmyDataDer Eigenverbrauchs-Rechner (43) rechnet jetzt stundenscharf statt mit dem Monats-Überlappungsmodell: Erzeugung aus der validierten TMY-Leistungskette der Rechner 27/28, Last aus einem NEUEN parametrischen Haushaltsprofil (Spez 9.1, Weg B) mit fünf Haushaltstypen (Berufstätig/Homeoffice/Rentner/Familie/Schichtarbeit), Werktag/Wochenende und Saisonmodulation — vollständig offengelegt statt Blackbox-Standardprofil. Speicher als Stunden-SoC-Modell (Leistungsgrenze, Round-Trip geteilt), optionaler deutscher 60-%-Einspeisedeckel, Gegenläufigkeitskurve über die Anlagengröße, Tagesprofile Sommer/Winter/Jahr und der Lastverschiebe-Tipp (1 kWh vom Abend in den Mittag).
Kreuzvalidiert gegen die öffentliche Referenzmatrix des HTW-Unabhängigkeitsrechners (Minuten-Simulation, VDI-4655-Profil, ausgelesen 02.08.2026): ohne Speicher trifft das Modell den Anker auf 0,2/0,7 Prozentpunkte (EVQ 29,9 vs. 29,7, Autarkie 31,1 vs. 30,4), mit Speicher auf 0,4/1,7 (Schranke 4). Der Haushaltstyp verschiebt die Quote um bis zu 11 Prozentpunkte — die Stellgröße, die kein Standardprofil kennt. Auflösungsehrlichkeit dokumentiert: Stundenwerte überschätzen den Eigenverbrauch leicht; Abregelverluste des 60-%-Deckels sind eine Untergrenze (HTW misst mit Minutendaten bis 9 % bei Süd).
HTW Berlin Unabhängigkeitsrechner (pvspeicher.htw-berlin.de), VDI-4655-Randbedingungen laut HTW-FAQ, eigene Kreuzvalidierung vom 02.08.2026
engine/annual-yield-tmyDataDer Jahresertrag-Rechner (28) läuft jetzt über das TMY-Stundenraster mit derselben Leistungskette wie der Monatsertrag (27): Perez-POA, Martin-Ruiz-Reflexionsverlust, Faiman-Temperatur mit Montageart, Huld-Kennlinie, Klimamittel-Kalibrierung — statt PSH × Performance Ratio mit Süd-Zwang und Azimut-Handfaktor. Darauf die Degradationsreihe (Jordan & Kurtz 0,5 %/a als sichtbare Annahme) mit Jahr-für-Jahr-Reihe, Lebensdauersumme, P90 des ersten Jahres und Erlösschätzung. Neu: der Garantie-Prüfer — aus der Hersteller-Leistungsgarantie (Endwert, Erstjahresverlust, Laufzeit) entsteht die Mindestkurve; unterschreitet der Erwartungspfad sie, meldet der neue Warncode DEGRADATION_EXCEEDS_WARRANTY das Jahr.
Jahr 1 ist deckungsgleich mit der Jahressumme von Rechner 27 (per Test erzwungen) und erbt dessen PVcalc-Kreuzvalidierung (±1,7 % Jahr). Die Degradationsmathematik reproduziert die Spez-Referenz: 20 Jahre bei 0,5 %/a liefern das 19,078-fache des ersten Jahres, nicht das 20-fache. Standardgarantie (87 % nach 25 a, 1 % Erstjahr) wird vom Erwartungspfad nie unterschritten — erst ab rund 1 %/a Degradation entsteht ein rechnerischer Garantiefall.
PVGIS 5.3 (SARAH3) über Rechner-27-Kette, Jordan & Kurtz 2013, eigene Kreuzvalidierung vom 01.08.2026
engine/monthly-yield-tmyDataDer Monatsertrag-Rechner (27) läuft jetzt über das TMY-Stundenraster mit der vollen PVGIS-Leistungskette: Perez-Transposition, NEU Reflexionsverlust nach Martin & Ruiz (a_r 0,16, je Strahlungskomponente), Modultemperatur nach Faiman aus Stundentemperatur und Wind MIT Montageart-Unterscheidung (frei/Aufdach), Huld-Kennlinie auf der effektiven Einstrahlung, Restverluste als sichtbarer Faktor, Klimamittel-Kalibrierung, P50/P90 aus den Einzeljahren. Die vereinfachte Ratgeber-Rechnung (PSH × PR) wird als Stufe 2 mitgeliefert und die Differenz ausgewiesen. Ersetzt den Monatsmittel-Weg (12 Städte, nur Süd, Azimut als Handfaktor).
Kreuzvalidiert gegen PVGIS PVcalc (API v5_3, SARAH3, abgerufen 01.08.2026) an vier Referenzstandorten, je Monat und für beide Montagearten: Jahressumme innerhalb von 1,7 % (Schranke 2,5), Monate innerhalb von 6,2 % (Schranke 8). Der verbleibende Offset von rund −1,5 % ist erklärt: PVcalc addiert eine Spektralkorrektur (l_spec, +1,8 % in Berlin), deren Datengrundlage nicht frei verfügbar ist — die Ergebnisse sind bewusst leicht konservativ. Der Aufdach-Malus (3,4 % in Berlin) deckt sich mit PVGIS (3,37 %). Messbefund gegen die Spez-Prognose: Die feste PR irrt im Sommer am stärksten (+8 % Juni, Modultemperatur), nicht im Winter.
PVGIS 5.3 (SARAH3), Martin & Ruiz 2001 via pvlib-Referenzimplementierung, eigene Kreuzvalidierung vom 01.08.2026
engine/azimuth-loss-tmyDataDer Ausrichtungs-Rechner (25) läuft jetzt über das TMY-Stundenraster — dieselbe kalibrierte Rechenkette wie die Rechner 23 und 24: Perez-Transposition über 8760 Stunden statt des isotropen Diffusmodells mit angenommenem Diffusanteil, 1.155 Rasterpunkte statt 12 Städte, Geländehorizont, Niveau aufs Vieljahresmittel 2005–2023 kalibriert. Der Relativertrag wird gegen das echte Standort-Optimum aus Neigung UND Ausrichtung gerechnet (Spezifikationsformel), zusätzlich als reiner Azimut-Effekt bei der eigenen Dachneigung ausgewiesen. Neu: 24-Punkte-Azimut-Sweep als Tabelle, Ost-West-Paar-Vergleichswert fürs Satteldach, Tagesprofile Ost/Süd/West für den Eigenverbrauchs-Blick.
Rechner 23, 24 und 25 geben jetzt dieselbe Antwort auf dieselbe Frage. Kreuzvalidiert gegen PVGIS PVcalc (API v5_3, SARAH3, abgerufen 01.08.2026) an vier Referenzstandorten über je 7 Ausrichtungen: Relativertrag innerhalb von 1,5 Prozentpunkten (typisch unter 1, Schranke 2). Die reale Ost-West-Wetterasymmetrie (in Berlin liefert Ost mehr als West) wird erstmals abgebildet — das Repräsentativtage-Modell konnte das prinzipbedingt nicht.
PVGIS 5.3 (SARAH3), eigene Kreuzvalidierung vom 01.08.2026
engine/stepsFixAlle Formelausdrücke der Rechenschritte (expression) von deutscher Prosa auf sprachneutrale Fachnotation umgestellt (Σ, H_a, d_m, η_…, P_cont, U_absorb, HDD, SCOP), damit die englischen Seiten keine deutschen Formeln mehr zeigen. Die lokalisierten Formelzeilen (calc.*.formula) beider Sprachen wurden auf dieselben Symbole angeglichen; die Datensatz-Metadaten tragen jetzt zusätzlich sourceEn/versionEn für die englische Quellenangabe. Zahlenwerte aller Rechner unverändert — nur Beschriftungen.
Golden Files aktualisiert (nur expression-Strings, keine Werteänderung). EN-Seiten zeigen Rechenweg und Datenquellen vollständig auf Englisch.
Sprach- und Fakten-Audit der Rechnerseiten vom 01.08.2026
engine/optimal-tilt-tmyDataDer Neigungswinkel-Rechner (24) läuft jetzt über das TMY-Stundenraster — dieselbe kalibrierte Rechenkette wie der Sonnenstunden-Rechner (23): 1.155 Rasterpunkte statt 12 Städte, beliebige Ausrichtung statt nur Süd, Geländehorizont, Niveau aufs Vieljahresmittel 2005–2023 kalibriert. Neu: Vergleich der eigenen Dachneigung gegen das Optimum, Neigungskurve mit Toleranzband als Diagramm, Werteübergabe von und zu Rechner 23. Zusätzlich ein Verstell-Planer: beste 2-Lagen-, 4-Lagen- und Monatsstrategie mit optimalen Umstellmonaten und Mehrertrag, gerechnet aus der Standort-Matrix statt aus Breitengrad-Faustformeln.
Beide Rechner geben jetzt dieselbe Antwort auf die Optimum-Frage. Kreuzvalidiert gegen die PVGIS-eigene Optimalwinkelsuche (optimalangles/optrad, abgerufen 31.07.2026): Optimalwinkel innerhalb von 1,4° (Schranke 2,5°), Jahressumme am Optimum innerhalb von 0,04 % (Schranke 1 %) an vier Referenzstandorten. Ost-/Westflächen erhalten erstmals ein eigenes, deutlich flacheres Optimum statt der Süd-Annahme. Der Verstell-Planer liefert die ehrliche Zahl: In DACH bringt zweimaliges Verstellen rund 3 % (Berlin +2,8 %, München +3,5 %), monatliches rund 4 % — deutlich unter den 5–15 % verbreiteter Faustformel-Rechner, die für sonnige Klimata gelten.
PVGIS © Europäische Union (TMY, MRcalc, PVcalc optimalangles); Kreuzvalidierung in packages/engine/test/optimal-tilt-tmy.spec.ts, Golden File test/golden/r24-optimal-tilt-tmy.json
engine/peak-sun-hours-tmyFixZwei Korrekturen am Sonnenstunden-Rechner (23). Erstens: Das PVGIS-TMY liegt je Rasterpunkt bis zu +5 % (GHI) bzw. +11 % (DNI) neben dem eigenen 19-Jahres-Klimamittel — die Absolutwerte (Jahressumme, P50/P90) werden jetzt je Monat aufs MRcalc-Klimamittel kalibriert; das TMY liefert nur noch Form und Profile. Zweitens: PVGIS-SARAH-Stundenwerte sind Satellitenscans um ca. hh:11, keine Stundenmittel — der Sonnenstand wird jetzt bei k+11/60 statt k+0,5 gerechnet.
Beispiel Berlin, 35° Süd: Jahressumme 1.308 statt 1.418 kWh/m², P50 1.302 statt 1.413, P90 1.208 statt 1.310 — das angezeigte P90 entsprach vorher dem Mitteljahr der PVGIS-Statistik, jetzt dem echten 10. Perzentil der Einzeljahre. Ost/West-Flächen: Die Stundenmitten-Annahme verschob Energie systematisch von Ost nach West (gemessen -4,3 %/+2,3 % gegen PVGIS seriescalc); nach der Korrektur sind beide symmetrisch bei rund -1 %. Absolute Jahressummen liegen jetzt an allen vier Referenzstandorten und allen Neigungen 15–90° innerhalb von 1,9 % der PVGIS-Referenz.
PVGIS © Europäische Union (MRcalc-Einzeljahre 2005–2023, seriescalc 2023); Kreuzvalidierung und Golden File in packages/engine/test/tmy.spec.ts und test/golden/r23-peak-sun-hours-tmy.json
engine/balcony-solarDataPunkt H1 aufgelöst und drei weitere Rechner veröffentlicht: Eigenverbrauch/Autarkie (43), Balkonkraftwerk (54) und Wärmepumpe+PV (60). Der Balkonertrag kommt aus den committeten 90°-POA-Reihen von PVGIS — gerechnet, nicht geschätzt; die Wärmepumpen-Monatslast aus den Gradtagszahlen der Monatsmitteltemperaturen desselben Datensatzes.
Rechner 43 und 60 sind ausgewiesene MONATSMODELLE mit angenommener Tagesgleichzeitigkeit (Warncode OVERLAP_MODEL_MONTHLY) — die Größenordnung stimmt, stundenscharfe Simulation ist genauer. Rechner 54 prüft die deutsche Vereinfachungsregel (800 VA / 2 000 Wp, Solarpaket I) und weist unvergüteten Export separat aus.
PVGIS © Europäische Union (POA 90° und Monatsmitteltemperaturen); Energiebilanz-Invarianten in packages/engine/test/calculators-22.spec.ts
irradiance/wave-1DataPunkt B10 aufgelöst: Der PVGIS-Datensatz (12 Standorte × 10 Neigungen, POA in Modulebene, API v5_3) ist committet und treibt sechs neue beziehungsweise freigeschaltete Rechner: Sonnenstunden (23), Neigungswinkel (24), Ausrichtung (25), Monatsertrag (27), Jahresertrag (28) und Solarmodul-Dimensionierung (2).
Die Ertragsrechner verwenden keine eigene Transposition, sondern interpolieren linear zwischen den PVGIS-Ankern. Punkt J2 ist damit als Leave-one-out-Test umgesetzt: Rekonstruktion eines entfernten Ankers aus seinen Nachbarn bleibt an allen zwölf Standorten unter 1 % Jahresfehler (unter 6 % über die künstlich vergrößerte 45–90°-Lücke; gemessener Worst Case Phoenix 5,3 %).
PVGIS © Europäische Union, re.jrc.ec.europa.eu; Kreuzvalidierung in packages/engine/test/poa.spec.ts
engine/azimuth-lossDataDer Ausrichtungsverlust (Rechner 25) ist ein offengelegtes Geometriemodell: Direktstrahlung über den Einfallswinkel an zwölf Repräsentativtagen integriert, Diffusstrahlung isotrop, Diffusanteil als sichtbare Annahme (Vorgabe 0,55).
Ost/West bei 35° Neigung liegt im Literaturband 75–92 % gegenüber Süd; Nord kostet grob ein Drittel. Das isotrope Modell ist konservativ — der Zirkumsolaranteil verstärkt den Effekt real leicht.
Liu & Jordan (isotrope Transposition), Klein 1977 (Repräsentativtage); Fixpunkt- und Bandtests in packages/engine/test/calculators-21.spec.ts
engine/payback-gridFixDie Sensitivitätsanalyse variierte alle Eingänge um einheitliche ±20 %.
Dadurch stand der Jahresertrag vor dem Strompreis — falsch, weil der Ertrag beide Erlösanteile skaliert, der Preis aber nur den Eigenverbrauch. Jeder Eingang hat jetzt seine eigene, dokumentierte Bandbreite: Strompreis über die Marktspanne, Ertrag über das P90/P110-Band.
Eigene Prüfung beim Testlauf
engine/array-sizingFixDie Warnung WINTER_SIZING_EXTREME verglich gegen den gewählten Auslegungsmonat statt gegen das Jahresmittel.
Die Warnung löste nie aus. Sie meldet jetzt korrekt, wenn eine Winterauslegung mehr als das Dreifache der Anlage des Jahresmittels erfordert.
Vom Abdeckungs-Gate aufgezeigt
web/hreflangFixSitemap und HTML gaben unterschiedliche Sprachcodes an: de-DE gegen de.
Zwei verschiedene Signale an Suchmaschinen. Beide jetzt auf de und en, passend zur DACH- und internationalen Zielgruppe.
Eigene Prüfung
tariffs/deDataStrompreissegmente und Einspeisevergütung auf den Stand Q3/2026 gebracht.
Die Amortisationszeit im Referenzfall verschiebt sich geringfügig.
Bundesnetzagentur SMARD, EEG-Vergütungssätze nach § 48 EEG 2023
emissions/deDataEmissionsfaktor des deutschen Strommix auf 344 g/kWh aktualisiert.
Die CO₂-Amortisation verlängert sich leicht. Der Verdrängungsfaktor bleibt bei 650 g/kWh und ist weiterhin umschaltbar — beide Werte beantworten verschiedene Fragen.
Umweltbundesamt, Emissionsbilanz erneuerbarer Energieträger, Ausgabe 2026