Neue Geräte für CUL_HM anlegen ohne Anlernen

[Otto123]

Hallo,

ich habe existierende Definition eines x-beliebigen CUL_HM Gerätes und möchte diese zurück ins System oder auf ein anderes System bringen. Das Gerät ist gepairt, die Hardware funktioniert.
Beispiel:

Code Auswählen Erweitern

define LichtWzLU CUL_HM 1AEE1E
attr LichtWzLU IODev HMLAN1
attr LichtWzLU IOgrp VCCU
attr LichtWzLU autoReadReg 1_restart
attr LichtWzLU event-on-change-reading .*
attr LichtWzLU expert 1_allReg
attr LichtWzLU firmware 2.8
attr LichtWzLU model HM-LC-SW1PBU-FM
attr LichtWzLU peerIDs 00000000,
attr LichtWzLU room CUL_HM
attr LichtWzLU serialNr JEQ0093131
attr LichtWzLU subType switch
attr LichtWzLU verbose 5
attr LichtWzLU webCmd statusRequest:toggle:on:off
Früher konnte ich die vorhandene Definition einfach nehmen in die Raw Definition werfen und ausführen. Diese Vorgehen funktioniert nicht mehr, je nach Reihenfolge bekomme ich zwei Fehler:

subType must not be changed by User.
Use modelForce instead

oder

model must not be changed by User.
Use modelForce instead

Ok, dann nochmal in der Doku schauen.
englisch:

define may also be invoked by the autocreate module, together with the necessary subType attribute. Usually you issue a hmPairForSec and press the corresponding button on the device to be paired, or issue a hmPairSerial set command if the device is a receiver and you know its serial number. Autocreate will then create a fhem device and set all necessary attributes. Without pairing the device will not accept messages from fhem. fhem may create the device even if the pairing is not successful. Upon a successful pairing you'll see a CommandAccepted entry in the details section of the CUL_HM device.

If you cannot use autocreate, then you have to specify:
the <6-digit-hex-code>or HMid+ch <8-digit-hex-code>
It is the unique, hardcoded device-address and cannot be changed (no, you cannot choose it arbitrarily like for FS20 devices). You may detect it by inspecting the fhem log.
the subType attribute
which is one of switch dimmer blindActuator remote sensor swi pushButton threeStateSensor motionDetector keyMatic winMatic smokeDetector
Without these attributes fhem won't be able to decode device messages appropriately.

Deutsch:

define kann auch durch das autocreate Modul aufgerufen werden, zusammen mit dem notwendigen subType Attribut. Normalerweise erstellt man hmPairForSec und drückt dann den zugehörigen Knopf am Gerät um die Verknüpfung herzustellen oder man verwendet hmPairSerial falls das Gerät ein Empfänger und die Seriennummer bekannt ist. Autocreate wird dann ein FHEM-Gerät mit allen notwendigen Attributen anlegen. Ohne Pairing wird das Gerät keine Befehle von FHEM akzeptieren. Selbst wenn das Pairing scheitert legt FHEM möglicherweise das Gerät an. Erfolgreiches Pairen wird durch den Eintrag CommandAccepted in den Details zum CUL_HM Gerät angezeigt.

Falls autocreate nicht verwendet werden kann muss folgendes spezifiziert werden:
Der <6-stellige-Hex-Code>oder HMid+ch <8-stelliger-Hex-Code>
Das ist eine einzigartige, festgelegte Geräteadresse die nicht geändert werden kann (nein, man kann sie nicht willkürlich auswählen wie z.B. bei FS20 Geräten). Man kann sie feststellen indem man das FHEM-Log durchsucht.
Das subType Attribut
Dieses lautet: switch dimmer blindActuator remote sensor swi pushButton threeStateSensor motionDetector keyMatic winMatic smokeDetector
Das model Attribut
ist entsprechend der HM Nomenklatur zu vergeben
Ohne diese Angaben kann FHEM nicht korrekt mit dem Gerät arbeiten.

Ok pairen will ich ja nicht nochmal, Gerät ist ja gepairt. Ich will bloß die Konfiguration per Hand anlegen. (Ich habe es mit autocreate und autocreate disabled versucht, das Ergebnis unterscheidet sich nicht.)
Nach dem define wird sofort ein subType gesetzt der sich nicht mehr ändern lässt.
* attr subType funktioniert also nicht!
* attr model funktioniert auch nicht!
Beide Fehler sagen: Ich soll modelForce verwenden.
Ich mache also aus der obigen Original Konfig diese hier:

Code Auswählen Erweitern

