76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Hallo Chris,

da (fast?) alle Geräte mit asynchron=1 betrieben werden, reagiert SF auf jedes Event der relevanten Readings dieser Geräte.
Du hast event-on-change-reading=.* fast überall verwendet wie du schreibst, was die Eventlast schon gut reduzieren dürfte.

Es wäre zu überlegen, ob wirklich alle Geräte mit asynchron=1 sinnvoll betrieben werden oder ob es nicht ausreicht z.B. nur den Meter als "führendes" Gerät mit asynchron=1 zu definieren. Das kannst du aber nur selbst einschätzen wie dein System arbeitet.

Ansonsten würde ich SF in einem separaten Room im FHEMWEB unterbringen, schon wegen der doch recht umfangreichen Grafik. Bei mir habe ich 5 ziemlich voll ausgebaute SF-Devices in einem Raum untergebracht. Das funktioniert auf meinem Server auch problemlos. Ich mache das aber nur um solche Worst Case Szenarien zu prüfen wie die SF-Systeme in solchen Umgebungen spielen oder ob es zu Problemen kommt.

LG,
Heiko

[Max_Meyer]

Gibt es noch etwas worauf ich achten muss?

Hallo Chris,
Vielleicht ist die Ursache nicht im SF/FHEM zu finden, sondern im Heimnetz - jedenfalls war das bei mir die Ursache für ähnliche Phänomene.
Meine Anlage ist auch (mit der Zeit) gewachsen und hat viele Sensoren (mehrere 100) verstreut über unterschiedliche Hardware und Schnittstellen - z.T. räumlich weit auseinander - die ich zuerst über FHEM2FHEM, später hauptsächlich mit MQTT verbunden habe. Und manche dieser Gerätschaften sind auch selber ziemlich 'gesprächig', viele bringen Ihren eigenen 'Bus' mit. Dadurch ist der Broadcast im Heimnetz gewachsen was schlussendlich die oben erwähnten Probleme verursachte - Abhilfe hab ich zum einen durch Router-Einstellungen (QoS/Storm-Control-Rate) und zum anderen eine Überprüfung der Netzwerkkabel auf CAT6 gefunden, damit das alles im 1GB läuft. Seither bin ich symptomfrei in diese Richtung.
Ist nur so eine Idee - die oben angesprochenen Einstellungen hatte ich auch ohne (durchschlagenden) Erfolg probiert
Gruß Gerd

[tomcat.x]

Hallo Heiko,

ich habe jetzt wenigstens mal beim Kühlschrank den Typ auf noSchdule geändert. Da macht die Planung definit keinen Sinn

Alle anderen kann man mit type=noSchedule definieren zur Anzeige

Allerdings kann ich nicht wirklich einen Unterschied feststellen. In der Verbraucherliste über der Grafik kommt beim Mouseover über die Uhr immer noch "Plannungsstatus: planned" und im Log auch "SolarForecast - Consumer "Kühlschrank" planned: ...". Er wurde noch nie geschaltet, weil keine Kommandos dafür definiert sind. Hätte ich sonst noch was ändern müssen?

Viele Grüße
Thomas

[DS_Starter]

Hallo Thomas,

Allerdings kann ich nicht wirklich einen Unterschied feststellen.

Falls du die Parameter gerade geändert hast... warten bis der neue Einplanungszyklus beginnt, i.A. morgen (in der Nacht).
Oder mit "set ... consumerNewPlanning <Verbrauchernummer>".

[tomcat.x]

Ne, habe extra gewartet. War gestern schon und in der Zwischenzeit sogar ein Restart wegen SolarForcast Update.

Jetzt nach dem "set ... consumerNewPlanning <Verbrauchernummer>" steht im Log: "WD_SolarForecast - Consumer planning of "Kühlschrank" deleted"

[DS_Starter]

Gerade probiert ... habe einen Consumer:

Code Auswählen Erweitern

