Fibaro Motion Sensor: (Reported) State bleibt auf open

[pairo]

Hallo,

habe leider einige Probleme mit meiner FHEM-Umgebung.
Einer meiner Sorgen-Sensoren ist der Fibaro Motion Sensor (erstere Generation).

Habe ein DOIF gestern gebaut, damit wenn eine Bewegung erkannt wird, es finster und jemand zuhause ist, das Licht an geht.
Hat soweit funktioniert, jedoch dürfte heute das Licht die ganze Zeit angeblieben sein, weil der state nach wie vor auf open ist.
Auch der letzte Wakeup ist um 09:53 Uhr erfolgt, trotz zweistündigen Intervalls - dh. 11:53 und 13:53 wurden ausgelassen.

Lux, Temperatur werden aber nach wie vor munter gesendet...

Code Auswählen Erweitern

Internals:
   DEF        e349cd07 2
   IODev      ZSTICK
   LASTInputDev ZSTICK
   MSGCNT     124
   NAME       KU_motion_sensor
   NR         21
   STATE      open
   TYPE       ZWave
   ZSTICK_MSGCNT 124
   ZSTICK_RAWMSG 00041002063105030a0073
   ZSTICK_TIME 2017-01-11 14:58:02
   ZWaveSubDevice no
   homeId     e349cd07
   isWakeUp   1
   nodeIdHex  02
   Readings:
     2017-01-11 13:54:59   alarm_type_00   level 255 node 2 seconds 0
     2016-06-07 07:40:16   alarm_type_03   level 0a
     2016-12-24 01:13:11   alarm_type_10   level 255 node 2 seconds 0
     2016-03-28 15:14:37   assocGroup_1    Max 5 Nodes
     2016-03-28 15:14:37   assocGroup_2    Max 5 Nodes
     2016-03-28 15:14:37   assocGroup_3    Max 1 Nodes ZWDongle_0
     2016-03-28 15:14:34   assocGroups     3
     2016-10-25 05:10:26   barometricPressure 19.6 kPa
     2016-12-15 21:14:33   basicReport     255
     2017-01-09 21:39:29   battery         100 %
     2016-12-26 14:39:07   cmdGet          wakeupInterval
     2016-12-30 02:53:21   configAmbientIlluminationLevelAbove83 1000
     2016-04-01 22:06:36   configAmbientIlluminationLevelBelow82 100
     2016-04-01 22:06:36   configBASICOFFCommandFrameValue 0
     2016-12-30 02:53:22   configBASICONCommandFrameValue 255
     2016-12-30 02:53:23   configBasicCommandClassFrames12 BASICONAndBASICOFFCommandFrames0
     2016-12-30 02:53:23   configIlluminationReportThreshold 200
     2016-12-30 02:53:24   configIlluminationReportsInterval 900
     2016-12-30 02:53:24   configIntervalOfTemperatureMeasuring 900
     2016-12-30 02:53:24   configLEDBrightness 50
     2016-12-30 02:53:24   configLEDIndicatingTamperAlarm LEDDoesNotIndicateTamperAlarm
     2016-12-30 02:53:24   configLEDSignalingMode LongBlinkThenShortBlinkLEDColour10
     2016-12-30 02:53:25   configMaximumTemperatureResultingInRed87 28
     2016-04-01 22:06:38   configMinimumTemperatureResultingIn86 18
     2016-12-30 06:54:10   configMotionAlarmCancellationDelay 30
     2016-04-01 22:06:38   configMotionSensorSBlindTime2 15
     2016-04-01 22:06:39   configMotionSensorSSensitivity 10
     2016-12-30 06:54:10   configNightDay  200
     2016-04-01 22:06:39   configPIRSensorOperatingMode PIRSensorAlwaysActive
     2016-04-01 22:06:39   configPIRSensorSPulseCounter 1
     2016-12-30 08:54:35   configPIRSensorSWindowTime 12Seconds
     2016-04-01 22:06:39   configTamperAlarmBroadcastMode TamperAlarmIsNotSentInBroadcast0
     2016-12-30 08:54:39   configTamperAlarmCancellationDelay 30
     2016-12-30 12:55:11   configTamperOperatingModes Tamper
     2016-12-30 12:55:12   configTamperSensitivity 15
     2016-12-30 12:55:12   configTemperatureOffset 0
     2016-12-30 12:55:12   configTemperatureReportThreshold 10
     2016-12-30 12:55:12   configTemperatureReportsInterval 900
     2017-01-10 12:03:10   generalPurpose  505
     2017-01-11 14:58:02   luminance       115 Lux
     2016-04-06 18:47:13   mcaSupportedGroupings 2
     2016-04-06 18:47:17   model           FIBARO System FGMS001 Motion Sensor
     2016-04-06 18:47:17   modelConfig     fibaro/fgms.xml
     2016-04-06 18:47:17   modelId         010f-0800-1001
     2017-01-11 06:06:41   reportedState   open
     2017-01-11 06:06:41   state           open
     2017-01-11 14:55:11   temperature     20.2 C
     2017-01-11 09:53:29   timeToAck       0.070
     2017-01-11 09:53:29   transmit        OK
     2016-04-06 18:47:14   version         Lib 3 Prot 3.67 App 2.7 HW 1 FWCounter 1 FW 2.7
     2017-01-11 09:53:24   wakeup          notification
     2016-04-06 18:47:17   wakeupReport    interval 7200 target 1
   SendStack:
     get:13020285052501
     get:13020220022502
     get:13020284052503
     get:1302037005532504
     get:1302037005522505
     get:1302037005102506
     get:13020370050e2507
     get:13020370050c2508
     get:1302037005282509
     get:13020370052a250a
     get:13020370053e250b
     get:130203700551250c
     get:130203700559250d
     get:130203700550250e
     get:130203700557250f
     get:1302037005562510
     get:1302037005062511
     get:1302037005022512
     get:1302037005012513
     get:1302037005092514
     get:1302037005082515
     get:1302037005032516
     get:1302037005042517
     get:13020370051a2518
     get:1302037005162519
     get:130203700518251a
     get:130203700514251b
     get:130203700542251c
     get:13020370053c251d
     get:130203700540251e
     set:13020485010101251f
