Umzug von altem System auf neue Hardware und Version - gelöst -

[misave]

Hallo,

eigentlich bin ich kein Anfänger, denn ich habe schon seit Jahren eine FHEM Installation laufen mit hauptsächlich HM-Komponenten, etwas von FS20 und Rademacher für Rollladen. Leider ist dies System sehr veraltet und noch auf dem Stand 5.6.. FHEM arbeitet dort über eine VCCU mit zwei HMLAN (VCCU und beide HMLANs haben dieselbe gesetzte HMID), FS20 mit einem Funkmodul auf dem Raspi, Rademacher mit USB-Stick, HUE-Bridge zur Anbindung von Alexa auf einem separaten Raspi. Beide RPi, HMLANs haben feste IP-Adressen. Die Integration einer CCU2 als Funkgateway hat auf dem alten System nicht geklappt. Deshalb habe ich 2 umprogrammierte CCUs auch verfügbar für das neue System.

Ja ich bin selber Schuld, dass ich dies nicht mehr sinnvoll updaten kann, da sich 6.0 weit von 5.6. entfernt hat und auch das Wheezy nicht mehr updatefähig ist. Ich gehe auch davon aus, dass ich nicht umhin komme, alle Geräte von Hand im neuen FHEM anzulernen.

Ich habe einen neuen RPi3 aufgesetzt mit Buster lite und FHEM 6.0. Da sind schon etliche Kalender, Pushover und telegramBot drauf und so ein "Hintergrund"-Kram.

So, nun meine eigentliche "Anfängerfrage":

Voraussetzung: das alte System läuft bei allen nun folgenden Schritten möglichst einfach weiter

1. Ich würde nun zuerst eine VCCU auf dem neuem System installieren und dieser dieselbe HMID geben wie der auf dem alten System.

     a) Alternativ besser eine andere HMID vergeben, damit das neue System später insgesamt eine neue HMID für die IO-Geräte nutzt?

2. Ich würde versuchen, die umprogrammierten CCUs als Funkgateway auf dem neuen System zu installieren und diesen dann entweder die alte HMID zu geben oder gemäß 1a die neue HMID.

     a) falls das Nutzen der alten HMID auf dem neuen System zu Konflikten mit dem alten laufenden FHEM führt, müsste ich ab diesem Zeitpunkt das alte System ausschalten solange das neue   läuft  und umgekehrt.
         
      b) falls es keine Konflikte gibt mit zwei parallel in Betrieb befindlichen FHEM-Systemen mit je einer VCCU mit identischen HMIDs, bzw. wenn ich eh besser eine neue HMID nutzen soll, können beide Systeme weiter laufen.

3. Ich würde einen NEUEN HM-Aktor im neuen System anlernen um zu prüfen, ob alles klappt

4. Im alten System trenne ich einen HMLAN vom Stromnetz. Dann kopiere ich die RAW Def dieses HMLAN in eine Textdatei. Dann entferne ich dieses HMLAN aus der config des alten Systems.

    a) ich müsste hierfür in allen Devices nachprüfen, ob dieses HMLAN noch als IODev drin steht, zudem muss ich es aus der VCCU "entfernen". Das alte System sollte dann weiterlaufen mit nur einem HMLAN. Möglicherweise können dann einige Geräte nicht mehr erreicht werden wegen der Funkreichweite im Haus.

    b) Falls ich im neuen System dieselbe HMID nutzen kann, nehme ich das HMLAN wieder in Betrieb. Dann will ich die alte RAW Definition nutzen und erhoffe mir, dass dieses HMLAN im neuen System mit der VCCU redet und auch den ersten dort angelernten HM-Aktor erreichen kann. Wenn das so klappt, kann ich danach alle alten Geräte im neuen System von Hand an die VCCU anlernen und entsprechend IOGrp setzen.

    c) falls ich besser eine neue HMID nutzen soll, muss ich das HMLAN zunächst über die HM-Originalsoftware mit neuen Daten (feste andere IP-Adresse) versorgen und dann ganz normal im neuen System anlernen, die neue HMID setzen und wie unter b) alle alten Geräte umziehen.