consumer16 SolCastDummy6 icon=sani_buffer_electric_heater_side type=noSchedule power=1000

definiert.

In seinem Reading steht:

Code Auswählen Erweitern

consumer16  name='SolarForecast Consumer Dummy 6' state='off' mode='can' planningstate='noSchedule'

Und das Mouse-Over zeigt gemäß SCreenshot.
Zeig mal dein Attribut.

[tomcat.x]

Wie gesagt, nach dem "set ... consumerNewPlanning <Verbrauchernummer>" jetzt alles ok.  "Planungstatus: noSchedule" und bei "Ein:" und "Aus:" keine Zeiten mehr. Seltsam. Danke!

[DS_Starter]

Passt. Eine reguläre Neuplanung findet nach dem Status "finished" statt bzw. nach einem internen Plan. Das kann sich auch bis in den neuen Tag hinein ziehen, je nach den bisherigen Ramendaten.

Übrigens ... ein Restart würde nichts nutzen. SF merkt sich bei einem regulären Shutdown/Restart alle aktuellen Einplanungsdaten und die Status jedes definierten Consumers. Wäre ja sonst fatal. Im Hintergrund findet ein entsprechendes Management statt.

[Burny4600]

@Gerd
An den Netzwerkkomponenten kann es bei mir nicht liegen. Das gesamte Netzwerk ist Cat7 Konform installiert.
Früher waren einige Pis per Powerlan mit dem Netzwerk verbunden, bis ich diese Bereiche ebenfalls mit Cat7 nachinstalliert hatte. Powerlan taugte bei mir jedenfalls auch nicht für die FHEM Anwendungen.
Ich gebe dir Recht, das es für FHEM ratsam ist auf die Netzwerkkomponenten acht zu geben. Da kann man leicht das falsche als Fehlerursache verdächtigen.
Bei mir ist das System in den letzten 10 Jahren auch erheblich gewachsen.
FHEM ist auf 10 Pis verteilt, die aber für sich grundsätzlich autark arbeiten. Gewisse Bereiche will ich eigenständig haben, wie die Heizung, Solarthermie, PV. Ich hole mir von diesen Bereichen nur notwendige Datenpunkte für eine Zentrale Übersicht.
Wieviele Sensoren, Aktoren und Schnittstellen vorhanden müsste ich mal wirklich zählen. Es sind im gesamten System sicherlich über 200 Stk.
Auch die Systeme wachsen immer noch, wie jetzt der PV-Bereich mit SolarForecast, und ich lerne immer noch dazu.


@Heiko
Ich habe Anpassungen betreffend asynchron=1 vorgenommen.
asynchron=1 ist nur mehr setupMeterDev definiert.

Alles andere passte und entsprach ohnehin deinen Vorschlägen. Mit den Entfernungen von asynchron=1 ist die Systemlast gleich um einiges verringert worden.
Trotzdem taucht jetzt wieder Connection lost, trying a reconnect every 5 seconds. auf.
Kann das mit der Verbrauchsplanung zusammenhängen?

EDIT:
Ich habe den Eventmonitor einige Zeit betrachtet, und mir ist da wieder der Consumer 07 aufgefallen.

eventMonitor

Code Auswählen Erweitern

2025-07-08 17:21:17.238 SolarForecast AB_WS_SS wrote cachefile consumers successfully
2025-07-08 17:21:17.261 Global global ATTR AB_WS_SS consumer07 AB_POOLD:Aussenbereich+Pool auto=automatic etotal=Active_Energy_Day__kWh:kWh icon=scene_pool interruptable=0 mintime=240 mode=must notafter=21:00 notbefore=03:00 off=AUS on=EIN pcurr=Active_Power__W:W:2 power=0 swoffcond=AB_POOLD:SF_Abort:1 swstate=state:EIN:AUS type=other
2025-07-08 17:21:17.279 Global global SAVE