Attributes:
   IODev      ZSTICK
   classes    SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM BASIC
   group      Sensor
   icon       people_sensor
   room       1.2_Kueche

Im Einsatz ist ein aeotec z-stick.

Danke schon mal für eure Unterstützung,

LG
pairo

[pairo]

Bin jetzt zuhause und habe den Wakeup manuell angestoßen, aber der sendstack wird nicht abgearbeitet und auch der Wert von wakeup wird nicht aktualisiert...

Code Auswählen Erweitern

cGroup_3    Max 1 Nodes ZWDongle_0
     2016-03-28 15:14:34   assocGroups     3
     2016-10-25 05:10:26   barometricPressure 19.6 kPa
     2017-01-11 15:55:13   basicReport     0
     2017-01-11 20:33:38   battery         74 %
     2016-12-26 14:39:07   cmdGet          wakeupInterval
     2017-01-11 17:55:47   configAmbientIlluminationLevelAbove83 1000
     2016-04-01 22:06:36   configAmbientIlluminationLevelBelow82 100
     2017-01-11 17:55:49   configBASICOFFCommandFrameValue 0
     2016-12-30 02:53:22   configBASICONCommandFrameValue 255
     2016-12-30 02:53:23   configBasicCommandClassFrames12 BASICONAndBASICOFFCommandFrames0
     2016-12-30 02:53:23   configIlluminationReportThreshold 200
     2016-12-30 02:53:24   configIlluminationReportsInterval 900
     2017-01-11 17:55:53   configIntervalOfTemperatureMeasuring 900
     2017-01-11 17:55:53   configLEDBrightness 50
     2016-12-30 02:53:24   configLEDIndicatingTamperAlarm LEDDoesNotIndicateTamperAlarm
     2017-01-11 17:55:54   configLEDSignalingMode LEDInactive
     2017-01-11 19:56:11   configMaximumTemperatureResultingInRed87 28
     2016-04-01 22:06:38   configMinimumTemperatureResultingIn86 18
     2016-12-30 06:54:10   configMotionAlarmCancellationDelay 30
     2017-01-11 20:29:40   configMotionSensorSBlindTime2 15
     2017-01-11 20:29:40   configMotionSensorSSensitivity 50
     2017-01-11 20:29:41   configNightDay  200
     2016-04-01 22:06:39   configPIRSensorOperatingMode PIRSensorAlwaysActive
     2017-01-11 20:50:51   configPIRSensorSPulseCounter 2Pulses
     2017-01-11 20:50:51   configPIRSensorSWindowTime 12Seconds
     2017-01-11 20:50:51   configTamperAlarmBroadcastMode TamperAlarmIsNotSentInBroadcast0
     2017-01-11 20:50:52   configTamperAlarmCancellationDelay 30
     2017-01-11 20:50:52   configTamperOperatingModes Tamper
     2017-01-11 20:50:54   configTamperSensitivity 15
     2016-12-30 12:55:12   configTemperatureOffset 0
     2016-12-30 12:55:12   configTemperatureReportThreshold 10
     2016-12-30 12:55:12   configTemperatureReportsInterval 900
     2017-01-10 12:03:10   generalPurpose  505
     2017-01-11 21:02:44   luminance       0 Lux
     2016-04-06 18:47:13   mcaSupportedGroupings 2
     2016-04-06 18:47:17   model           FIBARO System FGMS001 Motion Sensor
     2016-04-06 18:47:17   modelConfig     fibaro/fgms.xml
     2016-04-06 18:47:17   modelId         010f-0800-1001
     2017-01-11 20:36:34   neighborList    ZSTICK
     2017-01-11 21:16:45   reportedState   open
     2017-01-11 21:16:45   state           open
     2017-01-11 21:02:45   temperature     25.8 C
     2017-01-11 20:50:54   timeToAck       0.176
     2017-01-11 20:50:54   transmit        OK
     2016-04-06 18:47:14   version         Lib 3 Prot 3.67 App 2.7 HW 1 FWCounter 1 FW 2.7
     2017-01-11 19:56:11   wakeup          notification
     2016-04-06 18:47:17   wakeupReport    interval 7200 target 1
   SendStack:
     get:1302037005532501
     get:1302037005522502
     get:1302037005102503
     get:13020370050e2504
     get:13020370050c2505
     get:1302037005282506
     get:13020370052a2507
     get:13020370053e2508
     get:1302037005512509
     get:130203700559250a
     get:130203700550250b
     get:130203700557250c
     get:130203700556250d
     get:130203700506250e
     get:130203700502250f
     get:1302037005012510
     get:1302037005092511
     get:1302037005082512
     get:1302037005032513
     get:1302037005042514
     get:13020370051a2515
     get:1302037005162516
     get:1302037005182517
     get:1302037005142518
     get:1302037005422519
     get:13020370053c251a
     get:130203700540251b
