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...).

[Otto123]

Moin,

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.

Ich will keine Entscheidungen des Entwicklers in Zweifel ziehen. Im Gegenteil, ich möchte ihn gern unterstützen.
Und ich rede auch nicht von seltenen Ausnahmefällen, ich rede über grundlegende Funktionen in FHEM:
define Gerät CUL_HM ... funktioniert quasi nicht mehr!
Realität und Beschreibung stimmen nicht überein! (und ich will auch nicht das die Beschreibung angepasst wird)
Ich möchte mithelfen einen ganz normalen Weg für den User zu gestalten wie er seine Geräte anlegen kann ohne auf geheime Tipps angewiesen zu sein und ohne das Gefühl zu haben etwas "verbotenes" oder "eigentlich falsches" zu tun.

Und ich wollte einen momentanen Weg dokumentieren und wissen ob ich dabei was übersehen habe.  Ich selbst habe kein Problem und brauche keine Lösung - aber ich mag es auch nicht, wenn ich selbst Geheimtipps als quasi Standard Hilfe anbieten muss.

Gruß Otto

[Beta-User]

(Wir sind uns einig, es sollte schon so sein, dass man keine Geheimkenntnisse benötigen sollte, um Geräte händisch zu definieren).

Das define funktioniert, das Problem ist, was danach passiert bzw. danach vom Modul erwartet wird bzw. durchgeführt wird.

Nur als weitere Idee (dieses Mal ggf. auch an Martin): Beim Define einen Marker iVm. einem internaltimer setzen, der den Marker wieder entfernt nach sehr kurzer Zeit (2-5 Sek) , und dann die Prüfung bei $init_done um das alternative Vorhandensein des Markers erweitern. Dann würde typischerweise ein RAW-Input durchlaufen, nicht aber die manuelle Eingabe via Kommandozeile...

[Kusselin]

Hallo Otto,

muss deinen Thread hier nochmal aufmachen..... ich habe einen HMuart den ich mal zum Testen abgemacht habe vom Raspi und auf den Test Raspi gestetzt habe.....VCCU und HMuart opned!!!

Wenn ich jetzt dieses Device von meinem hauptfhem nehme:

Code Auswählen Erweitern

defmod Garage_Aktor CUL_HM 471C02
attr Garage_Aktor .mId 0061
attr Garage_Aktor IODev myHmUART
attr Garage_Aktor IOgrp VCCU:myHmUART
attr Garage_Aktor alias Garage_Aktor
attr Garage_Aktor autoReadReg 4_reqStatus
attr Garage_Aktor expert 2_raw
attr Garage_Aktor firmware 2.8
attr Garage_Aktor model HM-LC-SW4-DR
attr Garage_Aktor room CUL_HM
attr Garage_Aktor serialNr NEQ0194570
attr Garage_Aktor subType switch
attr Garage_Aktor webCmd getConfig:clear msgEvents

setstate Garage_Aktor CMDs_done
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgCtDlyOff geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgCtDlyOn geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgCtOff geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgCtOn geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgCtValHi 100
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgCtValLo 50
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgMultiExec on
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgOffDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgOffTime unused
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgOffTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgOnDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgOnTime unused
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgOnTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgSwJtDlyOff off
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgSwJtDlyOn off
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgSwJtOff off
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-lgSwJtOn dlyOff
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shCtDlyOff geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shCtDlyOn geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shCtOff geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shCtOn geLo
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shCtValHi 100
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shCtValLo 50
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shMultiExec off
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shOffDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shOffTime unused
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shOffTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shOnDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shOnTime unused
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shOnTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shSwJtDlyOff off
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shSwJtDlyOn off
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shSwJtOff off
setstate Garage_Aktor 2019-01-13 10:29:34 .R-HM_39CD09_Btn_01-shSwJtOn dlyOff
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgCtDlyOff geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgCtDlyOn geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgCtOff geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgCtOn geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgCtValHi 100
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgCtValLo 50
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgMultiExec on
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgOffDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgOffTime unused
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgOffTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgOnDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgOnTime unused
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgOnTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgSwJtDlyOff on
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgSwJtDlyOn on
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgSwJtOff dlyOn
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-lgSwJtOn on
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shCtDlyOff geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shCtDlyOn geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shCtOff geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shCtOn geLo
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shCtValHi 100
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shCtValLo 50
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shMultiExec off
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shOffDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shOffTime unused
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shOffTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shOnDly 0 s
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shOnTime unused
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shOnTimeMode absolut
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shSwJtDlyOff on
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shSwJtDlyOn on
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shSwJtOff dlyOn
setstate Garage_Aktor 2019-01-13 10:29:35 .R-HM_39CD09_Btn_02-shSwJtOn on
setstate Garage_Aktor 2019-01-13 10:29:31 .R-confBtnTime permanent
setstate Garage_Aktor 2019-01-13 10:29:31 .R-intKeyVisib invisib
setstate Garage_Aktor 2019-01-13 10:29:31 .R-localResDis off
setstate Garage_Aktor 2019-01-13 10:29:32 .R-statusInfoMinDly 2 s
setstate Garage_Aktor 2019-01-13 10:29:32 .R-statusInfoRandom 1 s
setstate Garage_Aktor 2019-01-13 10:29:32 .R-transmitTryMax 6
setstate Garage_Aktor 2019-01-13 10:29:33 .peerListRDate 2019-01-13 10:29:33
setstate Garage_Aktor 2020-06-28 08:28:47 .protLastRcv 2020-06-28 08:28:47
setstate Garage_Aktor 2019-01-13 10:29:26 D-firmware 2.8
setstate Garage_Aktor 2019-01-13 10:29:26 D-serialNr NEQ0194570
setstate Garage_Aktor 2020-06-28 08:28:29 PairedTo 0x123123
setstate Garage_Aktor 2019-01-13 10:29:34 R-HM_39CD09_Btn_01-lgActionType jmpToTarget
setstate Garage_Aktor 2019-01-13 10:29:34 R-HM_39CD09_Btn_01-shActionType jmpToTarget
setstate Garage_Aktor 2019-01-13 10:29:35 R-HM_39CD09_Btn_02-lgActionType jmpToTarget
setstate Garage_Aktor 2019-01-13 10:29:35 R-HM_39CD09_Btn_02-shActionType jmpToTarget
setstate Garage_Aktor 2019-01-13 10:29:31 R-pairCentral 0x123123
setstate Garage_Aktor 2019-01-13 10:29:32 R-powerUpAction off
setstate Garage_Aktor 2019-01-13 10:29:32 R-sign off
setstate Garage_Aktor 2020-06-28 08:28:29 RegL_00. 00:00 02:01 0A:12 0B:31 0C:23 15:FF 18:00
setstate Garage_Aktor 2020-06-28 08:28:47 commState CMDs_done
setstate Garage_Aktor 2019-01-13 10:43:47 deviceMsg off (to VCCU)
setstate Garage_Aktor 2019-01-13 10:43:47 level 0
setstate Garage_Aktor 2019-01-13 10:43:47 pct 0
setstate Garage_Aktor 2019-01-13 10:43:47 recentStateType info
setstate Garage_Aktor 2020-06-28 08:28:47 state CMDs_done
setstate Garage_Aktor 2019-01-13 10:43:47 timedOn off

Also das ist die RAW Definition...aber die geht ja so nicht mehr laut deinem Test.....wie kann ich den Aktor nun ohne wieder anlernen im test fhem anlernen???

Ich bekomme auch immer die Meldung:

Code Auswählen Erweitern

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

wenn ich jetzt nur zb.

Code Auswählen Erweitern

define Garage_Aktor CUL_HM 123123 gehts nicht.....dann kommt die Meldung ID ist schon von der VCCU vergeben....

Über ne jurze Hilfe vielen Dank.

[Otto123]

Wie kommst Du jetzt auf die andere hmId ?
Sollte alles so gehen:

Code Auswählen Erweitern

defmod Garage_Aktor CUL_HM 471C02
attr Garage_Aktor IODev myHmUART
attr Garage_Aktor IOgrp VCCU:myHmUART
attr Garage_Aktor alias Garage_Aktor
attr Garage_Aktor autoReadReg 4_reqStatus
attr Garage_Aktor expert 2_raw
attr Garage_Aktor firmware 2.8
attr Garage_Aktor modelForce HM-LC-SW4-DR
attr Garage_Aktor room CUL_HM
attr Garage_Aktor serialNr NEQ0194570

attr Garage_Aktor webCmd getConfig:clear msgEvents
Edit: das muss noch raus

Code Auswählen Erweitern

attr Garage_Aktor subType switch

Sollte sogar nur so gehen, nach meinem ersten Post:

Code Auswählen Erweitern

define Garage_Aktor CUL_HM 471C02
attr Garage_Aktor modelForce HM-LC-SW4-DR
attr Garage_Aktor IODev myHmUART
attr Garage_Aktor IOgrp VCCU:myHmUART
attr Garage_Aktor firmware 2.8
attr Garage_Aktor room CUL_HM
attr Garage_Aktor serialNr NEQ0194570


[Kusselin]

Hi Otto,
danke...

ich dachte ich muss immer die HMID von der VCCU verwenden.......

Ich probiers morgen mal aus und schreibs dir dann...Danke

[Pfriemler]

ich dachte ich muss immer die HMID von der VCCU verwenden.......

Dann fehlt FHEM doch die Info, welche ID das Gerät hat.

Die IO-Geräte (also in diesem Fall das HMUART) sollte die Zentralen-ID (vccu) haben. (Ein zweites IO-Gerät außerhalb der VCCU wiederum sollte eine abweichende HMID haben).

