Hallo,
ich habe vor dem Einbau einiger Schließerkontakt-Interfaces diese mit meiner Zentrale (VCCU, Cubietruck) gepairt. Anschließend habe ich eine Kopie von FHEM auf einem RaspPi aufgesetzt.
Ich hatte die Hoffnung, dass die Pairing Infos in den Sensoren gespeichert werden.
Allerdings sehe ich im neuen System zwar die Schließerkontakte, und diese senden auch, allerdings fehlt der PairedTo Eintrag.
Ein Unterschied ist, dass ich gleichzeitig von einem CUL (VCCU:CUL0) auf einen HMLAND (VCCU:HMUSB01) umgestiegen bin. Dazu habe ich in den fhem.config CUL0 durch HMUSB01 ersetzt. In der Hoffnung, dass die Reise dank VCCU dann einfach weitergehen würde..
Ist dieses Verhalten normal? Habe ich hier beim Einbau der Kontakte evtl. auf den Anlernknopf gedrückt?
Ein wenig stutzig hat mich gestern gemacht, dass ich in der neuen VCCU assignedIOs und IOList neu per Hand setzen musste.
Irgendwelche Ideen, wie ich es vermeiden kann, die Sensoren in den Anlernmodus zu versetzen?
Gruß
Ronny
ZitatIch hatte die Hoffnung, dass die Pairing Infos in den Sensoren gespeichert werden.
das ist auch so.
eigentlich sollte nach umzug alles weitergehen, es sei denn, dass der letzte stand in fhem nicht korrekt gespeichert war.
hast du auch die datei fhem.save mitgenommen.
Zitat von: frank am 19 Januar 2016, 13:00:44
hast du auch die datei fhem.save mitgenommen.
Argh.. an die habe ich nicht gedacht. Das wird es bestimmt sein!
In der Zwischenzeit habe ich auf dem neuen System Änderungen vorgenommen (Umbenennung der Aktoren). Ich versuche mal, testweise einzelne Sensoren in der fhem.save mit dem neuen Namen zu versehen.
Danke für den Hinweis, frank!
Ich habe einmal die drei Tags
Zitatsetstate TFK.Ankleide 2015-12-30 01:11:29 PairedTo 0xABCDEF
setstate TFK.Ankleide 2015-12-30 01:11:29 R-cyclicInfoMsg off
setstate TFK.Ankleide 2015-12-30 01:11:29 R-pairCentral 0xABCDEF
hinzugefügt und neugestartet, aber ohne Veränderung.
Gibt es eine elegante Möglichkeit, diese Config neu einzulesen?
grundsätzlich musst du eigentlich nur getconfig machen, damit fhem wieder alle infos hat.
Das habe ich schon vergeblich versucht. Kann es sein, dass die VCCU ein Ding weg hat - evtl. wegen des Interface Wechsels?
hast du das neue io in IOList eingetragen?
poste mal ein list der vccu.
Ja habe ich. Außerdem model CCU-FHEM per Hand gesetzt.
list vccu:
Internals:
DEF ABCDEF
IODev HMUSB01
NAME VCCU
NR 122
NTFY_ORDER 50-VCCU
STATE HMUSB01:ok,
TYPE CUL_HM
assignedIOs HMUSB01
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
channel_0D VCCU_Btn13
channel_0E VCCU_Btn14
channel_0F VCCU_Btn15
channel_10 VCCU_Btn16
channel_11 VCCU_Btn17
channel_12 VCCU_Btn18
channel_13 VCCU_Btn19
channel_14 VCCU_Btn20
channel_15 VCCU_Btn21
channel_16 VCCU_Btn22
channel_17 VCCU_Btn23
channel_18 VCCU_Btn24
channel_19 VCCU_Btn25
channel_1A VCCU_Btn26
channel_1B VCCU_Btn27
channel_1C VCCU_Btn28
channel_1D VCCU_Btn29
channel_1E VCCU_Btn30
channel_1F VCCU_Btn31
channel_20 VCCU_Btn32
channel_21 VCCU_Btn33
channel_22 VCCU_Btn34
channel_23 VCCU_Btn35
channel_24 VCCU_Btn36
channel_25 VCCU_Btn37
channel_26 VCCU_Btn38
channel_27 VCCU_Btn39
channel_28 VCCU_Btn40
channel_29 VCCU_Btn41
channel_2A VCCU_Btn42
channel_2B VCCU_Btn43
channel_2C VCCU_Btn44
channel_2D VCCU_Btn45
channel_2E VCCU_Btn46
channel_2F VCCU_Btn47
channel_30 VCCU_Btn48
channel_31 VCCU_Btn49
channel_32 VCCU_Btn50
Readings:
2015-12-30 16:51:13 CommandAccepted yes
2016-01-19 14:45:10 state HMUSB01:ok,
2016-01-19 13:38:38 unknown_324085 received
Helper:
HM_CMDNR 1
mId FFF0
rxType 1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
prefIO
vccu
ioList:
HMUSB01
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
dev 1
vrt 1
Attributes:
IODev HMUSB01
IOList HMUSB01
expert 2_full
model CCU-FHEM
subType virtual
webCmd getConfig:clear msgEvents
2016-01-19 14:45:10 state HMUSB01:ok,
der sieht doch gut aus.
bei den meisten batterie devices musst du natürlich aufs knöpchen drücken, damit sie aufwachen und befehle empfangen können.
Zitatlist vccu:
Code: [Auswählen]
Internals:
DEF F10703
und hier dann
Zitatsetstate TFK.Ankleide 2015-12-30 01:11:29 PairedTo 0xABCDEF
setstate TFK.Ankleide 2015-12-30 01:11:29 R-cyclicInfoMsg off
setstate TFK.Ankleide 2015-12-30 01:11:29 R-pairCentral 0xABCDEF
was ist denn jetzt deine gültige hmid?
Hallo Hary,
es ist die gleiche HMid. Ich hatte die fürs Forum abgeändert nach 0xABCDEF.
Zitat von: frank am 19 Januar 2016, 15:20:45
bei den meisten batterie devices musst du natürlich aufs knöpchen drücken, damit sie aufwachen und befehle empfangen können.
Ich hatte extra einen Tag gewartet und die meisten getConfigs wurden abgearbeitet, zumindest erschien ein CMDs_done.
Noch irgendwelche Ideen?
Also ich habe alle Infos eines Device aus der alten, vollständigen fhem.save in die Neue übernommen. Auf dem Weg dorthin umbenannt. Sehr nervig, aber es funktioniert.
Wie finde ich denn heraus, welche Geräte jetzt noch nur halbgar eingebunden sind? Gibt es hier nichts elegantes? Ich habe auf diese Weise bestimmt > 10 230V Schalter angelernt, die ich jetzt nun nicht extra ans Netz anschließen möchte, ob ein Knöpfchen zu drücken.
Ich könnte mich in den A... beißen, dass ich die fhem.save nicht mitgenommen habe.
Eigentlich sollte das mein neues Produktivsystem werden, aber so fange ich wohl nochmal neu an...
ZitatIch habe auf diese Weise bestimmt > 10 230V Schalter angelernt, die ich jetzt nun nicht extra ans Netz anschließen möchte, ob ein Knöpfchen zu drücken.
230v devices sind ständig wach. die kannst du sogar pairen, ohne knöpfchen zu drücken (pairSerial). getconfig sowieso.
kommst du an die knöpfchen nicht ran?
Ich komme an die Geräte leider nur schwer ran und kann außerdem gerade nur remote agieren.
Ich verstehe es nun so, dass ich eigentlich nicht mehr pairen muss, da diese Info in den Devices schon hinterlegt ist. (Auch erkennbar an "closed (send to MEINEVCCU)") Das heißt gleichzeitig, dass auch keine Gefahr besteht, dass eine andere Zentrale das Gerät "übernimmt". FHEM weiß davon nur so lange nichts, bis ich das Config Knöpfchen gedrückt und vorher ein getConfig ausgelöst habe.
Ist das richtig so?
Zitat von: derron am 20 Januar 2016, 13:05:52
Ich komme an die Geräte leider nur schwer ran und kann außerdem gerade nur remote agieren.
Ich verstehe es nun so, dass ich eigentlich nicht mehr pairen muss, da diese Info in den Devices schon hinterlegt ist. (Auch erkennbar an "closed (send to MEINEVCCU)") Das heißt gleichzeitig, dass auch keine Gefahr besteht, dass eine andere Zentrale das Gerät "übernimmt". FHEM weiß davon nur so lange nichts, bis ich das Config Knöpfchen gedrückt und vorher ein getConfig ausgelöst habe.
Ist das richtig so?
genau.
das übernehmen deiner devices kannst du eigentlich nur über aes mit eigenem key sicher verhindern. um ganz sicher zu gehen, müsstest du sogar das setzen der keys in den devices, das natürlich auch über funk geschieht, in einer "abhörsicheren" umgebung machen.
wer unbedingt will, kann sonst (ohne aes) auch deine hmid sniffen und sich als deine zentrale tarnen. aber diese ganzen scenarios sind bestimmt nur theoretischer natur.
Sorry, wenn ich das Thema nochmal aufgreife.
Ich habe in der Vergangenheit schon erfolgreich Devices umbenannt, in dem ich die fhem.cfg editiert habe. Alle Properties kamen korrekt mit. Die fhem.save wurde also beim Shutdown anscheinend abgeglichen mit den neuen Namen.
Daher war meine Überlegung jetzt, die alte fhem.save und alte fhem.cfg zu nehmen, FHEM starten, [Test: Alle Pairings OK], FHEM beenden, neue fhem.cfg überspielen, FHEM starten [TEST: Pairings weg].
Wieso? Übersehe ich etwas?
ZitatIn der Zwischenzeit habe ich auf dem neuen System Änderungen vorgenommen (Umbenennung der Aktoren).
das passt ja dann nicht mehr.
Dann habe ich immer noch ein Verständnisproblem, wo fhem seine Settings ablegt. Wo also noch, ausser in fhem.cfg und fhem.save?
Also das Umbenennen von Geräten über eine abgeänderte fhem.cfg ist doch ein legitimer Weg und führt doch nicht zu einer korrupten fhem.save?
Es gibt Register und peering welche im device liegen. Fhem liest diese aus dem device. Eine Veränderung in fhem.cfg aendert nicht das device.
Die Kopie der Register und peers kann über hminfo gesichert werden. Aber auch das ist eine Kopie.
Das sollte im Einsteigerdoc sowie wiki hm und hminfo beschrieben sein, hoffentlich ein wenig sinnvoll.
Ein umbenennen im system bietet/sollte bietenmdass wesentliche Zusammenhänge mit geändert werden. Wenn du es in fhem.cfg editierst gibt es keine Unterstützung. Die ist im system und 2mal mache ich es zumindest nicht.
Zitat von: martinp876 am 22 Januar 2016, 23:01:41
Wenn du es in fhem.cfg editierst gibt es keine Unterstützung. Die ist im system und 2mal mache ich es zumindest nicht.
Ähh, kannst du ein wenig mehr zu den Zusammenhängen sagen? Oder wo ich darüber etwas nachlesen kann? Ich möchte es gerne tiefergehend verstehen. Schlussendlich möchte ich nicht nur ein stabiles und konsistentes System, sondern mir im Fehlerfall auch selbst helfen können.
Das "offizielle" Rename von 7 Schließerkontakten über die CMD hat übrigens auch nur zur Hälfte funktioniert - Logfile und SVG Plot blieben auf der Strecke. Aber das meinst du wahrscheinlich schon mit "sollte bieten"..
Allgemeine Anleitungen habe ich nicht.
Beim rename werden (hoffentlich) alle operationellen Namen geändert. Sicher nicht betroffen sind historische Daten, also logfiles o.ä.
Auch notifies und andere regexp können nicht beinhaltet sein. Somit auch die operationellen filter für logs.
Ist aber kein hm Thema.