Attributes:
   IODev      ZSTICK
   classes    SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM BASIC
   group      Sensor
   icon       people_sensor
   room       1.2_Kueche

[krikan]

Dann ist die wakeupNotification-Nachricht wohl nicht beim Controller angekommen.
Die neigborList des Sensors ist ziemlich sparsam besetzt. Wenn die Direktverbindung Controller-Sensor nicht kurz ist, hast Du schon ein Problem.

[pairo]

Hallo,

leider nein - habe den Motionsensor soeben 20cm neben dem Stick liegen und da tut sich nix.
Lux, Temp und Co. werden aber brav gemeldet...

[krikan]

Hmm, zu kurz geht auch  . Eigentlich ist mir das alles noch zu "nebelig".

Würde mal einen Neustart von FHEM  durchführen, damit der Sendstack sich leert, verbose 5 am Dongle setzen und dann einmal Assoziation mit Controller kontrollieren.

Betrifft das nur den Sensor oder wie im anderen Thread erwaehnt mehrere Sensoren?

War das vor DOIF-Einbau anders? Ist das DOIF eventuell die Ursache?

Ist das wirklich der alte z-Stick von Aeotec?

[pairo]

Hi,

ich kann nicht sagen warum und weshalb, aber nach mehrmaligen Neustart sowie entfernen der Batterie vom Sensor und abermaligen manuellen Wakeup, als auch anschließenden neighborupdate wo nun mehrere Devices verfügbar sind funktioniert er nun wieder. Habe das Neighborupdate auf allen Devices durchgeführt, was mE. Verbesserungen gebracht hat - so wird statt "TRANSMIT_NO_ACK" bei den Schaltern wieder Lampen angezeigt. Durchaus aber möglich, dass ua. auch als Störungsursache das DOIF Mitanteil hatte (wobei ich nicht verstehen würde, wie ein "set on"-DOIF darauf Auswirkung haben sollte).