2025-07-08 17:21:20.248 SolarForecast AB_WS_SS wrote cachefile consumers successfully
2025-07-08 17:21:20.269 Global global ATTR AB_WS_SS consumer07 AB_POOLD:Aussenbereich+Pool auto=automatic etotal=Active_Energy_Day__kWh:kWh icon=scene_pool interruptable=0 mintime=240 mode=must notafter=21:00 notbefore=03:00 off=AUS on=EIN pcurr=Active_Power__W:W:2 power=0 swoffcond=AB_POOLD:SF_Abort:1 swstate=state:EIN:AUS type=other
2025-07-08 17:21:20.287 Global global SAVE
2025-07-08 17:21:20.773 SolarForecast AB_WS_SS Current_PowerBatIn_02: 570 W
2025-07-08 17:21:20.773 SolarForecast AB_WS_SS Current_Consumption: 188 W
2025-07-08 17:21:20.773 SolarForecast AB_WS_SS Current_Surplus: 6 W
2025-07-08 17:21:20.773 SolarForecast AB_WS_SS special_BatPowerIn_Sum: 570 W

2025-07-08 17:21:22.904 SolarForecast AB_WS_SS wrote cachefile consumers successfully
2025-07-08 17:21:23.224 Global global ATTR AB_WS_SS consumer07 AB_POOLD:Aussenbereich+Pool auto=automatic etotal=Active_Energy_Day__kWh:kWh icon=scene_pool interruptable=0 mintime=240 mode=must notafter=21:00 notbefore=03:00 off=AUS on=EIN pcurr=Active_Power__W:W:2 power=0 swoffcond=AB_POOLD:SF_Abort:1 swstate=state:EIN:AUS type=other
2025-07-08 17:21:23.571 Global global SAVE
2025-07-08 17:21:24.108 SolarForecast AB_WS_SS Current_PV: 249 W
2025-07-08 17:21:24.108 SolarForecast AB_WS_SS Current_Consumption: 243 W

2025-07-08 17:21:25.536 SolarForecast AB_WS_SS wrote cachefile consumers successfully
2025-07-08 17:21:25.557 Global global ATTR AB_WS_SS consumer07 AB_POOLD:Aussenbereich+Pool auto=automatic etotal=Active_Energy_Day__kWh:kWh icon=scene_pool interruptable=0 mintime=240 mode=must notafter=21:00 notbefore=03:00 off=AUS on=EIN pcurr=Active_Power__W:W:2 power=0 swoffcond=AB_POOLD:SF_Abort:1 swstate=state:EIN:AUS type=other
2025-07-08 17:21:25.575 Global global SAVE
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Current_BatCharge_02: 62 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour00_SoCforecast_02: 73.0 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour01_SoCforecast_02: 82.3 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour02_SoCforecast_02: 84.0 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour03_SoCforecast_02: 82.0 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour04_SoCforecast_02: 79.1 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour05_SoCforecast_02: 76.7 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour06_SoCforecast_02: 74.1 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour07_SoCforecast_02: 71.4 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour08_SoCforecast_02: 68.7 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour09_SoCforecast_02: 66.3 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour10_SoCforecast_02: 62.0 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour11_SoCforecast_02: 58.5 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour12_SoCforecast_02: 55.8 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour13_SoCforecast_02: 56.5 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour14_SoCforecast_02: 55.4 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour15_SoCforecast_02: 57.0 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour16_SoCforecast_02: 60.2 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour17_SoCforecast_02: 65.8 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour18_SoCforecast_02: 72.9 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour19_SoCforecast_02: 80.7 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour20_SoCforecast_02: 87.9 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour21_SoCforecast_02: 95.3 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS Battery_NextHour22_SoCforecast_02: 99.4 %
2025-07-08 17:21:26.144 SolarForecast AB_WS_SS special_BatWeightedTotalSOC: 51.00 %