define LichtWzLU CUL_HM 1AEE1E
attr LichtWzLU modelForce HM-LC-SW1PBU-FM
attr LichtWzLU IODev HMLAN1
attr LichtWzLU IOgrp VCCU
attr LichtWzLU firmware 2.8
attr LichtWzLU serialNr JEQ0093131
attr LichtWzLU room CUL_HM
Das Gerät wird angelegt und funktioniert.
Die restlichen Attribute autoReadReg expert peerIDs subType webCmd werden von irgendwem sofort von selbst angelegt.
Ist es das empfohlene Vorgehen?
Zur Define Zeile noch aus den vorhandenen attribute diese 6 attribute auswählen, dabei aus model modelForce machen und dann setzen?

Mein Resultat: Einen (steinigen) Weg gefunden, die Doku ist offenbar veraltet. (man kann ausschließlich modelForce setzen!)
Oder gibt es einen Weg der mir verborgen ist?

BTW: Ist das autocreate von dem in der Doku oben die Rede ist eigentlich das allgemeine autocreate Device? ( Ich habe eigentlich den Eindruck: es spielt keine Rolle ob autocreate disabled ist oder nicht)

Aus Benutzersicht gefragt: Was macht modelForce für einen Sinn? Wäre es nicht das Gleiche, das bisherige model einfach mit der Auswahlliste zu hinterlegen und damit model nicht mehr frei wählbar machen?
Dann bräuchte man bei der Übernahme einer Konfiguration nicht aus model -> modelForce machen.

Gruß Otto

[Pfriemler]

Also wem erzähle ich das jetzt ... 
Autocreate regelt das automatische Anlegen von Devices nach Empfang einer CUL_HM-Message über ein Device, insbesondere im Zusammenhang mit einer "ich bin hier neu"-Meldung - manchmal reicht ein powerOn.
Das eigene Anlegen eines Gerätes per Definition oder RAW-Import (was letztlich nichts als eine Batch-Abarbeitung auf der Kommandozeile ist) hat doch mit autocreate gar nichts zu tun?
Im Zusammenhang mit dem define-Auftrag für ein CUL_HM-Gerät werden aber eine Reihe von Attributen selbstredend automatisch angelegt, wie etwas peerIDs, expert etc, natürlich auch webCmd. Das sollte sich aber beim RAW-Import sofort überschreiben lassen.

Deiner alten DEF fehlt in jedem Fall das neue versteckte .mId-Attribut, woraus CUL_HM jetzt das model selbsttätig setzt, wenn es mit modelForce keine abweichende Vorgabe gibt. Da model als Attribut zum Setzen nicht mehr erlaubt ist, sehe ich wie Du modelForce als legitimen Nachfolger. subType geht demnach aber gar nicht mehr manuell zu setzen...?

Ja, streng genommen ist es eine Design-Lücke. Der Wiederimport einer alten DEF funktioniert hier nicht wie gewohnt. Ich habe aber schon damals nicht verstanden, warum das Setzen von model unterbunden wird.
model würde - wenn ich das damals richtig verstanden habe - bei jedem (Wieder-)Pairing-Vorgang aus der Message des Gerätes neu gesetzt. Da es aber inzwischen Geräte gibt, die dort eine falsche .mId setzen, hat Martin das zusätzliche modelForce installiert, welches bei einem Pairing eben nicht überschrieben wird. .mId speichert die Info für den Weg zurück, wenn modelForce gelöscht wird. Dieser Mechanismus würde bei model entfallen - aber wäre das schlimm?

Martin?

edit: .mId statt .mID

[Otto123]

Das eigene Anlegen eines Gerätes per Definition oder RAW-Import (was letztlich nichts als eine Batch-Abarbeitung auf der Kommandozeile ist) hat doch mit autocreate gar nichts zu tun?

Naja mir ist eigentlich nicht ganz klar, wer macht denn hier was? Vor allem weil ja die "Verwendung" von autocreate in der Doku explizit erwähnt wird. Aus meiner jetzigen Erfahrung spielt es bei einem manuellem define gar keine Rolle. Die attribute werden dann von CUL_HM angelegt?

[Otto123]

Deiner alten DEF fehlt in jedem Fall das neue versteckte .mId-Attribut, woraus CUL_HM jetzt das model selbsttätig setzt, wenn es mit modelForce keine abweichende Vorgabe gibt. Da model als Attribut zum Setzen nicht mehr erlaubt ist, sehe ich wie Du modelForce als legitimen Nachfolger. subType geht demnach aber gar nicht mehr manuell zu setzen...?

Ich war jetzt etwas unsicher hab das aber gerade nochmal probiert, aus der realen Umgebung:

Code Auswählen Erweitern