Ich werde mal alles genau beobachten und die Kommunikation genau beobachten und mich ggf. nochmals melden.
Danke jedenfalls für den Hinweis mit dem Neighbrupdate .

LG
pairo

[MadMax-FHEM]

Hi,

da hänge ich mich doch mal drauf...

Also ich habe mittlerweile 2 Bewegungsmelder Fibaro, also die "hübschen" Augen...

Liefen eigentlich immer/bislang sehr gut.

Seit kurz vor Weihnachten haben sie aufgehört die Batteriewerte zu liefern.
Also ich habe ein notify auf wakeup und dann die Abfrage der Batteriewerte.
Hat immer gut funktioniert, habe so jeden Tag ca. 1-3 Batteriewerte erhalten...
...am 21.12. morgens von beiden zum letzten Mal...

Das nur so am Rande...

Das eigentlich störende (weil sonst wäre mir das mit den Batteriewerten verm. gar nicht [so schnell] aufgefallen) war, dass das Licht in den Schränken (wo ich per Bewegung das Licht anschalte und dann bei keiner Bewegung mehr wieder ausschalte) nicht mehr zuverlässig aus ging.

Und nicht ganz so häufig auch nicht an...

Ich war auch schon drauf und dran alles mal zu resetten etc.

Bis ich dann bei einiger Suche drauf gekommen bin, nicht mehr "open/closed" zu verwenden sondern den basicSet.

Habe im Log gesehen, dass der basicSet öfter kommt als open/closed...

Also notify von state open|closed auf basicSet 255|0 geändert, seither alles wieder gut...
...bis auf die Batteriewerte, da werde ich mal noch mal analysieren...

Gruß, Joachim

[krikan]

@pairo:
Wenn Du wirklich den "alten" schwarzen AEOTEC Z-Stick 2 haben solltest: der kann afaik wegen des verwendeten SDKs keine Explorer Frames und damit ist neigborUpdate Pflicht.

@MadMax-FHEM:
Ist das die alte oder neue Gen5-Variante? Bei der alten würde ich auf eine unnötige Assoziierung des Controllers mit Gruppe 1 (Gruppe 3 reicht) und eventuellen Telegrammverlusten wegen Funkkollisionen tippen. Auch notifys auf wakeup können zu unnötigen Funkkollisionen führen. Würde dazu mal das Log analysieren.

[MadMax-FHEM]

@MadMax-FHEM:
Ist das die alte oder neue Gen5-Variante? Bei der alten würde ich auf eine unnötige Assoziierung des Controllers mit Gruppe 1 (Gruppe 3 reicht) und eventuellen Telegrammverlusten wegen Funkkollisionen tippen. Auch notifys auf wakeup können zu unnötigen Funkkollisionen führen. Würde dazu mal das Log analysieren.

Hmmm, ich bin nicht sicher, glaube aber (leider) keine Gen5.

Wo/wie sehe ich das??

Ich muss auch gestehen, dass ich hauptsächlich Homematic habe und mich da (sehr) gut auskenne.
Die Fibaro Bewegungsmelder habe ich eigentlich nur, weil meine Freundin die soooo hübsch findet (gut ich auch   und die Homematic Fensterkontakte [die ja auch gehen würden um zu "sehen", ob Schrank auf/zu] ihr nicht gefallen)...

Wie sehe ich in welcher AssocGroup der Controller ist?
Das Reading assocGroups steht auf 3 und bei wakeupReport steht target 1.

Da diese bei meiner Freundin verbaut sind kann ich auch nicht soo leicht nachschauen...

