HM-CFG-LAN korrupte Seriennummer und andere MAC

[azmodan2k]

Hallöchen,

ich kann seit heute Nacht meine Homematic Komponenten nicht mehr steuern, da sich scheinbar mein HM-CFG-LAN verabschiedet hat.

Er war in meinem FHEM System nicht mehr als connected verzeichnet -> gut dachte ich -> reconnect und danach ist wieder alles schön ... doch weit gefehlt, er kam nicht mehr online.

Also habe ich in meiner Firewall geschaut und dort hatte ich ein neues Gerät mit einer neuen MAC gehabt ... hatte mich schon gewundert. Dann mit dem HomeMatic LAN-Interface Configurator geschaut und siehe da, es war wirklich das neue Gerät. Sprich mein HM-CFG-LAN meldet sich seit heute Nacht mit einer neuen MAC und einer korrupten Serial Number.

Screenshot siehe Anhang

Kann ich hier noch irgendwas machen? Weiß einer Rat?
Würde ja Notfalls auf das LAN Gateway oder den RPi Aufsatz schwenken, doch meine Befürchtung ist, dass meine ganzen AES Komponenten nachher nicht mehr brauchbar sind mit dem neuen Gerät.

Bräuchte dringend einen Rat.

Danke und Grüße
Stefan

[Rampler]

Code Auswählen Erweitern

Würde ja Notfalls auf das LAN Gateway oder den RPi Aufsatz schwenken, doch meine Befürchtung ist, dass meine ganzen AES Komponenten nachher nicht mehr brauchbar sind mit dem neuen Gerät.


Da brauchst Du keine Befürchtung haben, du setzt ja das Atrribut HMid. (von Deinem defekten HMLAN)

Code Auswählen Erweitern

Kann ich hier noch irgendwas machen? Weiß einer Rat?

https://forum.fhem.de/index.php/topic,62442.msg538982.html#msg538982

[azmodan2k]

Danke erstmal für deine Antwort ... das sollte ich mir mal anschauen.

Mein Problem ist nur, dass ich eigene AES Keys verwendet habe und meine Einrichtung noch weit vor der VCCU war. Sprich ich habe meine Änderung der AES Keys auf dem hm-cfg-lan bzw die erste Änderung sogar noch mit der Software von HM durchgeführt. Somit hat meine VCCU aktuell kein attr hmKey.

Kannst du mir kurz umreißen, ob und wenn ja was ich beim wechsel auf ein neues IO device beachten muss?

betreibe fhem als zentrale mit dem hmlancfg als io dev. später habe ich mal eine vccu hinzugefügt, aber nur weil ich für meine fernbedienungen eine grüne rückmeldung beim erfolgreichen schaltvorgang haben wollte, sonst verwende ich die VCCU nicht. AES keys habe ich damals über die software, später über fhem direct auf dem hmlancfg angepasst und an die geräte veteilt.

vielleicht ist es ja auch garnicht so wild und ich mache mir jetzt unnötig gedanken ... habe nur kein bock meine aes enabled komponenten nachher einschicken zu müssen.

[Rampler]

Danke erstmal für deine Antwort ... das sollte ich mir mal anschauen.

Mein Problem ist nur, dass ich eigene AES Keys verwendet habe und meine Einrichtung noch weit vor der VCCU war. Sprich ich habe meine Änderung der AES Keys auf dem hm-cfg-lan bzw die erste Änderung sogar noch mit der Software von HM durchgeführt. Somit hat meine VCCU aktuell kein attr hmKey.

Das war bei mir genauso ...
Gut beschrieben ist das z.B hier:
http://www.meintechblog.de/2013/05/hmlan-adapter-am-fhem-server-einrichten/
Du hast doch Deinen  geänderten HM-key ?
Den bei der VCCU rein.
Die HMID, welche Du auch haben musst, siehe Link oben, dann bei dem Device..
Das wars dann auch schon..
VG
Klaus

[Rampler]

Ich würde auch mal das Netzteil prüfen ...

[azmodan2k]

Hallöchen, ich melde mich mal mit neuer Hardware und neuen Problemen zurück ... ich hoffe mir kann einer helfen.

