Migration auf VCCU und neue FHEM-Instanz in einem Schritt

Begonnen von ronzo, 29 Mai 2020, 23:32:41

Vorheriges Thema - Nächstes Thema

ronzo

Hi,

ich möchte ein paar Devices von einer FHEM-Instanz auf eine neue FHEM-Instanz verschieben. Die VCCU der neuen Instanz hat dieselbe ID wie das IODevice der alten Instanz. Dazu habe ich mir die "Raw definition" bei den Aktoren auf der alten Instanz angesehen und diese in der neuen Instanz einfach reingeklopft. Also z.B:

defmod MarkiseUnten CUL_HM 3A327E
attr MarkiseUnten userattr markise markise_map structexclude
attr MarkiseUnten IODev VCCU
attr MarkiseUnten devStateIcon auf:shutter_1 zu:shutter_closed .*:shutter_4
attr MarkiseUnten eventMap on:auf off:zu
attr MarkiseUnten expert 2_raw
attr MarkiseUnten modelForce HM-LC-BL1-SM
attr MarkiseUnten param levelInverse
attr MarkiseUnten peerIDs 00000000,3D9F4B05,3D9F4B06,5AB50001,5AB50002,
attr MarkiseUnten room CUL_HM
attr MarkiseUnten webCmd toggle:auf:zu:up:down:stop:statusRequest:clear msgEvents


Erst heute dämmerte mir, dass das so vermutlich nicht funktionieren kann.

Was kann ich nun tun, damit die Devices nun auch wirklich funktionieren. Ist ein hmPairForSec in Kombination mit dem Drücken der Anlerntaste ausreichend oder muss ich die so angelegten Devices komplett wegwerfen?

Ich glaube auch wo gelesen zu haben, dass bei IODev nicht die VCCU sondern ein IODevice drinstehen muss und bei IOgrp die VCCU (eventuell noch mit dem bevorzugten IODevice?). Was ist hier richtig?

Vielen Dank im Voraus für eure Antworten!

frank

ZitatIch glaube auch wo gelesen zu haben, dass bei IODev nicht die VCCU sondern ein IODevice drinstehen muss und bei IOgrp die VCCU (eventuell noch mit dem bevorzugten IODevice?). Was ist hier richtig?
ich frage mich: wo treibst du dich rum, dass du meinst, dass deine aktuelle version "richtiger" ist?

ich denke in allen seriösen quellen steht, dass es "attr IOgrp vccu" heissen muss.

warum nicht einfach in deinem "alten" system eine vccu definieren und gut und fertig?
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

frank

ausserdem fehlt noch mindestens attr subType.

mit deiner vorgehensweise wirst du wahrscheinlich noch ewig brauchen, bis alles einigermassen läuft.
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

Otto123

Hi,

was bedeutet das:
Zitatich möchte ein paar Devices von einer FHEM-Instanz auf eine neue FHEM-Instanz verschieben.
Also nicht alle Devices? Es leben dann zwei FHEM Instanzen weiter?
Was machen diese beiden Instanzen dann?

Du kannst die neue Zentrale mit VCCU (gleiche HMID) aufbauen, und als Beispiel mal einen Aktor aus der alten Instanz quasi "anlernen" mit set VCCU hmPairSerial xxxxxxx die Seriennummer hast Du ja in der alten Instanz stehen.

FHEM sollte Dir ein neues Device komplett und ordentlich anlegen.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

ronzo

Zitat von: Otto123 am 30 Mai 2020, 00:10:15
was bedeutet das:Also nicht alle Devices? Es leben dann zwei FHEM Instanzen weiter?
Was machen diese beiden Instanzen dann?

Die zweite Instanz gab es vorerst nur für meine Thermostate, da die mit dem CUL nicht so recht wollten. Ich hab mir die Raspberry-Aufsteckplatine besorgt und damit funktionierten sie perfekt. Später habe ich bei dieser Testinstanz noch meine beiden Markisen-Aktoren sowie einen Temperatursensor hinzugefügt.

Den Missstand der zwei voneinander getrennten Instanzen wollte ich nun beheben. Leider habe ich mir die Vorgangsweise zwischen Tür und Angel ausgedacht anstatt einmal gründlich darüber nachzudenken...