Es geht hier zwar ums "Eintragen ohne Anlernen", aber ich würde aus dem zweiten FHEM doch mal ein "hmPairSerial" mit Seriennummer des Sw4 riskieren. Dann sind define und model schon mal korrekt gesetzt.

Und: wie ich es verstanden habe, willst Du auf dem zweiten System die gleiche Zentralen-ID wie auf dem ersten verwenden? (denn sonst geht es ja gar nicht ohne Anlernen). Allerdings dürfen dann 1. und 2. FHEM nie gleichzeitig in Betrieb sein. Zwei Zentralen mit der gleichen ID zur gleichen Zeit gibt nur jede Menge Kleinholz.

[Kusselin]

Danke Pfriemler...gut erklärt!

[Kusselin]

Hi Otto,
danke...

ich dachte ich muss immer die HMID von der VCCU verwenden.......

Ich probiers morgen mal aus und schreibs dir dann...Danke

Hi Otto,
habe den Code so kopiert.....kam aber wieder die Meldung

Code Auswählen Erweitern

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

[Otto123]

Glaub ich Dir nicht.
Bei mir läuft das einwandfrei durch:

Code Auswählen Erweitern

define Garage_Aktor CUL_HM 471C02
attr Garage_Aktor modelForce HM-LC-SW4-DR
attr Garage_Aktor IODev myHmUART
attr Garage_Aktor IOgrp VCCU:myHmUART
attr Garage_Aktor firmware 2.8
attr Garage_Aktor room CUL_HM
attr Garage_Aktor serialNr NEQ0194570

Bei der ersteren Variante muss die subType Zeile raus, habe es oben geändert. Die Fehlermeldung ist aber eine Andere!

[Kusselin]

Ok schaue und meld mich

[martinp876]

1) die restriktion der Attribute werden ich beibehalten - ich sehe keinen Grund zum Ändern und keine Anwendugn welche der User nicht machen kann.
2) der Use-Case "Anlegen ohne Anlernen" ist mir nicht klar. Ohne Anlernen geht  nichts. Es kann sich also nur um ein Scenario handeln, in welchen der User ein Device gelöscht hat und es nun wieder will. Das KANN er nur in die alte Config gehen und die Attribute kopieren...
2a) dann könnte er es auch in das neue Config hineinkopieren?
2b) er könnte einfach einmal config drücken?
3) modelForce ist die Methode, das model ohne config-message(Anlerntaste! - nicht anlernen) und ohne cfg-file edit - zu setzen. Dann ist alles verfügbar. Warum sollte ich das drehen?

[Otto123]

2a) geht mit Deiner Restriktion nicht mehr In sicher 99 % alle FHEM Device geht das:
- Raw DEF öffnen
- alles kopieren
- in einen andere / neue Instanz gehen Raw DEF öffnen,
- alles einfügen
- ausführen - fertig!
2b) es gibt Geräte / Einbausituationen wo das eben nicht mal so einfach gemacht ist.

Warum sollte ich das drehen?

Damit die Logik wieder auf den Füßen steht, Du hast sie meiner Meinung nach auf den Kopf gestellt.

Gruß Otto

[martinp876]

Verstanden.
Raw Def habe ich bisher nicht betrachtet/bemerkt.
Die Implementierung von Raw Definition halte ich erst einmal für (sehr) fraglich - oder habe es noch nicht verstanden. Nicht aus Sicht des Users, aus Sicht der System-Integration.
### Meine Punkte / Philosophie
- Viel oder alles erlauben ist gut für Bastler, schlecht für "Anwender"
   + Baslter wursteln sich durch und müssen mit Problemen Lebel
   + Anwender brauchen Führung und Sicherheit. Für Module welche ich nicht maintaine wünsche ich mir das Dringend
   => Mögliche Fehler sind zu verhindern
- FHEM erlaubt sehr viel - es sollte aber Grenzen geben.
==> So mir nicht  noch Details fehlen, welche ich noch suchen werde, ist das Fenster undurchdacht. Schade eingentlich, die Idee ist gut.
### Raw Def:
- was ist "Raw" an dieser Definition? Es wird schlicht die Definition identisch dem fhem.cfg in eine Komamndozeile kopiert - gefolgt von. den Readings (welche überaltert sind)? Raw ist da erst einmal nichts. Das Kopieren ist ein Vorteil
=> ich hätte schlicht die Zeilen mit <entity> aus dem Config ge-grept und in das Kommandofenster ge-pastet.
=> Das Raw-Fenster im Eingabe-modus ist schlicht ein Terminal-fenster mit multi-Command Option
=> Das Fenster ist nicht auf "define" begrenzt - der Titel ist also falsch
=> Die Ausführung deines Beispiels wirft bei mir den ersten Fehler, dass das IO nicht vorhanden ist (logisch). Ich muss also editieren.
   . Lösche ich diese Zeile geht das Define schief, da es schon ausgeführt ist. => noch einmal editieren
   . Dann bleibt es am Model hängen - mit der Response "modelForce" zu nutzen. nicht ok? Editieren musste ich schon mehrfach
   . Sub-Type wird automatisch gesetzt - passt also
=> kopieren ich ein mehrteiliges Device (8-kanal-Schalter) wird es schon wieder schwierig. CUL_HM legt die 8 Kanäle an (was absolut sinn macht, weiche ich nicht ab!). Und nun willst du den 8-fach Schalter kopieren - natürlich mit 8 Kanälen. _> jetzt bist du dran... wie soll das gehen?
=> hast du schon einmal probiert, einen Kanal zu kopieren? So einfach ist das nicht....

#### Meine Vision / Anforderungen:
* Um ein Device aus CUL_HM zu kopieren muss ich  alle Kanäle mitnehmen
* CUL_HM kann das kopieren unterstützen und ein Datenpaket zu Verfügung stellen. Nur CUL_HM kennt die Zusammenhänge (wie jedes andere Modul auch)
* Um ein Device zu "pasten", es also "nach-zu Konfigurieren", entsprechend dem fhem.cfg - kann man implementieren. CUL_HM kann gerne in einen "raw" Modus implementieren. Dazu muss das raw-definition Fenster diesen aktivieren.

===>> Nun hatten wir einen neuen Modus (z.B. "raw")

##> Das Kommando ist aus meiner Sicht fehlgeschlagen. Um es zu betreiben ist einiges (EINIGES) nicht beachtet. Es würde sich relativ einfach lösen lassen, wenn fhem-web nachbessern würde.

[Otto123]

Hallo Martin,

ca. 4 Jahre nach der Einführung der Raw Definition stellst Du deren Sinnfälligkeit in Frage?

• Ob das Ding Raw Definiton oder "Willis Bastelbude" heisst spielt doch erstmal keine Rolle. Man findet einen Begriff für ein Tool, der Inhalt, Umfang usw. kann sich auch mal ändern. Man gibt dem Kind einen Namen ohne zu wissen was aus ihm wird wenn es erwachsen ist.
• Die Funktion der mehrzeiligen Kommandozeile gibt es in Form der telnet Schnittstelle doch schon immer?
• Die Anzeige in dem Fenster liefert keine veralteten Readings, es zeigt die Definition des Gerätes aus der aktuellen Config und den Inhalt des aktuellen statefile.
• Letztlich führt Raw Definitonen einen kleinen Auszug aus der config zur Laufzeit aus. Aus meiner Sicht muss das genauso funktionieren wie zum Start von FHEM auch.
• Wie es vom Prinzip her funktioniert hat Rudi hier mal kurz beschrieben.
• Raw Definition ist aus meiner Sicht eines der wichtigsten Mittel beim sicheren Umgang mit FHEM gerade für Anwender. Ich finde nicht, dass Raw Definition ein Modus für Bastler (Insider) ist

Gruß Otto

[martinp876]

Ich habe es vorher nicht gesehen, nicht gebraucht, nicht vermisst und nicht hinterfragt. Faktisch ist mir egal wie alt es ist.
Ich habe es gerne, wenn der Name Programm ist. Weder raw noch define passen. Define zum teil, ok.
Mein telnet client kann mehrzeilig, andere auch. Ist also kein added value für mich, ich gebe dir recht.
Natürlich sind die readings bei  EXPORT aktuell. Der IMPORT findet aber an einem andere  gerät zu einem anderen Zeitpunkt statt. Somit veraltet beim import. Ich würde die readings IMMER weglassen.
Das mit dem auszug ist mir klar. Das mit dem funktonieren zur Laufzeit: klares nein. Ich räume nach dem init auf, komtrolliere attribute und abhängigkeiten, welche der kernal mir unsortiert vor die Füsse wirft. Readings mit referenzen zu nicht mehr vorhandenen entities machen keinen sinn. Kanäle werden angelegt.... Wie machst du das?
Rudis erklärung werde ich mir ansehen. Wenn es nur eine Erklärung für Anwender ist kann ich es mir sparen. Das kann man nach 2min überreissen.
Im letzten punkt habe ich keine Meinung. Ich habe es bislang nicht vermisst, tue es noch immer nicht. Mir ist der usecase immer noch unklar. Für culhm sehe ich in der anwendung einige probleme, nicht nur "model" sondern auch kanäle.
Ich bin gerne bereit, rawdefine zu unterszützen. Auf der aktuellen basis wird es nicht funktionieren.

Die aktuelle basis ist für bastler. Sie für Anwender sollvoll zu gestalten wäre mein anliegen. Culhm kann nicht sehen, dass rawdef ausgeführt wird.

[martinp876]