Und das mit dem Batterieauslesen habe ich irgendwo gesehen, dass man auf wakeup ein notify macht und dann den get Batterisstatus absetzt...
...und hat ja auch immer funktioniert (bis kurz vor Weihnachten).

Die Homematic-Geräte schicken ja selbsständig ab und an (oder auch mal öfter) eine Meldung zum Batteriestand...
...ginge das hier auch?

Und seit umstellung von state open|closed auf basicSet 0|255 läuft zumindest die Erkennung für Licht an/aus wieder einwandfrei...

Vielen Dank schon mal und sorry wegen noch mehr Fragen zurück, Joachim

[pairo]

@pairo:
Wenn Du wirklich den "alten" schwarzen AEOTEC Z-Stick 2 haben solltest: der kann afaik wegen des verwendeten SDKs keine Explorer Frames und damit ist neigborUpdate Pflicht.

Nein hab eh den weißen Stick.

Wodurch wird der State eigentlich aktualisiert?
Habe da einige Geräte noch mit einem alten "TRANSMIT_NO_ACK", die aber ohne Probleme ihre Werte melden:

Code Auswählen Erweitern

state TRANSMIT_NO_ACK 2016-05-17 20:16:09

[MadMax-FHEM]

@MadMax-FHEM:
Ist das die alte oder neue Gen5-Variante? Bei der alten würde ich auf eine unnötige Assoziierung des Controllers mit Gruppe 1 (Gruppe 3 reicht) und eventuellen Telegrammverlusten wegen Funkkollisionen tippen. Auch notifys auf wakeup können zu unnötigen Funkkollisionen führen. Würde dazu mal das Log analysieren.

Also ist wohl (leider!?) die alte Variante...

Log analysieren?
Verbose bei was? USB-Stick, Gerät selbst, beides auf 5!?

Aktuell steht im Log (weder fhem noch Gerät beim USB-Stick hab ich noch nicht geschaut) nichts drin was mich auf einen Fehler deuten ließe.
Nach was soll ich da schauen??

Danke, Joachim

[krikan]

Wodurch wird der State eigentlich aktualisiert?

Durch das, was das Modul vorgibt. Bei manchen Geräten in 10_ZWave.pm gibt es keine Vorgabe, dann mit dem Attribut stateFormat anpassen.
Hatte das hier versucht darzustellen. Müsste das evtl. mehr generalisieren. Verbesseungsvorschläge willkommen.

Log analysieren?
Verbose bei was? USB-Stick, Gerät selbst, beides auf 5!?
Nach was soll ich da schauen??

Zunächst würde ich mit "get <device> associationAll" alle Assoziationen abrufen. Wenn bei dem (nicht schlechten) alten Auge <ZWdongle> nicht nur in Assogroup 3, sondern auch in Assogroup 1 steht, würde ich <ZWdongle> mit "associationDel" aus 1 löschen. Das ist überflüssig; notify natürlich wieder anpassen. Dann würde ich ohne trifftigen Grund die Abfragen von "get-battery" herausnehmen. Dadurch spart man sich Funktelegramme, spart eventuell Batterien und verhindert potentiell unnötige Probleme. Ich handle dabei immer nach dem vereinfachenden Motto: Nur notwendige Funknachrichten = wenig Probleme. Man kann mich aber gerne vom Gegenteil überzeugen.  Bspw. kenne ich keinen batteriebetriebenen Sensor, der zur Neige gehende Batterien nicht automatisch über die Assoziationsgruppe des Controllers meldet.

Zur Detail-Analyse von ZWave generell "attr <ZWdongle> verbose 5" setzen. Im Endeffekt kann man zur Anlayse auch für eigene Zwecke das https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F anwenden. Dann im Logfile suchen, wann es "knallt". Häufiges NO_ACK, CAN, TRANSMIT_NO_ACK, resending usw. sind Indizien für weitere Forschungen. Zwar auch nicht immer "böse", aber bei gehäuftem und regelmäßigem Auftreten auf jeden Fall einen genaueren Blick wert.

Obiges schließt aber nicht Gerätedefekte, ungünstige Empfangsbedingungen usw. aus. Es bleibt ein Einzelfallproblem. 

Gruß, Christian

[MadMax-FHEM]

