Hallo,
ich betreibe FHEM mit einer 7390 und CUL.. Ein Anfängerfehler bei mir war, dass ich die HMID zwar "vergeben" habe, aber leider nur die Standard-Id, die meine Nachbarn unter Umständen auch haben, wenn sie den gleichen Anfängerfehler gemacht haben. Dieses Sicherheitsproblem würde ich nun gerne korrigieren.
Wenn ich die Infos im Netz soweit richtig verstanden habe, lässt sich die HMID problemlos in der fhem.cfg ändern. Da diese ID beim initialen Anlernen in den Aktoren abgelegt wird, ist nach Änderung der HMID auch das Anlernen der einzelnen Devices zu wiederholen. Nun habe ich schon mindestens 20 Devices, die ich auch in Include-Dateien aufgeteilt habe, die in fhem.cfg eingebunden sind. Die Bezeichnung der einzelen Devices ist etwas durchdacht und ich würde sie nicht verlieren wollen, weil da einiges Arbeit investiert wurde.
Nun meine Frage(n):
1) Kann ich nach änderung der HMID in der fhem.cfg lediglich am Aktor die Anlerntaste drücken und die neue HMID wird übernommen, ohne, dass meine ganzen Devices (insb. Bezeichner), Notify, etc. in der Fhem-Konfiguration verloren gehen?
2) Hat jemand sowas bereits gemacht und kann kurz die Schritte dafür skizzieren?
3) Sind auch die Sensoren neu anzulernen?
Viele Grüße
Alcamar
Zitat1) Kann ich nach änderung der HMID in der fhem.cfg lediglich am Aktor die Anlerntaste drücken und die neue HMID wird übernommen, ohne, dass meine ganzen Devices (insb. Bezeichner), Notify, etc. in der Fhem-Konfiguration verloren gehen?
die hmid ist die homematic-adresse der zentrale deines systems. sozusagen die adresse von fhem. sie wird aus historischen gründen als attribut des io-devices festgelegt. bei dir also beim cul. wenn du das attribut nicht gesetzt hast wird defaultmässig aus der fhtID eine hmid erstellt. du musst also nur das attribut hmid des culs ändern/erstellen und musst nicht in der fhem.cfg editieren.
beim pairen deiner homematic komponenten wurde diese hmid bei den komponenten hinterlegt. somit lassen sie sich nur von dieser zentrale bedienen/konfigurieren. nach änderung der hmid deiner zentrale kannst du deine devices also nicht mehr über fhem konfigurieren. die devices müssen also mit der neuen zentrale gepairt werden.
du kannst versuchen, vor dem ändern der hmid, bei allen devices das register pairCentral zu ändern
set <dev> regSet pairCentral <neue_hmid>anschliessend das attribut hmid vom cul. danach bei allen devices ein getconfig. deine fhem-konfigurationen sollten eigentlich erhalten bleiben. zur sicherheit kannst du autocreate abschalten.
Zitat3) Sind auch die Sensoren neu anzulernen?
alle devices, die mit fhem gepairt sind.
gruss frank
Zitat2) Hat jemand sowas bereits gemacht und kann kurz die Schritte dafür skizzieren?
mache ich immer wieder einmal - weil ich es zum testen brauche.
Frank hat es schon beschrieben. Was er unter 1) beschrieben hat ist das "umpairen". Damit ist 3) erledigt. Will sagen du musst mit der "alten" ID in der Zentrale die neue ID in alle deine Devices schreiben. Die Kommandos müsen ausgeführt sein. Danach kannst du nicht mehr mit den Devices "reden", sie also auch nicht auslesen. Es wird/könnte beim Lesen zu Fehlern kommen. Das macht nichts - das Schreiben muss funktioniert haben.
Nachdem du die HMId des IO (oder der vccu...) geändert hast sollte der Zugriff wieder funktionieren.
Vor dem Ändern würde ich die message-events (protokol-events) löschen, um die neuen Ereignisse sehen zu können und alte messages aus den Queues zu löschen. HMInfo macht das über alle Devices, siehe "clear" dort.
Danach solltest du ein getConfig für alle auslösen und prüfen, dass das Register neu beschrieben wurde.
Vielen Dank für das schnelle Feedback.
Am Wochenende werde ich die ID in den devices ändern und danach das Attribut in der CUL. Würde demnach so aussehen:
set MyDevice01 regSet pairCentral ABC123
set MyDevice02 regSet pairCentral ABC123
set MyDevice03 regSet pairCentral ABC123
...
Danach
attr CUL_0 hmid ABC123
Werde mein Ergebnis hier posten.
erstmal vielen Dank an frank und martin! Es hat funktioniert!
Zunächst habe ich in einer Textdatei jeweils die einzelnen Befehle wie von frank beschrieben pro Device aufgelistet/vorbereitet:
set MyDevice01 regSet pairCentral ABC123
...
set MyDevice0n regSet pairCentral ABC123
Diese Textdatei habe ich nun am Wochenende zeilenweise (bzw. pro device) per copy and paste über die fhem-Web-Oberfläche abgesetzt.
Das klappte sehr gut. Die ID wurde jeweils an die Devices gesendet und, wie von martinp876 geschrieben, waren die devices danach nicht mehr ansprechbar. Die Prozedur hatte allerdings den Nebeneffekt, dass fhem über die web-Oberfläche ebenfalls nicht mehr ansprechbar war. Ließ sich nicht mehr aufrufen. Ich konnte den letzten Schritt
attr CUL_0 hmId ABC123
nicht mehr ausführen. Über ein telnet auf der FritzBox habe ich in der fhem.cfg das hmId-Attribut gesetzt und mit ./startfhem lief wieder alles.
(Achtet auf die Groß-und Kleinschreibung des Attributs. Ich hatte zunächst "hmid" statt "hmID")
Eine Frage habe ich allerdings noch:
define CUL_0 CUL /dev/ttyACM0@9600 1034
ist unverändert geblieben. Ist die 1034 nur die Hex-ID des CUL_0 und daher sicherheitsmäßig unbedenklich, weil die Kommunikation der Devices nun auf die geänderte ABC123 läuft?
Ist die Änderung der 1034 in eine andere 6-stellige ID sinnvoll?
P.S.
Selbstverständlich ist meine wirkliche HMID, die ich festgelegt habe nicht ABC123. Die wollte ich nur hier nicht posten :-)
Hallo,
ZitatZunächst habe ich in einer Textdatei jeweils die einzelnen Befehle wie von frank beschrieben pro Device aufgelistet/vorbereitet:
Achtung!
Für soetwas würde ich Notepad++ empfehlen.
Auch keinen Fall Word oder Wordpad oder ähnliche.
Grüße
leider musste ich feststellen, dass die Thermometer immer noch
PairedTo 0xF11034
bei den Readings zeigen. Also auf die alte HMID verweisen. Im Event Monitor sehe ich zwar, dass die Devices etwas senden, aber wie kann da sein, wenn deren (paired) hmid noch die alte ist?
Ich habe auf zwei Thermometer auf die Anlerntaste gedrückt, weil nach einem getConfig ein cmds_Pending angezeigt wurde. Die CMDs_Pendings waren danach weg. Bei der RemoteControl ist wohl das gleich Phänomen. :-(
Fernbedienung, Thermometer, Bewegungsmelder und Rauchmelder haben "Register changes pending" gemeldet und damit wage ich auch als Anfänger zu behaupten, dass nach
set Device_x regSet pairCentral ABC123
ein drücken der Lerntaste an jedem Device notwendig ist. Bei den Jalousieaktoren war das nicht notwendig. Es hängt wohl vom Transportmodus des Device ab.
Die Fernbedienung musste ich sogar aus Werkseinstellungen zurücksetzen, weil sie gar nicht mehr angesprochen werden konnte. Das beschreiben von Register mochte sie wohl nicht besonders.
Da ich dafür eine include-Datei in die fhem.cfg habe, war das releativ einfach:
1) Include-Zeile Datei auskommentieren
2) Fernbedienung neu anlernen
3) die durch 2) neu erzeugten Zeilen in der fhem.cfg komplett entfernen
4) die ursprüngliche Include-Zeile aus 1) wieder einbinden und fertig
Die Organisation in include-Datei kann ich nur empfehlen.
Meine Änderung der hmId ist noch nicht ganz fertig. :-(
PairedTo missing/unknown
und
PairedTo mismatch to IODev
schmücken leider noch mein "set hm configCheck"
Zitatdamit wage ich auch als Anfänger zu behaupten, dass nach
set Device_x regSet pairCentral ABC123
ein drücken der Lerntaste an jedem Device notwendig ist.
definitiv falsch. Nur bei manchen.
ZitatBei den Jalousieaktoren war das nicht notwendig.
eben
ZitatEs hängt wohl vom Transportmodus des Device ab.
genau
ZitatDie Fernbedienung musste ich sogar aus Werkseinstellungen zurücksetzen,
ich nicht. Reihenfolge beachten.
ZitatDie Organisation in include-Datei kann ich nur empfehlen.
verstehe ich nicht. Organisieren ist immer gut - was und wie organisierst du? Kommandos in includefiles empfehle ich nicht.
ZitatPairedTo missing/unknown
und
PairedTo mismatch to IODev
schmücken leider noch mein "set hm configCheck"
das bedeuted, dass fhem diese Daten nicht gelesen hat. Du solltest also ein getConfig machen, dann ist pairedTo erledigt. Wenn nicht, prüfe das pairing unbedingt.
Dass IODev und pairedTo zueinander passen solltest du auch sicherstellen. Es sollte sich dadurch erledigen, dass nach dem pairen die entsprechende ID mit der des IO übereinstimmt. - wenn alles fertig ist muss es passen, sonst hat etwas nicht funktioniert.
Bei einigen Devices deren Energieversorgung mit Batterien funktioniert, musste ich nach regSet pairCentral die Anlerntaste drücken.
Bei Jalousienaktoren, aber beim LED-Display war das nicht notwendig. Scheinbar haben die als Übertragungsmodus bevorzugt (nicht ausschließlich) "config", was wohl heißt man muss eben die Anlerntaste drücken.
Mein Eindruck ist, dass die Devices beim beschreiben der Register manchmal etwas bockig sind. Daher ist der Tipp nochmal zu prüfen, ob es geklappt hat, sehr wichtig.
Die Devices habe ich include-Dateien organisiert. Eine Inlcude-Datei beinhaltet beispielsweise die Themometer (Sensoren). Die Datei wird in fhem.cfg eingebunden.
@martin: Was Du mit Kommandos meinst, weiss ich nicht. Ich habe z.B. eine include-Datei mit notify-Definitionen, die Steueraktionen (Kommandos?) vornimmt. Wenn das Kommandos sind, dann habe ich einen weiteren Anfängerfehler begangen? Direkt in der fhem.cfg wäre für mich keine besonders gute Alternative, weil man das auf Kosten der Übersicht geht.
Eine Ergänzung zur Fernbeidieung: Die Reihenfolge war sicher die richtige, weil ich alles der Reihennach abgearbeitet habe. Aber ich kann nicht trotzdem nicht ausschließen, dass ich einen Fehler gemacht habe. einer von drei Thermometer musste ich ebenfalls neu anlernen.
"set hm configCheck" ist auch mit "Vorsicht" zu genießen. Viele Devices erfordern ein getConfig, damit die Register der Devices ausgelesen werden können. Viele Devices wiederrum setzen das Kommando zum Abruf der Register solange auf Pending, bis man auch hier die Lerntaste am Device drückt. "CMD_Pend" heißt es dann im web-Frontend beim Device. Die Erfahrung, die ich hier gemacht habe, war dass die Devices nach Drücken der Lerntaste einen Error bringen. Dies schien mir in Verbindung mit hohen RSSI der Fall zu sein. Vermutlich ist ein "zu" hohes RSSI noch ausreichend um eine Temperatur-Info an die Zentrale zu senden, aber nicht mehr ausreichend wenn man Register-Infos bzw. Veränderungen versendet. (?)
ich möchte mich für den Support bedanken. Als Newbie habe ich einiges von der Aktion und von euch gelernt.
Hallo,
ZitatDirekt in der fhem.cfg wäre für mich keine besonders gute Alternative, weil man das auf Kosten der Übersicht geht.
Vergiss das es eine fhem.cfg gibt.
Nicht DU sollst darin "lesen" sondern FHEM - und FHEM macht das am besten wenn man nicht ständig "dazwischen pfuscht".
Wie und wo was in der fhem.cfg steht - darum soll sich FHEM kümmern und eben NICHT der Anwender.
Seit ich mich daran halte klappt alles einwandfrei.
Aber jeder darf natürlich das machen was er/sie für richtig hält.
Grüße
Hallo Puschel,
das stimmt natürlich. Wie lassen sich aber include-Dateien in die fhem.cfg über das Web eintragen? Lieber gar nicht?
Autocreate habe ich auch über eine include-Datei eingebunden. In der fhem.cfg kommentiere ich die autocreate-Zeile aus, um autocreate zu deaktieren, oder mache das "#" einfach weg. Geht das anders?
Die neu gelernten Devices tragen sich in der fhem.cfg einfach nacheinander ein. Nicht besonders übersichtlich, oder? (Wenn man die Datei nicht lesen braucht, natürlich nicht weiter schlimm). Aber geht es wirklich ohne die Datei zu editieren?
Viele Grüße
Alcamar
autocreate lässt sich einfach per disable Attribut deaktivieren.
Die Datei habe ich seit 1 Jahr nicht angefasst und dabei ist meine Installation in der Zeit um 180% größer geworden. Es gibt keinen Grund, die Konfig-Datei direkt zu editieren oder darin lesen zu müssen.
Includes würde ich an deiner Stelle einfach weg lassen. Die benötigt man nicht, wenn man nicht mehr darin editiert ;) Strukturierte Ansichten gibt es ja im Frontend.
Hallo,
ZitatAber geht es wirklich ohne die Datei zu editieren?
Bis auf eine einzige mir bekannte Ausnahme, ja - definitiv.
Und diese Ausnahme tritt nur auf wenn nachträglich ein neues IO-Device hinzukommt und Geräte welche DAVOR stehen diesem zugeordnet werden sollen.
Das kann nicht klappen da das IO-DEV für diese Geräte noch garnicht definiert ist wenn deren Attribut ausgewertet wird.
Das ist aber, wie gesagt, die einzige mir bekannte Ausnahme wo man direkt in die fhem.cfg eingreifen muss.
Alles andere lässt sich definitiv OHNE in die fhem.cfg eingreifen zu müssen erledigen.
So machen es ja auch die Jungs die keine fhem.cfg mehr haben sondern ihre Konfig in eine DB portiert haben (betateilchen z.B. um nur einen zu nennen - der das dafür nötige auch programmiert hat).
Grüße
ZitatUnd diese Ausnahme tritt nur auf wenn nachträglich ein neues IO-Device hinzukommt und Geräte welche DAVOR stehen diesem zugeordnet werden sollen.
bei einer VCCU sollte auch dies nicht mehr der Fall sein.
Mein Weg ist leicht anders. ich habe ein fhem.cfg, das quasi leer ist. Es besteht aus subfile die ich includiere.
include cfg_IO_Common.cfg
include cfg_Heating.cfg
Wenn ich ein neues Device anlege wird es in fhem.cfg eingetragen. Ich kopiere es dann komplett in eines meiner subfiles.
Die Werte ändere ich nicht! Das macht fhem bei jeden save.
Ein Sonderfall ist mein cfg_fhemUser.cfg. Da führe ich Dinge aus, die ich bei jedem Starten machen will. Hier will ich sicherstellen, dass ein save sie nicht anfasst. daher ist es per notify gestartet. in einem der normalen configs brauche ich
define userCfg notify global:INITIALIZED include cfg_fhemUser.cfg
im cfg_fhemUser.cfg kann ich mich dann austoben. z.B.:
apptime
set hm loadConfig setup/cfgReg_confDevice.cfg
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual expert 0_off
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual autoReadReg 5_readMissing
attr TYPE=CUL_HM event-on-change-reading .*
deleteattr TYPE=CUL_HM:FILTER=DEF=........ expert
deleteattr TYPE=CUL_HM:FILTER=subType=virtual expert
deleteattr TYPE=CUL_HM:FILTER=DEF=........ autoReadReg
deleteattr TYPE=CUL_HM:FILTER=subType=virtual autoReadReg
deleteattr TYPE=CUL_HM verbose
man kann "set" und sonstwas einbauen.
Wichtiges Ergebnis: ein save ändert dieses file nicht.
Wow: attr autocreate disable 1
Danke!!!
Die Handhabung der Inlcudes, muss ich nochmal sacken lassen. 8)
Sollte ich die bestehenden Includes belassen und ab jetzt zulassen, dass die fhem.cfg mit neuen Devices beschrieben wird?
Dann hätte ich ein Mix von fhem.cfg und includes. :-[
Oder ein letztes Mal in die fhem.cfg fummeln und alles includes darin vereinen? Und danach die fhem.cfg vergessen. :-\
Die Lösung von Martin scheint mir symaptischer, auch wenn ich sie noch nicht ganz kapiert habe. Ich "editiere" in der fhem.cfg nix. Neu Devices trage ich einfach in die SubFiles. Ohne Änderungen und lösche sie damit auf der fhem.cfg.
Das mit der Datenbank leuchet mir auch ein. Muss mich wohl ein wenig mehr mit der Architektur von fhem beschäftigen. :)
Hallo,
ZitatDie Lösung von Martin scheint mir symaptischer, auch wenn ich sie noch nicht ganz kapiert habe.
Dann lass es.
ZitatMuss mich wohl ein wenig mehr mit der Architektur von fhem beschäftigen.
Genau deswegen - lass die Finger von der fhem.cfg
Tipp:
Lass die includes so wie du sie bis jetzt hast und lass FHEM den Rest machen.
Wenn du dann mal soweit bist das du die Architektur von FHEM verstanden hast und im speziellen worauf du achten musst wenn du die fhem.cfg direkt bearbeitest kannst du es immer noch so machen wie du meinst.
Aber bis dahin - vergiss die fhem.cfg einfach.
Glaube mir du ersparst dir, als Anfänger, unnötigen zusätzlich "Denkaufwand" den dir ohne mit einem CPU-Beinchen zu zucken FHEM für dich abnimmt.
ZitatWow: attr autocreate disable 1
Da musste ich (sorry) schonmal kurz schmunzeln :P
Grüße