define HM_56CDBC CUL_HM 56CDBC
attr HM_56CDBC .mId 00FD
Antwort:

.mId must not be changed by User.
Use modelForce instead

Also nur modelForce führt zum Ziel. 

[Pfriemler]

Dann wissen wir das. Danke.

[arthur_dent_2015]

Moin Otto,
ich ziehe gerade meine komplette Installation auf ein neu aufgesetztes System um und habe das selbe Problem wie Du. raw defs bringen bei attr mId, model und subtype Fehler. Wenn man die Zeilen löscht, funktioniert der Import. Wenn man mehr als 2, 3 Geräte hat, nervt das ganz schön. Ich hab knapp 50 davon.    Mein requirement an martin daher: Bei raw import bitte die attr Prüfung aussetzen.
Da ich die Gelegenheit nutzen will gleich aufzuräumen wird es wohl einige Wochen dauern bis das neue System produktiv gehen kann.  Und da bleibt (für mich) noch die Frage offen ob die Installation dann auch funktioniert.... Bis dahin muss das alte System ja noch weiter laufen.

Gruß
Arthur

[Beta-User]

Mein requirement an martin daher: Bei raw import bitte die attr Prüfung aussetzen.

Das wird so vermutlich nicht funktionieren, weil "im Prinzip" der RAW-Import nur ein zeilenweises Abarbeiten von "normalen FHEM-Kommandos" ist.

Was hindert dich daran, diesen Teil der Config schlicht auf Dateiebene in die fhem.cfg zu übernehmen? (die Prüfung findet nur statt, wenn der FHEM-Start abgeschlossen ist, siehe Zeile 823). Da es hier um Hardware geht, ist die Übernahme von "Altlasten" dabei kein Thema, oder? (Und zu Beginn sind die manuellen Editier-Gefahren auch überschaubar).

Etwas genereller gedacht (auch für configDB-Nutzer...) mal die ungeprüfte Idee: Könnte man die RAW-Definition nicht wegspeichern und via script bereinigen/einlesen lassen? So, dass das "hinderliche" Zeug wegfällt und gleich forceModel einmalig gesetzt wird und danach wieder gelöscht (wenn ggf. später irgendwann "hinderlich")? So ein Script könnte man ggf. auch als attrTemplate ausgestalten und zentral ausliefern (CUL_HM unterstützt nur derzeit SetExtensions/AttrTemplate noch nicht, oder?)... Im letzteren Fall müßte man dann nur das zu forcende Modell kennen und könnte das via Dialogfeld abfragen.

[Pfriemler]

Wir predigen einerseits, keine händischen Änderungen an der fhem.cfg vorzunehmen, weil es funktionierende Alternativen wie den RAW-Import gibt, und dann wird genau dieser Weg durch einen Fehler in 10_CUL_HM.pm verbaut?

Sorry, aber das ist nicht vermittelbar - schon mal weil es m.W. im gesamten übrigen FHEM keinen solchen erforderlichen Sonderweg gibt: überall anders funktioniert der RAW-Import.

Die Idee, den RAW-Import skriptbereinigt laufen zu lassen, ist zwar nett, fordert aber an anderer Stelle weitere Umbauten, die beim Rest der Entwickler nicht auf Gegenliebe stoßen werden. Die Idee mit modelForce ist gut und ihre aktuelle Umsetzung hilft einige Probleme zu umschiffen, aber sie ist an dieser Stelle nicht bis zu Ende gedacht. Das ist nichts Ehrenrühriges und das kommt vor. Deswegen kann man es ja trotzdem wieder ändern.
Im Sinne einer automatischen Korrektur im Hintergrund mag das Verbot des Setzens von model und subtype durch den User sinnvoll sein, aber hier ist es einfach nur kontraproduktiv und ein Mangel.
Und ich würde sogar soweit gegen und darauf bestehen, dass der bei sich bietender Gelegenheit beseitig wird, statt die commandref anzupassen.

[arthur_dent_2015]

Das wird so vermutlich nicht funktionieren, weil "im Prinzip" der RAW-Import nur ein zeilenweises Abarbeiten von "normalen FHEM-Kommandos" ist.

Geht nicht, gbts nicht  Aber, Du hast vermutlich Recht, der Aufwand dürfte nicht gerade gering sein...

Was hindert dich daran, diesen Teil der Config schlicht auf Dateiebene in die fhem.cfg zu übernehmen? (die Prüfung findet nur statt, wenn der FHEM-Start abgeschlossen ist, siehe Zeile 823). Da es hier um Hardware geht, ist die Übernahme von "Altlasten" dabei kein Thema, oder? (Und zu Beginn sind die manuellen Editier-Gefahren auch überschaubar).