2025-07-08 17:21:27.554 SolarForecast AB_WS_SS wrote cachefile consumers successfully
2025-07-08 17:21:27.576 Global global ATTR AB_WS_SS consumer07 AB_POOLD:Aussenbereich+Pool auto=automatic etotal=Active_Energy_Day__kWh:kWh icon=scene_pool interruptable=0 mintime=240 mode=must notafter=21:00 notbefore=03:00 off=AUS on=EIN pcurr=Active_Power__W:W:2 power=0 swoffcond=AB_POOLD:SF_Abort:1 swstate=state:EIN:AUS type=other
2025-07-08 17:21:27.593 Global global SAVE
2025-07-08 17:21:28.095 SolarForecast AB_WS_SS nextCycletime: 17:22:37
2025-07-08 17:21:28.095 SolarForecast AB_WS_SS consumer01_currentPower: 97.5 W
2025-07-08 17:21:28.095 SolarForecast AB_WS_SS consumer11_currentPower: 232.5 W
2025-07-08 17:21:28.095 SolarForecast AB_WS_SS Current_GridConsumption: 543 W
2025-07-08 17:21:28.095 SolarForecast AB_WS_SS Current_Consumption: 232 W
2025-07-08 17:21:28.095 SolarForecast AB_WS_SS Current_Surplus: 17 W

2025-07-08 17:21:33.255 SolarForecast AB_WS_SS wrote cachefile consumers successfully
2025-07-08 17:21:33.578 Global global ATTR AB_WS_SS consumer07 AB_POOLD:Aussenbereich+Pool auto=automatic etotal=Active_Energy_Day__kWh:kWh icon=scene_pool interruptable=0 mintime=240 mode=must notafter=21:00 notbefore=03:00 off=AUS on=EIN pcurr=Active_Power__W:W:2 power=0 swoffcond=AB_POOLD:SF_Abort:1 swstate=state:EIN:AUS type=other
2025-07-08 17:21:33.899 Global global SAVE
2025-07-08 17:21:34.385 SolarForecast AB_WS_SS Current_PowerBatOut_01: 0 W
2025-07-08 17:21:34.385 SolarForecast AB_WS_SS consumer12_currentPower: 271.7 W
2025-07-08 17:21:34.385 SolarForecast AB_WS_SS Current_Consumption: 222 W
2025-07-08 17:21:34.385 SolarForecast AB_WS_SS Current_Surplus: 27 W
2025-07-08 17:21:34.385 SolarForecast AB_WS_SS Current_AutarkyRate: 0 %
2025-07-08 17:21:34.385 SolarForecast AB_WS_SS special_BatPowerOut_Sum: 0 W
2025-07-08 17:21:34.385 SolarForecast AB_WS_SS special_SunHours_Remain: 3.72
Kann das an meiner pumpControl liegen?

Code Auswählen Erweitern

############################################################################
#   Pumpensteuerung
############################################################################
sub pumpControl {
  my $name  = shift;
  my $c     = shift;                                                              # Nummer des Verbrauchers, z.B. 07
  my $mneed = shift;                                                              # Soll-Pumpenzeit, z.B. 300 (Minuten)
 
  $c            = sprintf "%02d", $c;                                             # falls führende 0 vergessen wird
  my $pump      = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', '');       # Devicename der Pumpe
  my $plstate   = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
  my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate);                 # akt. Status des Consumers
  my $dhash     = $defs{$pump};

  readingsSingleUpdate ($dhash, 'SF_Abort', 0, 0);                                # default keine Zyklusbeendigung

  if ($simpCstat =~ /started|interrupt|continu/xs) {                              # Vorgang ist gestartet
      my $t       = time;
      my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon',  '');
      my $stopts  = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
      return if(!$startts || !$stopts);
     
      my $mrest = sprintf '%.0f', (($stopts - $t) / 60);                          # Restlaufzeit (Minuten)     
      my $dt     = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
      my $day    = $dt->{day};
      my $hstart = int $dt->{hour} + 1;                                           # lfd. Stunde bei Pumpen Start
      my $msum   = 0;
 
      for my $hod (1..24) {                                                       # bisherige Laufzeit der Pumpe
          next if($hod < $hstart);
          $hod = sprintf "%02d", $hod;
          $msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
      }
     
      if ($msum >= $mneed) {
          readingsSingleUpdate ($dhash, 'SF_Abort', 1, 0);                        # vorfristige Zyklusbeendigung
          return;
      }

      if ($mrest >= ($mneed - $msum)) {                       
          fhem ("set $name attrKeyVal consumer$c interruptable=1");               # Interrupt-Freigabe
      }
      else {                       
          fhem ("set $name attrKeyVal consumer$c interruptable=0");               # keine Interrupt-Freigabe
      }
  }
 
