Für die Homematic Geräte habe ich ein Netzwerk mit mehreren HM-MOD-RPI-PCB Modulen aufgebaut.
Ein HM-MOD-RPI-PCB ist am Basis Raspberry. Die restlichen sind über ser2net am Basissystem angebunden.
Internals:
CFGFN /media/hdd/fhem/mycfg/HM/hm_rasp01.cfg
DEF xxxxxx
HmUART_AB_GTO_MSGCNT 67
HmUART_AB_GTO_RAWMSG 05000038448002xxxxxxC242E00
HmUART_AB_GTO_RSSI -56
HmUART_AB_GTO_TIME 2018-12-06 08:23:56
HmUART_EG_MSGCNT 71
HmUART_EG_RAWMSG 05000051448002xxxxxx4C242E00
HmUART_EG_RSSI -81
HmUART_EG_TIME 2018-12-06 08:23:56
HmUART_OG1_MSGCNT 45
HmUART_OG1_RAWMSG 05000038448002xxxxxx4C242E00
HmUART_OG1_RSSI -56
HmUART_OG1_TIME 2018-12-06 08:23:56
HmUART_OG2_MSGCNT 69
HmUART_OG2_RAWMSG 0500003CEC8002xxxxxx5A1CAE00
HmUART_OG2_RSSI -60
HmUART_OG2_TIME 2018-12-06 08:23:53
IODev HmUART_OG2
LASTInputDev HmUART_EG
MSGCNT 252
NAME VCCU
NOTIFYDEV global
NR 2426
NTFY_ORDER 50-VCCU
STATE HmUART_AB_FR:ok,HmUART_AB_GTO:ok,HmUART_EG:ok,HmUART_OG1:ok,HmUART_OG2:ok,
TYPE CUL_HM
assignedIOs HmUART_AB_FR,HmUART_AB_GTO,HmUART_EG,HmUART_OG1,HmUART_OG2
channel_01 VCCU_Btn1
channel_02 VCCU_Btn2
channel_03 VCCU_Btn3
channel_04 VCCU_Btn4
channel_05 VCCU_Btn5
channel_06 VCCU_Btn6
channel_07 VCCU_Btn7
channel_08 VCCU_Btn8
channel_09 VCCU_Btn9
channel_0A VCCU_Btn10
channel_0B VCCU_Btn11
channel_0C VCCU_Btn12
lastMsg No:44 - t:02 s:xxxxxx d:4C242E 00
protLastRcv 2018-12-06 08:23:56
protRcv 97 last_at:2018-12-06 08:23:56
protRcvB 37 last_at:2018-12-06 08:19:12
rssi_at_HmUART_AB_GTO cnt:67 min:-68 max:-56 avg:-62.26 lst:-56
rssi_at_HmUART_EG cnt:71 min:-88 max:-74 avg:-79.09 lst:-81
rssi_at_HmUART_OG1 cnt:45 min:-75 max:-56 avg:-60.6 lst:-56
rssi_at_HmUART_OG2 cnt:69 min:-92 max:-53 avg:-69.21 lst:-60
READINGS:
2018-12-06 08:23:56 CommandAccepted yes
2018-12-06 06:37:06 aesReqTo EG_STH_T1_VG
2018-08-09 22:20:24 rssi_at_HmUART_AB_FR -83
2018-12-06 08:23:56 rssi_at_HmUART_AB_GTO -56
2018-12-06 08:23:56 rssi_at_HmUART_EG -81
2018-12-06 08:23:56 rssi_at_HmUART_OG1 -56
2018-12-06 08:23:53 rssi_at_HmUART_OG2 -60
2018-12-06 08:18:24 state HmUART_AB_FR:ok,HmUART_AB_GTO:ok,HmUART_EG:ok,HmUART_OG1:ok,HmUART_OG2:ok,
2018-08-29 23:06:20 unknown_4C0C96 received
2018-11-01 10:11:47 unknown_4C0DD6 received
2018-07-02 08:40:50 unknown_5D014C received
2018-07-02 08:37:17 unknown_5D015E received
2018-07-02 08:35:13 unknown_5D015F received
2018-07-02 08:38:51 unknown_5D0180 received
2018-09-18 17:47:04 unknown_5E58E7 received
2018-09-28 13:53:44 unknown_5E58F0 received
2018-09-26 17:03:47 unknown_5E5953 received
2018-09-18 17:37:45 unknown_5E596E received
2018-09-28 13:48:55 unknown_5E59A5 received
2018-09-28 13:41:17 unknown_5E59A8 received
2018-10-23 10:45:09 unknown_613E8F received
2018-11-09 14:39:36 unknown_6387DF received
2018-11-09 19:25:44 unknown_6387ED received
2018-11-09 19:22:41 unknown_6388CD received
2018-11-12 11:13:22 unknown_6752BE received
2018-10-23 22:14:23 unknown_6F61F6 received
2018-08-27 12:13:30 unknown_9A7248 received
helper:
HM_CMDNR 68
mId FFF0
regLst ,0
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 0
tpl 0
io:
nextSend 1544081036.95849
prefIO
vccu
ioList:
HmUART_AB_FR
HmUART_AB_GTO
HmUART_EG
HmUART_OG1
HmUART_OG2
mRssi:
mNo 44
io:
HmUART_AB_GTO:
-56
-56
HmUART_EG:
-81
-81
HmUART_OG1:
-56
-56
HmUART_OG2:
-56
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
at_HmUART_AB_GTO:
avg -62.2686567164179
cnt 67
lst -56
max -56
min -68
at_HmUART_EG:
avg -79.0985915492958
cnt 71
lst -81
max -74
min -88
at_HmUART_OG1:
avg -60.6
cnt 45
lst -56
max -56
min -75
at_HmUART_OG2:
avg -69.2173913043479
cnt 69
lst -60
max -53
min -92
role:
Attributes:
IODev HmUART_OG2
IOList HmUART_AB_FR,HmUART_AB_GTO,HmUART_EG,HmUART_OG1,HmUART_OG2
aesCommReq 0
alias HomeMatic Virtuelle CCU
event-on-change-reading .*
group .HomeMatic VCCU
hmKey 01:.............................................................
hmKey2 02:.............................................................
hmKey3 03:.............................................................
icon hm_ccu
model CCU-FHEM
room _HM,_Kontaktsensoren,_RxTx
rssiLog 1
subType virtual
verbose 0
webCmd virtual:update
Im Zuge dessen habe ich festgestellt das die Gerätekonfiguration IODev und IOgrp auch nicht einwandfrei funktionieren.
Meine Vermutung ist das es hier ein Timeingproblem gibt die über ser2net angebunden sind.
Durch die Größenortnung der Geräte und deren Erreichbarkeit war ich gezwungen mehrere HM-MOD-RPI-PCB einzusetzen um eine notwenige Flächenabdekung zu schaffen.
So ist die Konfiguration der HM-MOD-RPI-PCB bei den Geräten in der Form eingetragen, dass sich das naheste HM-MOD-RPI-PCB Geräte unter IODev HmUART_OG1 befindet und die weiteren erreichbaren HM-MOD-RPI-PCB Geräte unter IOgrp VCCU:HmUART_AB_FR,HmUART_OG2 eingetragen sind.
Was sich bei den Test herausgestellt hatte, ist das es einen Fehler bei der IOgrp gibt die ein none am Ende nicht akzeptiert.
Popup Meldung => value corrected IOgrp:VCCU:HmUART_AB_FR,HmUART_OG2.
Auf den Homematic Geräten ist auch zu beobachten das das Empfangssymbol sehr häufig und lange blinkt was eigentlich auch nicht sein dürfte.
Auch das Neuanlernen gestalltet sich sehr schwierig.
Hat sich bei der Konfiguration der VCCU und der HM-MOD-RPI-PCB Modulen etwas geändert?
Hallo Chris,
auf alle Fälle fehlt bei Deiner VCCU das attr IOgrp.
Ob das was mit deinem Problem zu tun hat, glaube ich nicht. Aber ohne das Attribute funktioniert im Fehlerfall die Umschaltung des Sende IOs der VCCU nicht.
Deine Frage nach der Änderung: Diese Erkenntnis (https://forum.fhem.de/index.php/topic,88621.0.html)und der Eintrag im Wiki (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Einrichten) kam erst Mitte diesen Jahres.
ZitatWas sich bei den Test herausgestellt hatte, ist das es einen Fehler bei der IOgrp gibt die ein none am Ende nicht akzeptiert.
Popup Meldung => value corrected IOgrp:VCCU:HmUART_AB_FR,HmUART_OG2.
Den Satz verstehe ich nicht :-[
Zum Anlernen: Mit mehreren IOs ist das neuanlernen von Komponenten definitiv nicht einfacher/besser als mit einem IO, das kann ich bestätigen. Ich nehme beim Pairen (wenn es schwierig wird) einfach alle IOs außer einen außer Betrieb (set close)
Ich habe allerdings nur drei :)
Gruß Otto
Hallo Otto.
Bei der VCCU gehört bei attr IOgrp in meinem Fall also nur VCCU eingetragen.
Bei den Geräten ist zb. das
attr IODev HmUART_OG1
attr IOgrp VCCU:HmUART_AB_FR,HmUART_OG2
Device
Internals:
CFGFN /media/hdd/fhem/mycfg/HM/hm_rasp01.cfg
DEF 541887
IODev HmUART_OG1
NAME AB_FR_AAM
NOTIFYDEV global
NR 2867
NTFY_ORDER 50-AB_FR_AAM
STATE CMDs_done
TYPE CUL_HM
channel_01 AB_FR_AAM_Led
channel_02 AB_FR_AAM_Mp3
READINGS:
2018-06-13 17:56:36 D-firmware 1.3
2018-06-13 17:56:36 D-serialNr OEQ0142956
2018-12-05 19:21:03 PairedTo 0x......
2018-08-13 07:47:45 R-intKeyVisib invisib
2018-08-13 07:47:45 R-pairCentral 0x......
2018-12-05 19:21:03 RegL_00. 00:00 02:01 0A:F1 0B:23 0C:47 DE:A0
2018-12-04 08:28:10 battery ok
2018-07-01 11:09:59 powerOn 2018-07-01 11:09:59
2018-07-01 11:09:59 recentStateType info
2018-12-05 19:21:04 rssi_at_HmUART_AB_FR -53
2018-12-01 10:45:59 rssi_at_HmUART_OG1 -91
2018-12-05 19:18:48 rssi_at_HmUART_OG2 -94
2018-12-05 19:21:04 state CMDs_done
helper:
HM_CMDNR 25
mId 00FA
regLst ,0
rxType 6
expert:
def 1
det 1
raw 1
tpl 1
io:
newChn +541887,00,03,00
rxt 0
vccu VCCU
p:
541887
00
03
00
prefIO:
HmUART_AB_FR
HmUART_OG2
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
prs 1
tmpl:
Attributes:
IODev HmUART_OG1
IOgrp VCCU:HmUART_AB_FR,HmUART_OG2
alias AB Fitnessraum - Alarmanlage - Meldungen
autoReadReg 4_reqStatus
event-on-change-reading .*
expert 251_anything
firmware 1.3
group AB Fitnessraum - Alarmanlage
icon hm-dis-wm55
model HM-OU-CFM-TW
msgRepeat 1 ???
room AB-Fitnessraum,Alarmanlage,_HM
rssiLog 1
serialNr ............................
sortby 01
subType outputUnit
userReadings rssi_dB:CUL_Master_RSSI.* {(ReadingsVal("$name","CUL_Master_RSSI",0))}
webCmd getConfig:clear msgEvents
Wenn ich bei einem Gerät das Attribut
attr IOgrp VCCU:HmUART_AB_FR,HmUART_OG2,none
definieren möchte bekomme ich diese Popup Meldung
value corrected IOgrp:VCCU: HmUART_AB_FR,HmUART_OG2
Deine Links werde ich mir gleich ansehen.
ZitatSo ist die Konfiguration der HM-MOD-RPI-PCB bei den Geräten in der Form eingetragen, dass sich das naheste HM-MOD-RPI-PCB Geräte unter IODev HmUART_OG1 befindet und die weiteren erreichbaren HM-MOD-RPI-PCB Geräte unter IOgrp
das ist falsch.
1. wenn es attr iogrp gibt, wird attr iodev nicht mehr angefasst.
2 in attr iogrp unter prefered müssen alle io aufgelistet sein, die benutzt werden sollen. das beste also zuerst, wenn mehrere aufgeführt sind.
das hatten wir doch schon mal geklärt, oder?
Da muss ich etwas falsch verstanden haben.
Das heißt, beim Device ist das angelegte IODev zu belassen wie es ist, und unter IOgrp muss ich dann alle HM-MOD-RPI-PCB Module eintragen die im Empfangsbereich sind.
Mehr von den IO... Attributen wird beim Device nicht benötigt?
Bei der VCCU werden diese Attribute benötigt:
IODev HmUART_OG2 => wobei der Eintrag ebenfalls nicht verwendet wird der aber bei der Anlage der VCCU eingetragen wird
IOList HmUART_AB_FR,HmUART_AB_GTO,HmUART_EG,HmUART_OG1,HmUART_OG2 => Hier werden sämtliche HM-MOD-RPI-PCB eingetragen
IOgrp VCCU => Hier wird nur die eine VCCU vorhandene eingetragen
Betreffend FHEMWIKI habe ich einen Satz gefunden den ich nicht ganz verstehe.
ZitatBitte die Werte in <> durch die echten Werte ersetzen und die <> weglassen! Beispiel: attr VCCU IOgrp VCCU
Bei dem Konfiguratiosnbeispiel ist mir das Attribut nicht ganz verständlich.
attr VCCU IOList <Name des io1>[,<io2>,...]
Heißt das das alle weiteren HM-MOD-RPI-PCB in einer Klammer [] anzuführen sind?
Das attr IODev an sich, wird von "FHEM" verwaltet und nicht von der "VCCU oder von CUL_HM" - so habe ich das mal verstanden. Ich weiß nicht genau welcher Prozess in FHEM für die Verwaltung und Vergabe IODev zuständig ist.
Ist dann bei einem CUL_HM Gerät IOgrp gesetzt, wird attr IODev nicht mehr beachtet sondern das IODev von der VCCU verwaltet. (nicht sichtbar im attr IODev sondern im Internal IODev)
Zu den Klammern:
<> bedeutet, was da drin steht ist ein Beispiel, die Klammern fallen weg, es muss richtig komplett ersetzt werden. Genau wie in deinem Zitat. Wie sollte das im Wiki stehen damit man es versteht? :o
Was in diesen [] Klammern steht ist eine Option, die Klammern sind auch nur zur Erklärung und fallen im wahren Leben weg. Also: Befehl Option1 [Option2] -> kann richtig so aussehen Befehl Option1 oder Befehl Option1 Option2 aber eben nicht Befehl.
So klarer?
attr VCCU IOList io1
attr VCCU IOList io1,io2
attr VCCU IOList io1,io2,io3
attr VCCU IOList io1,io2,io3,io4
Gruß Otto
Soweit alles klar.
Jetzt zu der Beschreibung.
IOgrp
kann an Devices vergeben werden udn zeigt auf eine virtuelle ccu. Danach wird die ccu beim Senden das passende IO für das Device auswählen. Es ist notwendig, dass die virtuelle ccu definiert und alle erlaubten IOs eingetragen sind. Beim Senden wird die ccu prüfen welches IO operational ist und welches den besten rssi-faktor für das Device hat.
Optional kann ein bevorzugtes IO definiert werden. In diesem Fall wird es, wenn operational, genutzt - unabhängig von den rssi Werten.
wenn kein prefIO verfügbar ist und none erkannt wird wird das IO aus IODev gewählt
Beispiel:
attr myDevice1 IOgrp vccu
attr myDevice2 IOgrp vccu:prefIO1,prefIO2,prefIO3
attr myDevice2 IOgrp vccu:prefIO1,prefIO2,none
Das Beispiel mit none funktioniert nicht.
Wenn bei der VCCU die Attribute gesetzt sind
attr VCCU IODev HmUART_OG2
attr VCCU IOList HmUART_AB_FR,HmUART_AB_GTO,HmUART_EG,HmUART_OG1,HmUART_OG2
attr VCCU IOgrp VCCU
Ist es dann noch nötige beim Device das Attribut attr myDevice2 IOgrp vccu:prefIO1,prefIO2,......... zu setzten?
none ist ja auch nur ein optionales element am ende der prefered-io-liste im attr IOgrp. da es nicht funktioniert lässt man none einfach weg, logisch. oder?
die vccu versucht immer das erste io in der prefered-io-liste zu nutzen. ist es nicht verfügbar, das nächste der liste. ist kein io der prefered-io-liste verfügbar, wird, falls die vccu noch weitere io verwaltet (siehe liste beim attr IOList), das io mt dem besten rssi der verbliebenden und funktionierenden io genutzt.
none würde diese weitere suche im pool der vccu verhindern. mit none kommen also nur io der prefered-io-liste in frage.
aber none funktioniert nicht, wie wir wissen.
was ist daran so schwer?
Ich würde zunächst per default versuchen ohne prefIO zu arbeiten. Also attr myDevice1 IOgrp vccu
Es gibt sicher Spezialfälle - aber ich würde erstmal der VCCU vertrauen und zusehen :)
Aber ich bin auch einer der lieber mit DHCP arbeitet ;D
Nichts ist schwer.
Ich habe nur auf einen Punkt der FHEM Wiki bzw. comanndref hingewiesen der wie er beschrieben ist nicht funktioniert um entweder den Fehler zu beheben oder zu korrigieren.
Jedenfalls bin ich mit diesem Punkt ein Stück weiter gekommen.
Danke für die Infos.
Hallo Chris,
Die Sache mit ,none kann nur Martin richten. Wenn Du mir noch Tipps gibst, was im Wiki geändert werden sollte, kann ich das übernehmen.
Gruß Otto
Hallo Otto.
Ich möchte jetzt nicht als Oberlehrer auftreten.
Es sind nur Kleinigkeiten an Schreibfehlern die mir beim Studium aufgefallen sind.
Zitatüberlicherweise
Vergrösserung
klassichen
Ein weitere Vorteil
Nutzung mehrer VCCUs
VCCUs das selbe I/O Device
VCCU genutzen I/Os
Zuweisung die selbe hmId.
bereits mehre Funkschnittstellen im Einsatz, werde diese unterschiedliche
Ausserdem muss in jedem Fall
VCCU mit der selben hmId angelgt
VCCU mit einer von vorhandene Schnittstellen abweichenden
zur Folge, das HM Devices
VCCU erst angefasst wenn das
Dabei ensteht folgende ungünstige Struktur
und für jedes HM gerät geprüft
muss dies Korrektur von Hand erfolgen
wo die direktes Editieren der fhem.cfg z.B. dem
Anschliessend die kompletten
Es ist im übrigen weiter möglich
Wirkung, ebensowenig Änderungen,
Das selbe IO wird mit
Ohne VCCU sendet sendet Befehle an ein HM Device
Ausserdem gibt es bewegliche Fernbedienungen
HM Geräten mit der sechstelligen DEF
Bei diesen Zeilen wäre es meiner Ansicht nach leichter verständlich.
Zitat
attr <dev> IOgrp <vccu>:<preferredIO> => einheitlich bei Beschreibungen Beibehalten <device>
attr <dev> IOgrp <vccu>:<prefIO1>,<prefIO2>,<prefIO3> => einheitlich bei Beschreibungen Beibehalten <device>
attr VCCU IOList <Name des io1>[,<io2>,...] => finde ich verwirrend und wäre so besser attr VCCU IOList <Name des io1>,<Name des io2>,...
Danke Chris, ich habe es eingearbeitet (und noch ein paar Fehler mehr gefunden)
Gruß Otto
Kein Problem Otto.
Wichtig ist Fehlererörterung und gemeinsame Lösungen zu finden.