Copy Gerät_1 Gerät_2 geht nicht

frank · 30 November 2015, 20:17:54

cool wäre es, "muster devices" (attr sample=master) definieren zu können. alle neuen devices (attr sample=slave) werden automatisch nach dem definieren, entsprechend dem muster device angelegt. wird das muster device verändert, verändern sich alle anderen entsprechend.

diesen mechanismus dann bitte auch für plots nutzbar machen.
danke im voraus.

marvin78 · 30 November 2015, 20:20:04

Alle Attribute kopieren ist aber ggf. gar keine gute Idee. Ich denke da bei HM an IOList, firmware, peerIds, serialNr etc.

justme1968 · 30 November 2015, 20:24:26

genau das ist das problem... wenn man anfängt darüber nach zu denken wird es schnell sehr komplex wenn man ex flexibel halten will. dann muss man angeben können welche attribute kopiert werden, ob sie überschreiben sollen oder nur kopiert werden sollen wenn es noch kein entsprechendes attribut im ziel device gibt oder nur die attribute die es im ziel schon gibt mit den werten aus der quelle füllen, exclude listen für bestimmte device typen, und und und

wenn jemand eine idee für eine einfache syntax hat die das alles abdeckt baue ich es gerne ein.

ich finde gerade den alten thread nicht mehr in dem es schon ein paar vorschläge dazu gab.

frank · 30 November 2015, 20:30:50

Zitat von: marvin78 am 30 November 2015, 20:20:04
Alle Attribute kopieren ist aber ggf. gar keine gute Idee. Ich denke da bei HM an IOList, firmware, peerIds, serialNr etc.

das stimmt schon. da muss natürlich noch eine art intelligenz mit rein.

insofern wäre eigentlich für homematic hminfo der richtige platz.

Bennemannc · 30 November 2015, 20:33:34

Hallo,

ups - da habe ich was losgetreten. Also wenn man es flexibel machen möchte, kann man das eigentlich nur grafisch machen.
Man würde dann vom Device_1 alle Werte (define, userattr, ?) anzeigen und dahinter 4 Felder - kopieren, überschreiben, ignorieren (oder einfach nichts machen wenn kopieren und überschreiben leer sind) und ein Textfeld in das man einen alternativen Wert schreiben kann. Und dann der "go" Button. Vielleicht kann man ja Teile der Auswahl von Room oder Group nutzen.

Gruß Christoph

justme1968 · 30 November 2015, 20:34:07

die alte diskussion war hier: http://forum.fhem.de/index.php/topic,23759.msg171457.html#msg171457.

schon ziemlich viele möglichkeiten und immer noch nicht vollständig.

Bennemannc · 30 November 2015, 20:43:10

Hallo,

also eigentlich wollte ich das, was der copy Befehl macht 1:1. Wenn Martin in der CUL_HM statt einen Fehler auszuwerfen die ID auf FFFFFF setzen würde (mit Hinweis blabla..), bräuchte man eigentlich nichts weiter ändern.
Sonst bleibt in meinen Augen nur eine grafische Lösung - das mit Befehlen zu machen ... ich glaube das wird zu komplex und dann nicht wirklich oder nur von wenigen genutzt.

Gruß Christoph

martinp876 · 30 November 2015, 22:05:37

Was wollt ihr eigentlich kopieren? Ein device zu ersetzen kann das wohl nicht sein. Wenn ich ein 2tes gleich einbauen wil..... Mal nachdenken.
Pairen muss man erst einmal. Damit sind schon die Kanäle angelegt und die wichtigen Attribute. Die sollte man nicht mehr aendern. Alle anderen Attribute kann man kopieren, wenn man will. Peerids wird nach einem getconfig über schrieben. Stellt also kein Problem dar.
Wenn es um die Register geht muss man beim peeren anfangen. Ob man das 1zu1 kopieren will ist fraglich. Kann man aus den registersavings laden.
Die Register wiederum man man mit dem kopierbefehl kopieren. Intelligenter ist es, ein template anzulegen.

Es ist also erst einmal zu klären, was ihr erreichen wollt

Bennemannc · 30 November 2015, 22:21:41

Hallo Martin,

schon ein Device - habe ja geschrieben pairen damit im Device pairCentral und pairTo gesetzt wird und ich die HMId bekomme. Dann das Device löschen und mit copy das Device neu anlegen und die HMId ändern.

Gruß Christoph

marvin78 · 01 Dezember 2015, 07:05:43

Das mit dem Löschen klingt für mich nicht nach einem eleganten Weg. Ich persönlich halte auch nichts davon, dass CUL_HM falsche IDs zuläst oder bei copy (wie soll es das eigentlich erkennen) eine Standard-ID zuweist. Ich sehe schon die Probleme, die dann hier im Forum gewälzt werden.

