Modul für Victron BMV600 / BMV602 / BMV700 / BMV702 / MPPT / Inverter

[MadMax-FHEM]

Hi Joachim,
ich hänge "meine" Version einfach mal hier dran...
Kannst ja mal schauen, ob du noch was davon gebrauchen kannst.

Schönen Abend... und bis die Tage.
Beste Grüße vom südl. Rande des Ruhrpotts
Johannes


00_VEDirect_meinPatch.pm

Danke.
Ich habe mir deine Version mal angesehen und einige der != -> ne "Ersetzungen" wieder zurückgenommen (ich denke, dass der index in einem Array/Zeichenkette eine Zahl ist   ).

Ich habe auch schon mal einige Logausgaben vorbereitet für Meldungen, die so "gemeldet" wurden, ich selbst aber nicht habe.
Interessant wäre jetzt nat.: läuft die Version überhaupt (bei mir tut sie es   [weiterhin])...
...und gibt es noch Ausgaben im Log?
Regelmässig oder "nur" beim Start.

Wenn ich das weiß, kann ich die dann noch mal auf Basis einer mir bekannten Version angehen

Diese Stelle finde ich (noch) eigenartig:

Code Auswählen Erweitern

          $payload = int(hex($payload))*$Register{ $type }->{ $id }->{'Skalierung'} if($Register{ $type }->{ $id }->{'Skalierung'} ne "" || !defined($Register{ $type }->{ $id }->{'Skalierung'}));
Aber dazu muss ich mal abwarten, ob dazu (überhaupt) noch eine Meldung kommt...

Andere/ähnliche Stellen können bei "komischen Konstellationen" auch Logausgaben "erzeugen".
Dazu bin ich aber nicht wirklich tief genug im Code drin (wollte ich eigentlich auch nicht, sonst bin ich ja fast schon bei Neuimplementierung   )...
EDIT: Tja, haben wir ja schon einen solchen Fall...

2023.04.17 20:46:49 1: PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/00_VEDirect.pm line 1206.

Und ich denke VEDirect_ChecksumHEX muss ich mir doch mal anschauen und mit der Beschreibung von Victron mal gegenprüfen...
(die 2x $val können schon Sinn machen, es wird ja entweder oder ausgeführt, es sind if dahinter   )
EDIT:

2023.04.17 20:37:48 1: PERL WARNING: Illegal hexadecimal digit '
' ignored at ./FHEM/00_VEDirect.pm line 1436

Gut hier ist die Frage, ob ich die Zeile noch korrekt zuordnen kann. Aber wenn es noch in etwa zusammenpasst, dann eben genau: VEDirect_ChecksumHEX noch mal prüfen...

So ganz zufrieden bin ich (noch) nicht...
...aber für heute muss ich mal (wieder) Pause machen...

EDIT:

2023.04.17 20:37:48 1: PERL WARNING: Use of uninitialized value $lastMin in numeric ne (!=) at ./FHEM/00_VEDirect.pm line 1039.

Sollte mit angehängter Version nicht mehr auftreten


DANKE für's Testen!


Gruß, Joachim

P.S.: jetzt müssten wir mal wieder "glatt ziehen" und mit der hier angehängten Version testen, sonst kriege ich die Zeilen nicht zusammen...
...und dann halt mal rauskriegen wann die Einträge kommen (Start oder regelmässig und wenn regelmässig: wie oft / wenn regelmässig aber sehr selten, dann wird verm. das Log recht voll, bis so ein Fall wieder eintritt   -> ist halt unangenehm für den Tester)
 (allerdings werde ich verm. die nächsten Tage inkl. WE zu nicht viel kommen   )

[MadMax-FHEM]

2023.04.17 20:46:49 1: PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/00_VEDirect.pm line 1206.

Code Auswählen Erweitern

            my $Hdate = POSIX::strftime("%Y%m%d",localtime(time+86400*$Register{ $type }->{ $id }->{'Skalierung'}));
            my $HdateOld = POSIX::strftime("%Y%m%d",localtime(time-86400*$Register{ $type }->{ $id }->{'Skalierung'}));

