VCCU und IOdev/IOgrp nach Save/Shutdown

[Morgennebel]

Moin Moin,


ich habe eine VCCU mit zwei entfernt stehen HMLAN:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        1A2B3C
   HMLAN1_MSGCNT 14
   HMLAN1_RAWMSG E1A2B3C,0000,15DF5FED,FF,FFB6,9980021A2B3C1A809500
   HMLAN1_RSSI -74
   HMLAN1_TIME 2017-10-07 15:09:29
   HMLAN2_MSGCNT 67
   HMLAN2_RAWMSG E1A2B3C,0000,B7570FBC,FF,FFB7,6C80021A2B3C4486D700
   HMLAN2_RSSI -73
   HMLAN2_TIME 2017-10-07 15:09:33
   IODev      HMLAN2
   LASTInputDev HMLAN2
   MSGCNT     81
   NAME       vccu
   NOTIFYDEV  global
   NR         7
   NTFY_ORDER 50-vccu
   STATE      HMLAN1:ok,HMLAN2:ok,
   TYPE       CUL_HM
   assignedIOs HMLAN1,HMLAN2
   lastMsg    No:6C - t:02 s:1A2B3C d:4486D7 00
   protLastRcv 2017-10-07 15:09:33
   rssi_at_HMLAN1 lst:-74 cnt:14 avg:-74.28 min:-75 max:-74
   rssi_at_HMLAN2 lst:-73 avg:-72.86 max:-72 cnt:67 min:-73
   READINGS:
     2017-10-07 15:09:33   CommandAccepted yes
     2017-10-07 15:06:11   recentStateType ack
     2017-10-07 15:08:51   state           HMLAN1:ok,HMLAN2:ok,
     2016-02-08 21:02:48   unknown_205007  received
     2017-10-05 23:25:55   unknown_280A7B  received
     2016-04-16 19:20:41   unknown_286865  received
     2015-09-12 14:27:52   unknown_295DF4  received
     2015-11-12 11:50:16   unknown_295E12  received
     2015-11-12 11:50:15   unknown_295E13  received
     2015-08-02 13:12:19   unknown_2B34B0  received
     2015-04-25 13:35:27   unknown_2C9B54  received
     2017-10-07 12:06:11   unknown_2C9BF9  received
     2015-12-21 11:13:41   unknown_2E6E52  received
     2015-04-25 12:31:52   unknown_301F53  received
     2015-04-25 12:25:30   unknown_30281F  received
     2015-08-25 18:10:42   unknown_313583  received
     2015-09-12 10:07:26   unknown_319889  received
     2015-11-16 20:18:49   unknown_31991C  received
     2015-09-18 15:05:54   unknown_31D1FD  received
     2015-05-21 20:33:45   unknown_323F16  received
     2016-08-19 09:01:04   unknown_32698B  received
     2016-12-18 15:35:38   unknown_32699B  received
     2015-08-25 18:11:08   unknown_34AFFC  received
     2015-04-25 17:45:34   unknown_35A426  received
     2015-04-25 17:35:27   unknown_35C61D  received
     2015-10-15 10:23:04   unknown_36821F  received
     2015-10-15 10:26:27   unknown_37008D  received
     2015-10-16 13:00:18   unknown_375D5E  received
     2015-10-15 09:19:37   unknown_38E43B  received
     2015-10-15 09:27:59   unknown_38E510  received
     2015-10-17 18:00:45   unknown_38E511  received
     2015-10-15 09:25:16   unknown_38F0FF  received
     2015-08-16 21:29:40   unknown_39DA87  received
     2017-08-14 13:38:55   unknown_3AC7D0  received
     2015-09-19 19:27:09   unknown_3BD11A  received
     2015-11-14 15:58:55   unknown_3BD1D5  received
     2015-10-16 09:19:14   unknown_3BD1F4  received
     2016-04-06 17:44:30   unknown_3DA3B8  received
     2016-04-16 18:44:35   unknown_3ECCC1  received
     2015-12-30 11:43:53   unknown_3F2D76  received
     2015-12-31 14:25:30   unknown_3F2DCE  received
     2015-12-30 18:37:45   unknown_3F2E6A  received
     2016-05-03 15:29:47   unknown_3FB679  received
     2016-05-03 15:34:26   unknown_3FB78D  received
     2016-05-03 15:06:14   unknown_3FB8BF  received
     2016-04-10 17:44:32   unknown_4063D8  received
     2016-08-13 17:32:13   unknown_4486D7  received
     2017-09-09 20:08:28   unknown_44FEA4  received
     2016-10-19 14:28:41   unknown_45786F  received
     2017-08-14 13:40:46   unknown_45EBEB  received
     2017-01-31 15:56:53   unknown_4656DC  received
     2016-11-15 19:41:44   unknown_4B7D83  received
     2017-03-24 15:12:34   unknown_50BACE  received
     2017-09-18 11:29:56   unknown_50E2F0  received
     2017-10-06 11:14:12   unknown_58AF99  received
     2016-11-22 18:00:54   unknown_A0011A  received
     2016-12-03 23:01:59   unknown_A0111A  received
     2016-12-03 23:04:55   unknown_A1121A  received
     2017-05-03 03:58:15   unknown_FFFFFF  received
   helper:
     HM_CMDNR   108
     mId        FFF0
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     io:
       nextSend   1507381774.01961
       prefIO
       vccu
       ioList:
         HMLAN1
         HMLAN2
     mRssi:
       mNo        6C
       io:
         HMLAN2     -71
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf
       qReqStat
     role:
       chn        1
       dev        1
       vrt        1
     rssi:
       at_HMLAN1:
         avg        -74.2857142857143
         cnt        14
         lst        -74
         max        -74
         min        -75
       at_HMLAN2:
         avg        -72.865671641791
         cnt        67
         lst        -73
         max        -72
         min        -73
     tmpl:
