Was gebaut wurde

Friert den Hausakku ueber einen eigenen DESS-Zeitplan in Slot 0 ein, solange EVCC SCHNELL laedt. NUR beim Schnellladen (Juergen 10.10.2026: 'es darf nur bei evcc schnell gehen'). Strategy=0 mit TargetSoc=aktueller SoC fuehrt auf IDLE_MAINTAIN_TARGETSOC; MultiRsDevice.idle() setzt den Netz-Sollwert auf den GANZEN Verbrauch inkl. Wallbox. Gemessen: Akku +5330 -> -85 W. SLOT 0, weil bei mehreren passenden Fenstern der NIEDRIGSTE Index gewinnt. JEDE MINUTE, weil DESS bei abgelaufenem Fenster SOFORT auf Eigenverbrauch zurueckfaellt - das ist auch die Antwort auf Juergens Anforderung vom 23.10.2026:

Gibt den Hausakku wieder frei, sobald das Schnellladen endet - bei Moduswechsel weg von 'now', Ladeende, zurueckgenommener Schnellwahl oder abgelaufenem Preisfenster. NOTBREMSE nach 6 h. === UMGEBAUT 23.10.2026 === (1) NEUE BEDINGUNG input_boolean.dess_eingefroren = on. Sie laeuft jetzt NUR, wenn wir wirklich eingefroren haben. Zwei gemessene Fehler fallen damit weg: Am 22.10.2026 nullte sie Slot 0 um 19:40:55, also im Moment des LADESTARTS - weil beim Umschalten auf 'now' smart_cost_active ausgeht und das einer ihrer fuenf Ausloeser ist. Und am 12.10.2026 feuerten beim Ladeende zwei Ausloeser

'Dauerhaft laden' (alwaysCharge) lädt mit Mindeststrom weiter, auch ohne Sonne — und zieht dabei den Hausakku leer (Vorfall 18.09.2026: 97 → 58 %). Anders als beim Battery Boost hat EVCC dafür KEINE eigene Untergrenze; batteryBoostLimit gilt nur für den Boost. Diese Automatisierung schließt die Lücke: Fällt der Hausakku unter sensor.minpv_grenze, schaltet sie 'Dauerhaft laden' ab. Die Grenze folgt der PV-Prognose für morgen — 50 % bei guter Aussicht, 80 % bei magerer; fehlt der Sensor, gilt 80 % (sichere Seite). Unterhalb der Grenze lässt es sich auch nicht wieder einschalten. Greift NICHT bei

JUERGENS REGEL (10.10.2026, woertlich): 'akku bei 73% Laden auch aus PV ist verboten er ab 80%'. Unter der Grenze gehoert der Solarueberschuss dem HAUSAKKU, nicht dem Auto - er ist der Puffer fuer den teuren Abend, das Auto kann nachts billig laden. DASSELBE SAGT EVCC SELBST: prioritySoc=75 heisst 'Solarueberschuss laedt den Hausakku bis zu diesem Stand, bevor das Auto drankommt'. EVCC haelt sich nicht daran - am 10.10. um 16:00 lud das Auto mit 4,38 kW bei 73 % Hausakku. Darum setzen WIR die Regel durch. VORGESCHICHTE: Erst nur gegen Entladung gebaut (Akku entlaedt sich ins Auto). Juergen: 'D

Loescht den Merker input_boolean.ev_minsoc_erhoeht, sobald die MQTT-Rueckmeldung des Geraets bestaetigt, dass der Mindest-SoC wieder auf dem Ruhewert steht. BEWUSST AN DER RUECKMELDUNG und nicht am Schreibvorgang: ein verlorengegangener MQTT-Publish wuerde sonst den Merker loeschen, obwohl am Geraet noch der hohe Wert steht - der Wachhund haette dann aufgehoert nachzufassen, genau in dem Fall, fuer den er gebaut wurde. So laeuft er alle 5 Minuten weiter, bis das Geraet selbst Vollzug meldet. Kein Zeitlimit noetig: bleibt die Rueckmeldung ganz aus, wird der Sensor per expire_after unavailable u

Merkt sich laufend, welchen Mindest-SoC der Nutzer selbst eingestellt hat, damit die Rueckstellung nach einer EV-Session immer den AKTUELLEN Ruhewert trifft und nicht einen alten. Grundlage ist der Hinweis des Nutzers vom 10.09.2026: "der min soc wird doch von mir eingegeben. Das mache ich nur wenn keine Ladung laeuft." Genau das macht den Ruhewert eindeutig ablesbar - er ist schlicht das, was das Geraet zeigt, solange nichts laedt und keine Session offen ist. ZWEI SICHERUNGEN, damit hier kein Ueberbleibsel als Ruhewert einfriert: (1) input_boolean.ev_minsoc_erhoeht muss AUS sein - der Merker