Manche Skalierungen sind mit "" angegeben -> wenn da eine davon "rausgegriffen" wird, kommt diese Meldung.
Muss ich nur sehen, was da "vernünftig" ist.
"Überall" eine numerische Skalierung angeben (welche?) oder prüfen, ob eine numerische Skalierung vorliegt...
...aber was tun, wenn nicht?

Muss ich mal drüber nachdenken...

Gruß, Joachim

[kpwg]

Hallo Johannes und Joachim,

besten Dank für Euren Input und die Versionen. Mit "global verbose 2" war bis jetzt komplett Ruhe, es kamen keine Logeinträge dazu. Aktuell habe ich global verbose auf 3 gesetzt, da kam gleich die erste Meldung (hat aber aufgrund des LogLevel damit nix zu tun):

Code Auswählen Erweitern

2023.04.18 06:20:44 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/00_VEDirect.pm line 1264.
Ich meine, das kommt vom 100/30, da ich (nur) dort das reading  Consumed_Wh    FFFFFFFF  habe.

Interessant ist auch noch der Charger_state, wenn die Sonne aufgeht: ich habe dann für einen kurzen Moment schnell wechselnde Werte zwischen den bekannten Zuständen ("Charger_state:not_charging,,fault,bulk,absorption,float,equalize,ess") und einer großen numerischen Zahl. Logeinträge werden dazu aber nicht generiert.

Viele Grüße und einen schönen Tag,

Ricardo

[kpwg]

Es gibt neue Logeinträge:

Code Auswählen Erweitern

2023.04.18 13:54:17 1: PERL WARNING: Use of uninitialized value within @bits in numeric eq (==) at ./FHEM/00_VEDirect.pm line 1092.
2023.04.18 13:54:17 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/00_VEDirect.pm line 1096.
Ich kann es nicht deuten, aber könnten dafür noch immer fehlerhafte Pakete verantwortlich sein? Ich "empfange" hier fast eine Million Frames am Tag aus den fünf Geräten, da kann schon mal was schief gehen. Die Fehler sind irgendwie diffus, nicht wirklich klar zuzuordnen. Ich bin allerdings auch kein Programmierer, lerne aber gerne was dazu.

Noch eine Bitte: Es sollte in Zeile 4 zur Version von Askie noch eine Art "mod-Version" mit Datum angehängt werden, damit wir den Stand besser unterscheiden können. Vielleicht meldet sich auch Askie mal

[MadMax-FHEM]

Ok, schaue ich mir mal an...
Aber ich fürchte ja, "komische" Pakete...
Und dann passt was nicht...

Jep, das mit Version ist eine gute Idee...
Ich schau mal...

Gruß, Joachim

[MadMax-FHEM]

Hallo Johannes und Joachim,

besten Dank für Euren Input und die Versionen. Mit "global verbose 2" war bis jetzt komplett Ruhe, es kamen keine Logeinträge dazu. Aktuell habe ich global verbose auf 3 gesetzt, da kam gleich die erste Meldung (hat aber aufgrund des LogLevel damit nix zu tun):

Code Auswählen Erweitern

2023.04.18 06:20:44 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/00_VEDirect.pm line 1264.
Ich meine, das kommt vom 100/30, da ich (nur) dort das reading  Consumed_Wh    FFFFFFFF  habe.

Interessant ist auch noch der Charger_state, wenn die Sonne aufgeht: ich habe dann für einen kurzen Moment schnell wechselnde Werte zwischen den bekannten Zuständen ("Charger_state:not_charging,,fault,bulk,absorption,float,equalize,ess") und einer großen numerischen Zahl. Logeinträge werden dazu aber nicht generiert.

Viele Grüße und einen schönen Tag,

Ricardo

Hmm, dazu habe ich nur folgendes gefunden:
https://github.com/exiftool/exiftool/issues/6

Scheint so als ob (bei bestimmten Plattformen und/oder Perl Versionen) Zahlen über 100000000 (Dezimal) zu dieser Warnung führen...

100000000Wh -> 100000kWh?

Und auch bei anderen Modulen (bislang ohne Lösung): https://forum.fhem.de/index.php?topic=122779.msg1173629#msg1173629

