Neueste Beiträge

#1

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von oelidoc - 07 August 2026, 11:31:37

STP-SE + BYD HVS – WR ignoriert Set_LadeP_max=0 in Ladeschlussphase trotz aktivem loadAbort

Hallo zusammen,

ich betreibe SolarForecast v2.9.4 mit einem SMA STP 8.0-SE + BYD HVS 7.7 und steuere die Batterieladung über die CmpBMS-Registergruppe (40793-40801, OpMod 40236=1438). Modbus-Steuerung ist am WR aktiv (Modbus P-Vorgaben auf Eingang 2: Ein).

Ziel: Verschleißreduzierung durch smartPower + loadAbort=90:500:80, um die Batterie im Normalbetrieb nicht bis 100 % zu laden.

Beobachtung: Trotz aktivem Battery_ChargeAbort_01=1 und kontinuierlich geschriebenem Set_LadeP_max=0 (alle 70 s) lädt der WR die Batterie in ~15-20 Minuten von ~90 % auf 100 % durch.

Konfiguration:

ctrlBatSocManagement01:
  careCycle=20
  loadAbort=90:500:80
  loadStrategy=smartPower
  loadTarget=100
  lowSoc=5
  maxSoC=100
  safetyMargin=0:0
  upSoC=50

setupBatteryDev01:
  pinmax=7680
  pinreduced=400
  poutmax=7680

Log der Steuerung (eigenes Skript, ruft batLoadMgmnt aus ctrlUserExitFn auf; dt = Sekunden seit letztem Aufruf):

10:40:10  chaMax=488W  dt=70s
10:41:20  chaMax=1252W dt=69s
10:42:30  chaMax=1027W dt=54s
10:43:40  chaMax=0W    dt=69s  [ABORT]  <- ChargeAbort greift bei SoC=93%
10:47:10  chaMax=0W    dt=70s  [ABORT]
10:48:20  chaMax=0W    dt=69s  [ABORT]
...
11:02:20  chaMax=0W    dt=69s  [ABORT]  <- Akku bei 100%

Das Skript schreibt kontinuierlich und im erwarteten 70-s-Takt (kein Aussetzer). Die Registergruppe wird jedes Mal komplett geschrieben (BMS_Mode=1438 zuerst, dann LadeP_min=0, LadeP_max=0, EntladeP_min=0, EntladeP_max=7680, GridWSpt=0).

Was ich weiß:

Register sind WriteOnly (Rücklese-Reading zeigt immer 4294967295 – ignoriert)
Das Schreiben funktioniert grundsätzlich: In früheren Ladephasen hat chaMax=0 den WR nachweislich gestoppt (real geprüft am Current_PowerBatIn_01).
Der SunnyHomeManager ist NICHT im prognosebasierten Ladebetrieb (SunnyPortal deaktiviert)
Netzsystemdienstleistungen umsetzen: Nein (im WR)
SoH der Batterie: 95 %
daysUntilBatteryCare_01=12 (also kein SF-seitiger Wartungszyklus fällig)

Frage:
Kennt jemand dieses Verhalten? Ignoriert der STP-SE / BYD in der Ladeschlussphase (letzte ~10 % SoC) externe BatChaMaxW-Vorgaben, evtl. wegen interner Zellbalancierung? Gibt es eine bekannte Kombination von Registern (z.B. OpMod-Wert oder zusätzliches Register), um das zuverlässiger zu unterbinden?

Vielen Dank für jeden Hinweis!

Gruß

oelidoc

#2

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 07 August 2026, 11:18:03

wenn der Lademodus (PV-Überschuss) implementiert würde, ergäbe sich die Frage wann das BEV geladen wird eventuell aus einem Schwellwert des SoC und der PV-Prognose wann Überschusskapazität in Relation zum prognostizierten Hausverbrauch zur Verfügung stünde.

Absolut richtig. Schwellenwert brauchen wir nicht einmal, das macht die KI für uns.
Aber die grundlegende Schwierigkeit ist, dass der SOC der BEV-Batterie erst dann verfügbar ist wenn der BEV angesteckt ist. Für eine Prognose im Vorfeld - also noch kein BEV angeschlossen, aber wir wollen trotzdem vorhersagen wann er geladen wird - fehlt diese Info einfach.