wie erwartet steht in deinem Link keinerlei hilfreiche Info für Entwickler drin.
Rudi hat (wie es in FHEM häufig ist) das ganze "self-containted" erstellt. Das funktioniert in den use-cases welche ich mir vorstelle nicht.
Die Use-cases sind
a) ein User hat 2 Systeme, bspw "test" und "live". Nun will er ein Element von Test nach Live oder umgekehrt kopieren... oder verschieben?
b) ein User will einem anderen die Installation seines Devices übermitteln

Beispiel Module wie meine Stereoanlage (Yamaha) oder die Fritzbox. Das geht wunderbar. Das sind low-level Entities. Kein IO verlinkt, keine Sub-komponenten, keine Peers. Alles Prime, copy and go.

Beispiel average. Kann ich kopieren - allerdings muss ich alle "probably assitiated" channels betrachten und bewerten. Ok, wird unterstützt, muss ich in CUL_HM nachhalten.
=> bei CUL_HM müssen dies erst einmal ALLE entites eines Device sein
=> es könnten/sollten auch alle peers sein
=> es sind auch die IOs und die VCCU

Bei CUL_HM muss für ein Kanal ein Device vorhanden sein. Technisch notwendig. Bei der Definition des Device werden die Kanäle angelegt. Ein folgendes "define" eines Kanals kann nicht funktionieren, die Adresse ist schon vergeben. Ggf wäre es ein "rename", kein "defmod".

Eine ordentliche Implementierung würde von Rudi erfordern, dass ein Trigger gesetzt wird oder im Kommando ein "raw" indikator mitgeschickt wird. Ein Beginn/ennd wäre notwendig.
=>mit "Beginn" sammelt CUL_HM die Definitionen und attribute
=> mit "end" wird die "normale" Prüfung gemacht und alles wie nach "config" eingetragen.
=> Readings welche fragwürdig zu kopieren sind werden entfernt/ersetzt
=> readings zu Registern bspw sind dem Peer zugeordnet. Existiert dieser? Wenn nicht ist das Reading zu ersetzten. Ebenso die Peernamen.
=> auf der anderen Seite hat der User die Möglichkeit, beliebige Kommandos hier abzuschicken. Möglich ist ein set on kommando. Das torpediert das Verhalten. Wenn ich das Define erst nach "end" scharf schalten klappt das "set" nicht. Sind wir wieder beim Punkt "Namen". raw Define understellt definitionen, keine aktionen.

Wie immer liegt der Teufel im Detail.

[Pfriemler]

Ich verstehe nicht, warum Du alles so kompliziert machen willst. Kein Mensch verlangt hier, dass die per RAW definierten Geräte vom Fleck weg voll funktionstüchtig sind. Wir wollen nur einen Mechanismus abseits des direkten fhem.cfg-Editieren, um relativ einfach CUL_HM-Geräte in ein FHEM zu bekommen.
Was genau akut hinderlich, wurde hier schon so oft beschrieben. Namentlich der Sonderweg von CUL_HM, ein normalerweise editierbares Attribut wie model für Benutzeränderungen zu sperren (und modelForce ist eine Behelfskonstruktion, mehr nicht). Viele User haben schon mehrfach und frühzeitig darauf hingewiesen, dass hier ein sonst zu FHEM inkompatibler Sonderweg beschritten wurde.
Und CUL_HM sind für mich keine Geräte mit irgendeinem höheren Level. Es gibt diverse Hardwarefamilien mit ähnlicher Komplexität - Rademacher zum Beispiel, und da gibt es keine Probleme mit RAW-Imports. Allesamt speichern sie alle Infos in der fhem.cfg und im statefile - und haben keine ernsten Probleme damit, wenn letzteres korrupt ist oder Daten fehlen.

readings ... ich kann auch im laufenden System ein "clear all" und "save" machen und habe damit alle Infos zum CUL_HM-Gerät gelöscht, vom peering/pairing bis zu aktuellen Werten. Wichtig ist allein, dass das HM-Gerät nicht vergessen hat, auf welche Zentralen-ID es hören soll. Der Rest lässt sich zur FHEM-Laufzeit per getConfig, devInfo etc wiederholen. Auch das wäre alles - nötigenfalls manuell - nach einer händischen CUL_HM-Def problemlos nachzuholen.

Gib dem User eine Möglichkeit, ein CUL_HM-Gerät mit FHEM-Bordmitteln (also ohne den Einsatz externer Editoren und unter Umgehung der zu Recht verpönten, hier aber bisher den einzigen Workaround darstellenden Direktänderung der fhem.cfg) zu importieren und fertig. Ich sähe kein Problem, wenn man die Geräte zunächst nicht voll funktionsfähig hat, sondern dazu einen Neustart machen muss. Ist bei jedem update doch auch so. Und nichts anderes machen wir hier als Workaround auch: 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.

[martinp876]

und modelForce ist eine Behelfskonstruktion, mehr nicht

I am sorry, was ein Quatsch. Das es ist ein Attribut. Alle (in Worten ALLE) Attribute haben und bewirken, triggern und steuern Funktionen.

Viele User haben schon mehrfach und frühzeitig

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

Und CUL_HM sind für mich keine Geräte mit irgendeinem höheren Level.

was auch immer ein höherer Level ist - da hast du recht. Aber mit notwendigen beziehungen. Ein Channel kann ohne Device nicht. Die Messages müssen synchronisiert werden. Als ich begonnen hatte war dies in den Grundlagen ignoriert worden. Die Übertragung müss (MUSS) in diesem fall schief gehen.
Das ist kein höherer level - aber es sind eine autonomen Entites.
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.

Gerne kannst du CUL_HM unschreiben, wenn du einen einfacheren Weg hast.

Es gibt diverse Hardwarefamilien mit ähnlicher Komplexität - Rademacher zum Beispiel, und da gibt es keine Probleme mit RAW-Imports

prima.

Allesamt speichern sie alle Infos in der fhem.cfg und im statefile - und haben keine ernsten Probleme damit, wenn letzteres korrupt ist oder Daten fehlen.

CUL_HM auch nicht. Es funktioniert halt nicht. 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. Testen werde ich das nie, debuggen auch nicht.
Bedarf?

laufenden System ein "clear all" und "save" machen

Was willst du mit sagen? - ich habe es implementiert. Warum also erst ausführen? Lösche den part vor Ausführung.

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.

hier aber bisher den einzigen Workaround darstellenden Direktänderung der fhem.cfg

falsch

Ich sähe kein Problem, wenn man die Geräte zunächst nicht voll funktionsfähig hat, sondern dazu einen Neustart machen muss.

das geht doch! Allerdings aufgepasst bei Kanälen. Aber support brauchst du hier nicht, wie ich herausgelesen habe - alle Checks "off"

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. Also eben nicht wie beschrieben.  Wäre es wie du sagst, also append to fhem.cfg (incl save), reboot, wäre alles kein Problem.

Workaround:
Ich habe einmal eueren Vorschalg importiert
1. Fehler: IOdev not defined => ich lösche oder editiere den IO namen, starte noch einmal
2. Fehler: Device already exist => beim 2. Versuch muss ich das devMod löschen, starte noch einmal
3. Fehler: IOgrp fail, weil das preferecIO nicht existiert: ich lösche oder editiere den IO namen, starte noch einmal
4. Fehler: model ... please use modelForce => ich editiere model nach modelForce, starte noch einmal
5. Fehler: subType must not be set. please use modelForce => ich lösche diese Zeile (wird automatisch gesetzt) und starte noch einmal
=> alles durch

Das war ein einfacher Fall, da keine Peers, es war ein Device, kein Channel.  Aber wenn das IO passt sind model durch modelForce zu ersetzen und subType zu löschen.

[Kusselin]

Hallo Otto,

wenn ich zb noch dieses HM-Cul Device habe:

Code Auswählen Erweitern

defmod Temperatur_Feuchte_Speicher CUL_HM 1FCAFC
attr Temperatur_Feuchte_Speicher .mId 003F
attr Temperatur_Feuchte_Speicher IODev myHmUART
attr Temperatur_Feuchte_Speicher IOgrp VCCU:myHmUART
attr Temperatur_Feuchte_Speicher actCycle 000:10
attr Temperatur_Feuchte_Speicher actStatus alive
attr Temperatur_Feuchte_Speicher alias Temperatur_Feuchte_Speicher
attr Temperatur_Feuchte_Speicher autoReadReg 4_reqStatus
attr Temperatur_Feuchte_Speicher expert 2_raw
attr Temperatur_Feuchte_Speicher firmware 1.3
attr Temperatur_Feuchte_Speicher model HM-WDS40-TH-I
attr Temperatur_Feuchte_Speicher peerIDs 00000000,
attr Temperatur_Feuchte_Speicher room CUL_HM
attr Temperatur_Feuchte_Speicher serialNr KEQ0242488
attr Temperatur_Feuchte_Speicher subType THSensor

setstate Temperatur_Feuchte_Speicher T: 37.3 H: 26
setstate Temperatur_Feuchte_Speicher 2020-07-05 17:35:04 .protLastRcv 2020-07-05 17:35:04
setstate Temperatur_Feuchte_Speicher 2020-07-05 06:22:38 Activity alive
setstate Temperatur_Feuchte_Speicher 2019-01-13 09:40:40 D-firmware 1.3
setstate Temperatur_Feuchte_Speicher 2019-01-13 09:40:40 D-serialNr KEQ0242488
setstate Temperatur_Feuchte_Speicher 2020-07-05 17:35:04 battery ok
setstate Temperatur_Feuchte_Speicher 2020-07-05 17:35:04 humidity 26
setstate Temperatur_Feuchte_Speicher 2020-07-05 17:35:04 state T: 37.3 H: 26
setstate Temperatur_Feuchte_Speicher 2020-07-05 17:35:04 temperature 37.3



