Hallo Zusammen,
ich habe mir einen Bewegungmelder gekauft und mit meinem HMLAN1 Adapter gepaart.
Allerdings ist die Entfernung zum Adapter recht weit und somit der rssi Wert sehr schlecht und der Bewegungmelder konnte
im Schnitt nur jedes Zweite mal seine Nachricht beim HMLAN1 los werden.
Da ich in der Nähe LAN habe und eh weitere Homematic Geräte in Betrieb setzen wollte habe ich mir einen weiteren HMLAN Adapter gakauft und
in Betrieb genommen. Ich verwende für beide HMLAN Adapter die Gleiche HmId.
Die rssi Werte sind folgendermassen:
g_bw_Carport :HMLAN1 g_bw_Carport -92.0 -94.5 -99.0< -88.0 137
g_bw_Carport :HMLAN2 g_bw_Carport -59.0 -60.7 -62.0< -58.0 139
Also HMLAN2 hat klar die besseren Werte.
Trotzdem ich den Bewegungmelder per IODev auf HMLAN2 fest gezurrt habe sendet der immer wieder mal auch an HMLAN1,
wie man im LogFile schön sehen kann.
2014-10-19_19:47:37 g_bw_Carport motion
2014-10-19_19:47:37 g_bw_Carport motion: on (to HMLAN2)
2014-10-19_19:47:37 g_bw_Carport motionCount: 225_next:4-15
2014-10-19_19:47:56 g_bw_Carport motion
2014-10-19_19:47:56 g_bw_Carport motion: on (to HMLAN2)
2014-10-19_19:47:56 g_bw_Carport motionCount: 226_next:4-15
2014-10-19_20:35:33 g_bw_Carport motion
2014-10-19_20:35:33 g_bw_Carport motion: on (to HMLAN1)
2014-10-19_20:35:33 g_bw_Carport motionCount: 227_next:4-15
2014-10-19_22:04:57 g_bw_Carport motion
2014-10-19_22:04:57 g_bw_Carport motion: on (to HMLAN1)
2014-10-19_22:04:57 g_bw_Carport motionCount: 228_next:4-15
2014-10-19_22:41:24 g_bw_Carport motion
2014-10-19_22:41:24 g_bw_Carport motion: on (to HMLAN1)
2014-10-19_22:41:24 g_bw_Carport motionCount: 229_next:4-15
Muss ich den Bewegeungsmelder erneut mit dem HMLAN2 paaren, da ich diesen zuerst mit HMLAN1 angelernt hatte da es noch keinen HMLAN2 gab?
Oder ist dieses Senden an beide HMLAN Adapter OK und eigentlich kein Problem?
Danke und Gruß, Stefan.
Hallo, richte dir ein vccu ein. Das übernimmt dann automatisch die Auswahl des IO devices. Beispiele findest du im Forum genug.
VG
Frank
Hi Stefan,
ZitatMuss ich den Bewegeungsmelder erneut mit dem HMLAN2 paaren, da ich diesen zuerst mit HMLAN1 angelernt hatte da es noch keinen HMLAN2 gab?
Genau, du musst per "unpair" den Melder vom HMLAN1 abmelden und dann neu mit HMLAN2 pairen. Warum?: Beim pairen bekommt der Melder gesagt, an welches Interface er seine Telegramme schicken soll und von wo er ggf. das "ack" bekommt. Das wird fest im Melder gespeichert. Die Änderung des IODEV bekommt er aber nicht mit und sendet so immer noch zum HMLAN1. Das senden FHEM -> Melder erfolgt jedoch (durch das IODEV) schon über HMLAN2. In umgekehrter Richtung empfangen ggf. beide HMLAN die Signale, aber nur die des HMLAN2 werden in FHEM verwendet.
Gruß
Frank
Edit: Ah ja, gute Idee Franky! @Stefan: Du pairst dann nicht mehr mit einem bestimmten HMLAN, sondern immer mit der VCCU.
ZitatGenau, du musst per "unpair" den Melder vom HMLAN1 abmelden und dann neu mit HMLAN2 pairen. Warum?: Beim pairen bekommt der Melder gesagt, an welches Interface er seine Telegramme schicken soll und von wo er ggf. das "ack" bekommt. Das wird fest im Melder gespeichert.
das ist falsch.
der melder wird mit einer zentrale (hmid) gepairt, nicht mit einem io. da beide io die selbe hmid haben, muss nichts neu gepairt werden. dadurch ändert sich ja nichts, da der melder die hmid speichert und diese die selbe ist. die messages vom melder werden zunächst einmal von allen io empfangen, die in reichweite und gerade auch in der lage dazu sind.
gruss frank
Ah- na klar, du hast Recht. Ist ja die gleiche ID. :-X ;)
Wenn zwei HMLAN die gleiche ID haben, dann empfangen auch beide die Meldung vom BM (je nach Reichweite) und schicken sie an FHEM weiter. Hier werden dann ggf. Duplikate eliminiert. Die Einträge im Logfile geben nicht immer die Wahrheit wieder. Martin hatte irgendwo mal geschrieben, dass er auch aus diesem Grund die Verwendung einer virtuellen CCU propagiert. Da steht im Log dann "motion: on (to CCU)" und gut is.
Wow,
danke für Eure super schnellen Antworten.
Bin nun allerdings etwas verunsichert, da im WIKI steht, dass das Thema VCCU komplex und bedeutend genug für einen eigenen Eintrag ist.
Dieser Eintrag fehlt aber noch und in der Command.ref ist auch nur wenig zu finden. ::)
Das was ich Forum finden konnte war auch nicht wirklich eindeutig.
Martin hat in einem Thread noch geschrieben, dass es empfohlen ist die hmId des Adapter zu verwenden und keine eigene zu vergeben.
Zitat:"Wenn du did hmid des hmlan nimmst (eh empfohlen )..."
Ich versuche mal zusammen zu fassen was ich bis dahin verstanden habe.
Ich definiere meine beiden HMLAN Adapter mit der gleichen, selbst vergebenen hmId:
define HMLAN1 HMLAN 192.168.1.150:1000
attr HMLAN1 hmId 0506AB
attr HMLAN1 hmKey 01:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 room Server
define HMLAN2 HMLAN 192.168.1.151:1000
attr HMLAN2 hmId 0506AB
attr HMLAN2 hmKey 01:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
attr HMLAN2 hmLanQlen 1_min
attr HMLAN2 room Server
Reicht es dann aus die VCCU als virtuelles device zu definieren ala...
define myVCCU CUL_HM 0506AB
attr myVCCU model CCU-FHEM
und sollte der Hex Wert (ich vermute eine Art hmID) die gleiche wie bei den HMLAN1/2 Adaptern sein?
Was ist mit den bereits angelernten devices (etliche Rolladenschalter, ein paar Dimmer) die bereits an HMLAN1 angelernt sind?
Muss ich diese Aktoren neu anlernen?
So ganz klar ist mir das Alles noch nicht.
Oder wäre es vielleicht besser (weniger Aufwand) den HMLAN2 mit einer anderen hmId zu versehen
und nur die Geräte die von diesem Adapter besser versorgt werden können explizit mit dem zu paaren.
Danke, Stefan.
Hallo,
da fehlt doch nix
http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU (http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU)
oder hab ich was übersehen?
Grüße
Edith. Die Seite bekomme ich auch wenn ich im Wiki im Suchfeld VCCU eingebe ???
Hallo puschel74,
Du hast Recht der Eintrag im Wiki sieht gut aus, muß ich mir nachher mal ansehen.
Ich bin nach Google Benutzung hier gelandet und dort steht nicht viel zur vccu... http://www.fhemwiki.de/wiki/CUL_HM
Vg Stefan.
Hallo,
ZitatIch bin nach Google Benutzung hier gelandet und dort steht nicht viel zur vccu...
Daher sollte auch ab und zu mal die Forums- oder Wikieigene Suchfunktion getestet werden ;)
Grüße
Hallo Zusammen,
so hab jetzt endlich mal Zeit gefunden das Thema weiter zu betrachten.
Ich habe da noch eine Frage:
Wenn ich das nach dem lesen der Wiki Eintrags und einiger Posts hier im Forum richtig verstanden habe,
dann wäre es sinnvoll der VCCU die HM-ID zu vergeben, die ich heute für die HMLAN Adpater verwende und den HMLAN Adaptern dann neue HM-ID's.
Dadurch erspare ich mir ein erneutes Anlernen der bereits bestehenden HM Devices.
Habe ich das so richtig verstanden?
Möchte mir ungern mein bestehendes System mehr als nötig durcheinander bringen.
Danke, Stefan.
Zitatdann wäre es sinnvoll der VCCU die HM-ID zu vergeben,
unbedingt
Zitatund den HMLAN Adaptern dann neue HM-ID's
hä?
IOs die der vccu "gehören" haben deren HMID. Müssen sie auch. Ändern kannst du das nicht (so lange sie der vccu gehören, also in ihrer Liste auftauchen)
an den IOs musst du nichts machen, macht die vccu.
ZitatDadurch erspare ich mir ein erneutes Anlernen der bereits bestehenden HM Devices.
korrekt
ZitatMöchte mir ungern mein bestehendes System mehr als nötig durcheinander bringen.
bringst du nicht.
ausserdem: Sichere dein fhem.cfg (regelmäßig) dann kannst du es ggf wieder einspielen
Hallo Martin,
danke für die Klarstellung werde die VCCU mal einrichten und berichten.
VG, Stefan.
Noch eine letzte Frage:
Ich verwende derzeit 2 x HMLAN.
Sollten ich den 2 Adaptern den gleinchen hmKey geben?
Danke, Stefan.
Du meinst die HM ID, die muss gleich sein. Also für vccu sowie die zwei HMLAN.
P.S. hmkey muss für beide HMLAN auch gleich sein, denn je nach dem welches IO device eine Message empfängt muss beiden IO Devices der key bekannt sein
.
Hallo Franky08,
ich meinte schon den hmKey, dass die hmId gleich sein muss habe ich schon gelesen.
Danke, Stefan.
So habe mal die VCCU eingerichtet und FHEM aktualisiert.
Auf den ersten Blick läuft alles gut, auf den zweiten Blick doch nicht so ganz.
Die HMLAN Adapter und die VCCU sind folgendermassen definiert.
define HMLAN1 HMLAN 192.168.1.150:1000
attr HMLAN1 hmId 0506AB
attr HMLAN1 hmKey 01:xyz
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 room Server
define HMLAN2 HMLAN 192.168.1.151:1000
attr HMLAN2 hmId 0506AB
attr HMLAN2 hmKey 01:xyz
attr HMLAN2 hmLanQlen 1_min
attr HMLAN2 room Server
define VCCU CUL_HM 0506AB
attr VCCU IODev HMLAN2
attr VCCU IOList HMLAN1,HMLAN2
attr VCCU model CCU-FHEM
attr VCCU room Server
attr VCCU subType virtual
attr VCCU webCmd virtual:update
Jetzt habe ich ein neuen 4x Schalter angelernt mit...
set VCCU hmPairForSec 600
das Ergebnis per Autocreate ist...
define CUL_HM_HM_LC_SW4_WM_251205 CUL_HM 251205
attr CUL_HM_HM_LC_SW4_WM_251205 IODev HMLAN1
attr CUL_HM_HM_LC_SW4_WM_251205 IOgrp VCCU:HMLAN1
attr CUL_HM_HM_LC_SW4_WM_251205 autoReadReg 4_reqStatus
attr CUL_HM_HM_LC_SW4_WM_251205 expert 2_full
attr CUL_HM_HM_LC_SW4_WM_251205 firmware 1.12
attr CUL_HM_HM_LC_SW4_WM_251205 model HM-LC-SW4-WM
attr CUL_HM_HM_LC_SW4_WM_251205 room CUL_HM
attr CUL_HM_HM_LC_SW4_WM_251205 serialNr KEQ1058411
attr CUL_HM_HM_LC_SW4_WM_251205 subType switch
define FileLog_CUL_HM_HM_LC_SW4_WM_251205 FileLog ./log/CUL_HM_HM_LC_SW4_WM_251205-%Y.log CUL_HM_HM_LC_SW4_WM_
attr FileLog_CUL_HM_HM_LC_SW4_WM_251205 logtype text
attr FileLog_CUL_HM_HM_LC_SW4_WM_251205 room CUL_HM
define CUL_HM_HM_LC_SW4_WM_251205_Sw_01 CUL_HM 25120501
attr CUL_HM_HM_LC_SW4_WM_251205_Sw_01 model HM-LC-SW4-WM
attr CUL_HM_HM_LC_SW4_WM_251205_Sw_01 peerIDs 00000000,
attr CUL_HM_HM_LC_SW4_WM_251205_Sw_01 webCmd statusRequest:toggle:on:off
define CUL_HM_HM_LC_SW4_WM_251205_Sw_02 CUL_HM 25120502
attr CUL_HM_HM_LC_SW4_WM_251205_Sw_02 model HM-LC-SW4-WM
attr CUL_HM_HM_LC_SW4_WM_251205_Sw_02 peerIDs 00000000,
attr CUL_HM_HM_LC_SW4_WM_251205_Sw_02 webCmd statusRequest:toggle:on:off
define CUL_HM_HM_LC_SW4_WM_251205_Sw_03 CUL_HM 25120503
attr CUL_HM_HM_LC_SW4_WM_251205_Sw_03 model HM-LC-SW4-WM
attr CUL_HM_HM_LC_SW4_WM_251205_Sw_03 peerIDs 00000000,
attr CUL_HM_HM_LC_SW4_WM_251205_Sw_03 webCmd statusRequest:toggle:on:off
define CUL_HM_HM_LC_SW4_WM_251205_Sw_04 CUL_HM 25120504
attr CUL_HM_HM_LC_SW4_WM_251205_Sw_04 model HM-LC-SW4-WM
attr CUL_HM_HM_LC_SW4_WM_251205_Sw_04 peerIDs 00000000,
attr CUL_HM_HM_LC_SW4_WM_251205_Sw_04 webCmd statusRequest:toggle:on:off
So weit so gut, alle Kanäle lassen sich über das Webinterface schalten.
Nur bin ich etwas überrascht, das als IODev und als IOGrp jeweils HMLAN1 eingetragen wurde.
attr CUL_HM_HM_LC_SW4_WM_251205 IODev HMLAN1
attr CUL_HM_HM_LC_SW4_WM_251205 IOgrp VCCU:HMLAN1
Da HMLAN2 fast direkt neben dem 4x Schalter ist wollte ich IODev und IOgrp auf HMLAN2 festlegen. (rssi Werte für HMLAN1 sind > 80)
Gedacht, getan...
attr CUL_HM_HM_LC_SW4_WM_251205 IODev HMLAN2
attr CUL_HM_HM_LC_SW4_WM_251205 IOgrp VCCU:HMLAN2
Jetzt kann ich aber keinen Kanal mehr schalten... :(
Hab mal den HMLAN1 abgezogen, um zu prüfen ob HMLAN2 überhaupt funktioniert.
Das ist der Fall, die Rolladenschalter lassen sich alle über HMLAN2 bedienen, allerdings waren diese auch schon
vor Einrichten der VCCU mit HMLAN1 in Betrieb und ich habe diese nicht neu angelernt.
Habt Ihr einen Tipp für mich? Hätte eigentlich gedacht, dass ein mit der VCCU neu angelerntes Device mit beiden HMLAN Adaptern gesteutert werden kann.
Danke, Stefan.
ZitatHätte eigentlich gedacht, dass ein mit der VCCU neu angelerntes Device mit beiden HMLAN Adaptern gesteutert werden kann.
so sollte es sein.
wie sieht ein list der vccu aus?
list VCCU:
Internals:
CFGFN /opt/fhem/cfg/cuno.cfg
DEF 0506AB
HMLAN1_MSGCNT 1702
HMLAN1_RAWMSG E26BE8D,0000,89572B1E,FF,FFC3,C5861026BE8D0000000AA4E3101F19
HMLAN1_RSSI -61
HMLAN1_TIME 2014-11-09 11:01:21
HMLAN2_MSGCNT 1759
HMLAN2_RAWMSG E26BE8D,0000,02A3967E,FF,FFA4,C5861026BE8D0000000AA4E3101F19
HMLAN2_RSSI -92
HMLAN2_TIME 2014-11-09 11:01:21
IODev HMLAN2
LASTInputDev HMLAN2
MSGCNT 3461
NAME VCCU
NR 158
STATE HMLAN1:ok,HMLAN2:ok,
TYPE CUL_HM
assignedIOs HMLAN1,HMLAN2
lastMsg No:3A - t:02 s:0506AB d:2B584D 00
protLastRcv 2014-11-09 10:10:42
rssi_at_HMLAN1 avg:-81.84 min:-84 max:-80 lst:-83 cnt:59
rssi_at_HMLAN2 avg:-82.6 min:-84 max:-80 lst:-82 cnt:105
Readings:
2014-11-09 10:10:42 CommandAccepted yes
2014-11-09 10:03:31 recentStateType ack
2014-11-07 07:33:32 unknown_236298 received
2014-11-09 11:00:57 unknown_248B43 received
2014-11-09 10:59:40 unknown_248B44 received
2014-11-09 10:59:32 unknown_248B45 received
2014-11-08 22:52:38 unknown_251205 received
2014-11-09 11:01:18 unknown_26B8A0 received
2014-11-09 11:01:21 unknown_26BE8D received
2014-11-09 10:59:31 unknown_26BF85 received
2014-11-09 09:15:23 unknown_272D47 received
2014-11-09 09:15:23 unknown_2CD579 received
Helper:
mId FFF0
rxType 1
Io:
nextSend 1415524242.56521
prefIO
vccu
ioList:
HMLAN1
HMLAN2
Mrssi:
mNo 3A
Io:
HMLAN2 -80
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
vrt 1
Rssi:
At_hmlan1:
avg -81.8474576271187
cnt 59
lst -83
max -80
min -84
At_hmlan2:
avg -82.6095238095238
cnt 105
lst -82
max -80
min -84
Attributes:
IODev HMLAN2
IOList HMLAN1,HMLAN2
model CCU-FHEM
room Server
subType virtual
webCmd virtual:update
war beim list von eben der hmlan2 dem schalter zugewiesen? sieht alles ok aus. noch ein list vom schalter für den fehlerfall vielleicht.
ZitatDa HMLAN2 fast direkt neben dem 4x Schalter ist wollte ich IODev und IOgrp auf HMLAN2 festlegen.
zu dicht gibt auch probleme.
Zitatwar beim list von eben der hmlan2 dem schalter zugewiesen? sieht alles ok aus. noch ein list vom schalter für den fehlerfall vielleicht.
nein, war er nicht.
Hab's mal geändert und anbei die erneuten list Ausgaben.
list VCCU (wobei HMLAN1 vom Netz getrennt):
Internals:
CFGFN /opt/fhem/cfg/cuno.cfg
DEF 0506AB
HMLAN1_MSGCNT 26
HMLAN1_RAWMSG E26BE8D,0000,89CF2443,FF,FFBD,F9861026BE8D0000000AA4E0101F19
HMLAN1_RSSI -67
HMLAN1_TIME 2014-11-09 13:12:22
HMLAN2_MSGCNT 31
HMLAN2_RAWMSG E26BF85,0000,031C758F,FF,FFB7,7E861026BF850000000AA8ED100018
HMLAN2_RSSI -73
HMLAN2_TIME 2014-11-09 13:13:24
IODev HMLAN2
LASTInputDev HMLAN2
MSGCNT 57
NAME VCCU
NR 158
STATE HMLAN1:disconnected,HMLAN2:ok,
TYPE CUL_HM
assignedIOs HMLAN1,HMLAN2
lastMsg No:0D - t:02 s:0506AB d:1B5ED0 00
protLastRcv 2014-11-09 13:11:14
rssi_at_HMLAN1 avg:-83.18 min:-84 max:-82 lst:-83 cnt:22
rssi_at_HMLAN2 avg:-83.44 min:-84 max:-82 lst:-83 cnt:25
Readings:
2014-11-09 13:11:14 CommandAccepted yes
2014-11-09 13:07:45 recentStateType ack
2014-11-07 07:33:32 unknown_236298 received
2014-11-09 13:11:44 unknown_248B43 received
2014-11-09 13:11:31 unknown_248B44 received
2014-11-09 13:11:28 unknown_248B45 received
2014-11-08 22:52:38 unknown_251205 received
2014-11-09 13:12:58 unknown_26B8A0 received
2014-11-09 13:12:22 unknown_26BE8D received
2014-11-09 13:13:24 unknown_26BF85 received
2014-11-09 09:15:23 unknown_272D47 received
2014-11-09 09:15:23 unknown_2CD579 received
Helper:
mId FFF0
rxType 1
Io:
nextSend 1415535075.02826
prefIO
vccu
ioList:
HMLAN1
HMLAN2
Mrssi:
mNo 0D
Io:
HMLAN2 -81
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
vrt 1
Rssi:
At_hmlan1:
avg -83.1818181818182
cnt 22
lst -83
max -82
min -84
At_hmlan2:
avg -83.44
cnt 25
lst -83
max -82
min -84
Attributes:
IODev HMLAN2
IOList HMLAN1,HMLAN2
model CCU-FHEM
room Server
subType virtual
webCmd virtual:update... und list CUL_HM_HM_LC_SW4_WM_251205
Internals:
DEF 251205
IODev HMLAN2
NAME CUL_HM_HM_LC_SW4_WM_251205
NR 1099
STATE MISSING ACK
TYPE CUL_HM
channel_01 CUL_HM_HM_LC_SW4_WM_251205_Sw_01
channel_02 CUL_HM_HM_LC_SW4_WM_251205_Sw_02
channel_03 CUL_HM_HM_LC_SW4_WM_251205_Sw_03
channel_04 CUL_HM_HM_LC_SW4_WM_251205_Sw_04
protCmdDel 6
protResnd 6 last_at:2014-11-09 13:13:30
protResndFail 2 last_at:2014-11-09 13:13:34
protSnd 2 last_at:2014-11-09 13:13:13
protState CMDs_done_Errors:1
Readings:
2014-11-08 23:06:37 CommandAccepted yes
2014-11-08 23:06:36 D-firmware 1.12
2014-11-08 23:06:36 D-serialNr KEQ1058411
2014-11-08 23:06:38 PairedTo 0x506AB
2014-11-08 23:06:38 R-intKeyVisib invisib
2014-11-08 23:06:38 R-pairCentral 0x506AB
2014-11-08 23:06:38 RegL_00: 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:05 0B:06 0C:AB 00:00
2014-11-09 13:13:34 state MISSING ACK
Helper:
cSnd 110506AB2512050201C80000
mId 0066
rxType 1
Io:
newChn +251205,00,01,00
prefIO HMLAN2
rxt 0
vccu VCCU
p:
251205
00
01
00
Mrssi:
mNo
Io:
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
dev 1
Attributes:
IODev HMLAN2
IOgrp VCCU:HMLAN2
autoReadReg 4_reqStatus
expert 2_full
firmware 1.12
model HM-LC-SW4-WM
room CUL_HM
serialNr KEQ1058411
subType switch
webCmd getConfig:clear msgEvents
Was mir noch aufgefallen ist.
Das IODev der VCCU ist HMLAN2?! Warum das und ist das OK?
Zitatzu dicht gibt auch probleme.
Der Aktor ist wirklich nur ca. 50cm vom HMLAN2 Adapter entfernt, werde mal gleich die Disatanz vergrößern und berichten.
Danke, für Deinen Support, Stefan.
Zitatzu dicht gibt auch probleme.
genau das ist das Problem!
Habe mal ein 4 Meter LAN Kabel verwendet und den HMLAN2 Adpter entsprechend weit entfernt, und nun funktioniert es.
Die Bedeutung des IODev der VCCU (=HMLAN2) ist mir trotzdem nicht klar.
Hab mal irgendwo gelesen das bei Verwendung einer VCCU das IODev keine Relevanz hat sondern nur die IOGrp zählt.
Danke und Ciao, Stefan.
ZitatHab mal irgendwo gelesen das bei Verwendung einer VCCU das IODev keine Relevanz hat sondern nur die IOGrp zählt.
fast. bei verwendung von IOgrp spielt IODev keine rolle.