Servus,
ich hab mal wieder ein kleines Problem. Und zwar wollte ich vom Pi mit USB-Stick (original Homematic) auf eine XEN Debian VM mit Lan Gateway umsteigen.
Lan Gateway deshalb weil der USB Stick nicht durchgereicht werden kann (oder ich es nicht geschafft hab) und weil der HM Lan ja nicht mehr verfügbar ist (gebraucht wollte ich (noch) nicht).
So bin dann mal nach folgender Doku vorgegangen weil im wiki.fhem ja nicht sooo viel steht. Der Link ist ja hoffentlich erlaubt...
http://www.meintechblog.de/2017/01/howto-homematic-funk-lan-gateway-mit-fhem-verwenden/
Ich bekomme dann beim Neustart gleich mal angezeigt das die Geräte den HMLANGW nicht finden können. Stecke ich den Stick dann ab dann bekomme ich im Event monitor angezeigt das der nicht mehr connected ist ... also irgendwie will das alles nicht so.
Gibt es da irgendwie ne Anleitung wie ich vorgehen kann? Oder hat wer das schon mal gemacht und paar Tipps am start?
Frag das doch am besten mal den Autor der Anleitung, nach der du vorgegangen bist!? Dann kann er die gleich korrigieren / ergänzen, indem er dein Feedback einarbeitet.
Das werde ich bei Gelegenheit auch noch machen. Frag bei sowas aber lieber gleich mal an der Quelle nach weil das Modul zum einbinden ja auch von hier kommt...
Mich hätte es aber trotzdem interessiert ob sowas schon mal wer gemacht hat und wie hier vorgegangen wurde.
Kann ich das umgehen wenn ich eine VCCU verwende? Oder ändert das nichts an meinen Problem?
Hi,
du hast Doch auf dem XEN Debian VM das System neu gemacht oder?
Funktioniert denn das Lan Gateway?
Oder hast Du das Langateway an das alte System angebunden und willst jetzt umziehen? So würde ich das machen.
Gruß Otto
Im Wiki steht zwar nicht viel drin, dafür aber auch nicht so viel unnötiger Kram wie in der von dir genannten Doku.
Vielleicht solltest du mal ne Aufzählung machen, was du alles gemacht hast.
-lib-crypt-rijndael-perl installiert?
-HMLGW update?
-feste IP am HMLGW eingestellt?
-...
Die Installation einer VCCU empfiehlt sich auf jeden Fall.
@Otto123:
Auf dem Xen hab ich bis jetzt nur einen neue VM aufgesetzt. Da hab ich noch nichts probiert.
Hab noch ein bisschen rum gespielt und hab es dann auch mal geschafft das es sich am Server anmeldet. Also das Gateway sollte auf jeden Fall funktionieren.
Ich wollte erst das Gateway an das alte System anbinden und dann eben den Stick entfernen und schauen das alles wieder läuft. Mit der Konfig wollte ich dann einfach umziehen...
@automatisierer
Die Doku hat halt nicht schlecht ausgeschaut und nachdem es ja bei ein paar vor mir anscheinend funktioniert hat... was hätte ich alles weg lassen können bzw. wie hätte man das anders machen können?
-lib-crypt-rijndael-perl installiert? - hab ich installiert
-HMLGW update? - Hab ich nach Anleitung gemacht. Aber irgendwie hab ich da keine Rückmeldung bekommen ob sich was getan hat oder nicht.
-feste IP am HMLGW eingestellt? - Nö hab dem über DHCP eine feste IP zugewiesen. Kann der nur mit einer festen eingestellten?
Ja das hab ich mir schon fast gedacht aber bis jetzt war es bei mir nicht notwendig. Würde sich jetzt aber gleich mit anbieten.
FHEM muss halt wissen welche IP der HMLGW hat, meine bevorzugte Variante ist eine statische IP im HMLGW zu vergeben. Wenn sie sich später einmal ändert geht dann wieder die Fehlersuche los...
Die Funk- und Lan-Firmware müssen schon geupdatet werden.
Nimm doch mal den Netfinder (http://www.eq-3.de/service/downloads.html?id=53), damit kannst du sehen welche LAN_Firmware der HMLGW hat und sie auch gleich updaten, wenn es noch nicht geschehen ist. Die IP kannst du damit auch einstellen...
Und die Funk-Firmware solltest du auch unbedingt updaten, da keine Rückmeldung kam, bitte wie im Wiki beschrieben nochmal durchführen.
Gut da bei mir aber alle IP´s über den DHCP zugewiesen werden (aus mehreren Gründen) bekommt der aber immer diese IP. Ich kann es aber auch mal kurz testen ob es einen Unterschied macht
Da hab ich die 1.1.5 drauf. Scheint dann wohl doch funktioniert zu haben.
Wo sollte ich den die Rückmeldung erhalten? Logfile? Bzw. wo kann ich nachschauen was aktuell drauf ist?
Natürlich funktioniert das mit der zugewiesenen IP, ich kenne das aber als nicht so zuverlässig und nutze daher immer statische IP's.
Das Update der Funk-Firmware wird aus FHEM gemacht, mit dem Befehl wie er im Wiki Steht und der zugehörigen Firmware-Datei. Ist schon ein paar Tage her, dass ich das gemacht hab, aber ich denke im LOG wird etwas dazu stehen - einfach mal rein schauen!
Die Firmware-Version siehst du in der FHEM Definition des HMLGW in den Readings.
Also. Noch mal step by step:
Du hast deine alte FHEM Installation auf einem PI laufen.
An dieses FHEM willst du den HMLGW ranstöpseln?
Wenn ja:
FHEM ist aktuell? (update)
wie sieht die Definition des HMLGW aus? ('list <HMLGW>' in die FHEM-Befehlszeile und die Ausgabe hier posten.(hmKey unkenntlich machen))
ZitatIch bekomme dann beim Neustart gleich mal angezeigt das die Geräte den HMLANGW nicht finden können.
Welche Geräte können da Was nicht finden? Der Satz ergibt für mich so keinen Sinn.
Hi,
Es gibt ein Problem, welches man bekommt wenn man in eine fertige FHEM Installation einen neuen IO packt und dann den alten raus nimmt. Dann steht der neue in der cfg ganz hinten un die HM Geräte finden keinen IO.
Das ist der einzige Fall wo ich empfehle (wo es sein muss) die fhem.cfg zu editieren und die DEF für den IO komplett an die Position des alten IO zu verschieben.
Aber bevor das passiert:
Beide IOs in Betrieb nehmen.
VCCU definieren nach Wiki -> https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
Schauen das alles auch mit dem neuen IO arbeiten kann. Einzelnes Gerät zum testen.
Dann altes Gerät rausnehmen (ist etwas umfangreicher als der eine Satz)
hmInfo definieren - > configCheck muss Fehlerfrei sein!
Dann Umziehen.
Gruß Otto
@automatisierer:
Ja ich hatte eigentlich auch immer alles auf festen IPs aber momentan bin ich da etwas faul geworden.
Im Logfile stehen jetzt die ganzen Fehler. Nach was müsste ich da genau suchen? Wenn ich nach "updateCoPro" suche finde ich nichts
Also bei den Readings steht:
D-LANfirmware 1.1.5
D-firmware 1.0.6
Ist das die neuste?
Ja genau. Momentan ist alles noch auf dem Pi mit USB Stick.
Da wollte ich den HMLGW dran fummeln.
Version ist aktuell. Hatte da vorher das Update gemacht.
Das wäre die Definition:
Internals:
AssignedPeerCnt 0
CNT 45
DEF 10.0.0.21
DEVCNT 45
DevState 99
DevType LGW
DeviceName 10.0.0.21:2000
FD 47
LastOpen 1488984635.48822
NAME HMLANGW
NR 167
PARTIAL
RAWMSG 040202
RSSI -53
STATE opened
TYPE HMUARTLGW
XmitOpen 1
msgLoadCurrent 1
msgLoadHistory 1/-/-/-/-/-/-/-/-/-/-/-
msgLoadHistoryAbs 1/0/-/-/-/-/-/-/-/-/-/-/-
owner HMIDXX
Helper:
CreditTimer 26
FW 65542
Initialized 1
Ackpending:
LastSendLen:
3
3
Log:
IDs:
Roundtrip:
Delay 0.00397610664367676
Loadlvl:
lastHistory 1488984938.38799
Peers:
Readings:
2017-03-08 15:50:38 D-HMIdAssigned HMIDXX
2017-03-08 15:50:38 D-HMIdOriginal FFFFFF
2017-03-08 15:50:35 D-LANfirmware 1.1.5
2017-03-08 15:50:38 D-firmware 1.0.6
2017-03-08 15:50:35 D-serialNr NEQ0382390
2017-03-08 15:50:35 D-type eQ3-HM-LGW
2017-03-08 15:50:38 cond ok
2017-03-08 15:55:40 load 1
2017-03-08 15:50:38 loadLvl low
2017-03-08 15:50:35 state opened
Keepalive:
CNT 44
DEVCNT 43
DevState 99
DevType LGW-KeepAlive
DeviceName 10.0.0.21:2001
FD 5
LastOpen 1488984635.8769
NAME HMLANGW:keepAlive
NR 168
PARTIAL
STATE opened
TEMPORARY 1
TYPE HMUARTLGW
XmitOpen 0
Helper:
NextKeepAlive 1488985027.17685
Log:
Resolve 1
IDs:
Readings:
2017-03-08 15:50:35 state opened
Lgwhash:
Attributes:
hmId HMIDXX
lgwPw Passwortx
Nach dem Neustart wird folgendes ausgegeben:
Messages collected while initializing FHEM:
configfile: OG_Bewe_Gang: unknown IODev HMLANGW specified
Treppenlicht: unknown IODev HMLANGW specified
...
Das kommt ja weil ich folgendes laut Anleitung gemacht habe?
Für Umsteiger, die von einem HMLAN kommen, ist es nun noch essentiell, das sog. "IODev" in allen HomeMatic-Komponenten zu aktualisieren.
Ein Umstieg lohnt sich aus funktionaler Sicht nicht, sondern ist beispielsweise für den Fall eines Hardware-Defekts am HMLAN gedacht.
Zuvor empfehle ich jedoch, ein Backup anzufertigen. Hierfür wird in der Kommandozeile von FHEM einfach der Befehl
1
backup
abgesetzt. Anschließend wird über einen Klick auf "Edit files" -> "fhem.cfg" die FHEM-Konfigurationsdatei geöffnet. Eine Möglichkeit, den alten HMLAN gegen das neue Funk-Gateway auszutauschen, ist den gesamten Inhalt der Datei in einen Texteditor herauszukopieren und mittels "Suchen und Ersetzen" die Passage "IODev HMLAN1" gegen den Eintrag "IODev HMLANGW" zu ersetzen, wenn der alte HMLAN in FHEM die Bezeichnung HMLAN1 hatte. Der editierte Inhalt kann dann wieder in die fhem.cfg zurückgespielt werden.
Hätte ich das per Hand ändern sollen bei allen Devices?
@Otto123:
Glaub das ist ja bei mir jetzt auch so. Hätte ja auch die cfg editiert.
Das mit der VCCU muss ich mir erst nochmal durchlesen. Das ist schon wieder ne Weile her. Aber so wäre es dann sicher besser!
Ich spiel mal das alte Backup wieder ein und teste es so mal
Bitte strukturiere deinen Post:
Wenn Du was aus einer Beschreibung zitierst nimm Zitat der Knopf oberhalb von :-\ :-*
Wenn Du ein list oder sowas postest nim die # Taste oberhalb von :-X
Editiere deinen letzten Post bitte nochmal damit man den versteht.
Gruß Otto
Sorry aber ich hatte noch nen Blocker an und konnte deshalb die Leiste nicht sehen. Wollte schon mit --- und ___ anfangen!
So hoffentlich besser?
Also wenn Du kannst geh nochmal zurück auf deinen Urzustand und mache es neu.
Das Gateway ist denke ich ok -> https://wiki.fhem.de/wiki/HM-LGW-O-TW-W-EU_Funk-LAN_Gateway
Dann mach das bitte mit der VCCU, das geht aus meiner Sicht ziemlich sanft. Teste mit einem Gerät, frage wenn Du was nicht verstehst.
Wie gesagt bevor wir den USB abnabeln musst Du mal etwas in der fhem.cfg per Hand verschieben. Aber vorher sollte das alles mit dem neuen erstmal sauber laufen.
Hast Du etwas Zeit? Oder muss das alles heute? ::)
Setze auf der VM ein frisches FHEM auf, damit dort schon mal alle Module und Dienste eingerichtet sind.
Ganz grob habe ich das mal hier (http://heinz-otto.blogspot.de/2017/01/umzug-von-fhem.html) aufgeschrieben. Aber ich finde son ein Umzug ist eigentlich individuell.
Gruß Otto
Zitat von: new_rasp am 08 März 2017, 16:08:11
@automatisierer:
Ja ich hatte eigentlich auch immer alles auf festen IPs aber momentan bin ich da etwas faul geworden.
Im Logfile stehen jetzt die ganzen Fehler. Nach was müsste ich da genau suchen? Wenn ich nach "updateCoPro" suche finde ich nichts
Also bei den Readings steht:
D-LANfirmware 1.1.5
D-firmware 1.0.6
Ist das die neuste?
nö, so schauts bei mir aus.
D-LANfirmware 1.1.5 2017-03-08 11:48:44
D-firmware 1.4.1 2017-03-08 11:48:47So stehts im Wiki:
Firmwareupdate
Die Verwendung einer Firmware >= 1.4.1 für die Rf-Interfaces wird dringend empfohlen, die Rf-Firmware kann direkt aus Fhem heraus aktualisiert werden:
HM-MOD-UART: coprocessor_update.eq3
HM-LGW-O-TW-W-EU: coprocessor_update_hm_only.eq3
Das Update wird in FHEM mit "updateCoPro" angestossen:
set myHmUART updateCoPro /path/to/coprocessor_update.eq3
für den HMUART bzw.
set myHmLGW updateCoPro /path/to/coprocessor_update.eq3
für das HMLAN.
Zusätzlich sollte die LAN-Firmware des HM-LGW-O-TW-W-EU auf mindestens Version 1.1.5 aktualisiert werden: hm-lgw-o-tw-w-eu_update.eq3. Dies kann entweder mit dem HomeMatic Netfinder (Java, betriebssystemübergeifend) oder den eQ-3 Tools (x86/arm, Linux) erfolgen. Die Links im Wiki funktionieren... Und das updateCoPro ist ein set Befehl für FHEM...
@Otto, du bist doch Wiki Bearbeiter. Kannst du aus dem etwas verwirrenden 'für das HMLAN' ein 'für das HMLGW' machen.
Ja das war jetzt auch mein Plan. Aber leider geht es mit der wiki.fhem anleitung nicht...
Was hab ich gemacht.
Bin wieder zurück auf Anfang. Also FHEM auf dem Raspi mit Stick.
Danach hab ich Rasbian upgedatet.
Dann hab ich FHEM upgedatet.
Danach bin ich 1 zu 1 nach dem wiki Eintrag vorgegangen... Hier bleibt der aber auf disconnected!
Internals:
CNT 80
DEF 10.0.0.21
DEVCNT 80
DevState 0
DevType LGW
DeviceName 10.0.0.21:2000
FD 5
LGW_Init 10
LastOpen 1488989217.39332
NAME HMLANGW
NR 167
PARTIAL
STATE opened
TYPE HMUARTLGW
XmitOpen 0
Helper:
Log:
IDs:
Readings:
2017-03-08 17:06:57 D-LANfirmware 1.1.5
2017-03-08 17:06:57 D-serialNr NEQ0382390
2017-03-08 17:06:57 D-type eQ3-HM-LGW
2017-03-08 17:01:43 cond disconnected
2017-03-08 17:01:43 loadLvl suspended
2017-03-08 17:06:57 state opened
Keepalive:
CNT 80
DEVCNT 80
DevState 0
DevType LGW-KeepAlive
DeviceName 10.0.0.21:2001
FD 47
LGW_Init 10
LastOpen 1488989217.41073
NAME HMLANGW:keepAlive
NR 201
PARTIAL
STATE opened
TEMPORARY 1
TYPE HMUARTLGW
XmitOpen 0
Helper:
Log:
Resolve 1
IDs:
Readings:
2017-03-08 17:06:57 state opened
Lgwhash:
Attributes:
hmId HMIDXX
lgwPw Passwortx
Von dem her müsste ich jetzt wieder die andere Anleitung benützen weil es hier ja dann funktioniert. Nur müsste ich halt bevor ich die cfg ändere die VCCU einbauen?
Oder kann sich wer den wiki Eintrag nochmal anschauen ob da evtl ein Fehler ist?
Aber gleich mal Dankeschön für die Hilfe. Bei der VCCU hab ich sicher dann auch noch Fragen ;)
Das muss nicht alles heute sein! :D
ach ja... und das kommt danach im Logfile
2017.03.08 17:13:28 1: 10.0.0.21:2000 reappeared (HMLANGW)
2017.03.08 17:13:28 3: HMLANGW:keepAlive device opened
2017.03.08 17:13:28 1: HMUARTLGW HMLANGW wants to initiate encrypted communication, but Crypt::Rijndael is not installed.
2017.03.08 17:13:28 1: HMUARTLGW HMLANGW:keepAlive wants to initiate encrypted communication, but Crypt::Rijndael is not installed.
2017.03.08 17:13:38 1: HMUARTLGW HMLANGW LGW init did not complete after 10s
2017.03.08 17:13:38 3: HMLANGW device closed
2017.03.08 17:13:38 3: Opening HMLANGW:keepAlive device 10.0.0.21:2001
2017.03.08 17:13:38 1: 10.0.0.21:2000 reappeared (HMLANGW)
2017.03.08 17:13:38 3: HMLANGW:keepAlive device opened
2017.03.08 17:13:38 1: HMUARTLGW HMLANGW wants to initiate encrypted communication, but Crypt::Rijndael is not installed.
2017.03.08 17:13:38 1: HMUARTLGW HMLANGW:keepAlive wants to initiate encrypted communication, but Crypt::Rijndael is not installed.
2017.03.08 17:13:48 1: HMUARTLGW HMLANGW LGW init did not complete after 10s
2017.03.08 17:13:48 3: HMLANGW device closed
2017.03.08 17:13:48 3: Opening HMLANGW:keepAlive device 10.0.0.21:2001
2017.03.08 17:13:48 1: 10.0.0.21:2000 reappeared (HMLANGW)
2017.03.08 17:13:48 1: HMUARTLGW HMLANGW wants to initiate encrypted communication, but Crypt::Rijndael is not installed.
2017.03.08 17:13:48 3: HMLANGW:keepAlive device opened
2017.03.08 17:13:48 1: HMUARTLGW HMLANGW:keepAlive wants to initiate encrypted communication, but Crypt::Rijndael is not installed.
Dazu noch was in der anderen Anleitung gefunden:
sudo apt-get install libcrypt-rijndael-perl
glaub das fehlt bei mir auch!
Also das ist wirklich abgegangen. Jetzt ist der connected!
Und es scheint als würde das firmware upgrade auf funktionieren!
2017.03.08 17:21:39 3: HMLANGW: Unknown code A0B6FA001354D4E2A112A020E::-31:HMLANGW, help me!
2017.03.08 17:21:40 3: HMLANGW: Unknown code A0A6F8002354D4E2A112A00::-31:HMLANGW, help me!
2017.03.08 17:23:16 3: HMLANGW device closed
2017.03.08 17:23:16 3: Opening HMLANGW:keepAlive device 10.0.0.21:2001
2017.03.08 17:23:16 1: 10.0.0.21:2000 reappeared (HMLANGW)
2017.03.08 17:23:16 3: HMLANGW:keepAlive device opened
2017.03.08 17:23:16 3: HMUARTLGW HMLANGW BidCoS-port opened
2017.03.08 17:23:16 3: HMUARTLGW HMLANGW:keepAlive KeepAlive-port opened
2017.03.08 17:23:17 1: HMUARTLGW HMLANGW starting firmware upgrade
Jetzt schaut es besser aus! Bitte im Wiki die Zeile hinzufügen!
sudo apt-get install libcrypt-rijndael-perl
D-firmware 1.4.1 2017-03-08 17:23:28
Dann mach ich mal ein zwischen Backup und versuch mit danach mit der VCCU
So dann mal gleich ne Frage wegen der VCCU... ;)
Hab jetzt mal folgendes konfiguriert (natürlich angepasst an mein System)
define VCCU CUL_HM 123456
attr VCCU IOList CUL0,HMLAN0
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update
Scheint alles zu funktionieren:
Internals:
DEF HMIDXX
IODev hmusb
NAME vccu
NOTIFYDEV global
NR 168
NTFY_ORDER 50-vccu
STATE hmusb:ok,HMLANGW:ok,
TYPE CUL_HM
assignedIOs HMLANGW,hmusb
Readings:
2017-03-08 18:12:07 state hmusb:ok,HMLANGW:ok,
Helper:
HM_CMDNR 90
mId FFF0
rxType 1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
prefIO
vccu
ioList:
hmusb
HMLANGW
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
vrt 1
Tmpl:
Attributes:
IODev hmusb
IOList hmusb,HMLANGW
expert 2_raw
model CCU-FHEM
subType virtual
webCmd virtual:update
Muss ich da jetzt noch was konfigurieren? Oder passt das jetzt schon so?
@Otto123:
Du hast gemeint mit einem Device testen? Wie gehe ich hier vor? Glaub ich steh grad bisschen aufm Schlauch
So hab einstweilen mal FHEM auf dem XEN installiert. Hierzu wieder eine kleine Info.
Hier wird beschrieben
https://forum.fhem.de/index.php?topic=27679.0
das man fhem auch aus dem debian-repository installieren kann... das geht irgendwie nicht mehr. Hab über
sudo apt-get install libdevice-serialport-perl
sudo apt-get install libio-socket-ssl-perl
# fhem-X.Y.deb bitte mit der aktuellsten, stabilen Version ersetzen
wget http://fhem.de/fhem-X.Y.deb
sudo dpkg -i fhem-X.Y.deb
installiert.
Hab mir das laufende System angeschaut. Hier ist ja bei den Devices der
IODev hmusb
eingetragen. Muss ich das ändern? Werd da ausm Wiki nicht ganz schlau...
wenn du eine vccu erstellt hast, dann kannst du das IODev so lassen wie es ist, dass ist dann nebensächlich. Dafür gibts aber ein Attribut IOgrp, da musst du dann den Namen der vccu eintragen. Oder halt ein preffIO (bevorzugtes IO)
Zitat von: automatisierer am 08 März 2017, 21:11:45
wenn du eine vccu erstellt hast, dann kannst du das IODev so lassen wie es ist, dass ist dann nebensächlich. Dafür gibts aber ein Attribut IOgrp, da musst du dann den Namen der vccu eintragen. Oder halt ein preffIO (bevorzugtes IO)
Muss ich dann also bei jedem Device das Attribut IOgrp mit dem Wert vccu hinzufügen? Weil wenn dann sollte er ja das nächste GW verwenden (für später mal)
attr <device> IOgrp VCCU
Zitat von: new_rasp am 08 März 2017, 17:26:52
Jetzt schaut es besser aus! Bitte im Wiki die Zeile hinzufügen!
Hi,
ich habe doch gefragt ob Du Zeit hast. Ich bin nicht immer online ;)
Welchen Wiki Eintrag meinst Du hier? Bitte Link.
Am einzelnen Device: Das IODev Attribute spielt bei der VCCU keine Rolle mehr! wie Automatisierer schon sagt.
Mit dem attr IOgrp VCC:<prefIO>
also bei Dir (wenn ich richtig liege) attr <> IOgrp VCCU:HMLANGW stellst Du das Langateway als bevorzugten IO ein.
Du kannst aber auch jederzeit, mit set <IO> close einen IO abschalten.
Hier (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Setzen_der_IOgrp_auf_.28fast.29_allen_Devices_mit_einem_einzigen_Befehl)steht doch genau wie Du IOgrp für alle setzen kannst.
Gruß Otto
Zitat von: Otto123 am 08 März 2017, 22:23:29
Hi,
ich habe doch gefragt ob Du Zeit hast. Ich bin nicht immer online ;)
Welchen Wiki Eintrag meinst Du hier? Bitte Link.
Am einzelnen Device: Das IODev Attribute spielt bei der VCCU keine Rolle mehr! wie Automatisierer schon sagt.
Mit dem attr IOgrp VCC:<prefIO>
also bei Dir (wenn ich richtig liege) attr <> IOgrp VCCU:HMLANGW stellst Du das Langateway als bevorzugten IO ein.
Du kannst aber auch jederzeit, mit set <IO> close einen IO abschalten.
Hier (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Setzen_der_IOgrp_auf_.28fast.29_allen_Devices_mit_einem_einzigen_Befehl)steht doch genau wie Du IOgrp für alle setzen kannst.
Gruß Otto
Servus,
kein Thema. Muss auch nicht heute sein. Wollte nur loswerden das es jetzt mal soweit funktioniert. ;)
Also das mit dem Wiki hab ich die
https://wiki.fhem.de/wiki/HM-LGW-O-TW-W-EU_Funk-LAN_Gateway
Seite gemeint. Hier fehlt der Hinweis das man
sudo apt-get install libcrypt-rijndael-perl
noch ausführen muss. Vorher gehts nicht.
Okay dann muss ich das noch bei allen hinzufügen. Vorher teste ich das mal mit einem.
Soll ich dann auf
vccu:HMLANGW
das Attribute setzen oder das auf
attr <device> IOgrp VCCU
lassen wenn ich noch ein weiteres GW hinzufüge? Das müsste ich ja dann wieder bei allen ändern wenn die Reichweite schlechter sein sollte und ich noch einen zweiten benötigen würde?
Das mit einem Befehl kann ich ja testen wenn es auf einem funktioniert
Hi,
aber hier (https://wiki.fhem.de/wiki/HM-LGW-O-TW-W-EU_Funk-LAN_Gateway#Verwendung_AES_in_FHEM)steht doch, das man das Paket installieren muss!?
attr <device> IOgrp VCCU
setzt die VCCU und ihre Eigenschaften bei dem Device. D.h. die VCCU entscheidet über den IO. Wenn man VCCU:<IO> einstellt wird zum senden der gewählte IO verwendet.
Alle IOs hören immer mit!
Gruß Otto
Ups... :-[ Das hab ich irgendwie überlesen! Sorry
Okay dann werde ich es mit
attr <device> IOgrp vccu (habs bei mir klein geschrieben was ja hoffentlich kein Problem sein sollte)
versuchen. Ist ja besser in Hinsicht auf später.
Danach gehts dann mit der cfg weiter?
hab jetzt mal bei einem Bewegungsmelder IOgrp vccu hinzugefügt...
Wie sehe ich jetzt das es funktioniert? Im Log steht nix besonderes. Der schaltet aber noch wie konfiguriert...
mach mal ein list von dem Bewegungsmelder. Aber wie schon gesagt, mithören tut jeder. Da der Bewegungsmelder nur "hört" ist diese Gerät zum Testen sicher suboptimal.
Gruß Otto
das wäre noch ein list
Internals:
DEF 3267F2
HMLANGW_MSGCNT 29
HMLANGW_RAWMSG 0500002ECA84103267F2HMIDXX06011B00
HMLANGW_RSSI -46
HMLANGW_TIME 2017-03-08 23:02:01
IODev hmusb
LASTInputDev hmusb
MSGCNT 58
NAME OG_Bewe_Gang
NOTIFYDEV global
NR 22
NTFY_ORDER 50-OG_Bewe_Gang
STATE noMotion
TYPE CUL_HM
hmusb_MSGCNT 29
hmusb_RAWMSG E3267F2,0000,006C57A2,FF,FFC4,CA84103267F2HMIDXX06011B00
hmusb_RSSI -60
hmusb_TIME 2017-03-08 23:02:01
lastMsg No:CA - t:10 s:3267F2 d:HMIDXX 06011B00
peerList OG_Treppenlicht,
protLastRcv 2017-03-08 23:02:01
rssi_at_HMLANGW avg:-46.17 min:-49 max:-44 lst:-46 cnt:29
rssi_at_hmusb avg:-61.41 min:-63 max:-58 lst:-60 cnt:29
Readings:
2017-03-08 21:14:03 Activity alive
2015-03-22 14:08:10 CommandAccepted yes
2015-03-22 14:08:08 D-firmware 1.6
2015-03-22 14:08:08 D-serialNr LEQ09870XX
2015-03-22 14:08:10 PairedTo 0xHMIDXX
2015-03-22 14:07:52 R-OG_Treppenlicht-peerNeedsBurst off
2015-03-22 14:08:10 R-brightFilter 7
2015-03-22 14:08:10 R-captInInterval off
2015-03-22 14:07:51 R-evtFltrNum 1
2015-03-20 21:06:22 R-evtFltrPeriod 1 s
2015-03-22 14:08:10 R-minInterval 30
2015-03-22 14:07:51 R-pairCentral 0xHMIDXX
2015-03-22 14:08:10 RegL_00. 02:01 0A:35 0B:4D 0C:4E 00:00
2015-03-22 14:08:10 RegL_01. 01:12 02:71 08:00 22:00 00:00
2015-03-22 14:08:11 RegL_04.OG_Treppenlicht 01:00 00:00
2017-03-08 23:02:01 battery ok
2017-03-08 23:02:01 brightness 27
2017-03-08 23:02:01 cover closed
2017-03-08 22:59:24 motion off
2017-03-08 22:58:52 motionCount 249_next:30s
2017-03-08 22:59:24 motionDuration 32
2017-03-08 19:26:57 peerList OG_Treppenlicht,
2015-06-10 17:41:24 powerOn 2015-06-10 17:41:24
2017-03-08 23:02:01 recentStateType info
2017-03-08 22:59:24 state noMotion
2017-03-08 22:58:52 trigger_cnt 249
Helper:
HM_CMDNR 202
mId 00C1
rxType 28
supp_Pair_Rep 0
Ack:
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +3267F2,00,00,00
nextSend 1489010521.42543
rxt 2
vccu vccu
p:
3267F2
00
00
00
Mrssi:
mNo CA
Io:
HMLANGW -46
hmusb -58
Prt:
bErr 0
sProc 0
sleeping 1
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmlangw:
avg -46.1724137931035
cnt 29
lst -46
max -44
min -49
At_hmusb:
avg -61.4137931034483
cnt 29
lst -60
max -58
min -63
Shadowreg:
Tmpl:
Attributes:
IODev hmusb
IOgrp vccu
actCycle 000:10
actStatus alive
alarmDevice Sensor
alarmSettings alarm6,|OG_Bewe_Gang:motion|OgBeGang|on
autoReadReg 4_reqStatus
expert 2_full
firmware 1.6
model HM-Sen-MDIR-O-2
peerIDs 00000000,2A112A01,
room CUL_HM
serialNr LEQ0987092
subType motionDetector
wäre es mit einem Relais besser zu testen?
Naja, vielleicht egal. Man sieht eigentlich das alles arbeitet.
Du könntest mit attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual:FILTER=model!=ActionDetector IOgrp VCCU
Das attr überall setzen und dann mal mit set <IO> close einen IO abschalten.
Gruß Otto
Zitat von: Otto123 am 08 März 2017, 23:29:16
Naja, vielleicht egal. Man sieht eigentlich das alles arbeitet.
Du könntest mit attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual:FILTER=model!=ActionDetector IOgrp VCCU
Das attr überall setzen und dann mal mit set <IO> close einen IO abschalten.
Gruß Otto
Okay. Dann werde ich mal versuchen alle umzustellen
Danach das set <IO> close? Also in meinen Fall
set hmusb close
Oder hast du mit dem close was anderes gemeint? Kann ich leider erst bisschen später testen weil Frau mit der Hausanlage alleine ist :D
Guten Morgen,
Genau mit close schaltest Du den IO quasi aus. Wird aber beim neustart nicht beachtet, d.h. nach einem neustart ist er wieder open. Dauerhaft geht es mit dem attr <IO> dummy 1
Du kannst das filter auch vorher mal ungefährlich mit list testen, da siehst Du welche Geräte das attr bekomen würden, also
list TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual:FILTER=model!=ActionDetector
Gruß Otto
Servus,
danke für den Hinweis. Habs erst mal so ausprobiert. Nachdem alles gut ausgeschaut hat hab ich mich jetzt ran gewagt! ;
Also erst noch
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual:FILTER=model!=ActionDetector IOgrp vccu
und dann gleich
set hmusb close
Schaut alles gut aus meiner Meinung. Config Check ist auch schön leer geblieben. Soll ich wieder ein list posten? Oder wie gehe ich jetzt am besten weiter vor? (werd mal schnell wieder ein Backup erstellen)
Naja, ist doch gut :) beobachten.
In der Zwischenzeit die VM vorbereiten! Das wichtigste ist die debian Pakete zu installieren die Deine Module brauchen.
Version gibt Dir die Liste Deiner verwendeten Module aus.
Damit gehst Du die commandref durch und hoffst mal, dass überall dazu steht was als Voraussetzung gebraucht wird.
Hier gibt es sowas wie eine default Liste https://debian.fhem.de/ aber die muss nicht komplett zu Dir passen.
Ich hatte hier mal angefangen mit meinen Modulen -> https://docs.google.com/spreadsheets/d/1_CkTYUzsJvysC6Xwn7VeXTt1rxhDW89YZCaQcFeReFw/edit?usp=sharing
Gruß Otto
Da steh ich jetzt wieder bisschen auf dem Schlauch. Ich hab jetzt z.B.
95_Alarm.pm
Das wäre ja dann ein Modul was ich brauche. Nur verstehe ich jetzt nicht wie ich das Modul installieren kann. Einfach beim neuen die Alarmanlage wieder so konfiguieren wie die vom alten?
attr global userattr alarmDevice alarmSettings
define AAA Alarm
attr AAA room AlarmRoom
set AAA unlock
Oder kann man die Module auch anders installieren? (Steht das nicht alles im Backup)
Wegen der Default Liste... Also den "stable" Eintrag hab ich nicht mehr. Muss ich jetzt einfach
sudo sed -i /debian.fhem.de/d /etc/apt/sources.list
ausführen?
Sorry aber da steig ich gerade wieder mal nicht ganz durch
Nachtrag:
HMinfo ist auch dabei. Das muss ja dann wohl über
define hm HMinfo
angelegt werden. Somit hätte ich ja auch das Modul installiert. Aber bei den anderen...
Zur FHEM Installation meine Notizen -> http://heinz-otto.blogspot.de/2016/09/fhem-in-wenigen-schritten.html
Passt nicht alles weil etwas RPI lastig aber weiter unten passt es schon.
Die FHEM Module brauchst Du nicht installieren, das passiert beim Restore.
Aber manche Module brauchen im Betriebssystem installierte System- und Perl Module!
Beispiel: fhem an sich (fhem.pl) braucht -> libdevice-serialport-perl libwww-perl libio-socket-ssl-perl
sendEmail braucht -> sendEmail libio-socket-ssl-perl libnet-ssleay-perl
Bei Alarm steht nichts zu Voraussetzungen -> https://fhem.de/commandref.html#Alarm hoffen wir mal das stimmt :)
usw.
Hast Du verstanden wie ich das meine?
Sonst hast Du am Ende ein Restore aber jede Menge Fehlermeldungen - bestenfalls.
Zu Deinem Nachtrag: Um die Sachen innerhalb von FHEM define usw musst Du nicht kümmern!, Du installierst ein leeres FHEM! Wir probieren bestenfalls vorher aus ob das Langateway läuft.
Gruß Otto
So jetzt hab ich dich verstanden. Dann werd ich mal schauen welche ich da brauche bzw. ob ich das repository rein bekomme. Sollte aber überschaubar sein weil da noch nicht viel läuft.
Ich bin mal so frei und poste meine Liste. Evtl fällt dir ja was auf wo ich aufpassen muss oder so
fhem.pl 13622 2017-03-05 21:37:35Z rudolfkoenig
95_Alarm.pm 13049 2017-01-12 20:17:00Z phenning
98_autocreate.pm 11984 2016-08-19 12:47:50Z rudolfkoenig
10_CUL_HM.pm 13437 2017-02-18 19:37:01Z martinp876
98_dummy.pm 12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm 11984 2016-08-19 12:47:50Z rudolfkoenig
01_FHEMWEB.pm 13623 2017-03-05 22:22:19Z rudolfkoenig
92_FileLog.pm 13565 2017-03-01 15:54:06Z rudolfkoenig
98_HMinfo.pm 13168 2017-01-21 11:57:16Z martinp876
00_HMLAN.pm 13605 2017-03-05 10:25:35Z martinp876
00_HMUARTLGW.pm 13573 2017-03-02 09:18:47Z mgernoth
91_notify.pm 13630 2017-03-06 21:05:08Z rudolfkoenig
33_readingsGroup.pm 13457 2017-02-19 21:49:33Z justme1968
99_SUNRISE_EL.pm 12485 2016-11-01 15:18:51Z rudolfkoenig
98_SVG.pm 13394 2017-02-11 21:29:40Z rudolfkoenig
98_telnet.pm 13443 2017-02-19 12:51:22Z rudolfkoenig
99_Utils.pm 13259 2017-01-28 17:39:39Z rudolfkoenig
98_version.pm 13628 2017-03-06 20:43:50Z markusbloch
98_weblink.pm 13558 2017-03-01 09:42:51Z rudolfkoenig
Blocking.pm 12648 2016-11-24 12:15:25Z rudolfkoenig
Color.pm 11159 2016-03-30 16:08:06Z justme1968
DevIo.pm 12716 2016-12-05 09:11:31Z rudolfkoenig
HMConfig.pm 13261 2017-01-28 18:59:02Z martinp876
HttpUtils.pm 13475 2017-02-20 19:33:48Z rudolfkoenig
myUtilsTemplate.pm 7570 2015-01-14 18:31:44Z rudolfkoenig
RTypes.pm 10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm 12935 2017-01-02 19:51:46Z rudolfkoenig
TcpServerUtils.pm 11908 2016-08-06 15:09:55Z rudolfkoenig
So habs jetzt ausm repository installiert. Da wurden dann noch elf andere Module installiert. Soll ich mal testen ob schon was geht? Ich könnte ja sonst bei Bedarf noch nachinstallieren oder nicht?
Nachtrag:
Zusätzlich hab ich noch
sudo apt-get install sendEmail libio-socket-ssl-perl libnet-ssleay-perl perl
nachinstalliert. Glaub wirklich das es das dann war weil sonst hätte ich jetzt nichts am laufen was nicht sowieso zum FHEM gehört
Hi,
das kann ich noch an Notizen zu Backup / Restore beisteuern.
-> http://heinz-otto.blogspot.de/2015/12/backup-und-restore-von-fhem.html
Gruß Otto
Zitat von: Otto123 am 09 März 2017, 21:55:32
Hi,
das kann ich noch an Notizen zu Backup / Restore beisteuern.
-> http://heinz-otto.blogspot.de/2015/12/backup-und-restore-von-fhem.html
Gruß Otto
Super Danke! Das wird dann mal mein erster Restore im Prog selbst! :) Die Logfiles für die Plots muss ich per Hand kopieren?
Also soll ich jetzt gleich mal versuchen umzuziehen? Den Stick dann erst am neuen System in der cfg entfernen?
Bevor Du den USB entfernst, denke bitte daran was ich am Anfang erwähnt habe -> https://forum.fhem.de/index.php/topic,68632.msg601549.html#msg601549
Gruß Otto
Zitat von: Otto123 am 09 März 2017, 22:26:19
Bevor Du den USB entfernst, denke bitte daran was ich am Anfang erwähnt habe -> https://forum.fhem.de/index.php/topic,68632.msg601549.html#msg601549
Gruß Otto
Okay. Also vorher den USB Stick weg bzw.
1. Die cfg anpassen? Welche Def soll ich an die vom hmusb verschieben? Die von der vccu? Da hab ich nicht ganz verstanden was du meinst.
2. Stick runter
3. Schauen ob Fehler angezeigt werden im HMinfo? Oder was soll ich hier definieren?
4. Wenn keine Fehler dann Backup
5. Restore
6. Hoffen das alles wieder geht ;)
Dann wäre ja ein Ende bald mal in Sicht! (und du hättest wieder deine Ruhe) :D
So nachdem ich es irgendwie geschafft hab meinen XEN Server Update unwillig zu machen musste ich jetzt mal "schnell" den neu aufsetzen...
Ab sofort wäre ich aber wieder bereit. Könntest du mir bitte noch kurz erklären wie du das gemeint hast?
Damit ist gemeint, dass in der cfg die IO's vor den Devices stehen sollen die das IO benutzen wollen.
Wenn du das IO über das webIf definierst, wird es einfach hinten an die .cfg dran gehangen, das führt dann zu dem Problem, dass bei einem FHEM Start die Devices geladen werden bevor das IO geladen wird.
Daher, dass neue IO (HMlgw) an die stelle schieben an der der HM_CFG_USB stand, dann gibt es diese Problem nicht.
Zitat von: automatisierer am 10 März 2017, 20:44:18
Damit ist gemeint, dass in der cfg die IO's vor den Devices stehen sollen die das IO benutzen wollen.
Wenn du das IO über das webIf definierst, wird es einfach hinten an die .cfg dran gehangen, das führt dann zu dem Problem, dass bei einem FHEM Start die Devices geladen werden bevor das IO geladen wird.
Daher, dass neue IO (HMlgw) an die stelle schieben an der der HM_CFG_USB stand, dann gibt es diese Problem nicht.
Danke für die Antwort. Also das macht Sinn. Der HMLANGW steht jetzt wirklich ganz unten.
Dazu kurz 2 Fragen:
1. Also soll ich den HMLANGW und die vccu davor einfügen oder?
2. Den USB Stick hab ich in der cfg noch nicht gelöscht. Hier einfach die Zeilen
define hmusb HMLAN 127.0.0.1:1234
attr hmusb hmId HMIDXX
attr hmusb hmLanQlen 1_min
attr hmusb loadLevel 0:low,40:batchLevel,90:high,99:suspended
löschen? Wenn bei den Devices in der cfg noch
IODev hmusb
drin steht sollte nichts machen?
so habs jetzt einfach mal probiert...
Also ich hab
define hmusb HMLAN 127.0.0.1:1234
attr hmusb hmId HMIDXX
attr hmusb hmLanQlen 1_min
attr hmusb loadLevel 0:low,40:batchLevel,90:high,99:suspended
gelöscht und mit
define HMLANGW HMUARTLGW 10.0.0.XX
attr HMLANGW hmId HMIDXX
attr HMLANGW lgwPw Passwortx
define vccu CUL_HM HMIDXX
attr vccu IODev hmusb
attr vccu IOList hmusb,HMLANGW
attr vccu expert 2_raw
attr vccu model CCU-FHEM
attr vccu subType virtual
attr vccu webCmd virtual:update
ersetzt. Hier bekomme ich gleich mal diverse Fehler beim speichern
vccu: unknown IODev hmusb specified OG_Bewe_Gang: ....
Starte ich neu dann kommt gleich mal
Messages collected while initializing FHEM:
configfile: vccu: unknown IODev hmusb specified
OG_Bewe_Gang: unknown IODev hmusb specified
Nochmal von vorne...
Jetzt hab ich alle Einträge angepasst. Hab zwar den Fehler das ich erst hmusb definieren soll beim speichern bekommen aber scheint zu funktionieren. Werd dann evtl noch umziehen
bin temporär umgezogen ... muss aber erst noch schauen ob sonst alles geht :)
spätestens bei einem zweiten gw hab ich sicher nochmal fragen!
aber gleich mal danke fürs helfen!
Zitat von: new_rasp am 10 März 2017, 22:45:57
Nochmal von vorne...
Jetzt hab ich alle Einträge angepasst. Hab zwar den Fehler das ich erst hmusb definieren soll beim speichern bekommen aber scheint zu funktionieren. Werd dann evtl noch umziehen
Hi,
naja, wenn Du den hmusb gelöscht hast, musst Du ihn natürlich auch in der VCCU aus der IOlist nehmen.
Gruß Otto
Zitat von: Otto123 am 12 März 2017, 19:12:33
Hi,
naja, wenn Du den hmusb gelöscht hast, musst Du ihn natürlich auch in der VCCU aus der IOlist nehmen.
Gruß Otto
Servus,
ja den hab ich eh gleich raus genommen. Bin noch nicht wirklich zum intensiv Testen gekommen. Schaut aber echt nicht schlecht aus bis jetzt.
Mit nen zweiten GW hätte ich dann aber evtl noch Fragen
Und denke daran: Es könnte beim Start Fehler geben wenn z.b: in der fhem.cfg als Reihenfolge steht:
....
define hmusb ...
define VCCU
....
define geräte
...
define LanGateway
Alle IOs sollten vor der definition der VCCU und vor der definition der HM Geräte stehen.
Einziger Fall wo manuelles Edit der fhem.cfg sinnvoll ist. 8)
Gruß Otto
Servus,
so hab mal bisschen testen können... bis jetzt schaut alles Super aus!
@Otto123:
Danke für den Hinweis. Das habe ich bei der Umstellung gleich gemacht. Da hab ich nämlich nen Fehler bekommen.
Mittlerweile liegt noch ein zweites Gateway rum. Werd mal schauen das ich das alleine zum laufen bekomme