muss ich dann auch nur das hier kopieren:

Code Auswählen Erweitern

defmod Temperatur_Feuchte_Speicher CUL_HM 1FCAFC
attr Temperatur_Feuchte_Speicher .mId 003F
attr Temperatur_Feuchte_Speicher IODev myHmUART
attr Temperatur_Feuchte_Speicher IOgrp VCCU:myHmUART
attr Temperatur_Feuchte_Speicher actCycle 000:10
attr Temperatur_Feuchte_Speicher actStatus alive
attr Temperatur_Feuchte_Speicher alias Temperatur_Feuchte_Speicher
attr Temperatur_Feuchte_Speicher autoReadReg 4_reqStatus
attr Temperatur_Feuchte_Speicher expert 2_raw
attr Temperatur_Feuchte_Speicher firmware 1.3
attr Temperatur_Feuchte_Speicher model HM-WDS40-TH-I
attr Temperatur_Feuchte_Speicher peerIDs 00000000,
attr Temperatur_Feuchte_Speicher room CUL_HM
attr Temperatur_Feuchte_Speicher serialNr KEQ0242488
attr Temperatur_Feuchte_Speicher subType THSensor

und das setstate immer weglassen.....

mit der RAW Definition zb fürs Abfallmodul usw...ist das eine feine Sache...klar noch die entsprechenden perl Abhängigkeiten per putty installieren...aber dann läufts....nur halt bei den schon gepairten HM Devices ist das nicht so einfach.....

Über ne Info herzlichen Dank

[Otto123]

@martinp876
1-3 sind nicht vorhanden wenn der IO genauso existiert wie im ursprünglichen System.
4. da stehst Du meiner Meinung nach auf dem Kopf - tausche model <-> modelForce in deinem Kopf (und CUL_HM) und ich bin zufrieden
5. subType nicht setzen zu dürfen, eine Zeile zu löschen - damit könnte man vielleicht leben. Ignoriere einfach das setzen dieses Attributes (wenn das geht?), schreib von mir aus eine Info ins Log. Gut ist ...

Martin: Keiner will Dich angreifen und Dir Vorschriften machen! Wir wollen nur ein leicht nutzbares System und ich will Feedback aus Usersicht geben!

Du hast leider meinen ersten Beitrag nicht komplett gelesen, ich habe dort auch gefragt warum die Doku anders ist als die Realität! Das ist ein Jahr nach meinem Beitrag leider immer noch so. 

[TomLee]

@Kusselin

setstate kannst mit kopieren oder auch nicht, wenn dann hast halt kurzzeitig (solange keine Aktualisierung auf dem zweiten Pi stattfindet) die Readings vom Alten im Neuen Device.

Gruß

[Otto123]

@Kusselin wie schon gesagt
model in modelForce ändern
.mId und subType Zeile löschen
Also so:

Code Auswählen Erweitern

defmod Temperatur_Feuchte_Speicher CUL_HM 1FCAFC
attr Temperatur_Feuchte_Speicher IODev myHmUART
attr Temperatur_Feuchte_Speicher IOgrp VCCU:myHmUART
attr Temperatur_Feuchte_Speicher actCycle 000:10
attr Temperatur_Feuchte_Speicher actStatus alive
attr Temperatur_Feuchte_Speicher alias Temperatur_Feuchte_Speicher
attr Temperatur_Feuchte_Speicher autoReadReg 4_reqStatus
attr Temperatur_Feuchte_Speicher expert 2_raw
attr Temperatur_Feuchte_Speicher firmware 1.3
attr Temperatur_Feuchte_Speicher modelForce HM-WDS40-TH-I
attr Temperatur_Feuchte_Speicher peerIDs 00000000,
attr Temperatur_Feuchte_Speicher room CUL_HM
attr Temperatur_Feuchte_Speicher serialNr KEQ0242488


[martinp876]

da stehst Du meiner Meinung nach auf dem Kopf - tausche model <-> modelForce in deinem Kopf (und CUL_HM) und ich bin zufrieden

verstehe ich nicht. modelForce ist schon von der Bedeutung her das Überschreibeh. (aber Namen interessieren dich ja nicht )
Wenn ich es tausche hast du das Problem anders herum - was alsió gewinnst du?
Aber: Ich kann das Attr "Model" zulassen, so lange es "leer" ist. Weiter kann ich das Überschreiben mit dem identischen Inhalt zulassen. Das ändert nichts.
Somit sind model und subTyp vom Eis.

1-3 sind nicht vorhanden wenn der IO genauso existiert wie im ursprünglichen System.

Sind wir wieder beim Usecase. Copy in identische Systeme... hm. wenn das alles ist.

subType nicht setzen zu dürfen, eine Zeile zu löschen - damit könnte man vielleicht leben.

das ist eine überraschende Wende. model nach modelForce zu tauschen ist nicht viel mehr - zumal es sogar vorgeschlagen wird, im pop-up Fenster

=> trotz der Änderung halte ich es immernoch für ein exterm nurdiges interface in dem man, um es zum Laufen zu bekommen ggf die foren durchschen muss. Ich sehe weitere Problem, welche euch nicht interessieren.

Martin: Keiner will Dich angreifen und Dir Vorschriften machen!

hast du auch gelesen?
Mein Anspruch ist, die eingaben und das handling für nicht-experten und non-Nurds nutzbar zu machen. Das will ich auch von anderen devices. Ein bischen mehr plug-and-play, alle vermeidbaren Fehler abfangen. Zusammenhänge aufdecken, darstellen, prüfen, Quatsch verhindern.

Doku werde ich mir noch ansehen

P.s.:

Ignoriere einfach das setzen dieses Attributes (wenn das geht?)

Das geht   mehrfach nicht. A) verhindert es das system und B) sollte es bei Verweigerung eines Kommandos immer ein reject geben. Bitte NIE etwas anderes implementieren!
Bei solchen Vorschlägen sind wir tief in der bastelecke. Nichts für ungut....

[Otto123]

Martin ich hatte und habe zwei Ziele mit diesem Beitrag:
1. Konsistenz zwischen Doku und Realität
2. Ein identisches Verhalten wie in (wahrscheinlich) 99% der Geräte in FHEM:
- Raw Def auf, alles kopieren
- Device löschen
- Raw Def auf und alles "einfach" einfügen, execute und fertig. Gerät existiert wie vorher.

Mir geht es nicht um Klick Klack und Popups und Hinweise. Ich mache vieles per Script, nur das ist wirklich nachvollziehbar. Für CUL_HM brauche ich ne Sonderlocke, habe ich längst. Also für mich kein Problem.
Aber dem normalen User muss man die Unterschiede zwischen den "normalen" Geräten und CUL_HM Geräten im Handling der Raw Def beibringen. Damit wird es nicht einfacher, es wird komplizierter.

[Beta-User]

Aber dem normalen User muss man die Unterschiede zwischen den "normalen" Geräten und CUL_HM Geräten im Handling der Raw Def beibringen. Damit wird es nicht einfacher, es wird komplizierter.

Genauer gesagt: das ist ein Ding der Unmöglichkeit; der "normale User" kapiert es nicht (bzw. es wird noch 5 Jahre dauern, bis sich das soweit rumgesprochen hat, dass der Hilfesuchende hinreichend viele Helfer findet, die das Thema kennen...)

Das Problem sind v.a. auch Systemumzüge, die viele User dazu nutzen, ihr System nochmal sauber aufzusetzen. Da werden sie dann nach Jahren plötzlich wieder mit der vollen Komplexität konfrontiert, die sie beim ersten Durchgang schon nicht vollständig durchschaut hatten.

Vielleicht etwas umfassender gesprochen: Auch die Diskussion zum "optimalen Startprozess" neulich ging sehr in die Richtung, dass CUL_HM sehr spezielle Anforderungen stellt (die ich bisher auch mehr oder weniger komplett nicht wahrgenommen hatte). Das ist nicht als Kritik gemeint, es zeigt aber m.E. ein Dilemma auf, das aus dem vorhandenen (beschränkten) "Werkzeugen" folgt, die wir in FHEM halt haben (oder eben nicht): Es gibt (fast) nur "harte Fakten" (die in der Konfiguration (cfg) stehen), volatile Dinge (Readings, statefile) und sehr volatile Infos (Internals). Dabei gilt bei den harten Fakten die Unterscheidung in DEF (vom Modul auf Gültigkeit geprüft, sonst verworfen) und Attribute. Bei Attributen hatte ich mal irgendwo den "Kernsatz" aufgeschnappt: Die sind für den User da.
Davon weicht CUL_HM (aus duchaus nachvollziehbaren Gründen) ab, indem es eben bestimmte Attribute dem Userzugriff entzieht (zumindest, wenn man nicht cfg-Editing betreibt).

(Dass andere Module teils die Querbeziehungen zwischen ihren Kanälen nicht (wirklich) "kennen", stört mich auch und ich halte  CUL_HM u.a. auch in der Hinsicht für sehr gut).

Leider kann ich im Moment auch keine Lösung für das Problem präsentieren. Vielleicht wäre es möglich, dem "normalen" attr-Befehl (über die Befehlszeile) ein "-f" (für "force") zu spendieren, damit man es sich wenigstens sparen kann, erst ein modelForce einzugeben, um es hinterher wieder zu löschen? User auf cfg-Editing zu verweisen halte ich jedenfalls für keine Option.

