Neue Geräte für CUL_HM anlegen ohne Anlernen

[frank]

dieser thread hat wohl corona.   

[Pfriemler]

Martin, auch von mir: Bitte nicht angegriffen fühlen, genau das Gegenteil war gemeint. Außerdem reden wir noch aneinander vorbei.

zu modelForce kann ich mich nur Otto anschließen: gestatte die Änderung von model mit den gleichen Mechanismen wie modelForce. Dass es eine händische Überschreibung war, merkt man doch anschließend gar nicht. Auch mit den Subtype-Issues könnte ich leben.

Alle (in Worten ALLE) Attribute haben und bewirken, triggern und steuern Funktionen.

model und subtype eben nicht mehr durch den User. Sie werden dürfen nur noch "ferngesteuert" gesetzt werden (model durch modelForce, subType setzt sich automatisch).

in der Einführungsphase - in der ich (schande) ein paar fehler gemacht habe. Seit dem ist m.E. alles prima.

Deines Erachtens. Aber dass wir modelForce von Anfang an nicht gut fanden und lieber model änderbar wollten, kannst Du nicht abstreiten. Diesen Userwunsch hast Du ignoriert. Das ist Dein gutes Recht übrigens, genauso wie unseres, eine andere Meinung zu haben. Und ich werde CUL_HM keinesfalls umpfuschen, weil es bei Dir schon in den besten Händen ist. Punkt.

... Ein Channel kann ohne Device nicht. Die Messages müssen synchronisiert werden. ...

Auch mit händischen Edits kann im Moment viel schief gehen. Jeder User kann auch im laufenden Betrieb Kanäle oder Devices löschen oder eben - das hattest Du missverstanden - unglaublich viele Infos zu den Geräten vorsätzlich oder unabsichtlich löschen (clear all) und den Status speichern (save), ohne dass es zu dauerhaften (!) Problemen kommen würde, die Du jetzt durch Deinen modelForce-Mechanismus abfangen zu müssen meinst. Aber wir reden ja gar nicht über händische Änderungen, sondern über das komplette Einkopieren anderswo erprobter und lauffähiger Konfigurationen. Im Gegenteil: Durch das jetzt erforderliche manuelle Ändern (von model auf modelForce und das Löschen des subTypes) steigt die Wahrscheinlichkeit von Fehlern sogar. Meine ich.