Wenn du es ohnehin so umständlich machen möchtest, wäre eine Attribut-Copy sub für dich eigentlich genau das Richtige.

Bennemannc · 01 Dezember 2015, 07:18:20

Hallo,

das mit dem Erkennen sollte kein Problem sein - an der Stelle wo jetzt die Fehlermeldung generiert wird, könnte man auch die HMId ändern gegen ein FFFFFF.
Andererseits könnte man auch den copy Befehl problemlos so umbauen, das er nur die Attribute kopiert. Der ist, wenn ich das richtig interpretiere, ohnehin zweigeteilt. Erst das define und dann die Atrribute.

Gruß Christoph

marvin78 · 01 Dezember 2015, 07:22:47

Nein. So kannst du nicht erkennen, ob jemand versucht hat, manuell eine falsche (nicht wohlgeformte) ID verwenden möchte, oder ob das Device durch copy angelegt wurde. Ich finde es gut und richtig, dass kontrolliert wird, ob die HMID schon da ist UND dass ein entsprechender Fehler ausgegeben wird.

frank · 01 Dezember 2015, 11:50:04

Zitat von: martinp876 am 30 November 2015, 22:05:37
Was wollt ihr eigentlich kopieren? Ein device zu ersetzen kann das wohl nicht sein. Wenn ich ein 2tes gleich einbauen wil..... Mal nachdenken.
Pairen muss man erst einmal. Damit sind schon die Kanäle angelegt und die wichtigen Attribute. Die sollte man nicht mehr aendern. Alle anderen Attribute kann man kopieren, wenn man will. Peerids wird nach einem getconfig über schrieben. Stellt also kein Problem dar.
Wenn es um die Register geht muss man beim peeren anfangen. Ob man das 1zu1 kopieren will ist fraglich. Kann man aus den registersavings laden.
Die Register wiederum man man mit dem kopierbefehl kopieren. Intelligenter ist es, ein template anzulegen.

Es ist also erst einmal zu klären, was ihr erreichen wollt

eventuell beschreibt der begriff "device clonen" den vorgang besser. also ein neues device erstellen (pairen), das dabei das erscheinungsbild/look/skin eines bereits definierten devices übernimmt/cloned, einschliesslich aller channel. das würde zunächst einmal "nur" die fhem attribute betreffen (individuelle und geclonte attribute).

zusätzlich könnte man bei diesem vorgang auch gleichzeitig das funktionelle verhalten (register/peering) clonen.
ein extremes beispiel wäre zb, eine zweite 19-tasten fernbedienung zu integrieren, die völlig identisch funktioniert, wie die bereits vorhandene, die vielleicht mit allen jalousie- und lichtaktoren gepeert ist.

justme1968 · 01 Dezember 2015, 12:00:59

es wäre aber schade das nur hm spezifisch zu machen. eine erweiterung von copy fr den generellen und device unabhängigen teil mit hooks/callbacks/events um die device spezifischen teile zu implementieren wäre schöner.

zu einem kleinen teil gibt es das schon mit dem COPYED event das der floorplan verwendet um die kopierten attribute noch mal anzupassen.

martinp876 · 01 Dezember 2015, 21:01:16

Ich verstehe es teilweise. Der nutzen ist mir unklar.
1. das device pairen ist eh Pflicht. Dann sind alle Kanäle angelegt. Das sollte man nicht aendern.
2. Attribute. Könnte man kopieren, bis auf die wichtigen wie model, peers,... Die also welche vom system gebraucht werden. Das lässt sich einfach machen. Aber so viele sind es bei mir nicht, dass sich hier etwas lohnt.
3. peers. Koennte man kopieren indem man die Kommandos aus archConfig frisiert. Aber man setzt nur die peers auf einer Seite. Macht so also keinen Sinn. Außerdem stellt sich die Frage, ob die 2. FB auch identisch gepeert werden soll.
4. Register. Kann man jetzt schon kopieren. Sollte man wissen, was man tut. Stellt sich außerdem die Frage, welche peers aktiv sind. Geht also auch nicht blind.

Ich sehe auf dieser Basis keinerlei Sinn.
Sinnvoll ist für mich z.b. ein defektes device ersetzen. Das kann man klonen. Dazu pairt man es erst. Man sucht die Kommandos aus archConfig vom alten device, kopiert sie und pastet sie in die Kommandozeile. Alles gepeert wie vorher. OK, das peering bei den peers muss noch korrigiert werden, eine Lücke!
Zu guter letzt kann man die hatte aus .cfg für das device Pasten und fertig.

Alles andere würde ich in fhem für hm nicht machen. Vielleicht vervollständigte ich das mit den peers noch einmal.

Vielleicht verstehe ich den Anwendungsfall einfach nicht