getConfig im 5-Min Takt an HM-TC-IT-WM-W-EU seit migration nach configDB

[rapster]

habe heute auf configDB migriert, seitdem wird auf meine HM-TC-IT-WM-W-EU im 5-Minutentank ein getConfig gefeuert bis die HMLAN's im Overload sind:

Code Auswählen Erweitern

2015.07.10 17:16:41.736 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 17:15:51.593 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 17:15:01.273 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 17:12:31.976 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 17:11:52.790 1: HMLAN_Parse: HMLAN2 new condition ERROR-Overload
2015.07.10 17:11:41.829 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 17:10:51.685 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 17:10:08.610 1: HMLAN_Parse: HMLAN2 new condition Warning-HighLoad
2015.07.10 17:10:01.534 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 17:07:32.206 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 17:06:42.060 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 17:05:51.917 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 17:05:01.769 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 17:02:32.489 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 17:01:42.346 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 17:00:52.202 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 17:00:02.054 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 16:57:31.765 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 16:56:41.622 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 16:55:51.469 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 16:55:01.325 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 16:52:32.040 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 16:51:41.899 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 16:50:51.759 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 16:50:01.605 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 16:47:32.321 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 16:46:42.180 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 16:45:52.040 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 16:45:01.895 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 16:42:32.566 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 16:41:42.416 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 16:40:52.275 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 16:40:02.111 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 16:37:31.730 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 16:36:41.595 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 16:35:51.453 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 16:35:01.309 3: CUL_HM set og_sz_wandthermostat getConfig

protoEvents gibt eine queue length von 0 aus, auch keine CMDs pending.
Habe schon autoReadReg bei allen Devices auf 0 gesetzt, wird allerdings nicht besser.

Kann einer helfen oder hat eine Idee?

Außer der migration auf configDB hat sich eigentlich nichts an der config geändert...

[martinp876]

ConfigDb nutze ich nicht. Was sendet das ? Welche trigger und kommandos loest es aus ?

[rapster]

das erschreckende - nichts/garkeine...

die configDB ersetzt nur die fhem.cfg,  es wird also lediglich beim Start aus der DB statt aus dem Config-File gelesen.

Während des Fhem Betriebs ist das Modul nicht weiter tätig (bis ein Save oder rereadcfg ausgeführt wird).

Der einzige evtl. gravierende Unterschied könnte sein, dass ich zuvor die Devices geordnet in verschiedenen Konfig-Files included hatte, jetzt übernimmt die configDB die Reihenfolge und die könnte jetzt eine andere sein als zuvor?

Allerdings alle anderen definitions und Geräte funktionieren wie gehabt, nur die Wandthermostate musste ich seitdem auf 'ignore' setzen.

[rapster]

Das komische ist ja wirklich dass es genau im 5 Minuten takt passiert:

Code Auswählen Erweitern

2015.07.11 07:55:51.322 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.11 08:00:52.013 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.11 08:05:51.735 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.11 08:10:51.462 3: CUL_HM set og_ez_wandthermostat getConfig

Irgen ein anderesEvent wird zu dieser Zeit nicht getriggert:

Code Auswählen Erweitern


2015-07-11 08:09:44.134 HMLAN HMLAN3 loadLvl: low
2015-07-11 08:09:55.472 PRESENCE TV_Esszimmer present
2015-07-11 08:09:55.472 PRESENCE TV_Esszimmer presence: present
2015-07-11 08:10:00.825 CUL_HM og_ez_wandthermostat_Climate humidity: 38
2015-07-11 08:10:09.133 HMLAN HMLAN3 loadLvl: low
2015-07-11 08:10:25.521 PRESENCE TV_Esszimmer present
2015-07-11 08:10:25.521 PRESENCE TV_Esszimmer presence: present
2015-07-11 08:10:34.135 HMLAN HMLAN3 loadLvl: low
2015-07-11 08:10:34.767 ROOMMATE rr_Claudiu durTimerAbsence_cr: 73456
2015-07-11 08:10:34.767 ROOMMATE rr_Claudiu durTimerAbsence: 1224:16:14
2015-07-11 08:10:51.461 CUL_HM og_ez_wandthermostat CMDs_pending

Ein at oder ähnliches ist hier auch nicht aktiv...

das 1. getConfig wird ziemlich zeitnah nach dem Fhem-Start ausgeführt (dauert keine 5 Min), ebenso wenn ich das 'ignore' Attr vom device entferne.

Kann ich irgendwas kontrollieren, oder irgendwelche Infos liefern, um dem auf die Spur zu kommen?