ein CUL_HM-Gerät mit FHEM-Bordmitteln (also ohne den Einsatz externer Editoren

ist vorhanden. Einfach model nach modelForce im internen Editor ändern, subType löschen, here you go.
Save, fertig.

Das Ergebnis ist zwar funktionell identisch, aber in der Konfiguration nicht. Und es erfordert Handarbeit. Bei einem Gerät: ok. Bei mehreren: einfach nur lästig.

Es macht auch keinen Sinn, in allen Kanäle alle Parameter eines Device zu replizieren. Das macht es komplex, langsam und verhindert die Beziehungs-notwendigkeit immer noch nicht.

Ich verstehe absolut nicht im Geringsten, was das mit der Problematik zu tun hat.

Wir können einen kompletten Konfigurationsblock, dessen Einpflege per RAW CUL_HM mit Fehlermeldungen vereitelt, händisch einkopieren und FHEM und CUL_HM lesen alles brav beim Neustart ein ohne einen Muckser zu machen.

nun, eben nicht. Die Daten werden nicht in fhem.cfg kopiert sondern ausgeführt.

Ja natürlich, und sie werden damit Bestandteil der Konfiguration und auch künftig abgespeichert. Und bis auf sehr wenige Dinge funktioniert das doch auch jetzt bereits mit CUL_HM, wie Du korrekt anmerkst: "modelForce nehmen und subType löschen und fertig." Ist nur leider noch nicht ganz so einfach...
Bitte widersprich mir, wenn ich falsch liege:
Im normalen Anlernprozess wird auf die Info-Meldung des Gerätes ein Device angelegt und anhand des erkannten Models mit besonderen Eigenschaften versehen und dazu ggf. zusätzliche Kanälen nach einem vom Hauptdevice abgeleiteteten Namen definiert. Gleiches passiert mit modelForce: ggf. werden Unterkanäle angelegt oder ggf. gelöscht. Prima, wie das funktioniert. Bereits vorhandene Kanäle, die auch in der neuen modelID benutz werden, werden auch nicht gelöscht und neu angelegt oder umbenannt. Alles korrekt!

Genau diese Hintergrundaktivitäten sind löblich und wichtig, wenn es um die Neuanlage einer vollständigen Konfiguration für neue Geräte geht. Braucht es aber bei einem Konfigurationsimport gar nicht. Die Kanäle sind alle schon dabei. Und sie haben vor allem vielleicht schon ganz andere Namen als wie sie beim automatischen Anlegen verwendet werden. FHEM kann die importierten Daten zu den Unterkanälen dann nicht zuordnen. Das meinte ich mit "ist doch nicht so einfach".

Wenn gewünscht kann ich einen Bastel-mode enfügen, in welchem ich alle checks abschalte. Dann kannst du alles eingeben und es wird sicher auch etwas herauskommen.

Genau. Das könnte es sein. Wir fügen einfach Konfigurationsdaten hinzu. Statt dass es viele Automatiken von Dir beim Anlernen tun, liefern wir die Infos direkt. Zum Schluss sagen wir "fertig" und dann kann CUL_HM alles prüfen - oder einfach auch erst beim nächsten Neustart.

[Pfriemler]

Nein Du hast model force geschrieben es MUSS aber
modelForce
heissen!

Siehst DU es? OHNE LEERZEICHEN und MIT GROßEM F

Donnerwetter. Das habe ich bis nach Berlin gehört ... 

[Otto123]

Donnerwetter. Das habe ich bis nach Berlin gehört ... 

Ja sorry, ist eigentlich nicht meine Art. Aber ich habe nochmal gezählt: Es war Nummer 5 

[frank]

modelForce wurde ja "eigentlich" entwickelt, um devices, die eine "falsche" modelid senden, nutzen zu können.

wenn man jetzt "normale" devices nur mit hilfe von modelForce manuell definiert bekommt (ausser über fhem.cfg), finde ich das irgendwie "unlogisch".

wenn man sich dabei "verschreibt", wird das wahrscheinlich auch nie automatisch korrigiert werden.

[Kusselin]

Ja sorry, ist eigentlich nicht meine Art. Aber ich habe nochmal gezählt: Es war Nummer 5 

ja siehst...kommt vor...wenn man vor lauter Wald die Bäume nicht sieht.....Aber danke Dir Otto...hat jetzt alles geklappt soweit mit dem Umzug.

[Beta-User]

@Kusselin:
MAn solltest du nach erfolgreicher Übernahme eigentlich die modelForce-Attribute wieder löschen - vorausgesetzt, die "eigentlichen Attribute" .mId und subType wurden vom Modul dann wieder automatisch und richtig erstellt. Sonst könnte es sein, dass es irgendwann, wenn du dich nicht mehr an den Grund erinnern kannst, nach einem Update oä. dann seltsame Effekte gibt...?

[Kusselin]

@Beta-User, danke Dir für die Info. Dann muss ich mal unter den Attributen schauen...

Frage: Würde das mit der .mId und subType auch in der RAW Definition drinne stehen....?

Frage: Wovon hängt das denn ab ob die .mId und subType sich wieder autom. einstellt?

Gruss

[Beta-User]

Diese Attribute sollten sich mAn. nach einem getConfig (oder irgendwas in der Art, bitte ausnahmsweise mal selbst in die Doku sehen) wieder von alleine füllen (und dann auch in der RAW wieder auftauchen); diese sind ja grade unter der Kontrolle vom Modul und eigentlich dem Benutzerzugriff entzogen, grade damit man sehen kann, dass (aus Modulsicht) alles paßt... Ich gehe weiter davon aus, dass das Modul nach einem FHEM-Start zumindest bei den nicht-Batterie-Geräten das getConfig früher oder später abfeuert, um konsistente Daten zu erhalten...

Kurz: Du checkst, ob die "richtigen" Attribute da sind und löschst (erst) dann das modelForce, wenn das der Fall ist. (Ich fange auch schon an, mich zu wiederholen, aber das dritte Mal werde ich mir gleich schenken...).

[MadMax-FHEM]

Diese Attribute sollten sich mAn. nach einem getConfig (oder irgendwas in der Art, bitte ausnahmsweise mal selbst in die Doku sehen) wieder von alleine füllen (und dann auch in der RAW wieder auftauchen); diese sind ja grade unter der Kontrolle vom Modul und eigentlich dem Benutzerzugriff entzogen, grade damit man sehen kann, dass (aus Modulsicht) alles paßt... Ich gehe weiter davon aus, dass das Modul nach einem FHEM-Start zumindest bei den nicht-Batterie-Geräten das getConfig früher oder später abfeuert, um konsistente Daten zu erhalten...

Kurz: Du checkst, ob die "richtigen" Attribute da sind und löschst (erst) dann das modelForce, wenn das der Fall ist. (Ich fange auch schon an, mich zu wiederholen, aber das dritte Mal werde ich mir gleich schenken...).

getConfig bzw. Register lesen (und das ist doch getConfig!?) richtet sich nach dem Attribut autoReadReg (zumindest würde ich das so verstehen/"erwarten")...
...und man kann es dadurch auch bzgl. automatisches Lesen "deaktivieren"...

Gruß, Joachim

[Beta-User]

? Macht es Sinn, hier proaktiv auf eventuelle weitere Fragen des TE einzugehen?

Erfahrungsgemäß wird er sich schon melden, wenn irgendwas unklar ist (und je mehr Aspekte genannt werden, desto größer ist die Wahrscheinlichkeit, dass etwas unklarer wird, was vorher in min. 90% der Fälle klar gewesen wäre...)

[Otto123]

Dem TE ist alles klar

[Kusselin]

@Kusselin:
MAn solltest du nach erfolgreicher Übernahme eigentlich die modelForce-Attribute wieder löschen - vorausgesetzt, die "eigentlichen Attribute" .mId und subType wurden vom Modul dann wieder automatisch und richtig erstellt. Sonst könnte es sein, dass es irgendwann, wenn du dich nicht mehr an den Grund erinnern kannst, nach einem Update oä. dann seltsame Effekte gibt...?

schön das man das so erfährt....Ihr, als Experts hier..klar ihr wisst das ..ich hab gar nicht die zeit sooft mich mit all dem zu beschäftigen....dann passieren mir noch solche Situationen wie mit Otto....mmhh da will man eigemntlich nicht mehr fragen....da ihr mich eh auf der Liste habt  , aber andere profitieren sicherlich davon

[Beta-User]

Ihr, als Experts hier..klar ihr wisst das

Das Problem ist, dass dieser Mechanismus (vermutlich) leider nicht nur speziell dir, sondern insgesamt ganz einfach zu wenigen klar ist, und ich selber werde das auch in 2 Monaten wieder vergessen oder verdrängt haben...
Genau deswegen war ja die Empfehlung von meiner Seite, das möglichst gleich wieder soweit gradzuziehen, dass du (und eventuelle Helfer) später nicht nochmal drüber stolpern; das hat nichts mit irgendeiner Liste zu tun auf der irgendjemand zu stehen glaubt!

(Dass du dennoch gut daran tätest, etwas genauer zu lesen, was man dir schreibt, steht auf einem ganz anderen Blatt, und für grovelling https://tty1.net/smart-questions_de.html#grovelling besteht zwar vieleicht Anlaß, aber letztlich ist es nicht hilfreich, weder für dich noch für uns. Kurz: mach einfach deine Hausaufgaben und mache sie gründlich, aber möglichst nicht verkrampft, sonst kommt es nämlich zu genau den Effekten, dass sogar sehr geduldigen Leuten wie Otto der Kragen platzt... Gehe einfach davon aus, dass du einen Fehler gemacht hast, wenn etwas nicht funktioniert; in der Regel hast du - wie hier - schludrig gelesen oder eine Anleitung nicht 1:1 befolgt - oder eben genau 1:1, obwohl sie sich nach Lektüre der aktuellen Doku (=>commandref) als veraltet darstellt).

[Otto123]

Ach der Kragen ist noch heil. Ich weiß: groß und rot sieht aus wie schreien - aber hier bei mir war es ganz still.
Ich war nur etwas verzweifelt. Und ich habe keine Liste