Könnte die Variante 4b klappen? wenn ja, dann hätte ich mir das Neu-Programmieren der HMLANs erspart und könnte sogar auf die Einbindung der umprogrammierten CCUs verzichten beim Umzug. ich kann die dann später immer noch als weitere Funk-Gateways im neuen System einbinden.

Ich habe es vielleicht etwas umständlich formuliert, dafür bitte ich um Entschuldigung.

Wenn eurer Rat ist, dass ich einfach ein neues System aufsetze mit neuer HMID und anderen IP-Adressen ist es auch ok....Ich denke, dass ich auf keinen Fall die alte Config in Bezug auf die DEF aller physischen Geräte einfach ins neue System kopieren kann.....es haben sich attr geändert bei den Geräten so weit ich nachgelesen habe....

Vielen Dank im Voraus.

Michael

[Otto123]

Zitat aus dem alten Thread

Du hast also schon begonnen:Dann mach weiter
"klemm" doch mal einen HMLAN um und schau was passiert? hast Du auf dem alten System eine VCCU oder haben beide HMLANs die gleiche hmId?

Dann fang mit der VCCU an, dazu brauchst Du nichts außer die hmId.
Dann im alten System den HMLAN auf close setzen (oder zur Sicherheit im Attribute auf dummy 1)
im neuen System definieren und in die VCCU einbinden.
mit der RAW Def beschäftigen - wenn nicht schon geschehen.

Dann einen Aktor per hmPairSerial (vom alten System) anlernen - keine Angst da passiert nichts!

usw...

Es gibt keinen Grund eine neue hmId zu verwenden!
Der zeitweise / testweise Parallelbetrieb führt u.U zu ein paar Eigenheiten:
Es können attack Meldungen auftreten
Anlernen mit beiden Systemen aktiv wird nicht gut funktionieren. Also da immer das andere System den HMLAN auf close setzen.

Anlernen mit hmPairSerial bei existierendem Pairing ist kein Anlernen im eigentlichen Sinne, es ist ein eleganter Weg die Anlern Nachricht vom Gerät abzufordern ohne Knöpfchen drücken.
https://heinz-otto.blogspot.com/2016/12/in-fhem-ein-homematic-gerat-neu-anlegen.html

Gruß Otto

[Peteruser]

Hallo,
das sehe ich etwas anders, habe selber schon Raspi über größere Distanzen hochgezogen.

Ich würde mal die SD-Karte sicher und dann den Versuch machen.
Sowas hilft auch bei späteren Aktionen selbstvertrauen aufzubauen.
https://www.prado.lt/how-to-upgrade-debian-7-wheezy-to-10-buster-safely

Sicher ist ein Neustart immer wieder mal nett, macht aber auch einiges an Arbeit.

Peter

[misave]

@Otto123

Ja schon begonnen, ja auf dem alten System haben alle VCCU und die beiden HMLAN dieselbe HMID, deinen blog lese ich nachher bzgl. serial anlernen vom alten system weg auf das neue, an dem ich einen alten HMLAN angeklemmt habe...bin gespannt, klar dsss ich beim serial anlernen das verbliebene HMLAN im alten System auf close setzen. ich bin echt gespannt.

Danke.

[Otto123]

Also Anle(rn|g)en am neuen System geht auch mit configtaster drücken und dann getConfig - versuch es einfach. Bei den Fernbedienungen und Sensoren musst Du configtaster drücken. Oder Du übernimmst die Konfiguration mit Raw Def, geht ein wenig tricki aber geht schon.

[misave]

@peteruser

danke für die Anleitung. Ich werde diese auch mal komplett ausführen um zu schauen, dass es auch funktioniert. Auch wenn das blöd klingt beides zu machen, aber ich habe zeit dies mal auszuprobieren und dabei lernt man auch viel.

Danke dafür.

[misave]

Also Anle(rn|g)en am neuen