[frank]

Der einzige evtl. gravierende Unterschied könnte sein, dass ich zuvor die Devices geordnet in verschiedenen Konfig-Files included hatte, jetzt übernimmt die configDB die Reihenfolge und die könnte jetzt eine andere sein als zuvor?

wenn das die ursache ist, müsste doch delete <device> und ein erneutes definieren/anlernen (am besten über autocreate) das drama beenden. zum testen erst mal eins. 
vorher kannst du das register setting und das peering sichern (saveConfig).

[martinp876]

Die 5min sind, meine ich, der automatischen abfrage geschulder. Die macht so etwas.
Es sollten aber die messages gesendet werden. Die abfrage autoreadreg stellt fest, dass daten fehlen und versucht diese zu holen. Eine pruefung dass nicht gesendet wurde isr nicht drin da davon ausgegangen wird, dass nach5min das vorige erledigt ist - erfolgreich oder nicht.
Das problem waere also, dass nicht gesendet wird. Kannst du dies klaeren oder ein list schicken ?

[rapster]

@frank: ein delete und neu definieren war mit eins was ich als erstes ausprobiert hatte, neu angelernt habe ich nicht - ob dies einen unterschied zu einem 'clear all; getconfig' macht?

@martin:
Habe versucht es zu klären, bin aber etwas unsicher

Hier erstmal das 'list og_ez_wandthermostat':

Code Auswählen Erweitern

Internals:
   .triggerUsed 1
   CFGFN
   DEF        31FE90
   HMLAN1_MSGCNT 924
   HMLAN1_RAWMSG E31FE90,0000,0497A5C2,FF,FFA2,D8865A31FE90000000310B26
   HMLAN1_RSSI -94
   HMLAN1_TIME 2015-07-11 13:52:02
   HMLAN2_MSGCNT 944
   HMLAN2_RAWMSG E31FE90,0000,046A257F,FF,FFC0,0B801031FE903765140300
   HMLAN2_RSSI -64
   HMLAN2_TIME 2015-07-11 13:51:10
   HMLAN3_MSGCNT 143
   HMLAN3_RAWMSG E31FE90,0000,3EF81408,FF,FF98,D7847031FE90000000010B26
   HMLAN3_RSSI -104
   HMLAN3_TIME 2015-07-11 13:49:30
   IODev      HMLAN2
   LASTInputDev HMLAN1
   MSGCNT     2011
   NAME       og_ez_wandthermostat
   NR         222
   NTFY_ORDER 50-og_ez_wandthermostat
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 og_ez_wandthermostat_Weather
   channel_02 og_ez_wandthermostat_Climate
   channel_03 og_ez_wandthermostat_WindowRec
   channel_06 og_ez_wandthermostat_remote
   channel_07 og_ez_wandthermostat_SwitchTr
   lastMsg    No:D8 - t:5A s:31FE90 d:000000 310B26
   protCmdDel 14
   protLastRcv 2015-07-11 13:52:02
   protResnd  2 last_at:2015-07-11 13:51:05
   protResndFail 2 last_at:2015-07-11 13:51:09
   protSnd    194 last_at:2015-07-11 13:51:10
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-93.65 lst:-94 cnt:200 min:-99 max:-87
   rssi_at_HMLAN2 max:-64 cnt:216 min:-64 lst:-64 avg:-64
   rssi_at_HMLAN3 max:-102 cnt:6 min:-105 lst:-104 avg:-103.83
   CHANGETIME:
   Helper:
     Dblog:
       Activity:
         Dblog:
           TIME       1436615360.89594
           VALUE      alive
       R-btnlock:
         Dblog:
           TIME       1436615086.90964
           VALUE      off
       R-burstrx:
         Dblog:
           TIME       1436615086.90964
           VALUE      on
       R-cyclicinfomsg:
         Dblog:
           TIME       1436615086.90964
           VALUE      on
       R-cyclicinfomsgdis:
         Dblog:
           TIME       1436615086.90964
           VALUE      0
       R-globalbtnlock:
         Dblog:
           TIME       1436615086.90964
           VALUE      off
       R-localresdis:
         Dblog:
           TIME       1436615086.90964
           VALUE      off
       R-lowbatlimitrt:
         Dblog:
           TIME       1436615086.90964
           VALUE      2.2 V
       R-modusbtnlock:
         Dblog:
           TIME       1436615086.90964
           VALUE      off
       R-paircentral:
         Dblog:
           TIME       1436615086.90964
           VALUE      0x376514
       Batterylevel:
         Dblog:
           TIME       1436615238.52211
           VALUE      2.7
       Desired-temp:
         Dblog:
           TIME       1436615238.52211
           VALUE      6.0
       Measured-temp:
         Dblog:
           TIME       1436615238.52211
           VALUE      26.7
       State:
         Dblog:
           TIME       1436615469.39064
           VALUE      CMDs_done
   Readings:
     2015-07-11 13:52:02   .protLastRcv    2015-07-11 13:52:02
     2015-07-11 13:49:20   Activity        alive
     2015-07-11 13:50:52   CommandAccepted yes
     2015-07-11 13:50:52   PairedTo        0x376514
     2015-07-11 13:44:46   R-btnLock       off
     2015-07-11 13:44:46   R-burstRx       on
     2015-07-11 13:44:46   R-cyclicInfoMsg on
     2015-07-11 13:44:46   R-cyclicInfoMsgDis 0
     2015-07-11 13:44:46   R-globalBtnLock off
     2015-07-11 13:44:46   R-localResDis   off
     2015-07-11 13:44:46   R-lowBatLimitRT 2.2 V
     2015-07-11 13:44:46   R-modusBtnLock  off
     2015-07-11 13:44:46   R-pairCentral   0x376514
     2015-07-11 13:50:52   RegL_00:          01:01 02:01 09:01 0A:37 0B:65 0C:14 0F:00 11:00  12:16 16:00 18:00 19:00 1A:00 00:00
     2015-07-11 13:47:18   batteryLevel    2.7
     2015-07-11 13:47:18   desired-temp    6.0
     2015-07-11 13:47:18   measured-temp   26.7
     2015-07-11 13:51:10   state           CMDs_done
     Regl_07::
       VAL
   Helper:
     HM_CMDNR   216
     cSnd       0137651431FE9002040000000008,0137651431FE9002040000000009
     mId        00AD
     rxType     6
     Io:
       newChn     +31FE90,00,01,00
       nextSend   1436615522.6115
       rxt        0
       vccu       vccu
       p:
         31FE90
         00
         01
         00
       prefIO:
         HMLAN2
     Mrssi:
       mNo        D8
       Io:
         HMLAN1     -94
         HMLAN2     -62
     Prt:
       awake      0
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rssi:
       At_hmlan1:
         avg        -93.65
         cnt        200
         lst        -94
         max        -87
         min        -99
       At_hmlan2:
         avg        -64
         cnt        216
         lst        -64
         max        -64
         min        -64
       At_hmlan3:
         avg        -103.833333333333
         cnt        6
         lst        -104
         max        -102
         min        -105
     Shregw:
       07         02
     Shadowreg:
Attributes:
   IODev      HMLAN2
   IOgrp      vccu:HMLAN2
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   event-on-change-reading .*
   expert     2_full
   firmware   1.1
   group      WAND-THERMOSTATE
   ignore     0
   model      HM-TC-IT-WM-W-EU
   msgRepeat  1
   room       Devices
   serialNr   LEQ0998921
   subType    thermostat
   webCmd     getConfig:clear msgEvents

Was ich probiert habe (siehe anhängendes Logfile, achtung reverseLog):
- habe das 'ignore' attr am devices og_ez_wandthermostat deleted
- habe auf allen 3 HMLAN's 'logIDs sys,og_ez_wandthermostat' gesetzt und global verbose 1
- habe ein notify erstellt welchen zusätzlich alle Events des Devices logt
- Habe um 13:44:30 ein 'set og_ez_wandthermostat clear all' gemacht
- Habe um 13:44:45 manuell ein 'getConfig' angestoßen
- Um 13:45:03  hat mein notify: 'CMDs_done' geloggt, einen Fehler konnte ich nicht erkennen.
- Um 13:45:51  ist das 1. mal automatisch das getConfig wieder angesprungen
- Um 13:46:10  hat mein noitfy: 'CMDs_done_Errors:1' gemeldet, heute vormittag ist mir das ohne das ntfy noch nicht aufgefallen...
- Um 13:50:51  ist das 2. mal automatisch das getConfig angesprungen
- Um 13:51:09  hat mein notify wieder 'CMDs_done_Errors:1' gemeldet, ist hier ein Muster zu erkennen?
- Habe ein list erstellt und dieses Beitrag geschrieben 

Hoffe du kannst aus dem Logfile was erkennen, viel sonstiger Müll sollte nicht drin sein, sind allerdings trotzdem einige Zeilen geworden...
Danke schonmal