Wie anfänglich erwähnt, ist mein hmlancfg defekt und wurde jetzt durch ein HM-MOD-RPI-PCB (als hmlangw modus unter raspberrymatic am laufen) ersetzt. der neue hmlangw wurde per HMUARTLGW eingebunden und der vccu bekannt gemacht, habe auch allen geräten gesagt, dass sie das neue iodev verwenden sollen. vorher hatte ich noch den mir bekannten aes key per vccu gesetzt.

also ich kann daten empfangen, wie zb mein türsender oder die fernbedienung ... kommt alles an in fhem, jedoch kann ich keine geräte schalten, bei dem AES aktiv ist. getConfig auf den geräten wird oft mit "RESPONSE TIMEOUT:RegisterRead" quitiert. ich habe das gefühlt, dass hier noch irgendwas mit der migration vom alten hmlancfg zum hmlangw und den aes nicht gefunzt hat.

kann mir bitte einer nochmal nen tipp geben, wie ich hier weiter komme.

*heul* es hat vorher alles so schön gefunzt und dann muss mir das scheiss hmlancfg abrauchen ... *kotz*

[azmodan2k]

oder soll ich den HM-MOD-RPI-PCB als ccu2 laufen lassen und die geräte dort neu pairen? zurücksetzen sollte ich ja keins von denen, sonst sind sie ja durch den aes key futsch oder? neu pairen mit ccu2 modus?

ach gerade keine ahnung mehr ... danke für eure hilfe

[Otto123]

Den Modus den Du nun am laufen hast kenne ich nicht, aber wenn es prinzipiell funktioniert.

vorher hatte ich noch den mir bekannten aes key per vccu gesetzt.

den Punkt verstehe ich nicht!?
Dein HMLAN ist kaputt, Du richtest schnell noch AES mit anderem Key ein und tauschst dann den IO gegen LGW?

habe auch allen geräten gesagt, dass sie das neue iodev verwenden sollen.

Ich hoffe Du hast allen gesagt, dass sie die VCCU verwenden sollen. Alles andere wäre verkehrt.

Gruß Otto

[azmodan2k]

Den Modus kann man über ein File aktivieren, sodass er nur als hmlangw läuft ... Wie gesagt, Daten empfangen geht. Also scheint mein Controller grundsätzlich zu gehen.

Also zur Erklärung nochmal von vorne. Mein hmlancfg ist defekt (siehe oben), also hab ich neue Hardware bestellt und alles fertig gemacht ... Hab das Ding als hmlangw laufen. Dann in fhem bekannt gemacht und der vccu als io gegeben, alle devices auf die vccu mit neuem io als primäres Gerät gesetzt. Dann hab ich den mir bekannten aes key über die vccu eingetragen und gehofft, dass dann die Kommunikation wieder geht. Aber dem ist leider nicht so.

Ich traue mich jetzt aber auch nicht weiter an den devices rumzuspielen, sodass sie nachher garnicht mehr gehen wegen custom aes.

Ist das oben beschriebene vorgehen richtig?

Falls nein, kann mir einer eine kurze Anleitung geben? Muss ich den aes key but auf der vccu setzten oder auch im neuen iodev hmlangw?

Gesendet von meinem Nexus 6 mit Tapatalk

[azmodan2k]

Hmid des alten Gerätes habe ich entsprechend über die vccu auch für das neue io gesetzt

Muss ich ein bestimmtes Format einhalten für den aes key beim neuen io? Vonwegen keyindex der Geräte vom alten hmlancfg?

Gesendet von meinem Nexus 6 mit Tapatalk

[Otto123]

sorry ich versteh weder die Aktion mit AES noch mit setzen der hmId noch mit setzen des io in den Geräten.

Das macht alles die VCCU von ganz allein!!!

Ob die Konstruktion LGW über Raspberrymatic überhaupt AES kann wäre die große Frage!?! Keine Ahnung...
Aber ja warum nicht, es ist ja trotzdem das PI Modul, das macht AES von selbst.

Ich denke Du hast Unsinn mit dem AES gemacht.

[azmodan2k]