@otto
ist das komische Schreiben von Anlerngen ein Schreibfehler? oder ein Befehl den ich nicht gefunden habe bisher.

Ja mein Wunsch ist es, so viel wie möglich ohne Knöpfchen drücken zu machen, Fernbedienungen habe ich nicht, allerdings einige Sensoren für Türen und diverse batteriebetriebenen Taster und an den Rauchmeldern separate Funktaster, die es mir ermöglichen von außen über die anliegende 5V einen extern weitergeleiteten Rauchalarm der anderen Rauchmelder zu simulieren. So kann ich bisher über einen SET an das Rauchmelderteam alle Rauchmelder laut werden lassen, sobald bei aktivierter Alarmanlage eine Tür geöffnet wird. Und sechs Rauchmelder plus die zusätzlichen beiden Sirenen machen einen ohrenbetäubenden Lärm. Das externe Lautwerdenlassen der Rauchmelder über Funk geht ja nicht mehr, aber als 5V Eingangssignal an den Klemmen klappt. Und die Rauchmelder die an den Decken kleben haben diese externe Alarmierung nicht sondern arbeiten vorschriftsmäßig als Rauchmelder und melden einen echten Alarm halt nur an das Team im FHEM.

[MadMax-FHEM]

Hallo,
das sehe ich etwas anders, habe selber schon Raspi über größere Distanzen hochgezogen.

Ich würde mal die SD-Karte sicher und dann den Versuch machen.
Sowas hilft auch bei späteren Aktionen selbstvertrauen aufzubauen.
https://www.prado.lt/how-to-upgrade-debian-7-wheezy-to-10-buster-safely

Sicher ist ein Neustart immer wieder mal nett, macht aber auch einiges an Arbeit.

Peter

Für jemanden der das schon öfter (u.U. auch "remote") gemacht hat ist ein Upgrade sicher "einfacher"/schneller...

Wobei selbst das (also schneller) glaube ich nicht...

Ein Raspbian ist null komma nix geflasht.
Basiseinrichtung dauert auch nicht wirklich...

fhem Installation (the easy way) dauert unter 5min...

Weitere notwendige Pakete einspielen, Backup einspielen und fertig...

Dauert bei mir deutlich unter 1h

Und dann ist das System neu, sauber und frisch

Weil bei diesem "running Upgrade" z.B. nicht von initd auf systemd umgestellt wird...
...weil initd ja noch unterstützt wird, was wenn nicht mehr?

Wenn beim Ändern der Paketquellen etwas schief geht?
Wenn beim Upgrade etwas schief geht und der Paketinstaller "durcheinander" ist...
Wenn...

Dann: ist ein "Newbee" / Linux-unkundiger "am Ende"...

Und: muss trotzdem neu anfangen...

Wo ist da der Zeit-Vorteil...

Und man hat trotzdem (in Teilen) ein (ver)altetes System...

Aber das nur meine Meinung zu dem Thema...


Und: ein Neu-Aufsetzen prüft/schult auch die (hoffentlich vorhandene) Backup-/Restore-Strategie!

Weil bei mir ist ein Umzug egal ob selbes OS, selbe Plattform oder ganz woanders hin nichts anderes wie ein Restore...

Gruß, Joachim

[Otto123]

Heute ist Nikolaus  , das war der erbärmliche Versuch Anlegen und Anlernen in ein Wort zu schreiben
Du simulierst ja ein Anlernen, dabei wird aber eigentlich die hmId der Zentrale ins Gerät geschrieben. Die steht aber schon drin. Deswegen ist es zwar der Anlernvorgang aber im ungefährlichen Sinne nur ein Anlegen.

Du kannst wie gesagt die Definitionen aus der alten Installation per raw Def kopieren, leicht abändern (etwas weglöschen) und im neuen System in der Raw Def wieder einwerfen. Ich such mal den Artikel dazu.
Der hier war der ursprüngliche
https://forum.fhem.de/index.php/topic,103344.0.html

Ob sich am aktuellen Stand was geändert hat weiß ich nicht mehr genau 

[misave]

Hallo Otto,

