Ich beschäftige mich grad mal mit dem Thema VCCU und habe auch das Wiki dazu gelesen aber ich bin da etwas verwirrt und auf Grund der verscheidenenen Möglichkeiten verstehe ich absolut grad nichts.
Zum Verständnis habe ich mal Fragen.
da das fhem komplett neu ist und ich bisher nur 2 Temperaturfühler "HM-WDS10-TH-O" drin habe und einen Homematic Schalter "HM-LC-SW1-PL2" wollte ich das jetzt mal angehen.
Dazu besitze ich noch den älteren "HM-CFG-LAN"
Wer sollte wen in der Konfig haben, die VCCU den HM-CFG-LAN und die Temp.fühler die VCCU.
Ich habe das Gefühl es ist alles irgendwie durcheinander, weil ich die VCCU hinterher eingerichtet haben.
Evtl. gibt es einen Beitrag im Forum wo es nochmals besser beschrieben ist, ich habe schon einiges gefunden und arbeite mich gerade durch
Die wichtigste Frage ist was sollte ich zuerst einrichten
1. HMLAN
2. VCCU
3. alle Devices danach
Ich hänge mal die Lists vom HMLan Adapter, einem Temp. fühler und der VCCU ran.
list HM-CFG-LAN
Internals:
DEF 10.0.0.45:1000
DeviceName 10.0.0.45:1000
FD 10
FUUID 60c0a7da-f33f-b063-3e7f-d6d2c5fbe164221f
HMLanHaus_MSGCNT 27882
HMLanHaus_TIME 2021-06-10 13:55:08
IFmodel LAN
NAME HMLanHaus
NR 209
NTFY_ORDER 50-HMLanHaus
PARTIAL
RAWMSG E1EA121,0000,7F4F809F,FF,FFD9,0080021EA12120798D00
RSSI -39
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 2 report:5
msgKeepAlive dlyMax:0.06 bufferMin:4
msgLoadCurrent 0
msgLoadHistoryAbs 5min steps: 0/0/0/0/0/0/0/0/0/0/0/0
msgParseDly min:6 max:7801 last:11 cnt:27851
owner 1EA999
owner_CCU vccu
uptime 024 593:18:36.703
READINGS:
2021-06-09 19:48:37 D-HMIdAssigned 1EA999
2021-06-09 19:48:37 D-HMIdOriginal 1EA121
2021-06-09 19:48:37 D-firmware 0.965
2021-06-09 19:48:37 D-serialNr xxxxxxxxxxxxx
2021-06-09 19:48:37 Xmit-Events init:1 disconnected:1 ok:1
2021-06-09 19:48:37 cond ok
2021-06-10 13:54:59 loadLvl low
2021-06-09 19:48:37 prot_disconnected last
2021-06-09 19:48:37 prot_init last
2021-06-09 19:48:37 prot_ok last
2021-06-09 19:48:37 state opened
helper:
assIdCnt 2
assIdRep 5
info 03C5,JEQ0706353,1EA121,1EA999
setTime 49539
cnd:
0 1
253 1
255 1
dly:
cnt 27851
lst 11
max 7801
min 6
ids:
20DA4B:
cfg +20DA4B,00,00,00
chn 00
flg 0
msg
name Temperatur_Norden
to 1623261509.25848
2EB1AD:
cfg +2EB1AD,00,00,00
chn 01
flg 0
msg
name Proxmox_PBS
to 1623260925.47052
k:
BufMin 4
DlyMax 0.06
Next 1623326124.0195
Start 1623326099.0195
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
ARRAY(0x557699eeca58)
q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLastMax 0
loadNo 10
scnt 6
ald:
0
0
0
0
0
0
0
0
0
0
0
0
apIDs:
ref:
drft -0.000159980802303724
hmtL 2135907186
kTs 0
offL 1621190191836
sysL 1623326099022
Attributes:
alias HMLan Haus
devStateIcon opened:WLAN_Status.1 disconnected:WLAN_Status.0
group Hardware
hmId 1EA999
hmLanQlen 1_min
icon hm_lan@blue
loadLevel 0:low,40:batchLevel,90:high,99:suspended
room Hardware Geräte->HWR
sortby 01
list Temperaturfühler
Internals:
DEF 20DA4B
FUUID 60c0b051-f33f-b063-676c-3a850bb29a178051
HMLanHaus_MSGCNT 425
HMLanHaus_RAWMSG E20DA4B,0000,7F58737B,FF,FFBC,F7867020DA4B000000010336
HMLanHaus_RSSI -68
HMLanHaus_TIME 2021-06-10 14:04:54
IODev HMLanHaus
LASTInputDev HMLanHaus
MSGCNT 425
NAME Temperatur_Norden
NOTIFYDEV global
NR 244
STATE T: 25.9 H: 54
TYPE CUL_HM
chanNo 01
lastMsg No:F7 - t:70 s:20DA4B d:000000 010336
protCmdDel 2
protLastRcv 2021-06-10 14:04:54
protRcv 425 last_at:2021-06-10 14:04:54
protResnd 3 last_at:2021-06-09 19:56:09
protResndFail 1 last_at:2021-06-09 19:58:33
protSnd 4 last_at:2021-06-09 19:58:27
protState CMDs_done_Errors:1
rssi_at_HMLanHaus cnt:425 min:-83 max:-66 avg:-69.32 lst:-68
READINGS:
2021-06-09 19:22:39 D-firmware 1.3
2021-06-09 19:22:39 D-serialNr KEQ0174978
2021-06-09 19:48:37 IODev HMLanHaus
2021-06-10 14:04:54 battery ok
2021-06-09 19:50:38 cfgState updating
2021-06-09 19:58:33 commState CMDs_done_Errors:1
2021-06-10 14:04:54 humidity 54
2021-06-10 14:04:54 state T: 25.9 H: 54
2021-06-10 14:04:54 temperature 25.9
RegL_00.:
VAL
helper:
HM_CMDNR 247
cSnd 011EA99920DA4B00040000000000,011EA99920DA4B00040000000000
getCfgListNo
mId 003D
peerFriend
peerIDsState peerUnread
peerOpt p:THSensor
regLst 0
rxType 140
supp_Pair_Rep 0
cmds:
TmplKey :no:1623260922.46747
TmplTs 1623260922.46747
cmdKey 1:1:0::Temperatur_Norden:003D:01:
cmdLst:
assignHmKey noArg
burstXmit noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan 0 -actChn- [({single})] [({set}|unset)] [actor|remote|both]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
tplDel -tplDel-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt
tplDel
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 1
det 0
raw 1
tpl 0
io:
flgs 0
newChn +20DA4B,00,00,00
nextSend 1623326695.00837
prefIO
rxt 2
vccu vccu
p:
20DA4B
00
00
00
mRssi:
mNo F7
io:
HMLanHaus:
-64
-64
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_HMLanHaus:
avg -69.3247058823529
cnt 425
lst -68
max -66
min -83
tmpl:
Attributes:
IOgrp vccu
actCycle 000:10
actStatus unset
alias * Eingang Norden *
autoReadReg 4_reqStatus
devStateIcon {ui_Table::temp_hum_ring(ReadingsVal("Temperatur_Norden","temperature",0),ReadingsVal("Temperatur_Norden","humidity",0))}
expert defReg,rawReg
firmware 1.3
group Temperatur Alle
model HM-WDS10-TH-O
peerIDs peerUnread
room Temperaturen
serialNr KEQ0174978
sortby 01
subType THSensor
verbose 0
list VCCU
Internals:
DEF 1EA999
FUUID 60c0a8dc-f33f-b063-81fc-93be5ef3af7064b8
HMLanHaus_MSGCNT 26973
HMLanHaus_RAWMSG E1EA121,0000,7F5B3524,FF,FFD9,0080021EA12120798D00
HMLanHaus_RSSI -39
HMLanHaus_TIME 2021-06-10 14:07:55
IODev HMLanHaus
LASTInputDev HMLanHaus
MSGCNT 26973
NAME vccu
NOTIFYDEV global
NR 214
STATE vccu:UAS,HMLanHaus:ok
TYPE CUL_HM
assignedIOs HMLanHaus,vccu
chanNo 01
READINGS:
2021-06-09 19:48:37 IODev HMLanHaus
2021-06-09 19:48:42 IOopen 1
2021-06-09 18:20:34 commState CMDs_done
2021-06-09 19:48:42 state vccu:UAS,HMLanHaus:ok
2021-06-10 14:05:41 unknown_0B7749 received
2021-06-10 14:07:55 unknown_1EA121 received
2021-06-10 14:07:25 unknown_1EA390 received
2021-06-10 14:07:55 unknown_20798D received
2021-06-10 07:45:37 unknown_215C80 received
2021-06-10 00:11:19 unknown_258DFC received
2021-06-09 23:30:00 unknown_2A18BD received
2021-06-10 13:29:51 unknown_2D7A80 received
2021-06-10 00:43:56 unknown_2EB19C received
2021-06-10 00:10:12 unknown_2F6DDB received
2021-06-10 14:07:24 unknown_3385ED received
2021-06-10 14:06:35 unknown_37A2DE received
2021-06-10 14:03:24 unknown_3DDEBA received
2021-06-10 07:45:46 unknown_431333 received
2021-06-10 13:33:45 unknown_444BF4 received
2021-06-10 13:58:16 unknown_444BF9 received
2021-06-10 14:07:09 unknown_45977F received
2021-06-10 14:07:54 unknown_4598FF received
2021-06-10 09:15:00 unknown_4AB318 received
2021-06-09 19:01:17 unknown_4BE8C2 received
2021-06-10 07:30:00 unknown_5298CD received
2021-06-10 12:32:30 unknown_534937 received
2021-06-10 08:02:44 unknown_55062D received
2021-06-10 07:45:29 unknown_5DDDBF received
2021-06-10 07:45:47 unknown_611DA1 received
2021-06-10 14:07:37 unknown_8FB1E9 received
2021-06-10 09:43:58 unknown_AF044D received
2021-06-10 13:53:18 unknown_AF38D9 received
2021-06-10 13:44:27 unknown_B0FA06 received
2021-06-10 09:53:14 unknown_BC584E received
2021-06-10 14:07:01 unknown_E742C9 received
helper:
HM_CMDNR 247
mId FFF0
peerFriend
peerOpt v:virtual
regLst
rxType 1
cmds:
TmplKey :no:1623260922.47152
TmplTs 1623260922.47152
cmdKey 1:1:1::vccu:FFF0:01:
cmdLst:
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
defIgnUnknown noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
peerChan -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
postEvent -condition-
press [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
pressL [(-peer-|{all})]
pressS [(-peer-|{all})]
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt
tplDel
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
listDevice noArg
param -param-
expert:
def 0
det 0
raw 1
tpl 0
io:
prefIO
vccu vccu
ioList:
HMLanHaus
mRssi:
mNo
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
vrt 1
tmpl:
Attributes:
IODev HMLanHaus
IOList HMLanHaus
IOgrp vccu
alias Virtuelle CCU
expert rawReg
group Software
hmId 1EA999
icon cul_cul@blue
model CCU-FHEM
room Software Geräte->HWR
subType virtual
webCmd virtual:update
ich werde indes weiter im Forum suchen nach eiteren Beiträgen.
Bei der VCCU geht es u.A. um das Management der IO's. Daher sind da ein paar Attribute besonders wichtig, die sich mit dem Thema beschäftigen.
Auszug aus meiner:
attr VCCU IOList myHmUART,CUL_0,mapleCUN1,HmUART_Maple
attr VCCU IOgrp VCCU
Und dann bekommen ALLE CUL_HM-(Haupt-? = mit 6-stelliger HmID) Geräte noch das IOgrp Attribut, ggf. gepaart mit dem "Vorzugs-IO". That's all (soweit ich das noch präsent habe).
Nachtrag noch zu dem Reihenfolge-Thema:
afaik ist CUL_HM seit langem "Reihenfolge-unempfindlich". "Wasserdicht" sollte es sein, wenn man es so macht wie du hier, nämlich
- erst die physischen IO's definiert werden,
- dann die VCCU, und
- zuletzt alles andere.
Zitat von: Beta-User am 10 Juni 2021, 14:15:18
Bei der VCCU geht es u.A. um das Management der IO's. Daher sind da ein paar Attribute besonders wichtig, die sich mit dem Thema beschäftigen.
Auszug aus meiner:
attr VCCU IOList myHmUART,CUL_0,mapleCUN1,HmUART_Maple
attr VCCU IOgrp VCCU
Und dann bekommen ALLE CUL_HM-(Haupt-? = mit 6-stelliger HmID) Geräte noch das IOGrp Attribut, ggf. gepaart mit dem "Vorzugs-IO". That's all (soweit ich das noch präsent habe).
OK also die IOgrp ist praktisch die eigene vccu bei dir groß geschrieben, bei mir klein geschrieben
Das habe ich ebenfalls so drin, also wäre das schon mal richtig.
und genau mit der IOList stehe ich grad auf dem Kriegsfuß.. :-\
Da sollte dann bei mir der HMLan Adapter drin stehen und falls man noch mehr Adapter hat wie deConz oder ähnliches sollen die da rein, so sehe ich das bei dir.. ist das richtig..?
sieht so bei mir aus:
attr vccu IOList HMLanHaus
attr vccu IOgrp vccudann habe ich noch das Attribut,
attr vccu IODev HMLanHausmuss ich das raus löschen ist das falsch, denn in den Readings steht ja bei IODev HMLanHaus
Zitat von: moonsorrox am 10 Juni 2021, 14:28:31
OK also die IOgrp ist praktisch die eigene vccu bei dir groß geschrieben, bei mir klein geschrieben
Das habe ich ebenfalls so drin, also wäre das schon mal richtig.
Ja.
Zitat
und genau mit der IOList stehe ich grad auf dem Kriegsfuß.. :-\
Da sollte dann bei mir der HMLan Adapter drin stehen und falls man noch mehr Adapter hat wie deConz oder ähnliches sollen die da rein, so sehe ich das bei dir.. ist das richtig..?
Jein!
Die 4 bei mir gelisteten sind ALLE (mehr oder weniger gut) für CUL_HM geeignet, deConz wäre es NICHT! (Das wäre eine HUEBrigde! Und wenn du einen ConBee II hast unter zigbee2mqtt, wäre das IO-Modul entweder MQTT2_SERVER, MQTT_CLIENT oder (00_)MQTT... Kurz: ganz andere Baustelle!)
Zitat
dann habe ich noch das Attribut,
attr vccu IODev HMLanHaus
muss ich das raus löschen ist das falsch, denn in den Readings steht ja bei IODev HMLanHaus
"Muss" ist zu viel gesagt, es gibt da grade eine nette Diskussion, die auch "kleine Developer" wie ich nicht vollständig verstehen... Im Moment würde ich behaupten, dass man es ohne weiteres löschen _kann_.
Zitat von: Beta-User am 10 Juni 2021, 14:37:46
Die 4 bei mir gelisteten sind ALLE (mehr oder weniger gut) für CUL_HM geeignet, deConz wäre es NICHT! (Das wäre eine HUEBrigde! Und wenn du einen ConBee II hast unter zigbee2mqtt, wäre das IO-Modul entweder MQTT2_SERVER, MQTT_CLIENT oder (00_)MQTT... Kurz: ganz andere Baustelle!)
"Muss" ist zu viel gesagt, es gibt da grade eine nette Diskussion, die auch "kleine Developer" wie ich nicht vollständig verstehen... Im Moment würde ich behaupten, dass man es ohne weiteres löschen _kann_.
OK, soweit bin ich da noch nicht, aber ich weiß das in meiner momentanen produktiv Config der MQTT2_Server drin ist, also muss der da auch mit rein, dann noch der sduino, sollte dort auch rein.?
Dann werde ich mal das IOdev löschen kann noch nichts passieren, ich hatte gestern schon alles mögliche gemacht und dachte da frage ich mal lieber weil ich keine Berührungspunkte bisher hatte mit VCCU. :-\
ich bin ja noch fleißig am lesen, weil ich grad überhaupt nichts verstehe... das muss mir erst mal klar werden.
...und ja den Cobee II (eigener docker deconz) habe ich auf einem fhem im (eigenen Docker), aber den will ich ja ablösen
Zitat von: moonsorrox am 10 Juni 2021, 14:50:57
OK, soweit bin ich da noch nicht, aber ich weiß das in meiner momentanen produktiv Config der MQTT2_Server drin ist, also muss der da auch mit rein, dann noch der sduino, sollte dort auch rein.?
NEIN! Beides hat NICHTS mit CUL_HM zu tun, also bleibt es draußen. (Ich habe noch diverse andere IO-Geräte, aber die stehen doch auch nicht in der Liste, oder...?)
Zitat
Dann werde ich mal das IOdev löschen kann noch nichts passieren, ich hatte gestern schon alles mögliche gemacht und dachte da frage ich mal lieber weil ich keine Berührungspunkte bisher hatte mit VCCU. :-\
Das mit IODev hat nun nicht primär was mit VCCU zu tun. Das Attribut war _unter CUL_HM mit VCCU (!)_ schon immer mehr oder weniger wirkungslos... (Anders gesagt: ohne VCCU _war_ es wichtig!) Jetzt ist es eben aus zwei Gründen "wurscht", nämlich weil die VCCU da ist, und weil das framework zwischenzeitlich ersatzweise das Reading setzt und auswerten würde...
Zitat
ich bin ja noch fleißig am lesen, weil ich grad überhaupt nichts verstehe... das muss mir erst mal klar werden.
...und ja den Cobee II (eigener docker deconz) habe ich auf einem fhem im (eigenen Docker), aber den will ich ja ablösen
deconz wirst du aber über die VCCU nicht los, und wenn du alles als HUE.*-Modul bereits eingerichtet hast, bin ich mir nicht sicher, ob der Aufwand lohnt, alles auf MQTT umzuziehen...
Nochmal: Das sind völlig getrennte Welten, das eine hat mit dem anderen nichts zu tun (allenfalls, dass sich die USB-Adressierungen der Geräte in die Quere kommen könnten, wenn man es ungeschickt anstellt).
Ich habe jetzt den letzten Stand nicht ganz verstanden - aber:
Nach meiner Erfahrung darf mal bei CUL_HM das IODev nicht löschen, es muss da sein auch wenn der Inhalt bei einer vccu keine Rolle spielt.
Insofern ist der Temperaturfühler unvollständig. kann aber sein - ich bin nicht aktuell. :)
Die vccu ist irgendwie verkehrt:
ZitatSTATE vccu:UAS,HMLanHaus:ok
...
assignedIOs HMLanHaus,vccu
Wieso da die vccu als io steht erschließt sich mir nicht. Ich denke die vccu ist falsch erzeugt!
Das Attribute hat bei der VCCU nichts zu suchen! Die hmId steht in der DEF!
ZitathmId 1EA999
Warum nicht nach Wiki gemacht? Steht da nicht eindeutig wirklich alles drin?!
Zu der Frage:
ZitatDie wichtigste Frage ist was sollte ich zuerst einrichten
1. HMLAN
2. VCCU
3. alle Devices danach
ja :)
Gruß Otto
Nach meiner Erfahrung darf mal bei CUL_HM das IODev nicht löschen, es muss da sein auch wenn der Inhalt bei einer vccu keine Rolle spielt.Afaik konnte man das bis vor wenigen Tagen nicht dauerhaft löschen, zwischenzeitlich geht das.
So wie ich martinp876's Beiträge rund um diese IODev-Änderung verstanden habe, findet er die jetzige Lösung nicht gut, hatte aber so oder so einige Workarounds in CUL_HM eingebaut, damit die dynamische Zuweisung (unter VCCU) klappt. Von daher würde ich behaupten, dass man das Attribut nicht mehr benötigt und gelöscht lassen kann (es wird - im Unterschied zu früher) nicht mehr automatisch angelegt.
Es gab die vergangenen Tage aber diverse Änderungen im framework, von daher sollte man im Moment tagesaktuell sein (oder ggf. auch die Entwicklerversionen von noansi nutzen), um vor "seltsamen" Nebenwirkungen gefeit zu sein, wenn man mit dem Löschen rumexperimentiert...
(Bei mir stehen die IODev noch drin, aber da ändert sich sowieso nichts.)
Zitat von: Otto123 am 10 Juni 2021, 15:13:17
Die vccu ist irgendwie verkehrt:
Das war auch mein Eindruck, aber ich kann im Moment auch nicht sagen, ob das jetzt nur komisch aussieht, oder wirklich Probleme verursacht.
Was mir auch unklar ist:
lastMsg No:F7 - t:70 s:20DA4B d:000000 010336Der Sensor sendet also an braodcast, das kann richtig sein, muss es aber nicht. Jedenfalls ist aus dem list nicht ersichtlich, ob der Sensor gepairt ist. Falls nicht: Wenn er noch an die HmID des HMLan gepairt ist, könnte man die für die VCCU übernehmen, dann sollten auch alle anderen Geräte wieder sichtbar (und weiter gepairt) sein. (Aber ein dauerhafter Doppelbetrieb ist evtl. keine gute Idee)
Zitat von: Otto123 am 10 Juni 2021, 15:13:17
Die vccu ist irgendwie verkehrt:
Wieso da die vccu als io steht erschließt sich mir nicht. Ich denke die vccu ist falsch erzeugt!
Das Attribute hat bei der VCCU nichts zu suchen! Die hmId steht in der DEF!
Warum nicht nach Wiki gemacht? Steht da nicht eindeutig wirklich alles drin?!
Gruß Otto
ich arbeite das jetzt chronologisch ab
Im DEF meiner vccu steht 1EA999 das ist also schon mal richitg...!
Das Wiki hat mich echt komplett durcheinander gebracht, deshalb wohl auch die Konfigurationsfehler.
Meine Problem Zonen waren die 3 Attribute IODev, IOList imd IOgrp, die sind im Wiki allgemein gehalten und das war mir nicht ganz klar was ich eintragen mußte.
Ich besitze ja einen HM-CFG-LAN also den Netzwerkadapter der bei mir so heißt "HMLanHaus"
Der steht bei mir in der vccu bei:
attr vccu IODev HMLanHaus
attr vccu IOList HMLanHaus
attr vccu IOgrp vccuist das denn richtig..?
werde jetzt nochmal ins Wiki schauen
EDIT:// im Wiki hatte mich noch verwirrt was bedeutet denn nun
attr <Name der vccu> IOList <Name des io1>[,<Name des io2>,...]dann sollte das mein CUL_HM sein.? un dnicht mein HMLan
Zitat von: moonsorrox am 10 Juni 2021, 17:21:14
Im DEF meiner vccu steht 1EA999 das ist also schon mal richitg...!
Aber ein attribute hmId hat bei der VCCU
nichts zu suchen!
Zum Wiki: Du findest nicht, dass hier ein konkretes Beispiel steht, welches deinem Scenario exakt (ich meine also zu fast hundert Prozent) entspricht: :'( :'( :'(
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Einrichten
alles klar Otto habe ich raus genommen ;)
hatte grad noch ein Edit hinzugefügt
und ist da jetzt das UAS weg?
STATE vccu:UAS,HMLanHaus:ok
das steht jetzt drin
state HMLanHaus:UAS,
Zitatdann sollte das mein CUL_HM sein.? un dnicht mein HMLan
Wer bitte ist Dein CUL_HM?
Schau doch bitte nochmal hier: https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Einrichten
Da steht doch exakt Deine Konfig ? Also wenn Du zu dem HMLAN noch einen CUL hast?
Zitat von: Otto123 am 10 Juni 2021, 17:32:10
Wer bitte ist Dein CUL_HM?
Entschuldigung, ich habe was verwechselt (so ist das wenn man nicht durchsieht) :-\ ;)
also so sieht das jetzt aus:
STATE HMLanHaus:ok
das ist ok :)
hmId 1EA999
wie hast du das Attribut in die VCCU gebracht?
Zitat von: Otto123 am 10 Juni 2021, 17:35:41
das ist ok :)
jetzt hat er das IODev allein hinzugefügt sieht jetzt so aus:
IODev HMLanHaus
IOList HMLanHaus
IOgrp vccuZitat von: fhem-hm-knecht am 10 Juni 2021, 17:35:48
hmId 1EA999
wie hast du das Attribut in die VCCU gebracht?
bei Anlegen der vccu, denn ich habe es nicht manuell eingefügt
Zitat von: moonsorrox am 10 Juni 2021, 17:37:23
jetzt hat er das IODev allein hinzugefügt sieht jetzt so aus:
IODev HMLanHaus
IOList HMLanHaus
IOgrp vccu
bei Anlegen der vccu, denn ich habe es nicht manuell eingefügt
das sieht ok aus!
Noch als Nachtrag: aktuell sollte das -> attr IODev <IOHM> nach wie vor drin sein.
wenn man es löscht in der vccu - kommt es nach Neustart wieder.
diese ganze Diskussion darum, bei den Entwicklern, ist für mich aktuell ein schlechter Schnellschuss...
Zitat von: fhem-hm-knecht am 10 Juni 2021, 17:40:28
Noch als Nachtrag: aktuell sollte das -> attr IODev <IOHM> nach wie vor drin sein.
wenn man es löscht in der vccu kommt es nach Neustart wieder.
diese ganze Diskussion darum bei den Entwicklern ist für mich aktuell so ein schlechter Schnellschuss...
genau das hatte ich gestern in meiner Verzweiflung raus genommen und er hat es vorhin wieder selber erstellt, wohl als ich die ganzen Eintragungen richtig drin hatte.
Also heißt es jetzt das die vccu fertig ist..?
Wenn ich jetzt z.B. einen Temp. Melder rein bringe sollte der automatisch die vccu bekommen..?
Zitat von: moonsorrox am 10 Juni 2021, 17:43:14
Wenn ich jetzt z.B. einen Temp. Melder rein bringe sollte der automatisch die vccu bekommen..?
Was genau soll "rein bringe" sein, und die VCCU kümmert sich dann um die automatische IO-Zuweisung, wenn in dem Device dann IOgrp gesetzt ist.
Frage nochmal: Ist die jetzt vergebene HmID identisch zu der früheren (=der alten, für den HMLAN bisher gültigen), oder willst du jetzt alles ablernen und dann neu anlernen?
Zitatrein bringe
wenn du über die vccu anlernst, pairst - kommen die vccu attribute von selber!
kopierer und cfg editierer müssen selber manuel Hand anlegen
wenn man ein Gerät schon hat, bevor man es mit der VCCU gepairt hat (was nur ein symbolischer Akt ist) muss man das attr IOgrp selbst eintragen. Auch das steht mMn exakt im Wiki.
Zitat von: Beta-User am 10 Juni 2021, 17:46:30
Was genau soll "rein bringe" sein, und die VCCU kümmert sich dann um die automatische IO-Zuweisung, wenn in dem Device dann IOgrp gesetzt ist.
ich meine damit wenn ich jetzt mal einen Temperatur Fühler mit
define Temperatur_Norden CUL_HM 20DA4Berstelle
Zitat von: Beta-User am 10 Juni 2021, 17:46:30
Frage nochmal: Ist die jetzt vergebene HmID identisch zu der früheren (=der alten, für den HMLAN bisher gültigen), oder willst du jetzt alles ablernen und dann neu anlernen?
ja die HmID ist jetzt die richtige..!!
nein ich wil nichts ablernen, die Temperaturfühler sind ja noch im produktiv Fhem drin und wenn ich die so langsam übernehmen möchte das meinte ich.
nein beim manuellen define passiert nichts automatisch mit der vccu - Außer das martin ein manuelles konfigurieren im Detail verhindert ...
OK Otto
Einen Fühler habe ich ja schon drin von gestern, der hat jetzt das Attribut bei
IOgrp vccu drin stehen das sollte richitg sein
ich habe jetzt gemerkt das er den neuen Temp Fühler im suptype virtual drin hat das kann ich nicht einfach ändern, da meckert er
genau das meine ich :(
Hier hatte ich mal einen Würgaround diskutiert https://forum.fhem.de/index.php?topic=103344.0
Wobei der Fühler im ersten Post nicht gepairt aussah und kein IODev hatte, was mMn falsch ist.
ganz genau, so geht es mir jetzt, ich werde mal lesen was dort steht habe nur deinen Beitrag gelesen.
Denn ich wollte die Geräte so nach und nach jetzt umziehen.
Genau den Fühler hatte ich raus geschmissen und wollte ihn neu anlegen
Hmm, wenn die zentrale HmID identisch ist, sollte es gehen, dass dann über ein erneutes Pairing (würde "pair serial" empfehlen, die Nummern sind ja aus der alten Installation bekannt) mit der VCCU der Rest _korrekt_ ergänzt wird (ggf. muss man "Knöppe drücken").