Naja, erstens arbeite ich mit configDB und 2. die fhem.cfg, die ich damit erstellt habe, ist 7201 Zeilen lang und alphabetisch sortiert. 3. ist mein "Altsystem" historisch ohne Namenskonventionen gewachsen. 4. find mal in den 7201 Zeilen die Hardware Definitionen 5. Ich hab es mir auch einfacher vorgestellt 

Etwas genereller gedacht (auch für configDB-Nutzer...) mal die ungeprüfte Idee: Könnte man die RAW-Definition nicht wegspeichern und via script bereinigen/einlesen lassen? So, dass das "hinderliche" Zeug wegfällt und gleich forceModel einmalig gesetzt wird und danach wieder gelöscht (wenn ggf. später irgendwann "hinderlich")? So ein Script könnte man ggf. auch als attrTemplate ausgestalten und zentral ausliefern (CUL_HM unterstützt nur derzeit SetExtensions/AttrTemplate noch nicht, oder?)... Im letzteren Fall müßte man dann nur das zu forcende Modell kennen und könnte das via Dialogfeld abfragen.

Das Model steht ja in den raw defs, das brauchte man nicht mal im Dialog abfragen

[Pfriemler]

Ich könnte mir übrigens einfach vorstellen, dass model vom User wieder zu setzen sein wird. Die Auswahlbox kann genau dort vorgesehen werden. Stattdessen könnte es ein (ggf verstecktes) Attribut (.)modelForce geben, welches CUL_HM im Hintergrund setzt, wenn die mId des vom User gesetzten models von  der bisherigen Definition abweicht. Im Moment führt "modelForce" ja dazu, dass "model" im Hintergrund gesetzt wird, anschließend steht der neue Wert in beiden Attributen. Funktionell gäbe es fast keinen Unterschied danach. Beim Setzen des model auf den Originalwert entsprechend der .mId würde (.)modelForce dann eben wieder im Hintergrund gelöscht.

[arthur_dent_2015]

Wir predigen einerseits, keine händischen Änderungen an der fhem.cfg vorzunehmen, weil es funktionierende Alternativen wie den RAW-Import gibt, und dann wird genau dieser Weg durch einen Fehler in 10_CUL_HM.pm verbaut?

Sorry, aber das ist nicht vermittelbar - schon mal weil es m.W. im gesamten übrigen FHEM keinen solchen erforderlichen Sonderweg gibt: überall anders funktioniert der RAW-Import.

Die Idee, den RAW-Import skriptbereinigt laufen zu lassen, ist zwar nett, fordert aber an anderer Stelle weitere Umbauten, die beim Rest der Entwickler nicht auf Gegenliebe stoßen werden. Die Idee mit modelForce ist gut und ihre aktuelle Umsetzung hilft einige Probleme zu umschiffen, aber sie ist an dieser Stelle nicht bis zu Ende gedacht. Das ist nichts Ehrenrühriges und das kommt vor. Deswegen kann man es ja trotzdem wieder ändern.
Im Sinne einer automatischen Korrektur im Hintergrund mag das Verbot des Setzens von model und subtype durch den User sinnvoll sein, aber hier ist es einfach nur kontraproduktiv und ein Mangel.
Und ich würde sogar soweit gegen und darauf bestehen, dass der bei sich bietender Gelegenheit beseitig wird, statt die commandref anzupassen.

Ich bin da ganz bei Dir. Nur, darauf bestehen bringt wohl wenig. Der Ehrgeiz des Entwicklers muss geweckt werden   Der jetzige Zustand ist unbefriedigend und sollte, wie auch immer, geändert werden.

[Beta-User]

Vorab: Dass das nicht 1:1 klappt, ein CUL_HM-Gerät zu kopieren und RAW einzulesen, ist ärgerlich, aber eben nur für wenige Fälle wirklich hinderlich, weil ja in der Regel via autocreate alles wesentliche erfaßt wird. Dass model später (nach $init_done) nicht mehr akzeptiert wird, ist lästig, aber grade in solchen Ausnahmefällen wie vorliegend, "muß" man ggf. eben ausweichen.

Es ging btw. nicht darum, den RAW-Import-Code anzupassen, sondern das Ergebnis eines "list" mit "-r"-Option (@artur_dent_2015: "list -r TYPE=CUL_HM"  ) zu kopieren, irgenwo in eine Datei zu schreiben und dann (über die Kommandozeile?) ein (vom RAW-Input völlig unabhängiges) Perl-sript aufzurufen, das das Ergebnis _einmalig_ in eine neue Konfiguration einliest und dann ggf. eben statt model modelForce verwendet (und gleich wieder löscht). Das wäre (nur!) für solche tranistionellen Themen ein Hilfsmittel, um das zu vereinfachen... So ein Script könnte man auch zentral mit dem Modul ausliefern (Wiederfinden macht Freude...).