ich habe als Beispiel die RAW für einen normalen Schaltaktor hier reinkopiert. Ich habe in dem von dir verlinkten Artikel folgendes verstanden:

Zuerst lege ich händisch dieses Gerät über eine Raw.definition an, sprich alle Einträge aus RAW in die FHEM Kommandozeile als Ganzes reinkopieren und ausführen. Das Gerät existiert ja noch nicht im neuen FHEM. Vorher muss ich aber einige Einträge löschen, weil die so nicht mehr möglich sind.


defmod Kueche_LED CUL_HM 377770
attr Kueche_LED IODev HMLAN2         #hier trage ich das im neuen System vorhandene HMLAN ein
attr Kueche_LED IOgrp VCCU              # dies bleibt so
attr Kueche_LED autoReadReg 4_reqStatus   #bleibt oder auf 2 setzen wegen des Funkverkehrs?
attr Kueche_LED expert 2_full      #bleibt
attr Kueche_LED firmware 2.3   #vermute dass das bleiben kann
attr Kueche_LED group Licht     # kann bleiben, da dann die grp Licht angelegt wird
attr Kueche_LED model HM-LC-Sw1PBU-FM # dies soll gelöscht werden, richtig? oder mit dem Force-befehl setzen?
attr Kueche_LED peerIDs 00000000,   # Gerät hatte nie einen peer, kann also bleiben und stört nicht
attr Kueche_LED room Kueche,CUL_HM  #kann bleiben, legt die Räume an
attr Kueche_LED serialNr MEQ0328910  #kann bleiben
attr Kueche_LED subType switch     # muss gelöscht werden?
attr Kueche_LED webCmd on:off   # kann bleiben

setstate Kueche_LED on
setstate Kueche_LED 2015-08-03 18:14:43 .D-devInfo 010100
setstate Kueche_LED 2015-08-03 18:14:43 .D-stc 10
setstate Kueche_LED 2015-08-03 18:14:48 .R-intKeyVisib invisib
setstate Kueche_LED 2018-08-10 12:10:12 .R-localResDis off
setstate Kueche_LED 2018-08-10 12:10:13 .R-statusInfoMinDly 2 s
setstate Kueche_LED 2018-08-10 12:10:13 .R-statusInfoRandom 1 s
setstate Kueche_LED 2018-08-10 12:10:13 .R-transmitTryMax 6
setstate Kueche_LED 2018-12-09 08:01:23 .peerListRDate 2018-12-09 08:01:23
setstate Kueche_LED 2020-12-06 11:59:44 .protLastRcv 2020-12-06 11:59:44
setstate Kueche_LED 2020-12-06 11:59:44 CommandAccepted yes
setstate Kueche_LED 2015-08-03 18:14:43 D-firmware 2.3
setstate Kueche_LED 2015-08-03 18:14:43 D-serialNr MEQ0328910
setstate Kueche_LED 2018-12-09 08:01:21 PairedTo 0xAAAAAA # hier steht in echt eine andere HMID
setstate Kueche_LED 2015-08-03 18:14:48 R-pairCentral 0xAAAAAA  #hier steht in echt eine andere HMID
setstate Kueche_LED 2015-08-03 18:14:49 R-sign off
setstate Kueche_LED 2018-12-09 08:01:21 RegL_00. 02:01 0A:AA 0B:AA 0C:AA 15:FF 18:00 00:00
setstate Kueche_LED 2018-12-09 08:01:22 RegL_01. 08:00  30:06 57:24 00:00
setstate Kueche_LED 2020-12-06 11:59:44 deviceMsg on (to VCCU)
setstate Kueche_LED 2020-12-06 11:59:44 level 100
setstate Kueche_LED 2020-12-06 11:59:44 pct 100
setstate Kueche_LED 2018-12-09 07:18:39 powerOn 2018-12-09 07:18:39
setstate Kueche_LED 2020-12-06 11:59:44 recentStateType ack
setstate Kueche_LED 2020-12-06 11:59:44 state on
setstate Kueche_LED 2020-12-06 11:59:44 timedOn off

