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

[Otto123]

mach mal ein

Code Auswählen Erweitern

list DEF=56CADC
Das Gerät wird schon unter anderem Namen existieren, jede Anlernmessage erzeugt sofort dieses Gerät.

Ansonsten poste bitte die kopierte Fehlermeldung damit wir uns nicht missverstehen.

Zwanghaft musst Du gar nichts

[misave]

Hallo Otto,

das Gerät ist tatsächlich im neuen System angelegt worden, obwohl ja diese Meldung im RAW Fenster erscheint:

HMid DEF already used by HM_56CADC

Dies Fenster kann man nur Kenntnis nehmen. Danach kann man das Fenster in der RAW Def schließen. Daraus leite ich (fälschlicherweise) ab, dass das Bekanntmachen (ist ja kein pairing) des Sensors im neuen System NICHT geklappt hat.

Ich hätte anstelle dieser Meldung eine Meldung erwartet, dass das Gerät nun im (neuen) System existiert/eingebunden ist.

Die Status-Meldung des Türkontakts erscheinen auch völlig normal im neuen System, im alten auch weiterhin vorhanden.

Ich mache dann mal weiter. Bin auch gespannt, wie Befehle (DOIF, at, usw.) ins neue System kopiert werden. Das müsste ja problemlos gehen, sobald die darin benutzten Geräte im neuen System bekannt sind.

Danke Dir.

[Otto123]

Wenn execute im Raw Def Fenster erfolgreich war steht das explizit da. Bei eine Fehlermeldung (wie bei Dir) wird nicht weitergemacht!. D.H. in einer der Zeilen ist ein Fehler aufgetreten die Folgezeilen werden nicht ausgeführt.
In seltenen Fällen, kann es sein, dass als Erfolgsmeldung ein leeres Fenster mit eine OK Button kommt.

[misave]

Hallo Otto,

nun ja, die Gerät sind trotz dieser Meldung alle im neuen System angelegt. Sie empfangen State-Änderungen (derzeit alles Türkontakte).

Was kann denn falsch sein, wenn das eine Fehlermeldung ist, die das Abarbeiten des Defmod irgendwie verändert?.

Was ich festgestellt habe ist, dass kein angelegtes Device eine Serialnummer hat und wenn ich die als attr zuordnen will erscheint die Meldung

serialNr illegal for virtual devices

Somit erkennt das neue System die physikalischen Device trotz modelForce nicht als reale Device an.

In den empfangenen Telegrammen wird die Serial mit übertragen, aber das Device wird wohl immer virtual bleiben?

wenn das so ist, kann ich doch kein physikalisches Gerät auf diese Weise umziehen? Oder ändert sich das doch erst wenn das physikalische Device richtig gepairt wird?

[Beta-User]

Irgendwie klingt das danach, als wären die CUL_HM-Devices im neuen FHEM schon vorhanden, wenn auch unter anderem Namen?

Dann wäre hier ein deviceRename eher angezeigt, und vermutlich kennt dann das neue FHEM auch schon das Model etc.. Einfach mal suchen, was schon da ist:

Code Auswählen Erweitern

list TYPE=CUL_HM DEF

[Otto123]

So wie ich und Jörg schon gesagt haben:
Wenn ein Gerät (aus welchen Gründen auch immer) eine Anlernnachricht sendet, wird FHEM per Autocreate das Gerät unter seinem Standardnamen anlegen.
Dann kannst Du keine neue Definition mehr per Hand machen. Du kannst die existierende verändern oder die existierende löschen und dann manuell neu machen.
Du hast jetzt tagelang mit deinen IOs rumgespielt, mich wundert es nicht das schon alle Geräte da sind. Aber das sieht man doch? Einfach im Raum CUL_HM schauen.

Der ursprünglich angedachte Weg ist, Du ziehst existierende um. Das wächst sich jetzt für Dich zum Problem aus 
Also löschen und neu machen.
Oder umbenennen und wie gesagt die Definition mit defmod drüber bügeln.

[frank]

welchen vorteil hat eigentlich dieses stückweise rumschaufeln von kleinen portionen der fhem.cfg.

die ganzen device daten fehlen dann ja immer noch.

[misave]

Hallo Beta-teilchen,

hier der List von VOR dem ersten Übernehmen:

Code Auswählen Erweitern


VCCUneu                  AAAAAA
VCCUneu_Btn1             AAAAAA01

Und richtigerweise, werden hier die zu HM lan gateways umprogrammierten CCU2 nicht als CUL_HM erkannt?

im nächsten Versuch habe ich einen Türkontakt rüberkopiert, allein mit der Defmod Zeile, ohne jedes attr.

List zeigt:

Code Auswählen Erweitern

Reserve                  56CADC
VCCUneu                  AAAAAA
VCCUneu_Btn1             AAAAAA01

Die Übernahme wurde als executed angezeigt. Der Gerätetyp ist virtuell.

Ein modelForce bringt dann mehr Internals, so dass der Kontakt nun über die HMLGW mit der VCCUneu spricht. Der Zustand wird sofort und richtig im STATE abgebildet. Das Device bleibt aber virtuell obwohl es auch einen subType liefert. Der lautet ThreeStateSensor, wohl richtig für einen normalen LED-Türkontaktsensor.

Nun erneut das Gerät gelöscht.

erneut zeigt das List, dass das Gerät nicht da ist.

Nun die Übernahme mit allen Zeilen aus dem Raw wie folgt:

Code Auswählen Erweitern

defmod Reserve CUL_HM 56CADC
attr Reserve IODev HMLGW2
attr Reserve actCycle 001:05
attr Reserve actStatus alive
attr Reserve autoReadReg 4_reqStatus
attr Reserve devStateIcon open:fts_window_2w_open@red closed:fts_window_2w@green
attr Reserve event-on-change-reading .*
attr Reserve firmware 1.0
attr Reserve group Fenster
attr Reserve icon fts_window_2w
attr Reserve room CUL_HM
attr Reserve serialNr OEQ0228104
attr Reserve subType threeStateSensor

Die Meldung nach dem Execute ist:

Code Auswählen Erweitern

Executed everything, no errors found.

nach dem OK zu dieser Meldung bleibt das RAW def Fenster stehen, nach dem schließen findet man das Gerät in Raum CUL_HM. Es hat nun als Readings die Serialnummer und die firmware

Code Auswählen Erweitern

Readings
Activity
unknown
2020-12-08 14:47:53
D-firmware
1.0
2020-12-08 14:45:39
D-serialNr
OEQ0228104
2020-12-08 14:45:39
recentStateType
info
2020-12-08 14:48:03

Das attr subtype ist jedoch virtual.

Es wurde kein modelforce genutzt beim Kopieren. ebenso nicht die VCCUneu mit aufgführt.

ein nachträgliches modelForce bringt dann alle attr zurück, das Setzen der IOgrp VCCUneu bringt dann auch einige readings. Es fehlt aber der sabotage-state. Zudem fehlt das pairing zur VCCUneu.

Letzter Versuch:

Code Auswählen Erweitern

defmod Reserve CUL_HM 56CADC
attr Reserve IODev HMLGW2
attr Reserve IOgrp VCCUneu
attr Reserve actCycle 001:05
attr Reserve actStatus alive
attr Reserve autoReadReg 4_reqStatus
attr Reserve devStateIcon open:fts_window_2w_open@red closed:fts_window_2w@green
attr Reserve event-on-change-reading .*
attr Reserve firmware 1.0
attr Reserve group Fenster
attr Reserve icon fts_window_2w
attr Reserve room CUL_HM
attr Reserve serialNr OEQ0228104
attr Reserve subType threeStateSensor


Im Ergebnis lief es wieder fehlerlos durch wie oben geschrieben. Als Readings nur firmware und serialNr., kein pairing in den internals.

ModelForce bringt den Modelltyp und den subType three statesensor, sieht auch ok aus, pairing nicht vorhanden. Sabotgeerror auch nicht.

Noch ein Versuch wie ganz am Anfang mal:

Code Auswählen Erweitern

defmod Reserve CUL_HM 56CADC
attr Reserve IODev HMLGW2
attr Reserve IOgrp VCCUneu
attr Reserve actCycle 001:05
attr Reserve actStatus alive
attr Reserve autoReadReg 4_reqStatus
attr Reserve devStateIcon open:fts_window_2w_open@red closed:fts_window_2w@green
attr Reserve event-on-change-reading .*
attr Reserve firmware 1.0
attr Reserve group Fenster
attr Reserve icon fts_window_2w
attr Reserve peerIDs 00000000,
attr Reserve room CUL_HM
attr Reserve serialNr OEQ0228104
attr Reserve subType threeStateSensor
attr Reserve model HM-SEC-SCo

Auch dies klappt nicht. Er meckert auch nicht bei model. ich kann auch nicht alle Readings auslesen, auch nicht durch setzen des expert.

Nun weiß ich nicht weiter....

[misave]

Du hast jetzt tagelang mit deinen IOs rumgespielt, mich wundert es nicht das schon alle Geräte da sind. Aber das sieht man doch? Einfach im Raum CUL_HM schauen.

Ein Blick in den Raum CUL_HM zeigt, dass es nur die von mir angelegten Device gibt und keine, die sich selber in das neue System geschlichen haben.

