Moin,
Gestern ist es passiert: meine Festplatte im Heimautomationsserver ist abgeraucht. Nach meiner Analyse ist die für mich am wenigsten stressige Lösung eine neue Platte zu bestellen und das System neu aufzusetzen - es war noch nicht so lange in Betrieb, daß sich die Wiederherstellung der Originaldaten lohnen würde. Also in der Richtung brauche ich keine Ratschläge ;-)
Meine Frage ist eine ganz andere: ich hatte wenige Tage vor dem Crash neue Homematic-Komponenten angelernt (1x Wandthermostat, 3x Heizungsthermostat). die waren auch in FHEM eingebunden, alles hat ganz normal funktioniert. Nun habe ich, damit ich, bis der etatmäßige FHEM-Server wieder aufgesetzt ist, meine Komponenten weiterhin zentral steuern kann, meinen kleinen RasPi wieder aktiviert. Der hatte diese Aufgabe ja bis vor kurzem eh noch gehabt, insofern war alles noch da, ich mußte es nur hochfahren.
Alles da? nein, die 4 neuesten Geräte waren da natürlich nicht in der fhem.cfg - und genau da setzt mein Problem an: Da die Geräte i.d.R. Ausschließlich über die Zentrale gesteuert werden sollen, sind alle Geräte mit "globalBtnLock on" konfiguriert - damit kann ich sie aber so ohne weiteres nicht mehr am RasPi anlernen, oder?
Ich hatte darauf gehofft, daß, da die neuen Geräte ja bereits angelernt waren, sie, wenn sie ihre Daten übertragen, automatisch wieder in FHEM auftauchen (autocreate ist an), halt ohne Namen, sondern, wie nach dem Anlernen, mit ihrer Seriennummer (die hätte ich dann zuordnen können). Bisher ist jedoch keins der Geräte aufgetaucht.
Ich fürchte deshalb ja, daß ich an den Geräten einen Werksreset durchführen muß, um sie komplett neu anzulernen - sehe ich das richtig? Oder kann mir jemand eine elegantere Methode empfehlen?
LG
McCavity
Gesendet von iPad mit Tapatalk
Batterie raus und wieder rein?
hmPairSerial heisst das Zauberwort :D
Anlernen mittels Seriannummer
lg, ici
Hi,
erstmal vielen Dank für die Antworten.
@Wuppi68: Batterien raus und rein funktioniert nicht. Das ist ja nur wie ein Batteriewechsel und die Einstellungen bleiben in den Geräten erhalten (inkl. des globalBtnLock) - das einzige, was die Dinger vergessen, ist die Uhrzeit, die man nach dem Wiedereinschalten neu setzen muß, und die Ventilstellung, die sich in einer Adapterfahrt dann wieder korrigiert (so es sich um einen Heizungsthermostaten handelt).
@Icinger: das wäre vermutlich die Lösung - wenn ich mir die Seriennummern (die 10-stelligen) irgendwo notiert gehabt hätte (Memo an mich: Versäumnis nachholen!).
Wie dem auch sei, ich bin über eine andere Lösung gestolpert. Es konnte ja nicht angehen, daß die Geräte schonmal in einer FHEM Instanz angelernt waren und eine andere FHEM-Instanz mit denselben Geräten so rein gar nichts davon mitbekommt. Also habe ich mal im Logfile geschaut und dort jede Menge Meldungen über unbekannte Codes gefunden:
...
2015.02.08 00:45:46 3: HMLAN1: Unknown code A0C1E84702D334700000000AE25::-74:HMLAN1, help me!
2015.02.08 00:45:51 3: HMLAN1: Unknown code A0F6B861033B2A90000000A90D1110000::-56:HMLAN1, help me!
2015.02.08 00:47:04 3: HMLAN1: Unknown code A0F1786102E2D510000000A88AE110040::-78:HMLAN1, help me!
2015.02.08 00:47:41 3: HMLAN1: Unknown code A0F0E86102E2D4E0000000A88AE110040::-70:HMLAN1, help me!
2015.02.08 00:48:11 3: HMLAN1: Unknown code A0C1F865A2D334700000088AE24::-71:HMLAN1, help me!
2015.02.08 00:48:20 3: HMLAN1: Unknown code A0F6C861033B2A90000000A90D1110000::-56:HMLAN1, help me!
2015.02.08 00:48:31 3: HMLAN1: Unknown code A0C1F84702D334700000000AE25::-72:HMLAN1, help me!
2015.02.08 00:49:55 3: HMLAN1: Unknown code A0F1886102E2D510000000A88AE110040::-83:HMLAN1, help me!
2015.02.08 00:50:34 3: HMLAN1: Unknown code A0F6D861033B2A90000000A90D1110000::-55:HMLAN1, help me!
2015.02.08 00:50:39 3: HMLAN1: Unknown code A0F0F86102E2D4E0000000A88AE110040::-70:HMLAN1, help me!
2015.02.08 00:50:41 3: HMLAN1: Unknown code A0C20865A2D334700000088AE25::-72:HMLAN1, help me!
2015.02.08 00:51:01 3: HMLAN1: Unknown code A0C2084702D334700000000AE25::-72:HMLAN1, help me!
...
Die rot markierten Bestandteile der Nachrichten sind dabei die IDs der gesuchten Geräte:
pi@heim /opt/fhem/log $ grep "HMLAN1: Unknown code" fhem-2015-02.log > /tmp/fhem.log
pi@heim /opt/fhem/log $ for stringZ in $(cat /tmp/fhem.log | awk '{print $7}' | cut -d: -f1); do echo ${stringZ:9:6}; done | sort | uniq
2D3347
2E2D4E
2E2D51
33B2A9
Voilà: ich vermisse vier Geräte und bekomme vier IDs zurückgeliefert. Daraufhin habe ich flugs aus zwei existierenden Definitionen (1x Wandthermostat, 1x Heizkörperthermostat) neue geschnitzt, FHEM einmal durchgestartet und es funktioniert... - bis auf die Tatsache, daß (natürlich) der Wandthermostat als Heizkörperthermostat und einer der drei heizkörperthermostaten demzufolge als WandThermostat auftauchte - aber das war recht schnell geradegebogen. Anhand der peerIDs, die dankenswerterweise dann doch wieder automatisch in fhem.cfg landeten, konnte ich die Geräte dann auch wieder identifizieren - die Flüchtigen wurden also erfolgreich wieder eingefangen :-) Bei den Einträgen hatte ich einige Attribute auskommentiert:
#attr Test1.Stellantrieb firmware 1.3
#attr Test1.Stellantrieb serialNr LEQ0902024
#attr Test1.Stellantrieb_Weather peerIDs 00000000,2F68D101,
#attr Test1.Stellantrieb_Climate peerIDs 00000000,2F68D102,
weil ich diese so nicht nachvollziehen kann (die vorhandenen Werte stammten ja von dem kopierten Gerät) - und mindestens einer der Stellantriebe ist Firmware 1.4, auch das wußte ich noch von der Ersteinrichtung. Wie oben schon erwähnt, die peerIds haben sich automatisch wieder eingetragen, jetzt muß ich nur noch die richtigen Firmwareversionen und Seriennummern ergänzen.
Problem gelöst, ohne daß ich alles nochmal hätte zurücksetzen müssen \o/ - zum Glück waren das aber nur vier Geräte, bei mehr wäre das dann doch irgendwann ziemlich viel Aufwand...
LG
McCavity