Hausladen und Nachbarladen trennen

Schritt 0 und 1 sind gebaut · Schritt 2 bis 5 offen · Stand 07.11.2026

Warum es diese Seite gibt. Jürgen am 07.11.2026: „schlimm ist das wir 2 Subdomains haben sich aber die Apps beeinflussen. Was ist das für eine schlechte Programmierung. … das gehört getrennt.“ Dazu die Regel aus derselben Nachricht: „ist kein Auto dran, darf die App auch nichts beeinflussen. Immer nur je Auto das mit chip freigeschaltet wurde kann starten und stoppen über die app.“ Die Regel ist am selben Abend gebaut. Diese Seite behandelt die Trennung selbst.

Was heute geteilt wird

Nicht nur die Oberfläche. Die zwei Adressen sind das Harmloseste daran.

Geteilt	Wo	Was davon schon schiefging
Ein Programm für zwei Masken	`nachbar_laden.py` mit dem Schalter `HAUS`; zwei Dienste aus einer Datei, Port 8091 Haus, 8089 Nachbar	Der Stoppknopf der Hausmaske schrieb in die Dateien des Nachbarn. Belegt am 07.11.: `nachbar_stopp.json` trug den Zählerstand von Jürgens ID.3, und Dietrichs Maske hielt einen Handstopp, den er nie gedrückt hatte
Dieselben Eingabefelder	`input_number.ev_ladeplan_start_soc` und `_ziel_soc` stehen in beiden Programmen als `H_START`/`H_ZIEL`	Wer in einer Maske speichert, verändert die Zahlen der anderen
Eine Zeile Zählerstand	Tabelle `zaehler`, eine einzige Zeile für beide	Belegt am 07.11. um 17:00:01: der Hauslauf überschrieb Dietrichs Nullpunkt mit Jürgens 23 %
Ein Ladepunkt	Modus, Phasen, `limitEnergy`, Preisgrenze — eine Wallbox	Lässt sich nicht trennen, nur ordnen. Siehe Schritt 3
Markendateien über Umwege	Die Hausmaske rief Funktionen aus `nachbar_fenster` auf, die auf `nachbar_*.json` schreiben	Teils am 07.11. behoben (Stopp, Grenze, Auftrag); die Ansteckmarke läuft weiter über den Nachbarn

Was sich nicht trennen lässt, und das muss man sagen. Es gibt eine Wallbox und einen Ladepunkt in EVCC. Modus, Phasenzahl, Mengengrenze und Preisgrenze sind je ein einziges Feld. Zwei Programme, die darauf schreiben, bleiben zwei Schreiber — egal wie sauber der Rest getrennt ist. Die Trennung kann also nur heißen: zu jedem Zeitpunkt gehört der Ladepunkt genau einer Seite, und die andere rührt ihn nicht an. Wer entscheidet das? Der Chip, mit dem freigeschaltet wurde. Genau das ist Jürgens Regel.

Der Vorschlag in fünf Schritten

Geordnet nach Nutzen gegen Risiko, nicht nach Aufwand. Jeder Schritt ist einzeln abschließbar; nach jedem läuft die Anlage.

Schritt 0 — die Gast-Automation abschalten GEBAUT am 07.11.2026

Seit dem 07.11. gehört der Gast zum Hausladen (Jürgen: „Gast kann mit ins Haus Laden … Ich lege dann die kwh des Autos in evcc an.“). Damit hat automation.evcc_fahrzeug_ladelimit_setzen keine Aufgabe mehr — ihr letzter Zweig war der Gast. Sie war ohnehin der dritte Schreiber auf limitEnergy und rechnete den Sitzungszähler nicht mit, setzte die Grenze also zu niedrig.

Erledigt. Die Automation steht auf off, dazu initial_state: false, damit sie auch nach einem Neustart von Home Assistant aus bleibt. Die ganze Begründung steht in ihrer eigenen Beschreibung, alte Fassungen liegen unter /home/juergen/energie/sicherung_ha/. Geprüft: kein Projektskript und keine andere Automation liest input_number.evcc_gast_ziel_kwh — der Helfer bleibt stehen, bis Jürgen ihn löschen will. Damit schreibt genau eine Stelle je Auto die Mengengrenze.

Schritt 1 — eine Stelle entscheidet, wem der Ladepunkt gehört GEBAUT am 07.11.2026

Heute steht dieselbe Frage zweimal im Code: haus_fenster.unser_auto() und nachbar_fenster.sein_auto(), dazu zwei Helfer in der Maske. Zwei Fassungen derselben Regel laufen auseinander — das ist genau der Fehlertyp, der die vergessene Automation verursacht hat („wird er in EVCC umbenannt, müssen BEIDE nachgezogen werden“ — es waren drei).

Erledigt. ladepunkt.py beantwortet jetzt als einzige Stelle: wem gehört der Ladepunkt? — haus, nachbar oder niemand, hergeleitet aus Stecken und Chipkennung. Daran hängen haus_fenster.unser_auto, nachbar_fenster.sein_auto und in der Maske meine_seite/meine_seite_grund; die Kartenliste und der Kartenname „Dietrich“ stehen nur noch dort. Das Modul kann sich selbst prüfen: python3 ladepunkt.py zeigt Kennung, Besitzer und wer gerade schalten darf.