Edit:
- in dem list ist autoreadreg 4 drin,  habe aber auch schon mit 0, und reboot, redefine usw. rumgetestet, hat aber nicht geholfen.

[rapster]

Habe heute nochmal probiert, heute laufen die getConfigs allerdings ohne Errors druch, die wiederholung von 5 Min bleibt aber:

Code Auswählen Erweitern

2015.07.13 17:46:42.395 1: ntfy_test_WT:CMDs_pending
2015.07.13 17:46:42.398 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.13 17:46:59.978 1: ntfy_test_WT:CMDs_done
2015.07.13 17:51:42.069 1: ntfy_test_WT:CMDs_pending
2015.07.13 17:51:42.072 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.13 17:51:59.856 1: ntfy_test_WT:CMDs_done

Gibt es noch irgendwas was ich tun/versuchen kann?

[frank]

so wie es aussieht, bist du wohl der einzige mit diesem problem. ansonsten hätten schon mehrere über overload berichtet. demnach kann es eigentlich nicht an cul_hm liegen.

nochmal zu delete. du hast alle channel und das device mit delete <device> gelöscht? dann save gemacht? danach am besten shutdown restart. dann musst du wohl nur das device in den anlernmodus bringen und  getconfig manuell starten.
oder versuche das in der db vorhandene device (plus alle channel) über edit DEF eine willkürliche hmid=111111 zu geben und auf ignore setzen. dann das reale device neu definieren. vielleicht kann man so die db überlisten. denn wer weiss, ob sie nach delete wirklich alles entfernt.

zu hminfo configcheck hast du dich nicht geäussert. was wird da berichtet?

zu deinem list vom device. ich habe auch kein dblog, deswegen ein paar "dumme" fragen:
sollten unter helper->dblog eigentlich alle readings auftauchen? wenn du mit den readings vergleichst, fehlen einige. besonders auffällig: pairedTo und RegL_00. wie sieht das bei deinen anderen, funktionierenden devices aus? 
dann, im reading von RegL_00: gibt es zwischen "11:00" und "12:00" 2 leerzeichen. seltsam.
unter dem reading state gibt es eine zeile mit "Regl_07::". müsste hier das reading der liste erscheinen? ich habe auch kein tc-it. 

ansonsten macht das verhalten ja den eindruck, dass cul_hm irgend etwas vermisst. das getconfig wird mit cmds_done erfolgreich vermeldet, aber die daten gehen wohl verloren. machst du nach einem erfolgreichen getconfig auch save? danach vielleicht mal einen restart.

anstatt auf ignore zu setzen, würde ich vielleicht attr dummy probieren, dann kannst du eventuell die devices noch ein wenig nutzen/beobachten ohne overload gefahr.

zum schluss könntest du noch versuchen die vccu für dieses device zu canceln. also attr IOgrp löschen. dann sollte attr IODev wirken.

gruss frank

[rapster]

Hi Frank,

danke erstmal für deine Tipps!

zu hminfo configcheck hast du dich nicht geäussert. was wird da berichtet?

ConfigCheck läuft sauber durch.

zu deinem list vom device. ich habe auch kein dblog, deswegen ein paar "dumme" fragen:
sollten unter helper->dblog eigentlich alle readings auftauchen? wenn du mit den readings vergleichst, fehlen einige. besonders auffällig: pairedTo und RegL_00. wie sieht das bei deinen anderen, funktionierenden devices aus? 
dann, im reading von RegL_00: gibt es zwischen "11:00" und "12:00" 2 leerzeichen. seltsam.
unter dem reading state gibt es eine zeile mit "Regl_07::". müsste hier das reading der liste erscheinen? ich habe auch kein tc-it. 

Das mit DbLog ist eine gute Frage, das Problem mit den TC-IT's trat allerdings schon vor der Nutzung von DbLog auf, also dürfte es damit nichts zutun haben.
Das Regl_07 leer ist, ist mir auch schon aufgefallen, das scheint glaube ich allerdings normal zu sein?

ansonsten macht das verhalten ja den eindruck, dass cul_hm irgend etwas vermisst. das getconfig wird mit cmds_done erfolgreich vermeldet, aber die daten gehen wohl verloren. machst du nach einem erfolgreichen getconfig auch save? danach vielleicht mal einen restart.

Save ganz klar, das ist in Fleisch und Blut übergegangen nach einer Konfigänderung
Restarts nach jedem einzelnen Schritt hatte ich auch probiert.