Holt den Hausakku-Mindest-SoC zurueck, wenn nicht mehr geladen wird, unser Session-Merker aber noch besagt, dass WIR ihn angehoben haben - unabhaengig davon, WARUM das Zurueckstellen ausgeblieben ist (HA war weg, MQTT-Schreibvorgang verloren, Automation nicht ausgeloest). Idee des Nutzers am 10.09.2026: "pruefe doch einfach ob der go-e laedt und wenn nicht ob ein Auto steckt. Ist beides nein, dann SoC zurueck." Robuster als jeder session-gebundene Ausloeser, weil es am realen Zustand haengt statt an einem korrekt durchlaufenen Ablauf. KORREKTUR NOCH AM SELBEN TAG, nach der Rueckfrage des Nutze

Fordert die ESS-Istwerte beim Multi RS an, damit die mqtt-Sensoren in configuration.yaml (Victron ESS Mindest-SoC / aktives SoC-Limit / Modus) einen Wert bekommen. Der Victron sendet auf N/... nur auf Anfrage - ohne diese Automation bleiben die Sensoren nach expire_after (180s) dauerhaft unavailable. Bewusst gezielte R/-Einzelanforderungen statt eines globalen Keepalive (R/<portal>/system/0/Serial): ein Keepalive laesst das Geraet ALLE Werte im Sekundentakt fluten, die gezielte Anforderung liefert genau drei Antworten. Live geprueft 09.09.2026: ohne Anfrage kommt nichts, mit gezielter Anfrage

JUERGENS AUFTRAG (18.10.2026, woertlich): 'checken wen dess abschaltet sollte dad Auto nicht aus dem Haus akku weiterladen.' DIE LUECKE, die das schliesst: Beim Netzladen (Preisfenster, Schnell-Modus, Schnell-Netz) sperrt den Hausakku kein Schalter, sondern ein PLAN - der DESS-Zeitplan in Slot 0, geschrieben von 'DESS: Hausakku einfrieren (Wachhund)'. Faellt DESS aus oder wird abgeschaltet, ist der Akku sofort wieder frei, und 11 kW laufen aus ihm ins Auto. Die vorhandene Abschaltung 'EVCC: Laden beenden, solange der Hausakku unter der Grenze liegt' faengt das NICHT: sie hat die Bedingung smar

Hebt den Hausakku-Mindest-SoC auch dann an, wenn NICHT WIR das Schnellladen ausgeloest haben, sondern EVCC selbst - per Preisgrenze (smart_cost_active) oder weil jemand in der EVCC-App auf "Schnell" gedrueckt hat (mode = now). Luecke gefunden am 10.09.2026, als der Nutzer die Preisgrenze in EVCC einschaltete: das Anheben haengt bis dahin an EINER Stelle, dem Umlegen von input_boolean.evcc_schnell_netz. Startet EVCC von sich aus, blieb der Mindest-SoC bei 20% und die 11 kW kaemen aus dem Hausakku - genau das Verhalten vom 06.09., gegen das der ganze Umweg gebaut wurde. PV-LADEN LOEST BEWUSST NI

'Dauerhaft laden' (EVCC: alwaysCharge) erzwingt Laden mit Mindeststrom, ohne Rücksicht auf Überschuss. Ohne diese Einstellung lädt der Ladepunkt nur mit Sonne — dann soll er fein herunterregeln können, also 6 A. Mit 'Dauerhaft laden' kommt ein Teil aus dem Hausakku; dann lieber zügig laden mit 13 A, weil der Eigenverbrauch der Umwandlung bei kleiner Leistung relativ stärker durchschlägt (Jürgens Begründung). Angelegt 27.09.2026. KORREKTUR am selben Abend: hörte zuerst auf switch.evcc_go_e_battery_boost — das ist aber ein anderes Feature. 'Dauerhaft laden' ist select.evcc_go_e_always_charge mit