Beim Zusammenlegen fiel ein Fehler auf, der sonst erst beim Laden aufgefallen wäre. Die erste Fassung von nachbar_fenster.sein_auto() verglich mit KARTE — und KARTE ist in dieser Datei nie definiert, sie steht in nachbar_laden.py. Beim Öffnen des Tors hätte das abgebrochen. Genau dafür gibt es jetzt eine Stelle statt dreier.

Zwei weitere Stellen entschieden es ebenfalls selbst und hängen jetzt mit dran: die Taste „Jetzt laden“ wies bisher nur Dietrichs Karte ab — ohne jedes Auto am Kabel hätte sie den Modus auf now gestellt. Und das Speichern der Eingaben. Dort bleibt die Strenge absichtlich unterschiedlich: Speichern ist kein Starten, Jürgen soll einen Plan auch vorbereiten können, bevor das Auto steckt — gesperrt ist es nur, solange der Ladepunkt dem Nachbarn gehört. Dietrichs Seite verlangt weiter seine steckende Karte, weil seine Eingabe zugleich die Zusage ist, nach der abgerechnet wird.

Dabei bleibt die Asymmetrie von heute: aufmachen darf nur der Eigentümer, zumachen und eigene Spuren wegräumen darf jeder immer — sonst bliebe ein Tor offen, nachdem abgesteckt wurde.

Schritt 2 — eigene Zählerzeile je Maske (klein, behebt einen belegten Zusammenstoß)

Die Tabelle zaehler hat eine Zeile für beide. Am 07.11. um 17:00:01 hat der Hauslauf Dietrichs Nullpunkt überschrieben.

Zu tun: eine Spalte maske (haus/nachbar) als Teil des Schlüssels, bestehende Zeile auf nachbar setzen. Kleine Wanderung der Datenbank, rückwärts verträglich.

Schritt 3 — eigene Eingabefelder je Maske (mittel, mechanisch)

ev_ladeplan_start_soc, _ziel_soc und die drei Fristfelder gehören heute beiden. Vorschlag: der Nachbar behält die bestehenden Namen (an ihnen hängen seine Automationen, sein Budget und seine Seite), das Haus bekommt neue, etwa input_number.haus_ladeplan_start_soc.

Warum diese Richtung: die Hausmaske ist das jüngere Programm und hat weniger daran hängen. Umgekehrt wäre es mehr Arbeit und mehr Risiko.

Zu tun: Helfer in Home Assistant anlegen (das machst du — sie erscheinen auf deinen Übersichten), dann H_START/H_ZIEL in der Hausmaske umhängen und die Werte einmal übertragen.

Schritt 4 — eigene Markendateien, keine Umwege mehr (klein)

Stopp, Mengengrenze und Auftrag hat das Haus seit dem 07.11. selbst. Offen ist die Ansteckmarke: die Hausmaske liest weiter nachbar_steckt.json über nachbar_fenster. Sie wird seit dem 29.10. für jedes Auto geführt, funktioniert also — der Name lügt aber, und beim Trennen fällt das auf.

Zu tun: die Ansteckmarke nach ladepunkt.py aus Schritt 1 ziehen; sie gehört dem Kabel, nicht einer der beiden Seiten.

Schritt 5 — das Programm teilen (groß, zuletzt, geringster Nutzen)

Erst wenn 0 bis 4 stehen, lässt sich nachbar_laden.py gefahrlos auftrennen: ein gemeinsamer Unterbau für Webserver und Seitenbau, dazu zwei schlanke Vorderseiten ohne HAUS-Schalter.

Ehrlich dazu: das ist der aufwendigste Schritt und bringt am wenigsten. Der Schaden entstand nicht daraus, dass es eine Datei ist, sondern daraus, dass in ihr ungeprüft auf die Dateien der anderen Seite geschrieben wurde. Das ist nach Schritt 0 bis 4 behoben. Schritt 5 sorgt dafür, dass es nicht zurückkommt.

Was ich nicht ohne dein Wort anfasse

Helfer in Home Assistant anlegen oder umbenennen — sie erscheinen auf deinen Übersichten.
Die Datenbank wandern lassen — vorher Sicherung, und du sollst wissen, wann.
Dienstdateien ändern — Neustarts gibst du selbst ein.
Dietrichs Preisgrenze und sein Budget — das ist seine Abrechnung, da geht nichts nebenbei.

Mein Rat zur Reihenfolge. Schritt 0 und 1 zusammen an einem Abend — danach gibt es je Auto genau einen Schreiber und eine einzige Stelle, die über den Ladepunkt entscheidet. Das ist der Großteil des Nutzens. Schritt 2 gleich hinterher, weil der Zusammenstoß belegt ist. Schritt 3 und 4 in Ruhe. Schritt 5, wenn sonst nichts drängt.