Autor Thema: Migration auf VCCU und neue FHEM-Instanz in einem Schritt  (Gelesen 433 mal)

Offline ronzo

  • Jr. Member
  • **
  • Beiträge: 72
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!

Offline frank

  • Hero Member
  • *****
  • Beiträge: 8642
Antw:Migration auf VCCU und neue FHEM-Instanz in einem Schritt
« Antwort #1 am: 29 Mai 2020, 23:47:37 »
Zitat
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?
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(stretch)
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 [hm.js]: https://forum.fhem.de/index.php/topic,106959.0.html

Offline frank

  • Hero Member
  • *****
  • Beiträge: 8642
Antw:Migration auf VCCU und neue FHEM-Instanz in einem Schritt
« Antwort #2 am: 29 Mai 2020, 23:50:48 »
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(stretch)
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 [hm.js]: https://forum.fhem.de/index.php/topic,106959.0.html

Offline Otto123

  • Hero Member
  • *****
  • Beiträge: 15950
  • schon mal restore trainiert?
    • Otto's Technik Blog
Antw:Migration auf VCCU und neue FHEM-Instanz in einem Schritt
« Antwort #3 am: 30 Mai 2020, 00:10:15 »
Hi,

was bedeutet das:
Zitat
ich 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
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7490+7412,WRT1900ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266

Offline ronzo

  • Jr. Member
  • **
  • Beiträge: 72
Antw:Migration auf VCCU und neue FHEM-Instanz in einem Schritt
« Antwort #4 am: 30 Mai 2020, 08:29:05 »
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?


Offline Otto123

  • Hero Member
  • *****
  • Beiträge: 15950
  • schon mal restore trainiert?
    • Otto's Technik Blog
Antw:Migration auf VCCU und neue FHEM-Instanz in einem Schritt
« Antwort #5 am: 30 Mai 2020, 08:54:35 »
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
« Letzte Änderung: 30 Mai 2020, 09:00:50 von Otto123 »
Viele Grüße aus Leipzig
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7490+7412,WRT1900ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266

Offline ronzo

  • Jr. Member
  • **
  • Beiträge: 72
Antw:Migration auf VCCU und neue FHEM-Instanz in einem Schritt
« Antwort #6 am: 30 Mai 2020, 09:15:30 »
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.

Offline frank

  • Hero Member
  • *****
  • Beiträge: 8642
Antw:Migration auf VCCU und neue FHEM-Instanz in einem Schritt
« Antwort #7 am: 30 Mai 2020, 10:01:40 »
Zitat
Man 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(stretch)
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 [hm.js]: https://forum.fhem.de/index.php/topic,106959.0.html

Offline Otto123

  • Hero Member
  • *****
  • Beiträge: 15950
  • schon mal restore trainiert?
    • Otto's Technik Blog
Antw:Migration auf VCCU und neue FHEM-Instanz in einem Schritt
« Antwort #8 am: 30 Mai 2020, 15:39:19 »
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
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7490+7412,WRT1900ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266

Online Pfriemler

  • Hero Member
  • *****
  • Beiträge: 3651
  • geht nich gips nich
Antw:Migration auf VCCU und neue FHEM-Instanz in einem Schritt
« Antwort #9 am: 30 Mai 2020, 16:57:03 »
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 ..."

Offline ronzo

  • Jr. Member
  • **
  • Beiträge: 72
Antw:Migration auf VCCU und neue FHEM-Instanz in einem Schritt
« Antwort #10 am: 01 Juni 2020, 09:09:23 »
Vielen Dank für die guten und aufschlussreichen Antworten. Habe die Devices gelöscht und per autocreate neu anlegen lassen. Nun funktioniert alles bestens!

 

decade-submarginal