die setstate würde ich alle so lassen, insbesondere das paired to 0xAAAAAA (AAAAAA ist ein fiktives Beispiel, das neue System hat in der vccu und dem HMLAN auch diese fiktive AAAAAA HMID).

Dann habe ich verstanden, dass ich in der VCCU ein HMpairserial auslöse in der Kommandozeile über diesen Befehl

set <Name des IO-Device> hmPairSerial <10-stellige Seriennummer>

oder über die Buttons auf der VCCU Definitionsseite im FHEM. Die 10-stellige Seriennummer des Aktors kenne ich ja aus der RAW Def. Am Ende sollte damit der Aktor quasi umgehängt worden sein an das HMLAN (welches sogar das alte sein kann, welches ich im neuen System eingerichtet habe) und nur noch im neuen System integriert sein. Die Verbindung des Aktors im alten System zum dort noch vorhandenen HMLAN geht von allein verloren, oder?

Entweder kann das Gerät dann direkt steuern oder einmal get config ohne Knopf drücken machen.

Alles richtig so?

Danke im Voraus.
Michael

[Otto123]

Zum ersten: wir reden immer von der Raw Definition https://wiki.fhem.de/wiki/Import_von_Code_Snippets

Die Verbindung zwischen Zentrale und HM Gerät besteht nur in der hmId - also hast Du zwei Zentralen mit der gleichen hmId, dann erkennt das Gerät beide Zentralen quasi als Eine.

Bei dem Vorgehen über das wir reden wird nicht wirklich angelernt und abgelernt.

Du kannst aus beiden Zentralen steuern.

Auf Grund der Eigenheit des Moduls CUL_HM kannst Du nicht einfach die Definition von der alten Installation nehmen und in der neuen genauso ausführen. Du musst vorher wie beschrieben ein paar Dinge einfach weglassen, die entstehen im neuen System von allein wieder. Es wird auch neue Dinge im neuen System geben, da eine Weiterentwicklung stattgefunden hat.

Gruß Otto

[misave]

Zum ersten: wir reden immer von der Raw Definition https://wiki.fhem.de/wiki/Import_von_Code_Snippets

Das habe ich gelesen, wobei es für mich als Leser kompliziert beschrieben ist wie man das konkret anwendet. Das im Link angelegte Import dummy dient dazu, selbst in ein bestehendes echtes Gerät importiert zu werden. Danach ist das echte Gerät als dummy definiert? Ich würde es besser verstehen wenn ich in dieses Import dummy die Einträge aus dem echten Gerät eintrage. Das hin- und herschieben eines Gerätes zwischen zwei parallel laufenden Systemen entspricht schon sehr genau meinem Erfordernis. Mein altes System wäre quasi das Testsystem aus dem ich nun ein Gerät in das neue Produktivsystem dauerhaft verschiebe.

Die Verbindung zwischen Zentrale und HM Gerät besteht nur in der hmId - also hast Du zwei Zentralen mit der gleichen hmId, dann erkennt das Gerät beide Zentralen quasi als Eine.

Ja ich habe ja auf dem alten und dem neuen System je eine VCCU mit identischer HMID. Wenn das HMLAN auf dem neuen System connected wäre (siehe mein anderer Beitrag bzgl. Disconnect der zum HMLAN umprogrammierten CCU2 im neuen System). Noch habe ich keines der beiden HMLANs aus dem alten System ins neue System übertragen. Das mache ich wenn die umprogrammierten CCUs nicht connected werden können.

Bei dem Vorgehen über das wir reden wird nicht wirklich angelernt und abgelernt.

Ja das hatte ich verstanden, denn ich paire ja nicht über das Knöpfchrn sondern gaukel dem Aktor bzw. Sensor nur vor, dass es wieder über die HMID mildem zuständigen IODev redet.

Du kannst aus beiden Zentralen steuern.

Genau das will ich ja versuchen sobald die blöde CCU2 connected ist.