Zunächst würde ich mit "get <device> associationAll" alle Assoziationen abrufen. Wenn bei dem (nicht schlechten) alten Auge <ZWdongle> nicht nur in Assogroup 3, sondern auch in Assogroup 1 steht, würde ich <ZWdongle> mit "associationDel" aus 1 löschen. Das ist überflüssig; notify natürlich wieder anpassen. Dann würde ich ohne trifftigen Grund die Abfragen von "get-battery" herausnehmen. Dadurch spart man sich Funktelegramme, spart eventuell Batterien und verhindert potentiell unnötige Probleme. Ich handle dabei immer nach dem vereinfachenden Motto: Nur notwendige Funknachrichten = wenig Probleme. Man kann mich aber gerne vom Gegenteil überzeugen.  Bspw. kenne ich keinen batteriebetriebenen Sensor, der zur Neige gehende Batterien nicht automatisch über die Assoziationsgruppe des Controllers meldet.

Zur Detail-Analyse von ZWave generell "attr <ZWdongle> verbose 5" setzen. Im Endeffekt kann man zur Anlayse auch für eigene Zwecke das https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F anwenden. Dann im Logfile suchen, wann es "knallt". Häufiges NO_ACK, CAN, TRANSMIT_NO_ACK, resending usw. sind Indizien für weitere Forschungen. Zwar auch nicht immer "böse", aber bei gehäuftem und regelmäßigem Auftreten auf jeden Fall einen genaueren Blick wert.

Obiges schließt aber nicht Gerätedefekte, ungünstige Empfangsbedingungen usw. aus. Es bleibt ein Einzelfallproblem. 

Gruß, Christian

Danke noch mal!

Werde ich mal prüfen/ausführen, wenn ich wieder Zugriff habe...

@pairo: vielleicht hilft bei dir ja auch schon die Umstellung von state auf basicSet. Dieser ist bei closed 0 und bei open 255 (und wie gesagt der kam schon immer öfter als state und seit der Umstellung funktioniert das Auge wieder wie es soll).


Bzgl. Batteriestatus. Es wird ja in Prozent übermittelt und das aber nur, wenn ich den Batterystate "abfrage". Irgendwo im Netz habe ich dann das mit der Abfrage auf wakeup gefunden. Also wakeup macht der Sensor ja eh (er wird ja nicht extra durch mich geweckt) gut ich setze einen Befehl ab und erwarte eine Antwort. Aber 1-3mal am Tag kann nicht so schlimm sein (die Homematic Geräte machen das mit unter alle 3min und die Batterien halten auch).

Der wakeup ist auf Standard (65535)...

Wenn ich sicher weiß/wüßte, dass der Sensor echt meldet, wenn die Batterie zur Neige geht (am besten mit etwas Vorlauf), dann würde ich das wieder raus nehmen.
Blöd nur, wenn ich (bzw. meine Freundin) das erst merken würde, wenn das Auge nichts mehr macht und auch nicht mehr blinkt...
...weil dann ist bestimmt Samstagabend und keine Batterie zur Hand...

Gruß, Joachim

[krikan]

vielleicht hilft bei dir ja auch schon die Umstellung von state auf basicSet.

, bitte nicht...

Neuer Versuch: 
basicSet gibt es afaik nur, wenn beim alten FGMS001 der Controller in der Assogroup 1 aufgenommen ist. Das ist überflüssig.
Der Controller gehört grds. nur in Assogroup 3, die über eine andere Class die gleiche Info wie Assogroup 1 liefert.
Bei Assoziierung mit 1 und 3 können unnötige Störungen wegen der zu vielen Nachrichten entstehen, die vielleicht genau zum bemängelten teilweisen Verlust der Nachrichten aus Assogroup 3 führen.
-> wirkliche Ursache suchen

Gruß, Christian

[MadMax-FHEM]

Ok, ich kontrollier das mal mit den AssocGroups...
Und schau mal ins Log.

Kann aber dauern weil das System nicht bei mir ist...

Warum nicht basicSet?
Habe das auf der Suche nach einer Lösung der Problematik gefunden.
Also dort nicht als Lösung sondern dort wurde generell gleich per basicSet eingebunden...

Gruß, Joachim