Meldet, wenn unsere eigene Auswertung der go-e-API nicht mehr passen koennte. Anlass ist die ausdrueckliche Sorge des Nutzers am 10.09.2026: "wir muessen nur dran bleiben wenn mal was in der Firmware geaendert wird ob dann noch alles so laeuft. Bei HA-Integrationen wird das ja hoffentlich mit Updates angepasst." Wir nutzen bewusst KEINE Integration, sondern zwei eigene REST-Sensoren - also muss diese Anpassung hier sichtbar werden statt still zu unterbleiben. Drei Ausloeser: (1) FIRMWARE GEWECHSELT: das Attribut fwv hat sich geaendert. Dann gehoert geprueft, ob die car-Codes (1 kein Auto, 2 la

AUSGESCHALTET AM 07.11.2026 — SIE HAT KEINE AUFGABE MEHR. Am Nachmittag wurde sie auf den GAST beschraenkt (vorher schrieb sie limitEnergy bei jedem Auto auf 0, weil alle drei Fahrzeugzweige ins Leere griffen). Am Abend hat Juergen entschieden: "Gast kann mit ins Haus Laden. wenn mal ein Gast kommt geht das darueber. Ich lege dann die kwh des Autos in evcc an." Damit ist auch der letzte Zweig weg. WER limitEnergy JETZT SCHREIBT: fuer den Leaf nachbar_fenster.py, fuer Juergens, Kristinas und das Gastauto haus_fenster.py (Karten Juergen/Kristina/Gast). BEIDE rechnen den Sitzungszaehler mit — die

Auf Juergens Wunsch am 03.10.2026: Nachricht in HA, wenn der Verdichter anlaeuft und wenn er abschaltet, mit Laufzeit. BEFRISTET — laeuft, bis Juergen Ende sagt; dann diese Automation loeschen oder deaktivieren.

Schreibt alle 2 Minuten die Stuben-Temperatur als Raumtemperatur an Heizkreis 1. Gegenstueck: hc1 control = CR10 und Raumeinfluss > 0. Rueckgaengig: Automation aus, remotetemp = -1, control = off, roominfluence = 0. QUELLE SEIT 02.10.2026: Shelly H&T Gen3 (192.168.6.100) statt FRITZ!DECT 440. Grund aus 673 Messpunkten ueber 11 Stunden: Der FRITZ RUNDET auf 0,5 K und stand vom 01.10. 21:40 bis zum 02.10. 08:52 UNVERAENDERT auf 24,5 - elf Stunden derselbe Wert, obwohl die Stube um 0,4 K fiel und wieder stieg. Der Shelly loest 0,1 K auf. Der Verdacht, der FRITZ messe zu warm, ist WIDERLEGT: er l

ENTWURF, deaktiviert. Schaltet den PV-Modus der Bosch über hpin4opt. An bei vollem Hausakku und echter Einspeisung, aus bei fehlendem Überschuss, fallendem Akku oder Sonnenuntergang. Bewusst träge: die Wärmepumpe soll nicht takten und der Regler nicht dauernd beschrieben werden.

ENTWURF, deaktiviert. Hängt die Warmwasserladung an einen bereits laufenden Kompressor an, statt ihn dafür neu starten zu lassen. Die Anlage kann immer nur heizen ODER Warmwasser; den Wechsel macht sie selbst. Läuft im Sommer kein Heizbetrieb, wird nach einer Viertelstunde trotzdem angefordert.

Gebaut 11.10.2026, zweiter Teil des Mechanismus vom 29.09.2026: 'wir beginnen immer einphasig und die Software plant dann die Ladung im Zeitfenster' (Juergen). Die Grundladung laeuft einphasig mit 6 A = 1,38 kW - sichtbares 'es laedt', ohne die Rechnung zu kippen. Faellt der Preis unter die Einkaufsgrenze 0,38, gibt diese Automation die Phasen frei (phases_configured = 0, EVCC darf dreiphasig), und die eigentliche Ladung laeuft mit voller Leistung in den guenstigen Stunden. Steigt der Preis wieder, geht es zurueck auf einphasig. WARUM NOETIG: Mit fest eingestellter 1 bliebe der Leaf bei 1,38 k

Gegenstueck zu 'Nachbar: Ladung vorbereiten'. Stellt die gesicherten Vorwerte wieder her, sobald ein anderes Fahrzeug am Ladepunkt gemeldet wird oder keins mehr. WARUM NOETIG: smartCostLimit, Phasen und Dauerhaft-Laden gehoeren dem EINEN Ladepunkt. Bliebe die Einkaufsgrenze 0,38 stehen, wuerde danach auch Juergens Auto danach laden - teurer als seine eigene Grenze. Der zweite Ausloeser alle 10 Minuten ist der Wachhund aus dem Konzept vom 29.09.2026: Er faengt ein verpasstes Absteck-Ereignis ab, etwa nach einem HA-Neustart. Faellt die Sicherung aus, bleibt nichts Gefaehrliches stehen - dann gre

Gebaut 11.10.2026. Ausloeser: EVCC meldet 'Leaf E 75kWh' am Ladepunkt - das geschieht, wenn die RFID-Karte 'Dietrich' (go-e Platz c3) angehalten wird; sie ist in EVCC als identifier dieses Fahrzeugs hinterlegt. EINPHASIG IST BEDINGUNG, NICHT DETAIL (Gedaechtnis 29.09.2026): Der neue Leaf hat 11 kW dreiphasig, 6 A waeren damit 4,1 kW statt 1,38 kW. Eine durchgehende Grundladung mit 4,1 kW deckt fast den ganzen Bedarf zum Mittel ALLER Stunden ab - in schlechten Novembernaechten 41 ct Einkauf gegen 35 ct Verkauf, also 6 ct Verlust je kWh. Einphasig sind es rund 2 Euro in der schlimmsten Nacht sta

Sucht freitags um 14:00 das guenstigste 90-Minuten-Fenster in der Nacht zum Samstag (00:00-08:00) und schreibt dessen Beginn nach input_datetime.wanne_ladezeit. WARUM 14:00: Die Boersenpreise fuer den Folgetag werden laut EPEX SPOT ab 12:55 MEZ veroeffentlicht (Orderbuch schliesst 12:00). Bei uns gemessen 13:15-13:30 Ortszeit, am 10.10. erst 15:00. 14:00 ist der Kompromiss - frueher waere es Prognose, spaeter unnoetig. WARUM 90 MINUTEN: Von 44 auf 60 Grad sind 16 K; die Normalladung am 11.10. schaffte 9 K in 40 min, die volle Ladung braucht also rund 80 min. chargeduration steht auf 90. WARUM

Loest die Einmalladung aus, sobald die freitags errechnete guenstigste Zeit erreicht ist (input_datetime.wanne_ladezeit). Ziel seltempsingle 60 Grad statt der 53 aus eco+ - am 03.10. war das Wasser knapp, weil eco+ dort deckelt. Juergen badet samstags 9-11 Uhr. IM SOMMER PASSIERT NICHTS: Steht der Speicher dank PV schon ueber 56 Grad, greift die Bedingung nicht (Juergen: 'im sommer bei genug pv ist das nicht noetig'). NEU 11.10.: FRIERT DEN HAUSAKKU EIN, solange der Preis stimmt. Begruendung: Was im Akku liegt, hat Nachtstrom gekostet PLUS 13-15 % Umwandlungsverlust - der Akku ist also nie bil

Setzt input_boolean.wanne_diesmal_ueberspringen samstags um 08:00 zurueck, damit ein einmaliges Ueberspringen sich verbraucht und nicht stillschweigend jede Woche gilt. Angelegt 01.11.2026 zusammen mit der Urlaubssperre in 'Wanne: Speicher laden'. 08:00 ist bewusst NACH der Ladezeit (die liegt immer vor 08:00) und vor Juergens Badezeit 9-11 Uhr. Der dauerhafte Schalter input_boolean.wannenladung_samstags wird hier NICHT angefasst - der bleibt, bis Juergen ihn selbst wieder einschaltet.

Sicherheitsnetz zum Umbau vom 01.11.2026. Die Wannen-Automation stellt die Warmwasser-Betriebsart fuer die Ladung auf 'comfort' (Ziel 62 Grad, kein Heizstab) und am Ende zurueck auf 'auto'. Faellt sie dazwischen aus - HA-Neustart, Stromausfall, Fehler im DESS-Zweig -, bliebe 'comfort' stehen und der Speicher wuerde dauerhaft auf 62 statt 53 Grad gehalten: mehr Standverlust und bei fehlendem Trinkwassermischer unnoetig heisses Wasser. Diese Automation zieht deshalb nach ZWEI STUNDEN UND 45 MINUTEN zurueck. ⚠ Nachgerechnet am 01.11.2026 beim Anhaengen der Haltezeit: ein regulaerer Lauf darf 95 M

Nachtwache ueber den Hausakku, waehrend Juergen ihn zum Zuruecksetzen des SoC leer fahrt.

Wartet, bis das Pack auf den neuen Mindest-SoC heruntergefahren ist.

Begleitet die geplante Ladung (Scheduled Charging) und den Abgleichlauf.

Begleitet das Volladen nach der Umstellung auf 672 Ah (25.10.2026).

Baut https://docs.mttec.de/akku/ aus den Teilen in ~/energie/akku_teile/.

Loest die sechs ESS-Sperren der drei Multi RS (Ladung + Einspeisung deaktiviert). Gebaut 18.10.2026: die Sperre aus akku_sichern() blieb stehen und drosselte die PV.

18.10.2026 — gibt den Hausakku frei und startet die Masken mit der neuen Fassung. Schritt 1: HA-Automation "DESS: Hausakku freigeben" anstossen. Sie schreibt Slot 0 aus input_text.dess_slot0_sicherung zurueck (VRMs eigenes Fenster) — das Nullen allein hinterli

Schaltet die alte HA-Logik zum SPERREN des Hausakkus ab. Auftrag Juergen 18.10.2026: "Das akku sperren ist eine alte funktion. alles laeuft jetzt ueber dess." Und: "Aus HA sollte ja die alte Ladelogik raus. wir nutzen nur noch die Loesung ueber evcc udnd DESS

Erzeugt die Wiki-Seite /steuerung/ mit allem, was in HA und hier gebaut wurde.

Beobachtet den Miner ueber die API, solange der Ringpuffer im Geraet aus ist.

Ueberwacht den Bitaxe Gamma Turbo (192.168.6.100) und haelt fest, was beim Fehler wirklich passiert.

Schneidet einen FRISCHEN Hochlauf des Bitaxe mit - ab der ersten Millisekunde.

Begleitet den Versuch vom 25.10.2026: Kaltstart, dann Neustart, dann warten.

Holt den Statistik-Ringpuffer des Bitaxe ab, bevor er verloren geht.

Friert den Hausakku ueber einen eigenen DESS-Zeitplan ein.

Was DESS WIRKLICH getan hat - das Gegenstueck zu dess_plan.py.

Liest den DESS-Fahrplan aus dem Ekrano und stellt ihn den Masken bereit.

Schneidet mit, wie DESS auf Netzbezug umschaltet und wieder zurueck.

Wartet auf den NEUEN DESS-Plan und stellt ihn dem alten gegenueber.

Liest die Dynamic-ESS-Zeitplaene aus dem Ekrano - NUR LESEND.

Erzeugt das PDF "Laden mit der neuen Wallbox" fuer Juergens Freund (Cupra Born).

Tagesgang der Lufttemperatur im Winter, Station Potsdam (DWD 03987).

Prueft periodisch die E.DIS-Modul-3-Netzentgelt-Werte (NT/ST/HT) gegen https://www.14a-atlas.de/netzbetreiber/e-dis-netz/ und aktualisiert bei Aenderung automatisch die zugehoerigen HA-Helper, inkl. Push-Benachrichtigung. Laeuft per Cron 2x im Monat (1. und 15

Referenzdokument: Autoladen und Hausakku-Schutz in EVCC.

Vergleicht Shelly H&T Gen3 und die beiden FRITZ-Fuehler in der Stube.

Minimaler WebSocket-Zugang zu Home Assistant - fuer alles, was die REST-API nicht kann.

Fenstersuche fuer das HAUSAUTO (ID.3 pro / pro S) — gebaut 16.10.2026.

Hausakku-Puffer nach der SONNENVORSCHAU setzen, nicht nach dem Kalender.

Erklaerseite der Hausenergieanlage — fuer Mitleser, die den Zugang neu bekommen.

Schneidet das LADEENDE im Fuenfsekundentakt mit — was passiert, wenn die Wallbox aufhoert.

Wem gehoert der Ladepunkt jetzt? — die EINE Stelle, die das entscheidet.

Monatliche Uebersicht der Ladevorgaenge je RFID-Karte.

Protokolliert das Ladeende: schaltet das Auto bei seinem eigenen Limit ab, und traegt car=4 dabei zuverlaessig? Rein lesend.

Baut die Seite fuer den Nachbarn: /var/www/docs/nachbar/ + PDF.

Fenstersuche fuer die Nachbarladung — setzt EVCCs Preisgrenze dynamisch.

Lademaske fuer den Nachbarn (Dietrich, Nissan Leaf 75 kWh).

Abrechnungsprotokoll fuer die Nachbarladung — Zeit, kWh und SEIN Preis.

Referenzdokument: Netzbetreiber-Steuerung (§9 EEG / §14a EnWG) fuer diese Anlage.

Haelt fest, WANN die Strompreise fuer den Folgetag eintreffen.

Vergleicht jeden Abend die Solarprognose mit dem, was wirklich geerntet wurde.

PV-Ertragsprognose der neuen Anlage aus dem Solarlog-Archiv der alten Anlage.

Holt die Solarprognose und legt sie als Sensoren in Home Assistant ab.

Schreibt ueber Nacht mit, ob die Waermeanforderung zurueckkommt.

Mitschrieb fuer die Ringmessung im OG-Einrohrring (02.10.2026).

Erzeugt die Wiki-Seite /schreiber/ — WER SCHREIBT WOHIN.

Startseite des apps-servers - ein Menue, das auf alles Weitere verzweigt.

Eine Zahl je Tag: wie weit weicht die Stube von dem ab, was Wetter und Sonne erwarten lassen?

Stellt die Ladeseite des Nachbarn von laden.lavolt.de auf laden.askai.de um. Teil 1 von 2: der apps-server. Teil 2 laeuft auf der .55. Aufruf: sudo bash ~/energie/umstellung_askai_apps.sh

charge.askai.de auf der .55 (CRM-Server) einsetzen — NUR DORT AUSFUEHREN 15.10.2026. Braucht sudo: Juergen gibt es selbst ein. Hinschieben vom apps-server: scp ~/energie/umstellung_charge_55.sh ~/energie/apache_charge_fuer_die_55.conf crm:/tmp/

charge.askai.de einsetzen — NUR AUF DEM APPS-SERVER (192.168.6.86) 15.10.2026. Braucht sudo: Juergen gibt es selbst ein. Was es tut: 1. nginx-Block fuer Port 8092 einsetzen und pruefen 2. Authelia: Regel fuer charge.askai.de (Gruppe `haus`) und juergen in die

Sichert alle veraenderbaren Einstellungen der Waermepumpe.

Zeichnet die Heizkurve der Bosch CS6800i AW als SVG, mit Mouseover.

Sichert alle Einstellungen der Bosch-Heizkurve, bevor daran gedreht wird.

Beobachtet taeglich, wie stark der Ist-Vorlauf den Sollwert ueberschiesst.

Erklärseite zu den Wärmepumpen-Sensoren (Bosch CS6800i AW 12 MB).

Anleitung: Was an der Bosch CS6800i AW einzustellen ist (PV-Überschuss).

Mitschnitt der Waermepumpe, eine Zeile je Minute.

Laeuft AUF der 55, hierher gereicht ueber "ssh crm bash -s". Gibt den Dump auf der Standardausgabe aus; auf der 55 entsteht ausser der Rueckfalldatei nichts. WARUM EINE RUECKFALLDATEI: Die Zugangsdaten stehen in Espos config-internal.php. Espo setzt die Recht

Dritte Stufe der Sicherung: von der NAS AUSSER HAUS zu Filen. WOZU: QNAP und TR-004 stehen im selben Raum. Brand oder Diebstahl haetten bis jetzt beide Kopien genommen. Juergen am 05.10.2026: "um bei einem brand zwar mit verlusten aber weiter machen zu koenne

Liest die Blockdatei ~/.config/publicompserver/ftp. Jeder Block beginnt mit einer Kommentarzeile (# Name) und enthaelt HOST/USER/PASS/PFAD. Rueckgabe: Liste von (name, dict). Werte werden NIE ausgegeben.

Laedt Thunderbirds lokale Ordner (mbox) per IMAP in ein Postfach.

Taegliche Sicherung des apps-servers auf die NAS-Freigabe /apps-server. Bereich dieser Sitzung: Hausenergie und Server-Infrastruktur. Seit 28.09.2026 auf Juergens ausdrueckliche Anweisung zusaetzlich die Bereiche der anderen Sitzungen: ~/buchhaltung, ~/mttec,

Taegliche Sicherung des CRM-Servers (192.168.6.55, VM 105) auf die NAS. Grundsatz: ZIEHEN, nicht schicken. Der apps-server holt sich alles ueber SSH; auf der 55 wird nichts geschrieben, kein Zwischenstand, kein Platzverbrauch. Der Datenbank-Dump laeuft ueber

Passt nach dem Umzug die Pfade, Adressen und Datenbankzugaenge an.

Packt einen Ordner aus ~/webserver als Archiv DIREKT auf das NAS und prueft es nach. Warum ueberhaupt: Juergen hat am 22.10.2026 die Webseiten von mttec, mks, Facil Blue und ivent samt Datenbanken auf den apps-server geholt, als Sicherheitskopie, solange der