Die beste Lösung wäre nun also vermutlich die Devices auf der neuen Instanz wegzuwerfen und sie entweder mit hmPairForSec oder hmPairSerial dort neu anlegen zu lassen?


Otto123

#5
Moin,

also Du willst migrieren.
Leider kann man bei CUL_HM nicht einfach die komplette Raw Def übernehmen, was ich nach wie vor nicht verstehe. Egal ist eben so.
Dann kannst Du eigentlich die define Zeile aus deinem alten System plus ein paar attr Zeilen übernehmen. Der Rest wird dann wieder angelegt.
Ich hatte das hier mal beschrieben:
https://forum.fhem.de/index.php?topic=103344.0

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

ronzo

Zitat von: Otto123 am 30 Mai 2020, 08:54:35
Leider kann man bei CUL_HM nicht einfach die komplette Raw Def übernehmen, was ich nach wie vor nicht verstehe.

Ich auch nicht. Ich habe mir gedacht, dass sie für genau solche Zwecke gedacht wäre. Auf einem System die RAW-Definition rauskopieren und woanders pasten. Das wäre doch spitze, wenn das funktionieren würde. Die Einstellung mancher Entwickler, Entscheidungen für alle User vorweg nehmen zu wollen, kann ich nicht teilen. (Man könnte ja beispielsweise eine Art Expertenmodus haben, in dem man Usern Dinge erlaubt die normalerweise nicht möglich sind.)

Es bleibt mir also offenbar nur die Neuanlage der betroffenen Devices... schade.

frank

ZitatMan könnte ja beispielsweise eine Art Expertenmodus haben, in dem man Usern Dinge erlaubt die normalerweise nicht möglich sind
gibt es doch.
einfach nach fhem.cfg kopieren und neu starten.


allerdings gebe ich folgendes zu bedenken:

sorry, aber dein bisher gezeigter "raw-code" sieht mir überhaupt nicht nach "experte" aus. eher im gegenteil.

daher denke ich, dass ein automatisches anlegen lassen der devices, wie überall empfohlen, für dich "the easy way" bedeutet.
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

Otto123

Zitat von: ronzo am 30 Mai 2020, 09:15:30
Es bleibt mir also offenbar nur die Neuanlage der betroffenen Devices... schade.
Naja das tut manchmal auch gut :)
Es ist nicht viel zu ändern und das Grundlegende kannst Du übernehmen und musst nicht neu anlernen.  Ich habe verstanden: Du willst migrieren und dabei aufräumen? Ansonsten kannst Du Dein altes System fit machen und einfach backup und restore?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Pfriemler

Ich verstehe bei dem ganzen noch nicht "ein paar Devices von einer FHEM-Instanz auf eine neue FHEM-Instanz verschieben" ...

Wenn es lediglich darum geht, die vorhandenen Definitionen in einem anderen FHEM weiterzuverwenden, kann man aus meiner Sicht durchaus auf dem Wege einer identischen IO-Konfiguration (also einer VCCU mit gleicher hmID (die aber nicht einmal identische IO-Geräte beherbergen muss) und der Kopie der Defs in die fhem.cfg und einem Neustart zum Ziel kommen.

Was nun aber gar nicht funktionieren wird ist, beide Instanzen in Funkreichweite parallel zu betreiben. Es darf immer nur eine Zentrale in der Reichweite der Geräte geben, sonst hagelt es sabotage attack errors.
Will man also etwa zwei FHEMs betreiben und diese sollen jeweils ein Set von Geräten betreuen, sind unterschiedliche hmId, ein Entpairen an der alten und ein Neupairen an der neuen Zentrale unverzichtbar.

Der Mechanismus der Kopie über RAW funktioniert im laufenden System leider deswegen nicht, weil namentlich das "model"- und .mId-Attribut beim Anlegen eines Devices per autocreate (sei es über eine config-Message vom Gerät oder über den Pair-Prozess) von CUL_HM selbst bestimmt und eingetragen wird und Usereingaben ausschließlich per modelForce möglich sind. Alle übrigen Daten lassen sich nach Anlernen, Autocreate und deviceRename 1:1 übernehmen.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

ronzo

Vielen Dank für die guten und aufschlussreichen Antworten. Habe die Devices gelöscht und per autocreate neu anlegen lassen. Nun funktioniert alles bestens!