Allg. kann ich den Argumenten nur zustimmen, die Otto123 hier aus Usersicht vertritt, auch wenn ich (aus MAINTAINER-Erfahrungen haraus) auch gut nachvollziehen kann, dass eigentlich Bedaf besteht, "Maintainer-Attribute" zu setzen. Falls das noch andere (echte Programmierer, nicht Hobbyisten wie ich) ähnlich sehen, wäre es evtl. an der Zeit, über "read-only Attribute" zu diskutieren. Sowas sollte sich doch über den Modulcode dann kennzeichnen lassen und ggf. diese "-f"-Variante (oder wie auch immer man das ggf. besser umsetzen kann) allg. verfügbar machen...? (Und wie ist das dann in diesen Fällen mit dem roten Fragezeichen...? Diese Diskussion ist hier insgesamt aber nicht wirklich gut aufgehoben.)

[Kusselin]

Hi Otto,

also, gestern abend folgendes gemacht.....dieses Device:

Code Auswählen Erweitern

defmod HZK_EG_Essen CUL_HM 31041E
attr HZK_EG_Essen .mId 0095
attr HZK_EG_Essen IODev myHmUART
attr HZK_EG_Essen IOgrp VCCU:myHmUART
attr HZK_EG_Essen actCycle 000:10
attr HZK_EG_Essen actStatus alive
attr HZK_EG_Essen alias HZK_EG_Essen
attr HZK_EG_Essen autoReadReg 4_reqStatus
attr HZK_EG_Essen expert 2_raw
attr HZK_EG_Essen firmware 1.3
attr HZK_EG_Essen model HM-CC-RT-DN
attr HZK_EG_Essen room CUL_HM
attr HZK_EG_Essen serialNr LEQ1084630
attr HZK_EG_Essen subType thermostat
attr HZK_EG_Essen webCmd getConfig:clear msgEvents:burstXmit
genommen und so verändert das .mID weg ist und bei model das "force" danach gesetzt also das es dann so aussieht:

Code Auswählen Erweitern

defmod HZK_EG_Wohnen CUL_HM 31076B
attr HZK_EG_Wohnen IODev myHmUART
attr HZK_EG_Wohnen IOgrp VCCU:myHmUART
attr HZK_EG_Wohnen actCycle 000:10
attr HZK_EG_Wohnen actStatus alive
attr HZK_EG_Wohnen alias HZK_EG_Wohnen
attr HZK_EG_Wohnen autoReadReg 4_reqStatus
attr HZK_EG_Wohnen expert 2_raw
attr HZK_EG_Wohnen firmware 1.3
attr HZK_EG_Wohnen model force HM-CC-RT-DN
attr HZK_EG_Wohnen room CUL_HM
attr HZK_EG_Wohnen serialNr LEQ1085508
attr HZK_EG_Wohnen subType thermostat
attr HZK_EG_Wohnen webCmd getConfig:clear msgEvents:burstXmit
Wenn ich dann unter RAW Definition "Execute commands" drücke kommt wieder folgende Meldung:

Code Auswählen Erweitern

model must not be changed by User.
Use modelForce instead
??
Jetzt bin ich halt bissl irritiert......Du hast doch geschrieben das man das model durch model force ersetzen muss und das .mID weglassen /löschen soll??

Was mach ich immer noch nicht richtig?
Gruss

[Otto123]

Hi Kusselin,

Du hast mich NICHT verstanden, ich habe folgendes gesagt.

@Kusselin wie schon gesagt
model in modelForce ändern
.mId und subType Zeile löschen
Also so:

Da steht nichts von model force und Du hast auch NICHT subtype gelöscht!
Abgesehen davon, dass beide Defs nicht viel gemeinsam haben

Das ist jetzt der dritte (oder vierte?) Anlauf in die gleiche Richtung, ich bin etwas frustriert.

Gruß Otto

[Kusselin]

Hi Otto,

o.k. subtype habe ich nicht gelöscht aber model force habe ich hinzugefügt schau:

Code Auswählen Erweitern

defmod HZK_EG_Wohnen CUL_HM 31076B
attr HZK_EG_Wohnen IODev myHmUART
attr HZK_EG_Wohnen IOgrp VCCU:myHmUART
attr HZK_EG_Wohnen actCycle 000:10
attr HZK_EG_Wohnen actStatus alive
attr HZK_EG_Wohnen alias HZK_EG_Wohnen
attr HZK_EG_Wohnen autoReadReg 4_reqStatus
attr HZK_EG_Wohnen expert 2_raw
attr HZK_EG_Wohnen firmware 1.3
[b]attr HZK_EG_Wohnen model force HM-CC-RT-DN[/b]
attr HZK_EG_Wohnen room CUL_HM
attr HZK_EG_Wohnen serialNr LEQ1085508
attr HZK_EG_Wohnen subType thermostat
attr HZK_EG_Wohnen webCmd getConfig:clear msgEvents:burstXmit

[Otto123]

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

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

[Kusselin]

Ups......ja jetzt .... Asche über mein Haupt
Danke