Für normale BEV Ladung müsste eventuell für den Nutzer ein Schlüssel eingeführt werden, in dem er sein Ladeverhalten als Profil grundsätzlich skizzieren kann.

Ja, das ist eine gute Idee. Dort könnte ein "Einsatzplan" hinterlegt werde, also wann plane ich als Nutzer typischerweise die Aufladung meines EV.
Diese Daten müssen natürlich einigermaßen praktikabel hinterlegbar sein. Sie werden dann auch in der Langzeitspeicherung im stündlichen Datensatz gespeichert, damit der Zusammenhang im Training vorhanden ist.

Das wäre ein "Planbit".
Konzeptionell:  Matcht die aktuelle Stunde mit dem hinterlegten "Einsatzplan"? -> Ja?  "Planbit=1" -> Nein? "Planbit=0"

Diese Info wird für eine KI sehr wertvoll sein, denn sie steht sowohl im Trainining, als auch für eine Prognose zusammen mit PV/Überschuß-Prognose (Prio/Auto-Bit) zur Verfügung.
Einzig der SOC bleibt ein Problem.

LG,
Heiko

#3

Solaranlagen / Aw: PowerFlow [animiertes SVG,...

Letzter Beitrag von schwatter - 07 August 2026, 11:17:04

Moin,

noch ein kleines Update. Momentan werden beim Seitenaufruf initial die Werte mit dem devSateIcon an das SVG übertragen. Danach lauscht das SVG
mit addInformIdHandler nach neuen Werten. Öffnet sich das Enddevice (bei mir das Tablet) zu einem ungünstigen Zeit, dann wurde der letzte Event
verpasst und der jeweilige Ring bekommt erst mit dem nächsten Event ein Update.
Dem entgegen steht jetzt addEventListener("visibilitychange", (). Damit werden jetzt Readingwerte auch aktualisiert wenn:

• der Benutzer auf einen anderen Tab wechselt.
• das Browserfenster minimiert wird.
• der Benutzer wieder zum Tab zurück kommt.
• das Tablet den Bildschirmschoner beendet

Gruß schwatter

#4

Sonstige Systeme / Aw: Support-Thread Modul 36_Sh...

Letzter Beitrag von gameshacker - 07 August 2026, 10:54:40

Hallo zusammen,

ich habe Probleme beim einbinden von einer Shelly Bulb Gen3.
Automatisch wird die Glühbirne als Generic gesetzt.
Ich habe nun das model auf shellybulbg3 gesetzt.

Die ID lautet shellycolorblbg3-48f6eeaab964

Als Generic gibts diese ausgabe

Code Auswählen Erweitern

Shelly Stehlampe mac: xx:xx:xx:xx:xx:xx
Shelly Stehlampe model_ID: S3BL-C010007AEU
Shelly Stehlampe model_family: Gen3
Shelly Stehlampe model_function: bulb
Shelly Stehlampe type key not found, set to "generic"
Shelly Stehlampe login: open
Shelly Stehlampe error: Stehlampe: error in command: id or component not found
Shelly Stehlampe Error
Shelly Stehlampe error: error in command: id or component not found

klingt erstmal das dieses Gerät nicht erkannt wird.
Wenn ich nun das Model setze gibt es diese ausgabe:

Code Auswählen Erweitern

setstate Stehlampe model already defined as 'shellybulbg3', might be generic
setstate Stehlampe 2026-08-07 10:25:53 ap disabled open
setstate Stehlampe 2026-08-07 10:25:53 ap_clients disabled
setstate Stehlampe 2026-08-07 10:25:53 ap_name ShellyColorBlbG3-48F6EEAAB964
setstate Stehlampe 2026-08-07 10:25:53 auto_off disabled
setstate Stehlampe 2026-08-07 10:25:53 auto_on disabled
setstate Stehlampe 2026-08-07 10:25:53 ble error
setstate Stehlampe 2026-08-07 10:25:53 ble_rpc -
setstate Stehlampe 2026-08-07 10:25:53 cloud disabled
setstate Stehlampe 2026-08-07 10:25:53 eco_mode -
setstate Stehlampe 2026-08-07 10:46:32 error 404: No handler for Light.Set
setstate Stehlampe 2026-08-07 10:25:53 firmware_ID 20260710-101058/2.0.0-g87fbfa4
setstate Stehlampe 2026-08-07 10:25:53 firmware_current v2.0.0
setstate Stehlampe 2026-08-07 10:26:55 firmware_updIcon OK
setstate Stehlampe 2026-08-07 10:26:55 firmware_updText -/-
setstate Stehlampe 2026-08-07 10:48:48 login open
setstate Stehlampe 2026-08-07 10:48:48 mac xx:xx:xx:xx:xx:xx
setstate Stehlampe 2026-08-07 10:48:48 model_ID S3BL-C010007AEU
setstate Stehlampe 2026-08-07 10:48:48 model_family Gen3
setstate Stehlampe 2026-08-07 10:48:48 model_function bulb
setstate Stehlampe 2026-08-07 10:25:53 network <html>connected to <a href="http://x.x.x.x">x.x.x.x</a> (Wifi)</html>
setstate Stehlampe 2026-08-07 10:24:53 network_DNS -
setstate Stehlampe 2026-08-07 10:25:53 network_connection online
setstate Stehlampe 2026-08-07 10:25:53 network_ip-address 10.0.30.82
setstate Stehlampe 2026-08-07 10:49:15 network_rssi -65
setstate Stehlampe 2026-08-07 10:25:53 network_ssid IOT_mpk
setstate Stehlampe 2026-08-07 10:25:53 network_wifi_roaming -80
setstate Stehlampe 2026-08-07 10:25:53 protection none
setstate Stehlampe 2026-08-07 10:25:53 restart_required false
setstate Stehlampe 2026-08-07 10:34:59 rgb 000000
setstate Stehlampe 2026-08-07 10:34:59 rgbw 00000000
setstate Stehlampe 2026-08-07 10:30:03 scripts 0
setstate Stehlampe 2026-08-07 10:48:48 state model already defined as 'shellybulbg3', might be generic
setstate Stehlampe 2026-08-07 10:49:15 uptime 131450
setstate Stehlampe 2026-08-07 10:25:53 webhook_cnt 0 / 0 / 0
setstate Stehlampe 2026-08-07 10:25:53 webhook_ver 0
setstate Stehlampe 2026-08-07 10:34:59 white 0
Also er füllt einiges aus, allerdings wen ich set Stehlampe ON eintrage, gibt es den Error:
error
   404: No handler for Light.Set

Gibt es eine Möglichkeit die Glühbirne über Fhem zu steuern.
MQTT funktioniert auch noch nicht.

Die Gerätebezeichnung lautet: Multicolor Bulb E27 Gen3


Viele Grüße Gameshacker

[wann]

#5

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Wolle02 - 07 August 2026, 10:50:37

Was generell bei BEV ein Problem bleibt, ist die Beantwortung der Frage wann ein BEV geladen werden wird.
Es liegen aktuell zwar Abhängigkeiten von Wochentag und Stunde etc. vor, zwingend sind die aber nicht, eher zufällig. Ein hartes Indiz ist die Batterieladung (SOC). Sie ist aber nicht als Dauermeßwert verfügbar, sondern erst wenn angesteckt.
Ideal wären Zeitpläne von Anwendern, also wann brauche ich ein vollgeladenes BEV in Verbindung mit dem aktuellen SOC-Stand.
Diese Info gibt es aber in dieser Form aktuell nicht und mir fällt auch keine Variante ein soetwas zu realisieren.

Moin Heiko,

wenn der Lademodus (PV-Überschuss) implementiert würde, ergäbe sich die Frage wann das BEV geladen wird eventuell aus einem Schwellwert des SoC und der PV-Prognose wann Überschusskapazität in Relation zum prognostizierten Hausverbrauch zur Verfügung stünde.
Für normale BEV Ladung müsste eventuell für den Nutzer ein Schlüssel eingeführt werden, in dem er sein Ladeverhalten als Profil grundsätzlich skizzieren kann.

Nur so als Idee.

[Ergänzender Punkt:]

#6

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 07 August 2026, 09:57:01

@TheTrumpeter,

einen grundlegenden Sachverhalt ergibt sich wahrscheinlich aus deinen Rohdaten.
Durch das notwendige Bereinigen von fehlerhaften Aufzeichnungen sind sehr wahrscheinlich auch Zusammenhänge von WP-Peaks verloren gegangen.

Dei Trainingsbewertung (im Überblick) verfehlt ganz knapp die Grenzwerte. Der Bitfehler wird strukturell durch bessere Inputdaten (wirst du zukünftig bekommen) in Verbindung mit darauf referenzierende Features verbessert. Unterstützen kann man einen verbesserten BitFehler durch Vergrößern von aiConBitFailLimit, was ein bisschen wie "zupflastern" von offenen Wunden ist.
BitFail-Limit: 0.34 ist der FANN-interne Toleranzwert, der bestimmt, ab welcher Abweichung ein Output als "Fail" gezählt wird. Eine Anhebung reduziert die gezählten BitFails, ohne dass sich an der tatsächlichen Modellgüte (Slope, R², RMSE) etwas ändert – die Retrain-Prüfung bitfail=65 > 5 würde dadurch leichter erfüllt, aber rein kosmetisch.


Was Gemini als "Konkrete, umsetzbare nächste Schritte" nennt, ist teilweise Unfug.

 - Historische Datenpunkte einschränken (Prio 1!) -> so wie es dasteht nicht, aber man kann mit aiConTrainLimit=X zu alte und dadurch vllt. fehlerhafte Datensätze ausschließen.
   Es ist hier aber mit Vorsicht einzusetzen, da ein TrainLimit bei ohnehin grenzwertigem DPR (6.080) das Verhältnis Datensätze/Parameter weiter verschlechtern kann, wenn man
   gleichzeitig die Netzgröße nicht anpasst (aber du weißt wie es geht).
 - Redundante Wetterprognose-Inputs abschalten -> die gibt es nicht, Temperatur und PV sind wichtige Ankerpunkte für WP-Betrieb, PV generell für Verbraucherführung
 - Architektur verschmalern -> das hast du ja schon durchgeführt und optimiert, kann man als Aufsetzpunkt automatisch bestimmen lassen


Ergänzender Punkt: RMSE_Rating bleibt "very bad" trotz R²-Verbesserung – das ist strukturell, kein neuer Fehler

R² ist von 0.16–0.30 (RPROP) auf 0.54 (jetzt) gestiegen – eine deutliche Verbesserung.
Trotzdem bleibt RMSE relative: 158% mit Bewertung "very bad". Das ist kein Widerspruch, sondern folgt aus der bekannten strukturellen Beziehung Bias ≈ mean_consumption × (1 − Slope):
Bei einem stochastischen Haushalt mit vielen kleinen, unregelmäßigen Verbrauchsspitzen (WP-Zyklen, Warmwasser) bleibt die relative Fehlermetrik unabhängig von der Modellqualität strukturell hoch, weil der Nenner (mittlerer Verbrauch) klein ist. Also nicht enttäuscht sein wenn das Rating "very bad" ist/bleibt.
 

Einen weiteren Hebel hast du ebenfalls, nämlich die Features zu verringern.
Das geht über das angewendete Profil bzw. die Flags in aiConProfile. Hier kannst du ansetzen und "active" weglassen und ggf. auch "pv". Dadurch verringert sich die Featurezahl im Input.
Wp muß drin bleiben sonst gehen zuviele Kausalitäten verloren. Wenn du das machst, natürlich wieder nur schrittweise (würde mit active starten) und im Ergebnis den Effekt auf Inputs-Zahl und DPR messen.

LG,
Heiko

#7

Sonstige Systeme / Aw: [Neues Modul] 74_Automower...

Letzter Beitrag von Ellert - 07 August 2026, 09:53:52

Probier die Lösung von spi3845 in #315.

[wann]

#8

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 07 August 2026, 09:00:36

Moin,

@Peter,

mit meinen Überlegungen bin ich ein Stück weiter. Bei den CON-Prognosen haben wir allgemein zwei Ebenen zu beantworten.

 * wie hoch wird der Verbrauch sein
 * wann wird der Verbrauch stattfinden

Bei BEV gibt es bereits etliche gespeicherte Daten die die Höhe des Verbrauchs gut für eine KI beschreiben/ableiten lassen:

Code Auswählen Erweitern

bevcsm           - Verbrauchernummern der registrierten E-Autos (BEV)
bevcsmBatCapXX   - nominale Batteriekapazität (Wh) des BEV-Verbrauchers XX
bevcsmPwrXX      - Ladeleistung (W) des BEV-Verbrauchers XX am Ende der Stunde
bevcsmSoCXX      - aktueller SOC (%) des BEV-Verbrauchers XX
bevcsmTargSoCXX  - eingestellter Ziel-SOC (%) des BEV-Verbrauchers XX
Dazu würden jetzt noch kommen (wäre zu implementieren):

 * der Modus als Punktesystem
       Prio - PV-Überschuss ins Auto laden, Priorität über Hausspeicher (Lädt den gesamten PV-Überschuss ins Auto)
       Auto -> PV-Überschuss ins Auto laden, Hausspeicher wird ebenfalls geladen (Lädt das ins Auto, was sonst ins Netz ginge)
 * die aktuell verwendete Anzahl Phasen, bzw. die Anzahl der verwendeten Phasen am Ende der Stunde für gespeicherte Daten

Für den Modus ist nur Prio und Auto sinnvoll, weil es die Verteilung der prognostizierten PV-Erzeugung (die als Daten vorliegt) bzw. des prognostizierten Überschusses für die KI beschreibt.

Was generell bei BEV ein Problem bleibt, ist die Beantwortung der Frage wann ein BEV geladen werden wird.
Es liegen aktuell zwar Abhängigkeiten von Wochentag und Stunde etc. vor, zwingend sind die aber nicht, eher zufällig. Ein hartes Indiz ist die Batterieladung (SOC). Sie ist aber nicht als Dauermeßwert verfügbar, sondern erst wenn angesteckt.
Ideal wären Zeitpläne von Anwendern, also wann brauche ich ein vollgeladenes BEV in Verbindung mit dem aktuellen SOC-Stand.
Diese Info gibt es aber in dieser Form aktuell nicht und mir fällt auch keine Variante ein soetwas zu realisieren.

Bleibt als nächsten Schritt eigentlich nur übrig die Implementierung folgender Datenhaltung vorzunehmen:

  * Modus Prio und Auto als Punktesystem (Rest ergibt sich als Differenz aus beiden)
  * die aktuell verwendete Anzahl Phasen, bzw. die Anzahl der verwendeten Phasen am Ende der Stunde für gespeicherte Daten

Später kann ich diese Features zu BEV hinzufügen.

LG,
Heiko

[Revision 31545: controls_fhem.txt: fhemupdate checkin]

#9

FHEM Code changes / Revision 31545: controls_fhem....

Letzter Beitrag von System - 07 August 2026, 08:00:28

Revision 31545: controls_fhem.txt: fhemupdate checkin

controls_fhem.txt: fhemupdate checkin

Source: Revision 31545: controls_fhem.txt: fhemupdate checkin

#10

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von TheTrumpeter - 07 August 2026, 08:00:06

So, nach vielen Iterationsstufen, die teilweise auch in die Irre geführt haben (z.B. Durchprobieren der unterschiedlichen aiConActFunc wie von SF vorgeschlagen oder diverse andere HiddenLayer-Konfigurationen wie von Gemini vorgeschlagen) bin ich nun hier angelangt, siehe Screenshot.



Gemini bewertet das wie folgt:

### 📊 FANN-Analyse & Optimierungs-Bericht (Modul 76_SolarForecast.pm)

**Status des letzten Trainingslaufs (07.08.2026):** `Trainingsbewertung: Retrain`
*  **Laufzeit:** 3.341 Sekunden (ca. 56 Min.) | **Algorithmus:** INCREMENTAL
*  **Modell-Güte:** R² = 0.54 (Grundsubstanz für Wärmepumpen-Profil steht)
*  **Kernproblem:** Die finale Modulfreigabe blockiert wegen `Data-Parameter-Ratio: CAUTION` und minimalem Overfitting.

---

#### 1. 🔍 Wo liegen aktuell die größten Schwachstellen?

*  **Der ungelöste Parameterüberhang (`Ratio = 6.080 < 7`):**
    Das Netz ist aufgrund der starren **123 Inputs** künstlich aufgebläht. Es besitzt zu viele synaptische Gewichte für die vorhandenen ~13.000 Datensätze. Das System lernt in den tiefen Epochen (Optimum bei Epoche 3.952) feines Datenrauschen statt allgemeingültiger Logik.
*  **Minimales, blockierendes Overfitting (`MSE diff = 0.005892 > 0.005`):**
    Der Validierungsfehler weicht um Haaresbreite zu stark vom Trainingsfehler ab. Es fehlen lediglich `0.000892` Punkte zur kritischen Freigabeschwelle des Moduls.
*  **Gedeckelte Modell-Steigung (`ModelSlope = 0.54`):**
    Die Steigung verfehlt das harte Wärmepumpen-Mindestlimit (`slope_min=0.60`). Dem FANN fehlt die mathematische Trennschärfe, um die Peak-Leistungen der Wärmepumpe sauber nachzubilden, weil diese im Wust der 123 Features schlicht untergehen.

---

#### 2. 🛠� Die wirksamsten Maßnahmen mit dem größten Hebel

*  **Maßnahme 1: Radikale Feature-Reduktion (Inputs reduzieren) ⬇️**
    *  *Hebel:* Das ist die einzig verbleibende Stellschraube auf Datenebene. Jedes weggelassene, redundante Eingangsfeature streicht dutzende Gewichte aus dem Netz. Die Ratio springt über 7 und das Overfitting bricht zusammen.
*  **Maßnahme 2: Proportionale Verkleinerung der Netzwerkbreite (Hidden Layers reduzieren) ⬇️**
    *  *Hebel:* Wechsel von 16-8 auf **12-6**. Ein schlankeres Netz erzwingt mathematisch eine stärkere Generalisierung und treibt die `ModelSlope` in Richtung 0.60.

---

#### 3. ⚠️ Hinweise auf strukturelle Probleme

*  **Keine Algorithmus- oder Hyperparameter-Fehler (Gelöst):**
    Die `Learning Rate` (0.0001) und der `INCREMENTAL`-Modus arbeiten perfekt. Das beweist die verschwindend geringe Standardabweichung der Validierung (`0.000004`).
*  **Strukturelle Informations-Sättigung:**
    Das FANN ist auf Hyperparameter-Ebene komplett ausoptimiert. Mehr Qualität lässt sich nicht mehr durch Drehen an den Rädchen erzwingen, sondern nur noch durch das Ausmisten irrelevanter Prädiktoren (Rauschfilterung).

---

#### 4. 🚀 Konkrete, umsetzbare nächste Schritte

Da das Modell mathematisch am Limit dessen läuft, was mit 123 Inputs möglich ist, muss jetzt die FHEM-Konfiguration der Datenquellen bereinigt werden:

1.  **Historische Datenpunkte einschränken (Prio 1!):**
    Prüfe die Attribute deines FHEM-Moduls. Falls Werte wie `aiConHistoryHours` auf 24 oder höher stehen, konsequent auf **6 oder 12 Stunden** reduzieren. Verbrauchswerte von vor über einem Tag enthalten für die Wärmepumpen-Logik fast nur noch Rauschen.
2.  **Redundante Wetterprognose-Inputs abschalten:**
    Überprüfe, ob mehrere Wetter- oder Strahlungsprognosen (DWD, Proplanta etc.) gleichzeitig aktiv in das Netz gespeist werden. Unnötige Kanäle deaktivieren. **Ziel: Die Anzeige `Inputs` muss beim nächsten Start zweistellig werden (unter 90).**
3.  **Architektur verschmalern:**
    Die Hidden Layers im gleichen Zuge von `16-8` auf **`12-6`** (oder alternativ auf eine einzelne Schicht mit **`14`** Neuronen) anpassen.
4.  **Hyperparameter einfrieren & Retrain starten:**
    `Learning Rate = 0.0001`, `Momentum = 0.5`, `BitFail-Limit = 0.34` und `INCREMENTAL` exakt so belassen. Nach der Feature-Ausdünnung das Training neu triggern.




Gemini schlägt immer wieder vor die "Inputs" zu reduzieren und irgendwelche etwaige Redundanzen bei der Datenerfassung zu entfernen. Diesbezüglich kann ich aber nix machen, bzw. wäre es auch nicht sinnvoll, oder???

Ich werde nun einen weiteren Versuch mit leicht reduzierten HiddenLayers starten, mal sehen was dann passiert. Schön langsam bin ich aber am Ende mit meinen Ideen (und auch die von Gemini haben bisher immer nur in die falsche Richtung gewirkt).