anstatt auf ignore zu setzen, würde ich vielleicht attr dummy probieren, dann kannst du eventuell die devices noch ein wenig nutzen/beobachten ohne overload gefahr.

Danke für den Tipp!


JETZT ABER MAL ZUM FAZIT:

nochmal zu delete. du hast alle channel und das device mit delete <device> gelöscht? dann save gemacht? danach am besten shutdown restart. dann musst du wohl nur das device in den anlernmodus bringen und  getconfig manuell starten.

zum schluss könntest du noch versuchen die vccu für dieses device zu canceln. also attr IOgrp löschen. dann sollte attr IODev wirken.

Habe ich grad nochmal genau nach deinem beschriebenen Vorgehen gemacht.
Nachdem das Gerät von autocreate mit dem default Namen und ohne Attr IOgrp angelegt wurde, scheint es jetzt wieder zu funktionieren, kein getConfig nach dem fhem-start, kein sich wiederholendes getConfig, manuelles getConfig allerdings problemlos.

Als ich das delete das erste mal probierte, habe ich es nach einem restart manuell wieder angelegt, und dies nicht von autocreate erledigen lassen, dadurch habe ich auch alle Attribute wieder mitgenommen.

Werde jetzt erstmal das Device wieder richtig renamen, meine Attribute sowie vccu setzen, und beobachten ob sich das Verhalten nach irgend einer dieser Konfig-Änderungen wiederholt oder ein Unterschied zwischen  dem neuen & alten list erkennbar ist.
Gebe anschließend nochmals bescheid.

Bis dahin schonmal vielen Dank an Dich und Martin

Gruß

[rapster]

Hallo Zusammen,

so, Problem erkannt, Problem gebannt?

Das komische getConfig-Verhalten wird durch den Device u./o. Channel-Namen hervorgerufen.

Folgende Namen lösen ein sich wiederholendes getConfig aus:

Code Auswählen Erweitern

device dg_wz_wandthermostat
channel_01 dg_wz_wandthermostat_Weather
channel_02 dg_wz_wandthermostat_Climate
channel_03 dg_wz_wandthermostat_WindowRec
channel_06 dg_wz_wandthermostat_remote
channel_07 dg_wz_wandthermostat_SwitchTr

Mit diesen Namen ist nun kein Problem mehr vorhanden:

Code Auswählen Erweitern

device dg_wz_wt
channel_01 dg_wz_wt_Weather
channel_02 dg_wz_wt_Climate
channel_03 dg_wz_wt_WindowRec
channel_06 dg_wz_wt_remote
channel_07 dg_wz_wt_SwitchTr

Jetzt ist natürlich die Frage warum das ganze so ist, und wo hier nach einem Fehler gesucht werden muss...

Den Fehler kann ich jetzt natürlich für mich erstmal durch Anpassung der Namen umgehen.


Danke und Gruß
Claudiu

[LuckyDay]

jaaaaa, da war doch etwas wegen zu langer Namen , glaube länger als 32 Zeichen? ,
ich sag weiter nichts dazu

[rapster]

Ja diese standardmäßige Begrenzung beim anlegen von configDB und DbLog auf 32 Zeichen ist einfach nur Katastrophal, keine Ahnung wie man sich darauf versteifen konnte.

Allerdings denke ich wird dies hier nicht das Problem sein, weil:
1. der längste Bezeichner ist hier 'dg_wz_wandthermostat_WindowRec" mit 31 Zeichen
2. Habe ich meine SQL-Table manuell angelegt ohne jegliche Begrenzungen
3. Würde die verwendete SQLite DB so oder so keine Begrenzung kennen,
4. (Hat hier zwar nichts damit zutun) Habe die Angabe welche DbLog für das substr() verwendet ebenfalls erhöht.
5. Andere HM-devices (auch mit noch längerem Namen, z.B. 'og_schlieserschnittstelle_haustuer' mit 35 Zeichen) funktionieren???

[frank]

die namen, die nicht funktionieren, sind doch von anfang an die selben. oder nicht? vielleicht gibt es so etwas wie einen cache und es wird immer die alte version benutzt. wenn du auch configdb nutzt, da gibt es doch eine versions historie.

gruss frank

[rapster]

ja, Versionierung der Konfig gibts, nur von einem Cache wüsste ich nichts.

Habe zwar 100 Versionen bei mir konfiguriert, es ist(sollte) zumindest ja immer nur Version 0 der Konfig aktiv sein.

Auf jedenfall verdammt komischer Fehler, hätte nicht erwartet dass es am Namen liegt...

Gruß Claudiu