[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

[Kusselin]

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

Die rote Schrift habe ich dann auch gesehen  ja, beta user da hast du schon recht wenn du schreibst ....verkrampfe nicht so.....ich bin dann halt auch immer so angespannt was jetzt kommt und dann passierts eben.. aber zumeindest kann ich jetzt schon mal mein komplettes fhem umziehen auf neuen Raspi und das ohne backup!!

[MadMax-FHEM]

aber zumeindest kann ich jetzt schon mal mein komplettes fhem umziehen auf neuen Raspi und das ohne backup!!

GRATULIERE!
Und war doch auch gar nicht sooo schwer!?

Aber nur weil das "Original-fhem" noch läuft/lief...

Besser auch mal "üben" (und nicht nur vorbereitet sein [und vorbereitet bist du ja hoffentlich ZUMINDEST!]) für den Fall, dass es eben NICHT mehr läuft...
...und vorbereitet sein, für den Fall, dass es nicht mal mehr "erreichbar" ist, also für den "Super-Gau"

EDIT: aber das war ja schon mal eine gute "Fingerübung" in die richtige/wichtige Richtung...

Gruß, Joachim

[Kusselin]

Haaaalt zurück..... mit den HM Devices gibts doch noch Unstimmigkeiten.....habe mal ein hminfo gemcht ojeee:

Code Auswählen Erweitern

configCheck done:

missing register list
    Dachfenster_Flur: RegL_00.,RegL_01.
    HM_Fernbedienung: RegL_00.
    HM_Fernbedienung_Btn_01: RegL_01.,RegL_04.peerUnread
    HM_Fernbedienung_Btn_02: RegL_01.
    HM_Fernbedienung_Btn_03: RegL_01.
    HM_Fernbedienung_Btn_04: RegL_01.
    HM_Fernbedienung_Btn_05: RegL_01.
    HM_Fernbedienung_Btn_06: RegL_01.
    HM_Fernbedienung_Btn_07: RegL_01.
    HM_Fernbedienung_Btn_08: RegL_01.
    Temperatur_Feuchte_Speicher: RegL_00.

peer list incomplete. Use getConfig to read it.
    incomplete: HM_Fernbedienung_Btn_01: peerUnread
    incomplete: HM_Fernbedienung_Btn_02:
    incomplete: HM_Fernbedienung_Btn_03:
    incomplete: HM_Fernbedienung_Btn_04:
    incomplete: HM_Fernbedienung_Btn_05:
    incomplete: HM_Fernbedienung_Btn_06:
    incomplete: HM_Fernbedienung_Btn_07:
    incomplete: HM_Fernbedienung_Btn_08:

peer not verified. Check that peer is set on both sides
    Beleuchtung_Terrasse: p:HM_Fernbedienung_Btn_01
    Beleuchtung_Terrasse: p:HM_Fernbedienung_Btn_02
    Garage_Aktor_Sw_02: p:HM_Fernbedienung_Btn_03
    Garage_Aktor_Sw_02: p:HM_Fernbedienung_Btn_04
    Garage_Aktor_Sw_03: p:HM_Fernbedienung_Btn_05
    Garage_Aktor_Sw_03: p:HM_Fernbedienung_Btn_06
    Garage_Aktor_Sw_04: p:HM_Fernbedienung_Btn_07
    Garage_Aktor_Sw_04: p:HM_Fernbedienung_Btn_08
    HZK_EG_Wohnen_Weather: p:Temp_Feuchte_Wohnen_EG_Weather
    Temp_Feuchte_Wohnen_EG_Weather: p:HZK_EG_Essen_chn-07
    Temp_Feuchte_Wohnen_EG_Weather: p:HZK_EG_Essen_chn-31

PairedTo missing/unknown
    Dachfenster_Flur:
    HM_Fernbedienung:
    Temperatur_Feuchte_Speicher:

IOgrp: CCU not found
    VCCU: ->meineVCCU

templist mismatch
    HZK_EG_Essen_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
    HZK_EG_Wohnen_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
    Temp_Feuchte_Wohnen_EG_Climate: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory
    Temp_Feuchte_Wohnen_OG_Climate: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory



den GaragenAktor.....da hat das peeren nicht geklappt......peeren und Pairen...ja ich weiss ein Unterschied......Wenn ich im Wiki peeren lese müsste ich es aber hinbekommen oder?

Gruss

[MadMax-FHEM]

Dass du immer gleich Panik bekommst...

Das sind praktisch (fast) alles Ausgaben die mittels getConfig von den gemeldeten Geräten gelesen würden und alles gut...

...die Meldung bzgl. Templisten ignorieren (wenn du keine brauchst hast) oder halt welche anlegen (lassen) und gut...

EDIT: gut ein paar sind dann doch "interessanter", würde aber erst mal die "einfachen" weg machen   vccu, da mal ein list und/oder nat. bei den Devices schauen ob das genannte Attribut passt...

EDIT: evtl. sind dann auch ein paar weitere bzgl. missing Peer/Paired auch weg... EDIT: also durch das getConfig...

EDIT: und statt "Panic Mode" einfach mal in Ruhe Meldung für Meldung lesen (kurz nachdenken) und "machen was da steht"!? Senkt den Blutdruck und führt zu einem längeren und ruhigeren Leben

Gruß, Joachim

[Kusselin]

Joachim.....beim Garagen Aktor kann ich ein "getConfig" machen....bei den Heizkörperthermostaten auch.....
Frage: Was macht man bei den Channels vom GaragenAktor also 01-04?

List VCCU

Code Auswählen Erweitern

Internals:
   DEF        123123
   FUUID      5f02d92e-f33f-fb9b-1ed4-518c1363cd71cb79
   IODev      myHmUART
   NAME       VCCU
   NOTIFYDEV  global
   NR         82
   NTFY_ORDER 50-VCCU
   STATE      myHmUART:ok
   TYPE       CUL_HM
   assignedIOs myHmUART
   chanNo     01
   READINGS:
     2020-07-07 20:01:23   IOopen          1
     2020-07-07 20:02:01   cfgState        ok
     2020-07-07 20:01:23   state           myHmUART:ok
     2020-07-06 17:43:46   unknown_2D8997  received
     2020-07-06 17:41:46   unknown_31041E  received
     2020-07-06 17:45:05   unknown_31076B  received
     2020-07-06 16:33:50   unknown_39CD09  received
     2020-07-06 17:43:43   unknown_515175  received
     2020-07-06 16:03:54   unknown_56CBBF  received
     2020-07-06 16:11:25   unknown_56CBE6  received
   helper:
     HM_CMDNR   150
     mId        FFF0
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     ack:
     cmds:
       TmplKey    :no:1594061753.02493
       TmplTs     1594061753.02493
       cmdKey     :1:1:1::FFF0:01
       TmplCmds:
       cmdList:
         assignHmKey:
         assignIO:-IO- [set|unset]...
         clear:[readings|rssi|msgErrors|msgErrors|unknownDev]
         defIgnUnknown:
         deviceRename:newName
         fwUpdate:-filename- -bootTime- ...
         getDevInfo:
         hmPairForSec:-sec- ...
         hmPairSerial:-serial-
         peerChan:-btnNumber- -actChn- ... [single|dual|reverse] [set|unset] [actor|remote|both]
         peerSmart:[Beleuchtung_Terrasse|Dachfenster_Flur|Garage_Aktor_Sw_02|Garage_Aktor_Sw_03|Garage_Aktor_Sw_04|HM_Fernbedienung_Btn_01|HM_Fernbedienung_Btn_02|HM_Fernbedienung_Btn_03|HM_Fernbedienung_Btn_04|HM_Fernbedienung_Btn_05|HM_Fernbedienung_Btn_06|HM_Fernbedienung_Btn_07|HM_Fernbedienung_Btn_08|HZK_EG_Essen_WindowRec|HZK_EG_Essen_remote|HZK_EG_Wohnen_WindowRec|HZK_EG_Wohnen_remote|Temp_Feuchte_Wohnen_EG_WindowRec|Temp_Feuchte_Wohnen_EG_remote|Temp_Feuchte_Wohnen_OG_WindowRec|Temp_Feuchte_Wohnen_OG_remote|Terrasse_Wz]
         postEvent:-condition-
         press:[long|short] [noBurst] [-repCount(long only)-] [-repDelay-] ...
         raw:data ...
         reset:
         unpair:
         update:
         virtual:-noButtons-
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     io:
       prefIO     
       vccu       
       ioList:
         myHmUART
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     tmpl:
Attributes:
   IODev      myHmUART
   IOList     myHmUART
   alias      VCCU
   model      CCU-FHEM
   subType    virtual
   webCmd     virtual:update

dann kommt CMD pending..... und dann steht wieder CMD done was o.k. ist!
Gruss

[MadMax-FHEM]

Entweder halt beim Channel-Device...
...aber getConfig sollte bei den Haupt-Devices reichen...

Und dass das Attribut, genau wie in der Meldung steht, fehlt ist dir aufgefallen!?

Gruß, Joachim

[Kusselin]

du meinst das hier:

Code Auswählen Erweitern

IOgrp: CCU not found
    VCCU: ->meineVCCU
das Attribut war in der VCCU....habs mal raus. Jetzt kommt die Melsung nicht mehr im hminfo.
Ist das Attribut wichtig für meine Konfig?

Wie gesagt...getConfig kann ich nur am Haupt Device machen.....geht auch...aber nachdem das CMD...done steht und ich ein configcheck mache stehen die Meldungen immer noch drinne....

hier nochmal ein list vom Hauptdevice den garagenaktor:

Code Auswählen Erweitern

Internals:
   DEF        471C02
   FUUID      5f02bd52-f33f-fb9b-a4d7-d65985e6f005fd45
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     142
   NAME       Garage_Aktor
   NOTIFYDEV  global
   NR         75
   NTFY_ORDER 50-Garage_Aktor
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 Beleuchtung_Terrasse
   channel_02 Beleuchtung_Ostseite
   channel_03 Garage_Aktor_Sw_03
   channel_04 Garage_Aktor_Sw_04
   lastMsg    No:E8 - t:10 s:471C02 d:123123 030000
   myHmUART_MSGCNT 142
   myHmUART_RAWMSG 0501004FE8A010471C02123123030000
   myHmUART_RSSI -79
   myHmUART_TIME 2020-07-07 20:15:02
   protLastRcv 2020-07-07 20:15:02
   protRcv    142 last_at:2020-07-07 20:15:02
   protResnd  3 last_at:2020-07-07 20:14:46
   protSnd    194 last_at:2020-07-07 20:15:02
   protState  CMDs_done
   rssi_at_myHmUART cnt:142 min:-83 max:-75 avg:-78.47 lst:-79
   rssi_myHmUART cnt:13 min:-93 max:-87 avg:-87.84 lst:-87
   READINGS:
     2020-07-06 06:57:43   D-firmware      2.8
     2020-07-06 06:57:43   D-serialNr      NEQ0194570
     2020-07-07 20:14:31   PairedTo        0x123123
     2020-07-06 08:52:39   R-pairCentral   0x123123
     2020-07-07 20:14:31   RegL_00.         00:00 02:01 0A:12 0B:31 0C:23 15:FF 18:00
     2020-07-07 20:29:07   cfgState        ok
     2020-07-07 20:15:02   commState       CMDs_done
     2020-07-07 20:15:02   state           CMDs_done
   helper:
     HM_CMDNR   232
     cSnd       01123123471C02040439CD090703,01123123471C02040439CD090803
     mId        0003
     peerFriend
     peerOpt    -:switch
     regLst     0
     rxType     1
     supp_Pair_Rep 0
     cmds:
       TmplKey    :no:1594061752.55202
       TmplTs     1594061752.55202
       cmdKey     :0:1:0::0003:01
       TmplCmds:
       cmdList:
         assignHmKey:
         clear:[readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
         deviceRename:newName
         fwUpdate:-filename- -bootTime- ...
         getConfig:
         getDevInfo:
         getRegRaw:[List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
         getSerial:
         getVersion:
         pair:
         raw:data ...
         regBulk:-list-.-peer- -addr1:data1- -addr2:data2- ...
         regSet:[prep|exec] -regName- -value- ... [-peerChannel-]
         reset:
         tplDel:tmplt
         unpair:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +471C02,00,00,00
       nextSend   1594145703.05351
       rxt        0
       vccu       VCCU
       p:
         471C02
         00
         00
         00
       prefIO:
         myHmUART
     mRssi:
       mNo        E8
       io:
         myHmUART:
           -77
           -77
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       dev        1
       prs        1
     rpt:
       IO         myHmUART
       flg        A
       ts         1594145702.7578
       ack:
         HASH(0x457a9d8)
         E88002123123471C0200
     rssi:
       at_myHmUART:
         avg        -78.4718309859155
         cnt        142
         lst        -79
         max        -75
         min        -83
       myHmUART:
         avg        -87.8461538461539
         cnt        13
         lst        -87
         max        -87
         min        -93
     shadowReg:
     tmpl:
Attributes:
   IODev      myHmUART
   IOgrp      VCCU:myHmUART
   alias      Garage_Aktor
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   2.8
   model      HM-LC-SW4-DR
   modelForce HM-LC-SW4-DR
   room       CUL_HM
   serialNr   NEQ0194570
   subType    switch
   webCmd     getConfig:clear msgEvents

und ein list von einem Channel dazu:

Code Auswählen Erweitern

Internals:
   DEF        471C0203
   FUUID      5f02bd52-f33f-fb9b-6881-006bffe2f36978d1
   NAME       Garage_Aktor_Sw_03
   NOTIFYDEV  global
   NR         78
   NTFY_ORDER 50-Garage_Aktor_Sw_03
   STATE      off
   TYPE       CUL_HM
   chanNo     03
   device     Garage_Aktor
   peerList   HM_Fernbedienung_Btn_05,HM_Fernbedienung_Btn_06,
   READINGS:
     2020-07-06 16:45:30   CommandAccepted yes
     2020-07-06 16:49:56   R-HM_Fernbedienung_Btn_05-lgActionType jmpToTarget
     2020-07-06 16:49:56   R-HM_Fernbedienung_Btn_05-shActionType jmpToTarget
     2020-07-06 16:49:58   R-HM_Fernbedienung_Btn_06-lgActionType jmpToTarget
     2020-07-06 16:49:58   R-HM_Fernbedienung_Btn_06-shActionType jmpToTarget
     2020-07-06 08:53:04   R-powerUpAction off
     2020-07-06 08:53:04   R-sign          off
     2020-07-07 20:14:41   RegL_01.         00:00 08:00 30:06 56:00 57:24
     2020-07-07 20:14:59   RegL_03.HM_Fernbedienung_Btn_05  00:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:64 0C:66 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:64 8C:66
     2020-07-07 20:15:00   RegL_03.HM_Fernbedienung_Btn_06  00:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:13 0C:33 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:13 8C:33
     2020-07-07 20:29:07   cfgState        PeerVerf
     2020-07-07 20:07:35   deviceMsg       off (to VCCU)
     2020-07-07 20:07:35   level           0
     2020-07-07 20:07:35   pct             0
     2020-07-07 20:14:42   peerList        HM_Fernbedienung_Btn_05,HM_Fernbedienung_Btn_06,
     2020-07-07 20:07:35   recentStateType info
     2020-07-07 20:07:35   state           off
     2020-07-07 20:07:35   timedOn         off
     2020-07-06 09:12:39   trigLast        fhem:02
   helper:
     peerFriend peerSens,peerVirt
     peerIDsRaw ,39CD0906,39CD0905,00000000
     peerOpt    3:switch
     regLst     1,3p
     cfgChk:
       idPz02     p:HM_Fernbedienung_Btn_05
p:HM_Fernbedienung_Btn_06
     cmds:
       TmplKey    HM_Fernbedienung_Btn_05,HM_Fernbedienung_Btn_06,:no:1594061752.59743
       TmplTs     1594061752.59743
       cmdKey     :1:0:0::0003:03HM_Fernbedienung_Btn_05,HM_Fernbedienung_Btn_06,
       TmplCmds:
         tplSet_HM_Fernbedienung_Btn_06:[SwCondAbove_long|SwCondAbove_short|SwCondBelow_long|SwCondBelow_short|SwOff_long|SwOff_short|SwOnCond_long|SwOnCond_short|SwOn_long|SwOn_short|SwToggle_long|SwToggle_short|autoOff_long|autoOff_short|motionOnSw_long|motionOnSw_short]
         tplSet_HM_Fernbedienung_Btn_05:[SwCondAbove_long|SwCondAbove_short|SwCondBelow_long|SwCondBelow_short|SwOff_long|SwOff_short|SwOnCond_long|SwOnCond_short|SwOn_long|SwOn_short|SwToggle_long|SwToggle_short|autoOff_long|autoOff_short|motionOnSw_long|motionOnSw_short]
       cmdList:
         clear:[readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
         eventL:-peer- -cond-
         eventS:-peer- -cond-
         getConfig:
         getRegRaw:[List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
         inhibit:[on|off]
         off:
         on-for-timer:-ontime-
         on-till:-time-
         on:
         peerBulk:-peer1,peer2,...- [set|unset]
         peerIODev:[IO] -btn- [set|unset]... not for future use
         peerSmart:[remove_HM_Fernbedienung_Btn_05|remove_HM_Fernbedienung_Btn_06|Dachfenster_Flur|HM_Fernbedienung_Btn_01|HM_Fernbedienung_Btn_02|HM_Fernbedienung_Btn_03|HM_Fernbedienung_Btn_04|HM_Fernbedienung_Btn_07|HM_Fernbedienung_Btn_08|Terrasse_Wz|VCCU]
         press:[long|short] -peer- [-repCount(long only)-] [-repDelay-] ...
         regBulk:-list-.-peer- -addr1:data1- -addr2:data2- ...
         regSet:[prep|exec] -regName- -value- ... [-peerChannel-]
         sign:[on|off]
         statusRequest:
         toggle:
         tplDel:tmplt
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     regCollect:
     role:
       chn        1
     shadowReg:
     tmpl:
Attributes:
   alias      Beleuchtung_Suedseite
   group      Licht
   icon       li_wht_on
   model      HM-LC-SW4-DR
   peerIDs    00000000,39CD0905,39CD0906,
   room       alexa
   webCmd     statusRequest:toggle:on:off

Was meinst du mit "Entweder halt beim Channel Device"?? Da geht doch kein getConfig oder? Ich habe nichts gefunden

Gruss

[MadMax-FHEM]

das Attribut war in der VCCU....habs mal raus. Jetzt kommt die Melsung nicht mehr im hminfo.
Ist das Attribut wichtig für meine Konfig?

Verstehe ich nicht!?

Ist es JETZT draußen oder DA das Attribut!?

Haben list und Meldung zusammengepasst, also war das list der vccu OHNE VERÄNDERUNG nach dem hminfo configCheck!?

Warum lässt du eigentlich (immer) andere für dich kucken!?
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Einrichten

Gut warum sind wir auch immer "bereit" für dich zu kucken!?

Ob es wichtig ist!?
Schon mal im Forum gesucht!?

Es gibt mind. einen Thread dazu...

ABER: wenn es so im Wiki steht -> warum dann immer anders machen und ändern nur weil, ja warum eigentlich!?

Gruß, Joachim

[Kusselin]

das attribut war falsch drin gestanden..
meine VCCU heisst 2VCCU" und nicht meineVCCU"
es passt jetzt

Code Auswählen Erweitern

nternals:
   DEF        123123
   FUUID      5f02d92e-f33f-fb9b-1ed4-518c1363cd71cb79
   IODev      myHmUART
   NAME       VCCU
   NOTIFYDEV  global
   NR         82
   NTFY_ORDER 50-VCCU
   STATE      myHmUART:ok
   TYPE       CUL_HM
   assignedIOs myHmUART
   chanNo     01
   READINGS:
     2020-07-07 20:01:23   IOopen          1
     2020-07-07 20:49:25   cfgState        ok
     2020-07-07 20:01:23   state           myHmUART:ok
     2020-07-06 17:43:46   unknown_2D8997  received
     2020-07-06 17:41:46   unknown_31041E  received
     2020-07-06 17:45:05   unknown_31076B  received
     2020-07-06 16:33:50   unknown_39CD09  received
     2020-07-06 17:43:43   unknown_515175  received
     2020-07-06 16:03:54   unknown_56CBBF  received
     2020-07-06 16:11:25   unknown_56CBE6  received
   helper:
     HM_CMDNR   150
     mId        FFF0
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     ack:
     cmds:
       TmplKey    :no:1594061753.02493
       TmplTs     1594061753.02493
       cmdKey     :1:1:1::FFF0:01
       TmplCmds:
       cmdList:
         assignHmKey:
         assignIO:-IO- [set|unset]...
         clear:[readings|rssi|msgErrors|msgErrors|unknownDev]
         defIgnUnknown:
         deviceRename:newName
         fwUpdate:-filename- -bootTime- ...
         getDevInfo:
         hmPairForSec:-sec- ...
         hmPairSerial:-serial-
         peerChan:-btnNumber- -actChn- ... [single|dual|reverse] [set|unset] [actor|remote|both]
         peerSmart:[Beleuchtung_Terrasse|Dachfenster_Flur|Garage_Aktor_Sw_02|Garage_Aktor_Sw_03|Garage_Aktor_Sw_04|HM_Fernbedienung_Btn_01|HM_Fernbedienung_Btn_02|HM_Fernbedienung_Btn_03|HM_Fernbedienung_Btn_04|HM_Fernbedienung_Btn_05|HM_Fernbedienung_Btn_06|HM_Fernbedienung_Btn_07|HM_Fernbedienung_Btn_08|HZK_EG_Essen_WindowRec|HZK_EG_Essen_remote|HZK_EG_Wohnen_WindowRec|HZK_EG_Wohnen_remote|Temp_Feuchte_Wohnen_EG_WindowRec|Temp_Feuchte_Wohnen_EG_remote|Temp_Feuchte_Wohnen_OG_WindowRec|Temp_Feuchte_Wohnen_OG_remote|Terrasse_Wz]
         postEvent:-condition-
         press:[long|short] [noBurst] [-repCount(long only)-] [-repDelay-] ...
         raw:data ...
         reset:
         unpair:
         update:
         virtual:-noButtons-
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     io:
       prefIO     
       vccu       VCCU
       ioList:
         myHmUART
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     tmpl:
Attributes:
   IODev      myHmUART
   IOList     myHmUART
   IOgrp      VCCU
   alias      VCCU
   model      CCU-FHEM
   subType    virtual
   webCmd     virtual:update

[MadMax-FHEM]

Was meinst du mit "Entweder halt beim Channel Device"?? Da geht doch kein getConfig oder? Ich habe nichts gefunden

Also ich kann bei meinen Channels ein getConfig auslösen...

Aber ohne passendes list OHNE VERÄNDERUNG und ein GENAU DAZU PASSENDES configCheck...
...wie soll ich/sollen wir da was zusammenfinden?

Das Kommando heißt: set DeviceName getConfig / also es ist ein set-Befehl, sollte das der Grund für das Nichtfinden sein...

Gruß, Joachim

[MadMax-FHEM]

List VCCU

Code Auswählen Erweitern

Internals:
   DEF        123123
   FUUID      5f02d92e-f33f-fb9b-1ed4-518c1363cd71cb79
   IODev      myHmUART
   NAME       VCCU
   NOTIFYDEV  global
   NR         82
   NTFY_ORDER 50-VCCU
   STATE      myHmUART:ok
   TYPE       CUL_HM
   assignedIOs myHmUART
   chanNo     01
   READINGS:
     2020-07-07 20:01:23   IOopen          1
     2020-07-07 20:02:01   cfgState        ok
     2020-07-07 20:01:23   state           myHmUART:ok
     2020-07-06 17:43:46   unknown_2D8997  received
     2020-07-06 17:41:46   unknown_31041E  received
     2020-07-06 17:45:05   unknown_31076B  received
     2020-07-06 16:33:50   unknown_39CD09  received
     2020-07-06 17:43:43   unknown_515175  received
     2020-07-06 16:03:54   unknown_56CBBF  received
     2020-07-06 16:11:25   unknown_56CBE6  received
   helper:
     HM_CMDNR   150
     mId        FFF0
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     ack:
     cmds:
       TmplKey    :no:1594061753.02493
       TmplTs     1594061753.02493
       cmdKey     :1:1:1::FFF0:01
       TmplCmds:
       cmdList:
         assignHmKey:
         assignIO:-IO- [set|unset]...
         clear:[readings|rssi|msgErrors|msgErrors|unknownDev]
         defIgnUnknown:
         deviceRename:newName
         fwUpdate:-filename- -bootTime- ...
         getDevInfo:
         hmPairForSec:-sec- ...
         hmPairSerial:-serial-
         peerChan:-btnNumber- -actChn- ... [single|dual|reverse] [set|unset] [actor|remote|both]
         peerSmart:[Beleuchtung_Terrasse|Dachfenster_Flur|Garage_Aktor_Sw_02|Garage_Aktor_Sw_03|Garage_Aktor_Sw_04|HM_Fernbedienung_Btn_01|HM_Fernbedienung_Btn_02|HM_Fernbedienung_Btn_03|HM_Fernbedienung_Btn_04|HM_Fernbedienung_Btn_05|HM_Fernbedienung_Btn_06|HM_Fernbedienung_Btn_07|HM_Fernbedienung_Btn_08|HZK_EG_Essen_WindowRec|HZK_EG_Essen_remote|HZK_EG_Wohnen_WindowRec|HZK_EG_Wohnen_remote|Temp_Feuchte_Wohnen_EG_WindowRec|Temp_Feuchte_Wohnen_EG_remote|Temp_Feuchte_Wohnen_OG_WindowRec|Temp_Feuchte_Wohnen_OG_remote|Terrasse_Wz]
         postEvent:-condition-
         press:[long|short] [noBurst] [-repCount(long only)-] [-repDelay-] ...
         raw:data ...
         reset:
         unpair:
         update:
         virtual:-noButtons-
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     io:
       prefIO     
       vccu       
       ioList:
         myHmUART
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     tmpl:
Attributes:
   IODev      myHmUART
   IOList     myHmUART
   alias      VCCU
   model      CCU-FHEM
   subType    virtual
   webCmd     virtual:update

In dem zuerst geposteten list der vccu war das Attribut GAR NICHT drin...

Drum ja immer: es muss schon zusammenpassen, also das was du postest!!

Es bringt nichts, wenn du ein configCheck machst und postest und dann am list bzw. am Devive änderst und dann das list postest...

Gruß, Joachim

[MadMax-FHEM]

Hier noch ein (etwas älterer Link) mit Erläuterungen was was ist (stimmt bestimmt noch [so in etwa]):

https://forum.fhem.de/index.php/topic,26577.msg195542.html#msg195542

Gruß, Joachim

[Kusselin]

Hallo joachim...das hat der Martin super erklärt in diesem Thread.....aber wie bekommt mans weg???

Habe jetzt nochmal ein getConfig bei dem HauptDevice dem HM Aktor gemacht.......nach cmd pendings.....cmd done o.k.

was mache ich bei den Channels? status request...ich weiss es leider nicht ....

[MadMax-FHEM]

Mehr als dass ich bei den Channels ein getConfig auslösen kann, kann ich nicht sagen/schreiben...
...ich habe allerdings auch den von dir verwendeten Aktor nicht.
Aber andere Schaltaktoren, da geht das...

Und ohne AKTUELLE und STIMMIGE lists inkl. der AKTUELLEN Ausgabe von configCheck:wie sollen wir helfen!?

In dem Thread geht's doch (auch) drum: wie macht man configCheck sauber!!?

Wenn nicht: es gibt auch viele weitere Threads zu dem Thema...

Und wenn das nicht hilft: neuen eigenen Thread aufmachen im PASSENDEN Unterforum. Genau erläutern was du gemacht hast (evtl. Link zu hier) und (genau wie für uns hier wichtig): eben AKTUELLE Ausgabe von configCheck und AKTUELLE dazu PASSENDE (UNVERÄNDERTE) lists von den genannten Devices/Channels...

Gruß, Joachim

[Kusselin]

beim configcheck so wie bei mir jetzt mit dem HM garagenAktor 4 channel (ist jetzt nur ein Auszug):

Code Auswählen Erweitern

peer not verified. Check that peer is set on both sides
    Beleuchtung_Ostseite: p:HM_Fernbedienung_Btn_03
    Beleuchtung_Ostseite: p:HM_Fernbedienung_Btn_04
    Beleuchtung_Suedseite: p:HM_Fernbedienung_Btn_05
    Beleuchtung_Suedseite: p:HM_Fernbedienung_Btn_06
    Beleuchtung_Terrasse: p:HM_Fernbedienung_Btn_01
    Beleuchtung_Terrasse: p:HM_Fernbedienung_Btn_02
    Beleuchtung_Westseite: p:HM_Fernbedienung_Btn_07
    Beleuchtung_Westseite: p:HM_Fernbedienung_Btn_08

ist da der peer dann zwischen Ostseite und der Fernbedienung Taste 03 und 04 nicht o.k. und Suedseite mit Taste 5 und 6 usw.... hab ich das richtig verstanden?

is spät......ich gehe jetzt schlafen und träum hoffenmtlich nicht von Fhem!!

Gruss und danke

[MadMax-FHEM]

Naja steht doch da:

peer not verified. Check that peer is set on both sides
es konnte nicht geprüft werden, dass der peer auf beiden seiten (sensor nach Aktor UND aktor nach Sensor) eingetragen ist.

Entweder passt tatsächlich nicht ODER konnte nicht verifiziert werden (weil evtl. nicht gelesen -> getConfig)...
...wenn auch nach den entspr. getConfig diese Meldungen noch da sind: dann die Peerings erneuern...

Gruß, Joachim

[Kusselin]

o.k....wobei ich die FB ja eigentlich gar nicht in Fhem benutze.....wichtig ist das der Aktor also das Hauptdevice mit Fhem arbeitet......

bzgl. der fernbedienung schaue ich aber mal...muss man hinten aufmachen und mit Büroklammer den Knopf betätigen.....dann setzt FB orange ab....

Gruss

[MadMax-FHEM]

Wenn du sie nicht benutzt: Meldungen ignorieren...
...oder eben Peerings "nachziehen"...
...oder: löschen.

Es heißt ja auch nicht, dass configCheck sauber sein MUSS!
Es weist halt nur auf "Mängel" hin...
...wenn dir klar ist was der Grund ist, es dich nicht "stört" weil z.B. nicht verwendet -> ignorieren...

Ich hatte auch mal einen von den "bunten Display Schaltern"...
Aber nachdem das dann doch nicht ging wie gedacht: Batterien raus und liegt in der Ecke. Klar "mosert" da dann configCheck.
Aber ich weiß ja WARUM
Könnte ich ändern indem ich den Schalter nicht nur nicht mehr verwende sondern auch lösche...
...oder Batterien wieder rein und gut

Gruß, Joachim

[martinp876]

Ich habe zur Grundsatzdiskussion einmal einen neuen Threat aufgemacht. Die Diskussion halte ich für wichtig, aber separat.

In diesem Threat:
Was ist ein use-case, Kusselin? Kannst du das einmal abstrakt artikulieren? Das hilft typisch dem Support und auch dir selbst.
Ich will nicht versuchen, es aus dem (langen) Thread zu destilieren.

[Kusselin]

Was ist ein use-case, Kusselin? Kannst du das einmal abstrakt artikulieren? Das hilft typisch dem Support und auch dir selbst.
Ich will nicht versuchen, es aus dem (langen) Thread zu destilieren.

Use Cases dokumentieren die Funktionalität eines geplanten oder existierenden Systems auf Basis von einfachen Modellen. In einem Use Case – auch Anwendungsfall genannt – wird das nach außen sichtbare Verhalten eines Systems aus Sicht der Nutzer beschrieben.

[frank]

martin möchte deinen anwendungsfall in erfahrung bringen. 

[Kusselin]

ich soll meinen Fall hier in kurzen prägnaten Zeilen wiedergeben?

[martinp876]

Deine Beschreibung eines use case ( Anwendungsfalls) kann ich nicht ganz unterschrieben. Es muss nicht das ganze system beschrieben werden sondern ein Anwendungsfall. Wichtig ist, wie du beschreibst, die Anwender Sicht. Was hat der Anwender vor, was hat er vorliegen, was will er erreichen?
Du nutzt raw def um was zu erreichen?
Ausgangsdaten hast du woher? Anderer user/alte Installation/sicherung/ausgedavht?
Du spielst es in ein live system/test system/ alternativ System?
Die systeme sind identisch(sicher nicht)/semi-identisch/total verschieden?
Der aktor soll danach voll funktionieren/ansprechbar sein/nur einen modeltyp simulieren/ sonstiges?
Dich interessieren die Möglichkeiten eines bei dir nicht vorhandenen aktors, also eine Simulation?