Attributes:
   IODev      HMLAN2
   IOList     HMLAN1,HMLAN2
   model      CCU-FHEM
   room       SYS_Homematic
   subType    virtual
   webCmd     virtual:update


Füge ich neue Geräte hinzu, erhalten diese per Default von irgendwoher:

Code Auswählen Erweitern


IOdev      HMLAN1
IOgrp      vccu:HMLAN1


Bei jedem Gerät muß ich dann dies ändern auf:

Code Auswählen Erweitern


IOgrp      vccu


Dann funktioniert es auch prima, wenn ich das Gerät in der Wohnung bewege...

Jedoch nach einem shutdown restart wird diese Konfiguration wieder geändert auf:

Code Auswählen Erweitern


IOdev      HMLAN2
IOgrp      vccu


In diesem Fall wurde die Konfiguration bei HMLAN2 abgeschlossen.

Frage:

• Warum wird ein IOdev beim shutdown restart hinzugefügt?
• Wie kann ich das verhindern?

Ich nutze derzeit die ConfigDB, falls dies irgendwie relevant sein sollte...

Danke, MN

[LuckyDay]

Code Auswählen Erweitern

IOdev      HMLAN2
IOgrp      vccu

das IOdev kommt von fhem , und wird neu gesetzt fals gelöscht.

die vccu "überschreibt" das IOdev intern mit IOgrp.

Also die kurze version. du brauchst immer ein IOdev als attr , wird aber nicht benutzt bei vccu

[Morgennebel]

Also die kurze version. du brauchst immer ein IOdev als attr , wird aber nicht benutzt bei vccu

Die Geräte verhalten sich aber anders, wenn ich das IODev lösche.