Auf Grund der Eigenheit des Moduls CUL_HM kannst Du nicht einfach die Definition von der alten Installation nehmen und in der neuen genauso ausführen. Du musst vorher wie beschrieben ein paar Dinge einfach weglassen, die entstehen im neuen System von allein wieder. Es wird auch neue Dinge im neuen System geben, da eine Weiterentwicklung stattgefunden hat.

Ja es passt nicht direkt in die neue Welt, deshalb hatte ich oben die raw def hingeschrieben und das markiert von dem ich glaube, dass das weg muss. Aber ist das alles, was ich anpassen muss?

Import:dummy.

Ich würde also im neuen System das importdummy anlegen und in dessen raw def die Daten aus dem echten Gerät aus dem alten System reinkopieren?

Danke für deine Geduld.

Gruß Otto

[Otto123]

Du brauchst normal kein Importgerät! Oben das große Plus neben der Eingabezeile drücken!

Ich meine das reicht:

Code Auswählen Erweitern

defmod Kueche_LED CUL_HM 377770
attr Kueche_LED IODev HMLAN2         #hier trage ich das im neuen System vorhandene HMLAN ein
attr Kueche_LED IOgrp VCCU              # dies bleibt so
attr Kueche_LED autoReadReg 4_reqStatus   #bleibt oder auf 2 setzen wegen des Funkverkehrs?
attr Kueche_LED expert 2_full      #bleibt
attr Kueche_LED firmware 2.3   #vermute dass das bleiben kann
attr Kueche_LED group Licht     # kann bleiben, da dann die grp Licht angelegt wird
attr Kueche_LED modelForce HM-LC-Sw1PBU-FM # dies soll gelöscht werden, richtig? oder mit dem Force-befehl setzen?
attr Kueche_LED peerIDs 00000000,   # Gerät hatte nie einen peer, kann also bleiben und stört nicht
attr Kueche_LED room Kueche,CUL_HM  #kann bleiben, legt die Räume an
attr Kueche_LED serialNr MEQ0328910  #kann bleiben
attr Kueche_LED webCmd on:off   # kann bleiben

Gruß Otto

[misave]

Danke Otto

Versuche dann mal sobald ich ein IODev im neuen System habe. Das mit Force hatte ich ja schon vermutet.

Danke für die Durchsicht der raw def.

[misave]

Hallo Otto,

Der Umzug funktioniert so nicht.

Ich würde mich auch gerne daran beteiligen, die wiki-Eintragung über dieses Import-Dev zu anzupassen, dass man sie nachmachen kann. Insbesondere fehlt mir dort die klare Beschreibung, wie Device von einem Testsystem auf ein Produktivsystem umziehen OHNE Knöpfchen drücken.

Aber zurück zum Umzug.

Ich habe über Chrome das neue System (192.168.a.xx) im webfrontend aufgerufen. Das vorhandene alte System rufe ich über Edge auf (192.168.A.yy). Ich gehe im alten System auf ein vorhandenes Gerät (Türkontakt, CUL_HM 56CADC), gehe dort in die RAW-def und kopiere alle attr Einträge, alle anderen Einträge kopiere ich nicht. Dann gehe ich in das neue System und kopiere den Eintrag in der FHEM Befehlszeile unter Nutzung des + .

Im geöffneten Fenster im neuen System (das Device ist noch nicht da) passe ich die Einträge in der RAW Definition an:

IODev (alt HMLAN1) auf ein im neuen System befindliches IODev (HMLGW1),
IOgrp (alt VCCU) auf eine im neuen System befindliche IOgrp (VCCUneu),
model .... durch modelFroce

Wenn ich dann den execute Befehl im neuen System drücke erscheint die Fehlermeldung dass das HMid CUL_HM 56CADC schon existiert. Dieses Device existiert aber noch gar nicht im neuen System, es sollte ja durch das reine Kopieren der angepassten RAW-Definition erst angelegt erden. Das Anlegen in der Befehlszeile im FHEM klappt so nicht.

Oder muss ich hierfür zwanghaft das IODev (HMLAN1) aus dem alten System vorher ins neue System einbinden?