return;
}

[DS_Starter]

Kann das mit der Verbrauchsplanung zusammenhängen?

Ja und Nein. Wichtig ist ob und wieviele Daten zwischen dem FHEM Server und dem Browser ausgetauscht werden müssen (Änderungen in der Grafik, Readingänderungen usw.) und ob es bei diesem Datenaustausch ein Abbruch der longpoll Verbindung gibt die als Folge diese Meldung hat.
Im Normalfall kommt die Meldung mal und verschwindet nach dem Neuaufbau (5 Sekunden) wieder. Sollte natürlich nicht ständig passieren.
Hat sich ein Browsertab mal abgehängt einfach Refresh drücken und dann sollte es auch weitergehen.
Wie gesagt, kann mal passieren keine Frage, aber natürlich kein penetranter Dauerzustand.

[DS_Starter]

Ich habe den Eventmonitor einige Zeit betrachtet, und mir ist da wieder der Consumer 07 aufgefallen.

Ich möchte es weiter fassen ... versuche die Events weiter zu reduzieren.
Die Minimalvariante wäre im SF Device zu setzen:

Code Auswählen Erweitern

event-on-change-reading state

state muß auf jedenfall aktualisieren (Grafik Update).
Ich gehe stark davon aus du wirst eine Abhängigkeit zwischen dem Eventvolumen und deiner Browsermeldung feststellen.

[Burny4600]

Code Auswählen Erweitern

notbefore Startzeitpunkt Verbraucher nicht vor angegebener Zeit 'Stunde[:Minute]' einplanen (optional)
Der <Ausdruck> hat das Format hh[:mm] oder ist in {...} eingeschlossener Perl-Code der hh[:mm] zurückgibt.

notafter Startzeitpunkt Verbraucher nicht nach angegebener Zeit 'Stunde[:Minute]' einplanen (optional)
Der <Ausdruck> hat das Format hh[:mm] oder ist in {...} eingeschlossener Perl-Code der hh[:mm] zurückgibt.
notafter müsste eigentlich Endzeitpunkt lauten. Ist ein wenig verwirrend.
Ich würde das Startzeitpunkt weglassen. Verbraucher nicht vor bzw. Verbraucher nicht nach ist ausreichend.


Eine Frage zur Planung der Consumer.
Die Definition für consumer 04 lautet

Code Auswählen Erweitern

EG_WI_TRD:EG-Wirtschaftsraum+Trockner
auto=automatic
etotal=Active_Energy_Day__kWh:kWh
exconfc=2
icon=scene_clothes_dryer
interruptable=EG_WI_TRD:SF_Int:1
mintime=300
mode=must
notafter=16:30
notbefore=08:00
off=AUS
on=EIN
pcurr=Active_Power__W:W:2
power=0
swstate=state:EIN:AUS
type=dryer
Warum greift die Planung nicht?

Code Auswählen Erweitern

consumer04
consumer04_planned_start 08.07.2025 15:00:02
consumer04_planned_stop  08.07.2025 20:00:02
consumer04_planned_stop müsste um 16:30 anhalten.

[300P]

Code Auswählen Erweitern

