Neue Geräte für CUL_HM anlegen ohne Anlernen

[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