Beispiel: ich füge ein Gerät hinzu - das klappt nur, wenn HMLAN1 (-90dB) statt HMLAN2 (-40dB) die Kontaktaufnahme bestätigt. Dann steht in IODEv HMLAN1. Weitere Konfiguration funktioniert meist nicht. Lösche ich das Attribut und lasse nur IOGrp vccu zu, redet auch HMLAN2 mit dem neuen Gerät und alles flutscht super durch.

Trifft Deine Aussage evtl. nur auf vollständig gepairte Geräte zu?

Danke, -MN

[marvin78]

Trifft Deine Aussage evtl. nur auf vollständig gepairte Geräte zu?

Was sind denn nicht vollständig gepairte Geräte? IODev ist unerheblich und zu ignorieren, IOGrp ist eintscheidend und ja das gilt selbstverständlich für gepairte Geräte.

[CoolTux]

Die Geräte verhalten sich aber anders, wenn ich das IODev lösche.

Beispiel: ich füge ein Gerät hinzu - das klappt nur, wenn HMLAN1 (-90dB) statt HMLAN2 (-40dB) die Kontaktaufnahme bestätigt. Dann steht in IODEv HMLAN1. Weitere Konfiguration funktioniert meist nicht. Lösche ich das Attribut und lasse nur IOGrp vccu zu, redet auch HMLAN2 mit dem neuen Gerät und alles flutscht super durch.

Trifft Deine Aussage evtl. nur auf vollständig gepairte Geräte zu?

Danke, -MN

Wie genau fügst Du denn ein Gerät hinzu? Wäre ja auch interessant.

[Otto123]

Hi,

nicht gepairte Geräte erhalten doch gar kein IOgrp?

Gruß Otto

[frank]

Die Geräte verhalten sich aber anders, wenn ich das IODev lösche.

ist trotzdem verboten.

[Morgennebel]

Wie genau fügst Du denn ein Gerät hinzu? Wäre ja auch interessant.

Code Auswählen Erweitern

set vccu hmPairForSec 600

Anlernknopf. Prozedur wiederholen, bis neues Device in CUL_HM vorhanden ist. Anlernknopf wiederholt drücken, bis alle Pending Commands weg sind.

Und genau diese Pending Commands gehen schneller, ebenso die weitere Konfiguration, wenn ich IODev lösche und nur noch IOGrp verwende. Ich sehe auch am HMLAN2 (keine 1.5m entfernt, -40dB) viel mehr Datenverkehr anhand der LEDs - während das neue Gerät sehr oft HMLAN1 (-90 - -95dB) in FHEM zeigt...

Ciao, -MN

[Otto123]

Hi MN,

IOgrp betrifft eigentlich nur senden -> https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Bemerkungen
Ich weiß Frank hat das schon oft ganz genau erklärt 
Ich würde an Deiner Stelle, so wie Du das Verhalten beschreibst, zum pairen den HMLAN1 in Deinem Beispiel mit set HMLAN1 closed temporär rausnehmen. Ich hatte das auch schon, "zu viele IOs in zu vielen FHEMs verderben den Brei" 
Danach setzt Du mit IOgrp der preferredIO oder auch nicht.

Gruß Otto

[marvin78]

Und was möchtest du nun genau erreichen? Dass IODev permanten gelöscht bleibt, kann es nicht sein denn das wird nicht passieren. Du kannst Ottos Rat befolgen und nur für das Pairen HMLAN1 closen (mach dir eben einen cmdalias dafür). Was allerdings definitiv nicht stimmt ist, dass viele IOs "den Brei verderben". Ich habe 10 HM IOs und bei mir läuft alles wie am Schnürchen.

[Otto123]

Oh sorry, das wieder ein laxer Satz von mir. Nein, ich habe auch mehrere IOs und das läuft wie am Schnürchen!
Aber mit "schwierigen" HM Komponenten (Display Taster z.B.), mehreren IOs in einer Installation und einem IO in einer parallel Installation mit gleicher HMID, viel Funklast wegen vieler unwissender Versuche - war es dann doch entspannter alle bis auf einen zu deaktivieren.