Das mit den wechselnden Zuständen bei Sonnenaufgang: da schaue ich mal, wenn ich das Ladegerät einschalte (müsste ja dasselbe sein?), ansonsten mal verbos auf 5 setzen bevor das passiert, dann sieht man was empfangen wird. Wird das so empfangen, dann wohl auch so gesendet und dann kann man auf Empfangsseite wenig tun (ignorieren ist ja keine Lösung?   )...
EDIT: eben probiert und geht bei mir sofort (also zumindest wenn ich im Device-Overview schaue) auf bulk...

Aber bei verbose 5 (und 4) wird sehr viel geloggt!
(drum habe ich auch einige Logausgaben in verbose geändert, damit das Modul wenigstens in verbose 3 betrieben werden kann / es gibt nur eine [oder sehr wenige] Ausgaben mit verbose 1, also nur wenn ein Fehler im Modul erkannt wurde / so wie verbose definiert ist -> habe ich zumindest versucht)

Gruß, Joachim

[MadMax-FHEM]

Es gibt neue Logeinträge:

Code Auswählen Erweitern

2023.04.18 13:54:17 1: PERL WARNING: Use of uninitialized value within @bits in numeric eq (==) at ./FHEM/00_VEDirect.pm line 1092.
2023.04.18 13:54:17 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/00_VEDirect.pm line 1096.
Ich kann es nicht deuten, aber könnten dafür noch immer fehlerhafte Pakete verantwortlich sein? Ich "empfange" hier fast eine Million Frames am Tag aus den fünf Geräten, da kann schon mal was schief gehen. Die Fehler sind irgendwie diffus, nicht wirklich klar zuzuordnen. Ich bin allerdings auch kein Programmierer, lerne aber gerne was dazu.

Was mich wundert ist die Zeile.
Bei mir steht in Zeile 1092:

Code Auswählen Erweitern

          for my $b (0 .. $#bits)

Ich denke aber bzw. macht es mehr Sinn, wenn der Fehler hierher stammt (1093):

Code Auswählen Erweitern

          {$cntOnes+=1 if($bits[$b] == 1); }
Ich habe in dem Fall das Ende "korrigiert", kann aber sein, dass das Array nicht bei 0 sondern bei 1 beginnt, dann wäre am falschen Ende "korrigiert" worden...
Ich habe mal in Zeile 1085 das Logging angepasst (von 5 auf 1), da ich die Ausgabe aber nicht bekomme, habe ich auch kein Log
Wenn du willst kannst du das ja mal ändern, dann kann man das "Bit-Array" mal nachbauen und schauen wie es richtig ist...

Code Auswählen Erweitern

        Log3 $name, 1, "VEDirect ($name) - ParseTXT: AR: $tmpVal --> bin: $bin";

Auch die Meldung zu 1096 verwirrt mich, bei mir steht da:

Code Auswählen Erweitern

            my $arVal = 2**$b;


Das erste "concatinate" was dort passen würde ist bei mir in 1098:

Code Auswählen Erweitern

            $Rout .= $ARtext{$arVal} if (defined $ARtext{$arVal} && $bits[$b] == 1);

Gruß, Joachim

[MadMax-FHEM]

Ich werde mir dann doch bei Gelegenheit mal die HEXChecksum-rüfung anschauen...
(...müssen).

Gruß, Joachim

[kpwg]

Mal wieder eine Rückmeldung nach Tagen: Die letzte hier gepostete Version läuft gut, es gibt deutlich weniger Fehlermeldungen. Heute habe ich im Schuppen ein wenig gebaut (ISO-Rohr verlegt, Kabel gezogen und an den unmöglichsten Stellen doch noch durch bekommen) und musste dafür die Technik kurz außer Betrieb nehmen. Ein Neustart wäre auch so kein Problem, aber man startet ja nicht ohne Not ständig neu 

Die Logeinträge nach dem Start:

Code Auswählen Erweitern

2023.04.23 15:18:38 1: Including ./log/fhem.save
2023.04.23 15:18:38 0: Featurelevel: 6.2
2023.04.23 15:18:38 0: Server started with 63 defined entities (fhem.pl:27410/2023-04-07 perl:5.032001 os:linux user:fhem pid:529)
2023.04.23 15:18:38 1: PERL WARNING: Use of uninitialized value $lastMin in numeric ne (!=) at ./FHEM/00_VEDirect.pm line 1039.
2023.04.23 15:18:38 1: PERL WARNING: Illegal hexadecimal digit '
' ignored at ./FHEM/00_VEDirect.pm line 1436.
2023.04.23 15:18:48 2: AttrTemplates: got 271 entries
2023.04.23 15:19:41 1: PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/00_VEDirect.pm line 1206.Die 1039 ist noch da, obwohl sie das gar nicht mehr sollte?
Dort steht

Code Auswählen Erweitern

if($lastMin != $minu)
    {
      my $command = ":154";
      DevIo_SimpleWrite($hash, $command, 2, 1) ;
      $hash->{helper}{lastHex} = $minu;
    }Muss $lastMin hier noch definiert werden? Oder habe ich doch nicht die aktuellste Version erwischt

Die 1436 gehört zum sub VEDirect_ChecksumHEX($$). Ich denke, da klemmt es noch immer, da sich hier auch in seltenen Fällen noch falsche Werte durchmogeln (falsche Spannung vom Shunt, entsprechende Reaktion ...) Hier kommt ein Zeilenumbruch, denk ich. Aber woher!

Ansonsten war das Log über fünf Tage recht ruhig:

Code Auswählen Erweitern

2023.04.17 20:37:48 0: Server started with 60 defined entities (fhem.pl:27410/2023-04-07 perl:5.032001 os:linux user:fhem pid:945)
2023.04.17 20:37:48 1: PERL WARNING: Use of uninitialized value $lastMin in numeric ne (!=) at ./FHEM/00_VEDirect.pm line 1039.
2023.04.17 20:37:48 1: PERL WARNING: Illegal hexadecimal digit '
' ignored at ./FHEM/00_VEDirect.pm line 1436.
2023.04.17 20:46:49 1: PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/00_VEDirect.pm line 1206.
2023.04.18 06:20:44 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/00_VEDirect.pm line 1264.
2023.04.18 13:54:17 1: PERL WARNING: Use of uninitialized value within @bits in numeric eq (==) at ./FHEM/00_VEDirect.pm line 1092.
2023.04.18 13:54:17 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/00_VEDirect.pm line 1096.
2023.04.19 10:28:18 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/00_VEDirect.pm line 1592.
2023.04.20 05:59:35 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at ./FHEM/00_VEDirect.pm line 1264.
2023.04.21 18:58:14 1: PERL WARNING: Use of uninitialized value $tmtset[1] in split at ./FHEM/00_VEDirect.pm line 1657.
2023.04.22 11:55:23 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/00_VEDirect.pm line 1592.
2023.04.22 12:14:15 1: PERL WARNING: Use of uninitialized value $payload in concatenation (.) or string at ./FHEM/00_VEDirect.pm line 1274.
2023.04.22 12:14:15 1: PERL WARNING: Use of uninitialized value $payload in concatenation (.) or string at ./FHEM/00_VEDirect.pm line 1275.Die Einträge "Hexadecimal number > 0xffffffff non-portable" entsprechen dem Zeitpunkt, zu welchem der Laderegler morgens seinen Betrieb aufnimmt.

[kpwg]

Was mich wundert ist die Zeile.
Bei mir steht in Zeile 1092:

Code Auswählen Erweitern

          for my $b (0 .. $#bits)


Das ist hier die 1091

Ich denke aber bzw. macht es mehr Sinn, wenn der Fehler hierher stammt (1093):

Code Auswählen Erweitern

          {$cntOnes+=1 if($bits[$b] == 1); }


Genau, ist hier in 1092

Ich habe in dem Fall das Ende "korrigiert", kann aber sein, dass das Array nicht bei 0 sondern bei 1 beginnt, dann wäre am falschen Ende "korrigiert" worden...
Ich habe mal in Zeile 1085 das Logging angepasst (von 5 auf 1), da ich die Ausgabe aber nicht bekomme, habe ich auch kein Log
Wenn du willst kannst du das ja mal ändern, dann kann man das "Bit-Array" mal nachbauen und schauen wie es richtig ist...

Code Auswählen Erweitern

        Log3 $name, 1, "VEDirect ($name) - ParseTXT: AR: $tmpVal --> bin: $bin";


Das will ich heute noch testen, wenn man (also Frau!) mir die Zeit lässt.

Auch die Meldung zu 1096 verwirrt mich, bei mir steht da:

Code Auswählen Erweitern

            my $arVal = 2**$b;


Das steht in der 1095

Das erste "concatinate" was dort passen würde ist bei mir in 1098:

Code Auswählen Erweitern

            $Rout .= $ARtext{$arVal} if (defined $ARtext{$arVal} && $bits[$b] == 1);


=> 1097

Ich habe glaub ich soeben vermurkst zitiert. Aber man versteht es, denk ich. Da sind wir auch wieder bei den Versionsnummern 

[MadMax-FHEM]

Jaja, Versionsnummer, verstanden...
Aktuell leider wenig Zeit...

Aber da du eine Zeile verrutscht bist: doch nicht letzte Version?

Und ja $lastMin in 1039 hätte ich nicht mehr erwartet.
Ich prüfe mal...
EDIT: jetzt bin ich wirklich verwirrt (erst mal). Im Original steht schon

Code Auswählen Erweitern

  $hash->{helper}{lastHex} = "1"; 
Hatte ich übersehen.
Ich habe dann mal (weil ich es korrekter finde) folgendes "ergänzt" (eigentlich als einziges einfügen wollen   ):

Code Auswählen Erweitern

  $hash->{helper}{lastHex} = -1; 
Entweder wird das gar nicht durchlaufen?
(Weil sonst könnte man ein "definition wegen früherer definition usw." (hab grad den engl. Fehlertext nicht parat )
Muss ich noch mal schauen.
Ist aber wirklich nur beim Start, da dann eben der hash noch nicht initialisiert ist. Nach dem ersten Durchlauf steht ja immer der des letzten Durchlaufs drin...

Und stelle meine aktuelle Version inkl. Versionsangabe hier rein...
EDIT: done. V1.0

EDIT: ja, muss mir das mit CRC-HEX mal ansehen. Ich selbst habe leider keine Meldungen (oder so gut wie). Mache aktuell aber auch noch nicht wirklich was damit. Mehr Meldungen bei Text-Messages hatte ich, da ich eben per LAN/WLAN angebunden habe, da gingen dann wohl einige Meldungen "kaputt"...

Danke für's Testen!

Gruß, Joachim

[kpwg]

Ich muss danken fürs Fehler beheben!

Die neue Version ist in Betrieb, Logauszug bei Start

Code Auswählen Erweitern

2023.04.23 21:13:30 1: Including ./log/fhem.save
2023.04.23 21:13:30 0: Featurelevel: 6.2
2023.04.23 21:13:30 0: Server started with 65 defined entities (fhem.pl:27410/2023-04-07 perl:5.032001 os:linux user:fhem pid:528)
2023.04.23 21:13:30 1: PERL WARNING: Use of uninitialized value $lastMin in numeric ne (!=) at ./FHEM/00_VEDirect.pm line 1042.
2023.04.23 21:13:30 1: PERL WARNING: Illegal hexadecimal digit '
' ignored at ./FHEM/00_VEDirect.pm line 1443.
2023.04.23 21:13:45 2: AttrTemplates: got 271 entries
2023.04.23 21:17:29 1: PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/00_VEDirect.pm line 1209.
Ich beobachte das mal, sieht soweit gut aus, die Kiste rennt

[MadMax-FHEM]

Das mit $lastMin muss ich mir mal ansehen, ist eigenartig aber zumindest "klar"...

Die anderen Meldungen sind dann hoffentlich weg, wenn ich CRC-Hex geprüft habe...
Ansonsten müssen wir wohl (erst mal) damit leben...

Gruß, Joachim

[kpwg]

Nach 22h Laufzeit gibt es aktuell keine Fehlermeldungen bis auf den Sonnenaufgang, so schaut das richtig gut aus. Der Eintrag kommt so auch nicht jeden Tag!
Ich baue mir jetzt noch ein DOIF, um die Ausreißer-Werte einzufangen und zu loggen.

Auffällig war gestern nach dem Neustart, das die "1209er" Fehlermeldung immer etwas verzögert nach dem Start kommt, genauer hier zwischen einer und vier Minuten. Ich meine, danach tritt das nicht wieder auf? Entweder rutschen hier falsche Werte durch oder es ist ein Wert nicht initialisiert?

Viele Grüße,
Ricardo

[MadMax-FHEM]

Hmmm, obwohl es gut läuft habe ich mal ein wenig weitergebastelt
(ihr könnt ja bei "nichtgefallen" auf die V1.0 zurück   )
Anbei also die V1.1

Das Problem beim Start bzgl. $lastMin konnte ich beheben, obwohl es mir seltsam vorkommt aber sei's drum:

Code Auswählen Erweitern

    my $lastMin = -1;
    $lastMin = $hash->{helper}{lastHex} if(defined($hash->{helper}{lastHex}));

Ich habe auch ChecksumHEX umgebaut (so wie es eigentlich sein sollte?).
Bislang wurde die Funktion dazu genutzt um die Checksum für Kommandos zu berechnen, das habe ich gelassen.
Ich habe eine neue Funktion hinzugefügt (noch nicht "sauber" aber sollte tun), die nun "stur" die Prüfung der Checksum bei HEX-Antworten durchführt und im Falle, dass etwas nicht stimmt dies ausgibt (verbose 1).
Da ich eigentlich keine WARN habe (oder so gut wie), trotzdem aber einige Checksum-Fehler bin ich nicht sicher, ob da nicht einige korrekte verworfen werden...
Da müsstet ihr mal testen

Dann gibt es ja noch die "isn't numeric" Meldungen (die ich auch ab und an habe).
Da bin ich dran.
Folgende weiß ich woher, beheben: hmmm (was ist die richtige Skalierung?)

Code Auswählen Erweitern

2023.04.26 14:14:31 1: PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/00_VEDirect.pm line 1216.
2023.04.26 14:14:31 1: VEDirect (VictronMPPTTCP) - 1221 numberproblem payload: Tot_Sys_res: 1.58 kWh |Tot_Sys: 1.81 kWh |PvMax: 51.62 V |BattVMax: 14.43 V |BattVMin: 0.07 V |NrDays: 30    type: MPPT   id: 0x104F    Register...:
(Zeilennummer kann/wird bei euch auch bzgl. der V1.1 abweichen, soll nur zeigen wie ich suche und was ich gefunden habe )

Das ist mir klar, da eben bei diesem Eintrag die Skalierung "" ist

Code Auswählen Erweitern

"0x104F"=>{"Bezeichnung"=>"Total_history", "ReadingName"=>"Total_history", "Einheit"=>"", "Skalierung"=>"", "Payloadnibbles"=>"68", "min"=>"", "max"=>"", "Zyklisch"=>"0", "getConfigAll"=>"0", "getValues"=>"Total_history:noArg", "setValues"=>"-", "spezialSetGet"=>"-"},
Was mich allerdings wundert ist, dass ich bei Folgeaufrufen mit dieser "Kennung" type: MPPT  id: 0x104F keine "isn't numeric" bekomme, obwohl es ja eigentlich IMMER nicht numeric ist/sein müsste (was mir auch mein Logeintrag "sagt")...

Es gibt bestimmt noch weitere, die zu finden, naja.
Ich hänge mal eine V1.1v (für verbose   ) mit dran, wo ich mehr Ausgaben bzgl. "isn't numeric" eingebaut habe.
Allerdings weiß ich nicht wie die "spamt"
Im Zweifel halt die V1.1 (oder eben wieder V1.0) nehmen...

EDIT: wichtig nat. wenn ihr "Fehler" oder "Meldungen" postet, mit welcher Version die aufgetreten sind...

Bei mir läuft aktuell die V1.1v

Gruß, Joachim