Hallöchen, dann schreibe ich kurz per fhem command was ich getan habe ... ist denke ich einfacher.

Code Auswählen Erweitern


// neues device anlegen
define HMLANGW HMUARTLGW <ipAdresse>
attr HMLANGW hmId <hmid des alten hmlancfg>

// meine vccu hat schon lange die hmid des alten hmlancfg
attr vccu IOList HMLANGW

// IOgrp der devices updaten auf vccu, ehemalig war es vccu:hmlancfg
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual:FILTER=model!=ActionDetector IOgrp vccu


soweit ist es, denke ich jedenfalls, klar ... so dann fängt der spass mit aes an, als erstes habe ich es bei der vccu gesetzt (weil ich damals aes eingerichtet habe, als es noch keine vccu gab ... somit habe ich damals den aes key direkt aufm hmlancfg eingegeben)

Code Auswählen Erweitern


attr vccu hmKey <mein aes key als klartext> --> resultat wurde als 01:md5Hash gesetzt


danach habe ich die kommunikation getestet, welche jedoch nicht ging. also empfang von daten ja, senden von aktionen nein. und ich habe noch ein wenig weiter getestet mit folgenden befehlen

Code Auswählen Erweitern


attr vccu hmKey 01:<md5Hash des ersten keys>
attr vccu hmKey2 02:<md5Hash des aktuellen keys>

attr HMLANGW hmKey 01:<md5Hash des ersten keys>
attr HMLANGW hmKey2 02:<md5Hash des aktuellen keys>


zwischenzeitlich immer mal wieder getConfig von devices gemacht, um zu sehen, ob alles angekommt. wie oben schon geschrieben, wird mir getConfig oft mit "RESPONSE TIMEOUT:RegisterRead" quitiert.

nun will ich nicht einfach weiter spielen, sondern wollte lieber mal fragen, was der richtige weg ist ...

danke und viele grüße
stefan

[Otto123]

Hallo Stefan,

ok jetzt habe ich es verstanden, Du hattest also die vccu nur halbherzig eingerichtet 
Das hat sich offenbar jetzt aber auch gleich gerächt.
Abgesehen davon, dass attr HMLANGW hmId <hmid des alten hmlancfg> ein bisschen überflüssig ist (aber nicht stört) ist alles in Ordnung.

Es funktioniert jetzt AES nicht, das scheint festzustehen. Ich kann nicht sagen warum und ich bin da auch nicht gut drin, aber eigentlich ist es auch nicht kompliziert. Entweder:
-  stimmt etwas mit den Schlüsseln nicht.
- oder das Konstrukt über Raspberrymatic kann kein AES oder macht damit irgendetwas falsch.

Warum machst Du es so kompliziert über Raspberrrymatic Warum nicht einfach Raspbian und socat - da wäre mir zumindest bekannt das es geht.

Das Du jetzt sehr vorsichtig bist ist gut!

Gruß Otto

[azmodan2k]

ich kann Entwarnung melden!!! Juhu!!!

Ich habe jetzt meine AES keys nochmal überall raus genommen und neu über die vccu gesetzt (siehe kommando vorher) ... abwarten ... neustarten ... abwarten ... und siehe da es geht jetzt wieder alles 

danke dir trotzdem für deine unterstützung, jetzt kann ich mich wieder hinlegen 

[azmodan2k]

Warum machst Du es so kompliziert über Raspberrrymatic Warum nicht einfach Raspbian und socat - da wäre mir zumindest bekannt das es geht.

ich war mir halt nicht sicher, ob ich ne ccu2 haben will oder nicht .. deshalb erstmal raspberryMatic. Ich ging davon aus, dass wenn mein Modul ordentlich gelötet ist, ich am ehesten sehe, dass es darüber geht. aber ich werde aktuell nicht auf die ccu2 modus wechseln, sondern es erstmal als hmlangw laufen lassen und dann schaue ich mal in zukunft, wie ich weiter mache.

wie gesagt, danke nochmal ... war ein wenig aufgeregt und konnte mein vorgehen nicht richtig in worte fassen. deshalb dann nochmal per fhem command auflistung