Hallo,
der copy Befehl von fhem geht bei Homematic Geräten nicht. Das Kopieren wird abgelehnt, da die hmId bereits vorhanden ist (logischer Weise). Das ist irgendwie doof, da man dann immer alles von Hand machen muss. Schöner wäre, wenn der Copy Befehl funktioniert und man an dem neuen Device einfach die def ändern könnte. Oder gibt es da einen Parameter, den ich nicht kenne ?
Gruß Christoph
copy ist nicht für Devices dieser Art gedacht. Es macht auch keinen Sinn, eine ID für HM zwei mal im System zu haben. Auch nicht kurzfristig. Warum lässt du die HM Geräte nicht per autocreate anlegen? Du musst sie doch ohnehin pairen.
Hallo,
das mit dem Autocreate mache ich schon - aber das ganze Geraffel wie Icons, Room, Gruppe, .... wäre schön wenn man das kopieren könnte.
Mein vorgehen wäre - pairen, dann hat das Device die ID für PairCentral und ich die ID vom Device. Das Device löschen und ein anderes Device kopieren - mit allen Attributen. Anschließend die ID vom neuen Device einsetzen und gut.
Gruß Christoph
Es gab diesbezüglich mal Vorschläge (Attribute von einem Device auf das andere kopieren) hier im Forum. Das ganze ist aber, wenn ich mich recht erinnere, im Sand verlaufen.
Ich weiss nicht, wie gut makefine (http://www.fhemwiki.de/wiki/Makefine) in diesem Fall funktioniert - auf jeden Fall geht es wohl in die Richtung dessen, was Du möchtest (und ist vielleicht auch das, was marvin78 meint).
Peter
Ja mit einer eigenen sub (oder eben dieser makefine sub), kann man viel machen. Das ist aber nicht, was ich meine. Es ging um eine Erweiterung von copy.
Hier eine kleine Quick&Dirty sub, die angegebene Attribute von einem Gerät auf ein anderes kopieren kann:
sub copyAttr($$$) {
my ($dev,$copy,$attrs) = @_;
my @attrs = split(":",$attrs);
foreach my $attr (@attrs) {
my $attrVal=AttrVal($dev,$attr,"-");
if ($attrVal ne "-") {
$attr{$copy}{$attr} = $attrVal;
}
}
}
Anwendung:
{copyAttr('DEVICE1','DEVICE2','Attr1:Attr2:Attr3')}
Bitte beachten, es gibt keine Überprüfung, ob es sinnvoll ist, die Attribute zu kopieren oder ob die Attribute überhaupt vorhanden oder für das Zieldevice geeignet sind.
Edit: cmdalias dazu
define copyAttributes cmdalias copyattr .* AS {copyAttr("$EVTPART0","$EVTPART1","$EVTPART2")}
Verwendung:
copyattr DEVICE1 DEVICE2 Attr1:Attr2:Attr2
ja. es gab mal eine diskussion das copy kommando so weit aufzubohren das man angeben kann was alles kopiert oder überschrieben wird. ein ganzes device, nur bestimmte attribute, ...
das ganze ist aber im sande verlaufen weil nicht klar war wie viele echte anwendungen es dafür gegeben hätte und zum anderen die syntax nicht ganz klar war wenn es wirklich flexibel sein soll.
ich denke mit einer cmdalias basierten lösung die du auf deinen anwendungsfall maßschneidern kannst hat du mehr möglichkeiten.
gruss
andre
Hallo,
wer meckert eigentlich die doppelte ID an - in welchem Modul ist das festgelegt ? Wenn ich mir das so ansehe, ist das kopieren in der fhem.cfg (ich weiß soll man nicht) die einfachste Möglichkeit.
Gruß Christoph
CUL_HM mag keine doppelten IDs. Aus sehr gutem Grund. FS20 etc. machen das aber das gleiche. Ebenfalls aus gutem Grund.
Eventuell hilft dir ja mein Beitrag weiter oben vorerst.
das copy kommando geht über die define routine des moduls. die CUL_HM DefFn spuckt die meldung aus.
neben allen anderen problemen beim bearbeiten der fhem.cfg hast du zusätzlich immer den nachteil das fhem neu startet und eine weile tot ist und jeder aktuelle interne zustand der nicht im save file landete verloren geht.
das ist also niemals optimal.
gruss
andre
FS20 kann man mehrfach mit der gleichen id definieren. aber das ist eigentlich nicht sinnvoll.
gruss
andre
Du hast Recht. Ich habe nicht erst nachgesehen, hatte es aber anders in Erinnerung. Dann wäre copy aber immerhin möglich.
Hallo,
das es bei FS20 geht hilft nicht wirklich. Das es keinen Sinn macht, eine doppelte ID im System zu haben ist schon klar. Ich wollte die ja auch dann direkt ändern. Das kann man ja recht einfach mit Klick auf DEF. Vielleicht macht es ja Sinn, den copy Befehl so zu ändern, das er beim Kopieren von Devices eine Dummy ID einsetzt. Prüft DefFn auch ob die ID korrekt ist (also 6 Stellen hat) ? Wenn nein, dann wäre es doch einfach dort "new" reinzuschreiben.
Gruß Christoph
DefFn prüft auf die korrekte Form, ja. new kann dort nicht stehen.
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. :)
Alle Attribute kopieren ist aber ggf. gar keine gute Idee. Ich denke da bei HM an IOList, firmware, peerIds, serialNr etc.
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.
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. ;)
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
die alte diskussion war hier: http://forum.fhem.de/index.php/topic,23759.msg171457.html#msg171457 (http://forum.fhem.de/index.php/topic,23759.msg171457.html#msg171457).
schon ziemlich viele möglichkeiten und immer noch nicht vollständig.
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
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
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
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.
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
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.
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.
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.
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
Hallo Martin,
der Anwendungsfall ist eigentlich simpel. Ein Raum und x Fenster - an jedem ein Rollo und ein Fensterkontakt - vielleicht auch noch mehrere Heizkörper. Da habe ich keine Lust Group, Room, Icon, devStateIcon, webCmd, event-on-change, expert, autoreadreg immer für jedes Gerät einzustellen. Eigentlich geht es mir nur um die Attribute - die peerings und das eine register setze ich dann von Hand - den Namen muss ich ja auch anpassen und die Version,Typ ... bekomme ich ja über einen getConfig. Die Geräte, die ich kopieren möchte sind Baugleich.
Gruß Christoph
Ich würde ( im Gegensatz zur allgemeinen Empfehlung - auch von mir) einfach fhem.cfg manipulieren. Oder besser: kopieren die Attribute des masterdevice in einen editor. Löschen die Zeilen, die du nicht kopieren willst. Ersetze den Namen. Paste es in die kommandozeile.
Ich setze einige Attribute mit meinem userfhem.cfg automatisch. So setze ich generell eventonchangereading für alle cul_hm beim reboot. Ebenso expert in jeden device,in channels löschen ich das. Das gleiche koennte man mit icon abhängig vom device machen.....
Den Raum muss man manuell einstellen. Group koennte auch automatisch gehen. Ich werde das bei mir evtl. Noch ausbauen.
Voraussetzung ist ein (aus meiner Sicht unbedingt notwendiges) user.cfg. Das file muss per notify nach dem init ausgeführt werden.
vermutlich muss man unterscheiden zwischen alle bestehenden devices ändern (weil sich das namenschema oder was auch immer) geändert hat. das geht zur zeit attributweise über devspec.
ein neues device hinzu nehmen. ich weiss nicht wie aufwändig das wirklich ist eine hand voll attribute zu setzen. das passiert ja nicht oft.
beim automatisch setzen muss man sehr aufpassen. bewegunsgsmelder und taster z.b. funktionieren mit gesetzten event-on-change nicht mehr. die einen kennen nur motion, bei den anderen funktioniert danach Short nicht mehr. das muss man also eigentlich recht fein konfigurieren können. das gilt glaube ich auch für ein default device icon oder auch devStateIcon. da wäre ein solcher default mechanismus besser als kopieren. zumal es dann völlig automatisch geht.
Hallo Martin,
wo findet man den ein größeres/komplexeres Beispiel so einer fhem_user.cfg? Im Wiki konnte ich nur beim HM-Dis-WM55 einen kurzen Ausschnitt finden.
Gruß,
Reiner
Du kannst hier ausführen was du willst. Wie gesagt ausühren. Im normalen Config kann man nichts wirklich ausführen. Hier ist ausserdem sichergestellt, dass es NACH dem init ausgeführt wird, wenn also alle Devices schon existieren.
define a5 at +00:01:00 set hm loadConfig
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual expert 12_templOnly
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual autoReadReg 5_readMissing
attr TYPE=CUL_HM event-on-change-reading .*
deleteattr TYPE=CUL_HM:FILTER=DEF=........ expert
deleteattr TYPE=CUL_HM:FILTER=subType=virtual expert
deleteattr TYPE=CUL_HM:FILTER=DEF=........ autoReadReg
deleteattr TYPE=CUL_HM:FILTER=subType=virtual autoReadReg
deleteattr TYPE=CUL_HM verbose
set dis_01 displayWM short line1 e:{myLineA(1,0)}
set dis_01 displayWM short line2 e:{myLineA(2,0)}
set dis_01 displayWM short line3 e:{myLineA(3,0)}
Dass du das UserConfig per notify starten/laden musst ist dir klar?
.....
Da die makefine sub hier schon mal Erwähnung fand, ich habe sie etwas überarbeitet.
http://forum.fhem.de/index.php/topic,45553.msg373345.html#msg373345
Grüße
igami