notbefore     Startzeitpunkt Verbraucher nicht vor angegebener Zeit 'Stunde[:Minute]' einplanen (optional)
    Der <Ausdruck> hat das Format hh[:mm] oder ist in {...} eingeschlossener Perl-Code der hh[:mm] zurückgibt.
   
notafter     Startzeitpunkt Verbraucher nicht nach angegebener Zeit 'Stunde[:Minute]' einplanen (optional)
    Der <Ausdruck> hat das Format hh[:mm] oder ist in {...} eingeschlossener Perl-Code der hh[:mm] zurückgibt.
notafter müsste eigentlich Endzeitpunkt lauten. Ist ein wenig verwirrend.
Ich würde das Startzeitpunkt weglassen. Verbraucher nicht vor bzw. Verbraucher nicht nach ist ausreichend.

Das interpretierst du evtl. falsch:
notbefore =>>> starte die "Einplanung" nicht vor dieser Zeit
notafter  =>>> starte die "Einplanung" nicht nach dieser Zeit

(bedeutet NICHT schalte mich an und aus innerhalb dieser Zeit  )

[Max_Meyer]

An den Netzwerkkomponenten kann es bei mir nicht liegen. Das gesamte Netzwerk ist Cat7 Konform installiert.
Früher waren einige Pis per Powerlan mit dem Netzwerk verbunden, bis ich diese Bereiche ebenfalls mit Cat7 nachinstalliert hatte. Powerlan taugte bei mir jedenfalls auch nicht für die FHEM Anwendungen.
Ich gebe dir Recht, das es für FHEM ratsam ist auf die Netzwerkkomponenten acht zu geben. Da kann man leicht das falsche als Fehlerursache verdächtigen.
Bei mir ist das System in den letzten 10 Jahren auch erheblich gewachsen.
FHEM ist auf 10 Pis verteilt, die aber für sich grundsätzlich autark arbeiten. Gewisse Bereiche will ich eigenständig haben, wie die Heizung, Solarthermie, PV. Ich hole mir von diesen Bereichen nur notwendige Datenpunkte für eine Zentrale Übersicht.
Wieviele Sensoren, Aktoren und Schnittstellen vorhanden müsste ich mal wirklich zählen. Es sind im gesamten System sicherlich über 200 Stk.
Auch die Systeme wachsen immer noch, wie jetzt der PV-Bereich mit SolarForecast, und ich lerne immer noch dazu.

@Chris,
Meine Anlage hat aus gleichen Gründen eine ähnliche Größe (8 PI's) - für einzelne Komponenten reicht auch PowerLan - dort ist das Problem, dasjenige worum es sich hier dreht, die durch WR produzierte PV-Energie welche den Sinus beeinträchtigt (Oberwellen) auch aus diesen Gründen hat die Ausführung (bei dir CAT7) nicht unbedingt was mit der im Router ankommenden Bandbreite zu tun.
Ich würde dir wirklich raten
1.) im Router mal einen 'Kabeltest' zu machen um die ausgehandelte Geschwindigkeit zu sehen
2.) mit den beiden im oberen Post genannten Einstellungen (QoS/Storm-Control-Rate) den Brodcast zu dämpfen
es sei denn dein internes Netzwerk ist deutlich schneller als 2GB (z.B. mit LAG) dann solle es unkritisch sein
Ist ja kein Risiko dabei - die Einstellungen lassen sich jederzeit wieder auf Default setzen und der Aufwand ist überschaubar - aber so kann man ausschließen Geister zu jagen. Und ich hatte seither keine Abbrüche, und negative Verbräuche mehr.
Gruß Gerd
PS @Heiko: Ist das ist Out-Topic hier?

[DS_Starter]

PS @Heiko: Ist das ist Out-Topic hier?

Alles gut, wir sind im Ausstausch und ich schweife auch gerne mal ab. Ansonsten könnt ihr euch damit in ein Technikforum zurückziehen wenn sich das Thema ausweiten wollte.