Erfahrungen mit HMLAN und ein paar Fragen

Begonnen von ingog, 22 Januar 2017, 12:30:23

Vorheriges Thema - Nächstes Thema

ingog

Hallo,

da mir die Foren im Internet weitergeholfen haben, will ich hier auch meine Erfahrungen zum Besten geben und auch noch ein paar Fragen loswerden.
Ich betreibe seit ein paar Jahren ein wenig Hausautomation mit fhem (raspi) und Homematic Komponenten. Als Gateway benutze ich einen HM-LAN-CFG. Als Geräte sind Schaltsteckdosen, Fensterkontakte, Heizkörperthermostate, Raumregler, eine Wetterstation und ein TH-Sensor im Einsatz - hat alles supi funktioniert. Zusätzlich habe ich mein BHKW über ein selbstgebasteltes Modul über eine Serielle Schnittstelle angekoppelt, sende meinem Webserver Daten und Statusinfos aus fhem (auch selbst gebastelt) und nutze Pushover für Alarmmeldungen.
Vor ca. 3Wochen hat mein HMLANCFG angefangen unregelmäßig neu zu starten - so als wenn ein Watchdog oder Brown-Out Detector zugeschlagen hat. War eher Zufall, dass ich das bemerkt habe. 1Woche später war der HMLANCFG aus der IP-Konfig verschwunden - einfach weg. Dafür hat mein Routing Switch (Mikrtotik cloud CRS125-24G) eine neue MAC-Adresse an diesem Port gefunden. Habe testweise dieser MAC meine HMLAN-IP-Adresse zugewiesen und siehe da, die neue MAC war mein alter HMLANCFG - hat sich einfach eine neue MAC verpasst. Mit dem HMLAN Konfigurationstool konnte ich sehen, dass auch die Seriennummer des Gerätes weg war - es hat also irgendeinen EEPROM in dem Ding gekillt. Möglicherweise durch die vielen Restarts des Gerätes. Prinzipiell hat das Ding aber immer noch funktioniert.  Nur Firmwareupgrade war nicht mehr möglich (wahrscheinlich wegen fehlender Seriennummer oder falscher Vendor-ID aufgrund der krummen MAC-Adresse).
Nun wollte ich dem Thema der Reset´s auf den Grund gehen. Erster verdacht: Netzteil - nein alles gut, Zweiter Verdacht Netzwerk - irgendwelche unschönen Pakete - nein, habe den HMLAN in ein eigenes Netzwerksegment gepackt und mit der Firewall beschränkt - nein Fehler blieb. Verlorene Netzwerkpakete scheiden auch aus. HMLANCFG auseinandergebaut (vieleicht ein dicker Kondensator o.ä. nix). Dummerweise J1 beim basteln kurzgeschlossen - das war´s dann für den HMLAN entweder habe ich den Atmel gegrillt oder komplett gelöscht.
Also neuen HM-LAN-CFG erbeutet - gebraucht, den angestöpselt - immer noch das gleiche Problem mit den Reset´s.
Nochmal intensiv durchs´s Internet gesucht - aha, der HMLAN braucht spätestens nach 30s ein Keep-Alive auf Port 1000 (macht normalerweise fhem alle 25s).
Mal eine alte Konfig im fhem eingespielt und siehe da, die Reset´s waren weg. Hat ne weile gedauert, bis ich mich erinnert habe, dass ich 2 Server mit Presence in die Überwachung genommen habe - das arbeitet wohl nicht blockadefrei oder ärgert das Timersystem im fhem. Jedenfalls kommt dann der Keep-Alive vom fhem an den HMLANCFG nicht mehr regelmäßig. FHEM ist eben leider nicht in mehrere Threads aufgeteilt und damit anfällig für solche Fehler. Nachdem ich die Überwachung der Server rausgeworfen habe, lief die Kommunikation wieder störungsfrei.