Das Model steht ja in den raw defs, das brauchte man nicht mal im Dialog abfragen (https://forum.fhem.de/Smileys/default/wink.gif)

Na ja, du bekommst das nur nicht "in FHEM", um es innerhalb des Systems auswerten zu können . Deswegen muß man es bei Verwendung von AttrTemplate "anders" mitteilen (und deswegen hat der script-Weg den Vorteil, dass die vorhandene Info genutzt werden kann, der AttrTemplate-Weg hätte den Vorteil, dass man "nur" die "define"-Anweisung als Basis benötigen würde (aber mehrstufig vorgehen müßte wegen allen anderen Attributen...).

[Otto123]

@Pfriemler Du hast mich verstanden und sagst exakt das, was ich auch denke!
@Beta-User Sorry, aber Du liegst komplett daneben. Und du schnitzt neue Krücken weil CUL_HM "ein Bein" verloren hat.

Ich könnte mir übrigens einfach vorstellen, dass model vom User wieder zu setzen sein wird. Die Auswahlbox kann genau dort vorgesehen werden. Stattdessen könnte es ein (ggf verstecktes) Attribut (.)modelForce geben, welches CUL_HM im Hintergrund setzt, wenn die mId des vom User gesetzten models von  der bisherigen Definition abweicht. Im Moment führt "modelForce" ja dazu, dass "model" im Hintergrund gesetzt wird, anschließend steht der neue Wert in beiden Attributen. Funktionell gäbe es fast keinen Unterschied danach. Beim Setzen des model auf den Originalwert entsprechend der .mId würde (.)modelForce dann eben wieder im Hintergrund gelöscht.

Das wäre auch genau mein Vorschlag, er behält die momentane Funktion und dreht für den Benutzer die Logik wieder vom Kopf auf die Füße.

Aber model wird auch von anderen Modulen verwendet, vielleicht sehe ich etwas "Übergeordnetes" nicht

[arthur_dent_2015]

raw defs ist das hier offiziell propagierte Verfahren um Definitionen zu importieren und das sollte dann auch mit CUL_HM (ohne Modifikation der raw defs!) möglich sein. Der "normale" FHEM Anwender ist weder bereit die defs zu modifizieren noch sich Perl scripts zu schreiben um die Definitionen zu importieren. Der Weg über  "list -r TYPE=CUL_HM", output kopieren und mit paste in die fhem.cfg einfügen ist da schneller....
Ich denke da auch gerade drüber nach

[Beta-User]

Mag ja sein, dass das alles Krücken sind usw.. Nach meiner persönlichen Lesart ist das ganze Thema mit model als Attribut eine Altlast, die aus historischen Gründen so entstanden ist - irgendwie braucht man einen Ort, um die Info zu speichern, aber "eigentlich" ist das nichts, wo der user "einfach so" rumfrickeln können sollte. Es macht wenig Sinn, hier die grundsätzliche Entscheidung des Entwicklers, das dem Zugriff des Users zu entziehen, in Zweifel zu ziehen wegen der  seltenen Ausnahmefälle, in denen man irgendeinen "Kompabilitätsmodus" braucht, wie z.B. solche Teilumzüge.

Und dass CUL_HM auch an anderen Stellen hin und wieder "spezielle Kommandos" braucht, ist auch nichts neues, siehe "rename".

Allgemein kurz: zieht sich das Modul die Infos nicht "irgendwann" sowieso aus den Infos, die vom Gerät her angefordert werden (getConfig?). Dann wäre es einfach, das beim Importieren einfach wegzulassen (ist schon klar, dass dann weiter Nacharbeit erforderlich ist, und uU. auch gewartet werden muß, bis alle Kommandos und Attribute verfügbar sind).

Hat halt alles Pferdefüße...


Zur Info: Habe neulich auch meine Installation umgezogen. Die ist configDB-basiert und enthält einiges CUL_HM-Zeug. War zwar ein Vollumzug, aber: 0 Problemo, was aus der config kommt, wird ansstandslos übernommen...
Wer unbedingt sowas spezielles wie Teilumzüge machen will, kann immer noch händisch den Hardareteil in die cfg reineditieren (und auf configDB dann erst migrieren, wenn der Teil steht). In so einem Fall ist sowieso einiges an Nacharbeit angesagt. M.E. auch kein Grund, Entwickerkapazität zu beanspruchen (aber kommunizieren sollte man, wie es geht...).