[Otto123]

Nur zur Sicherheit: AAAAAA ist deine hmId aus dem alten System?

Ansonsten verstehe ich bei den hier dokumentierten Versuchen nur Bahnhof. Ich denke der angedachte Weg ist für Dich falsch.

und wenn dann modelForce sofort und nicht irgendwann 
attr subType darfst Du nicht mitgeben, hatte ich doch schon geschrieben 

[Otto123]

Ein Blick in den Raum CUL_HM zeigt, dass es nur die von mir angelegten Device gibt und keine, die sich selber in das neue System geschlichen haben.

Dann hätte es diese Meldung nie geben dürfen!
HMid DEF already used by HM_56CADC

[misave]

hallo Otto,

die beiden Systeme sehen wie folgt aus:

FHEM auf 6.0 (neues System)
VCCUneu AAAAAA
HMLGW1 owner AAAAAA, owner_CCU kein Eintrag
HMLGW2 owner AAAAAA, owner_CCU kein Eintrag

keine weiteren Einträge in CUL_HM

FHEM 5.6 (altes System)
VCCU AAAAAA
HMLAN1 owner AAAAAA, owner_CCU VCCU
HMLAN2 owner AAAAAA, owner_CCU VCCU

dutzende Geräte im Raum CUL_HM, u. a. der Reservetürkontakt, den ich nun mehrmals mit verschiedenen DefMod-Befehlen rüberkopieren wollte. Die verschiedenen Versuche stehen oben in meinem Text. ich gebe zu etwas lang, aber ich habe nun zwischen dem defMod (nur die echte defmod-Zeile und KEIN einziges Attr) und einigen Varianten mit und ohne modelforce; mit und ohne VCCU-Name gemacht. attr subtype habe ich auch mal weggelassen, mal mitgemacht. Das Ergebnis ist immer dasselbe....

Ich hatte Dir ja ganz am Anfang mal meinen Vorschlag zum Rüberkopieren aufgeschrieben. Da hatte ich den modelForce drin als Frage....

[misave]

welchen vorteil hat eigentlich dieses stückweise rumschaufeln von kleinen portionen der fhem.cfg.

die ganzen device daten fehlen dann ja immer noch.

Hallo Frank,

ja da hast du Recht. Aber meine fhem.cfg basiert ja auf einem FHEM 5.6 was die Syntax aller Programmierungen betrifft. Ebenso sind die Geräte in der alten Welt definiert. ich hatte mir schon vorher überlegt, dass ich die config nicht mal eben einfach auf das neue system als fhem.cfg bringe. ich befürchte aber, dass ich in der Menge der Fehlermeldungen ersticke.

Zudem hat das neue System eigene IOs (zu HMLGW umprogrammierte CCU2 während das alte System mit echten HMLAN arbeitet.

[Otto123]

Ich hatte Dir ja ganz am Anfang mal meinen Vorschlag zum Rüberkopieren aufgeschrieben. Da hatte ich den modelForce drin als Frage....

und du hast meine Antwort aus #12 mal so probiert?

Aber vielleicht funktioniert das alles mittlerweile nicht mehr. Dann kopiere doch einfach über edit Files den Inhalt Deiner alten Installation in die neue und versuch das nachzuarbeiten (IP Adresse des Gateways)?

[misave]

und du hast meine Antwort aus #12 mal so probiert?

Aber vielleicht funktioniert das alles mittlerweile nicht mehr. Dann kopiere doch einfach über edit Files den Inhalt Deiner alten Installation in die neue und versuch das nachzuarbeiten (IP Adresse des Gateways)?

Ja nr 12 von Dir habe ich gemacht. Dort steht ja auch die Ergänzung drin mit modelforce. Du könntest diesen Versuch in meinem langen Text wiederfinden.

die Gateways alt haben 192.168.2.xx0 bzw. 192.168.2.xx2
die neuen Gateways haben 192.168.2.y3 bzw. 192.168.2.y4

Alle liegen im Adressbereich der fritzbox, wobei die alten in einem Bereich liegen, die die Fritzbox bei ihrer freien Vergabe von IPs für neue Teilnehmer nicht nutzen kann.

Wie gesagt, die Meldungen des Fensterkontakts kommen in beiden Welten an. Aber das pairing nicht. Oder muss ich dazu vielleicht VOR dem defmod im neuen System das alte System ausschalten, damit der Türkontakt am Anfang nur mit der neuen VCCU redet?

Nun ja, das fhem.cfg einfach so rüberkopieren ins neue System geht nur Stückweise, denn die neue Welt hat schon virtuelle Geräte und echte HMLGW und echte Fritzbox....