Der gebrauchte HMLANCFG hatte zusätzlich eine hässliche Fehlfunktion. Das Ding hat alle Pakete meiner Geräte zwar fein empfangen und weitergeleitet - aber keinerlei Pairing-Protokolle weitergeleitet. Damit konnte ich meine Thermostaten und den Raumregler nicht wieder anlernen.
Als letzte Option habe ich aus dem alten HMLAN das Sende/Empfangsmodul ausgelötet und in den neuen HMLANCFG eingebaut und auf einmal war alles wieder gut!

Hierzu eine Frage an die Spezis. Das kleine Sendemodul (gibt es auch als Bausatz für den PI) hat ja bestimmt einen eigenen Prozessor - kann es sein, das man den für Pairing disablen kann, wenn ja, wie kann man das zurücksetzen?

Der Wechsel auf den neuen HMLAN war nicht ganz banal, zwar reden die meisten Komponenten sofort wieder mit dem HMLAN, aber insbesondere die Thermostaten wollen Resetet und neu angelernt werden da man die sonst nicht ansteuern kann. FHEM scheint aber auf eine Pairinganforderung eines bereits erlernten Gerätes nicht zu reagieren - also lernen die Thermostate auch nicht neu an. Habe es dann mit dem Konfigwerkzeug von Homematic hinbekommen, war aber nicht so toll. Kann man das irgendwie cleverer lösen? Ist ja nur eine Frage der Zeit, wenn ich mal wieder einen Thermostat reseten muss.

VG
Ingo

budy

Moin Ingo,

als erstes solltest du eine VCCU in FHEM definieren und der die alte HMID deines HMLAN verpassen, damit hättest du dann schon mal alle deine Devices wieder. Der VCCU kannst du dann den neuen HMLAN als IODev zuweisen, sowie nahezu beliebig viele weitere.

Dass ein Gerät seine MAC-Adresse verändert ist schon sehr seltsam, so was habe ich noch nie gesehen.

Gruß,
Stephan
Debian stretch, FHEM 5.9.
HM-CC-RT-DN, HM-ES-PMSw1-Pl, HM-LC-Dim1TPBU-FM, HMUARTLGW, HMLAN, HM-SEC-KEY, HM-SEC-RHS, HM-SEC-SC-2, HM-SEC-SCo, HM-SEC-SD-2, HM-OU-CFM-TW, div. HUEs, Wifilight, Ring Video Pro

frank

neulich war schon einer hier und vermisste seine seriennummer. https://forum.fhem.de/index.php/topic,65090.msg563294.html#msg563294
vielleicht ist da auch noch die mac weg.  :)

es würde mich nicht wundern, wenn hier hmIP mit im spiel ist. https://forum.fhem.de/index.php/topic,63702.msg549740.html#msg549740
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Hollo

Zitat von: budy am 22 Januar 2017, 23:03:38
...Dass ein Gerät seine MAC-Adresse verändert ist schon sehr seltsam, so was habe ich noch nie gesehen...
Er hat ja nicht geschrieben, von was nach was sie sich geändert hat.
Das kann schon mal passieren, wenn das Flashen "in die Hose" geht.
Ich hatte schon mal einen Netzwerkadapter, der seine ursprüngliche MAC verloren hat und stattdessen nun 88:88:88:88:87:88 zeigte.

FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

ingog

Hallo,

Danke für die Antworten - das mit der vccu ist super, aber mir völlig entgangen. Kann es sein, das es die vor 3 Jahren noch nicht gab?. Nur noch zur Info, die Mac  war nach der Änderung 44:11:11:00:1C:00. Ist also kein typisches Muster wie 55, AA oder so was ähnliches. Allerdings sind überdurchschnittlich viele 0-Bits dabei.

VG

Ingo

martinp876

 Vor 3jahren hat hm in fhem sich erst stabilisiert meine ich.
Eine Mac sollte ein device nicht verlieren. Dann ist etwas kaputt.