ActionDetector

[Zrrronggg!]

Ich habe leider mal eine Weile nicht aufgepasst und jetzt nach ca 15 Monaten wieder eine hM Gerät gepairt und jetzt gibts einen "ActionDetector".

Der Wikieintrag http://www.fhemwiki.de/wiki/HomeMatic#Action_Detector lässt mich ein wenig ratlos zurück.

Was ich verstehe ist: Es gibt zu HM Devices eine attr das in etwa so aussieht:

Code Auswählen Erweitern

attr Shutter actCycle 028:00

Das definiert den Zeitraum, in dem sich das Device gemeldet haben muss, sonst wirds als dead gelistet.

Aber muss der ActionDetector nicht noch irgendwie definiert werden?

Und wie kriege ich z.b. ein Listing am Webfronend hin, in dem ich sehen kann, welche Geräte alle als Dead marktiert sind?

(Ich habe mir z.B. mit define battStatus readingsGroup .*:[Bb]attery  eine Anzeige gebastelt welche Battereien alle schwach sind.... so ähnlich)

Letzte Frage: Sind die von Autocreate angelegten Werte realistisch? Autocreate legt für HM-SEC-SC 028:00 an, ich meine mich zu erinnern, das der sich nur alle 24 Stunden meldet. Oder wie ist das Format
von actCycle HHH:MM?

[marvin78]

Der ActionDetector ist ja offenbar schon definiert sonst wäre dir das Beschriebene ja nicht aufgefallen.

Der actCycle ist schon gut gewählt, für den Fall, dass sich das Gerät nicht pünktlich meldet (aus welchem Grund auch immer). Es ist bei jedem Device etwas mehr, als der Melderythmus.

Eine regex für eine ReadingsGroup der "Activitiy" sieht bspw. so aus:

Code Auswählen Erweitern

.*:Activity

Und dann

Code Auswählen Erweitern

attr READINGSGROUPNAME valueFormat {$VALUE !~ m/alive/?$VALUE:undef;}

[Zrrronggg!]

Der ActionDetector ist ja offenbar schon definiert sonst wäre dir das Beschriebene ja nicht aufgefallen.

Ich habe das nur bemerkt, weil Autocreate jetzt das zusätzliche Attribut
attr  actCycle
anlegt.

Mehr habe ich nicht bemerkt. Und nach lesen in Wiki und Commandref habe ich nur verstanden wie das von der Idee her Funktioniert, aber das war's auch schon.

Und so richtig viel weiter bin ich jetzt immer noch nicht, leider.

Irgenwo wird man den ActionDetector doch definieren müssen, z.b. entnehme ich der Commandref das man den cycle einstellen kann.

Der actCycle ist schon gut gewählt, für den Fall, dass sich das Gerät nicht pünktlich meldet (aus welchem Grund auch immer). Es ist bei jedem Device etwas mehr, als der Melderythmus.

Also ist das Zeitformat hhh:mm und der Wert aus Autocreate ist nicht generisch sondern ans aktuelle Gerät angepasst.

[martinp876]

der ActionDetector wird automatisch erstellt, sollte er noch nicht existieren.
Im ActionDetector kann man eine zusammenfassung aller angemeldeten Devices sehen.

Durch das setzen des Attributs im HM device wird der ActionDetector definiert - wenn man ein sav macht steht er auch im fhem.cfg.

das Attribut ActCycle wird automatisch angelegt für Devices, die sich nach Anleitung automatisch melden (meist Batterie-devices). Andere kann der User manuell aufnehmen - muss aber selbst sicherstellen, dass das Device auch im Zeitraum etwas sendet.

[Zrrronggg!]

Okay.


Hier mal zu meinen Vorgehen:
- wenn ich ein HM Device paire benutze ich Autocreate.
- da Autocreate mit regelmaessig meine komplette  fhem.cfg zerschiesst, verwende ich dafür immer eine leere fhem.cfg, in der steht nix ausser die Schnittstellendefinition und webinterface
-mit der restarte ich FHEM,dann gebe ich gehe ich für 30 Sekunden in den paringmodus, lerne das Device an
- jetzt steht in der vormals leere fhem.cfg das Autocreate Ergebnis des Pairings
- das kopiere ich jetzt in meine richtige fhem.cfg, mit der Reboote ich dann FHEM.

Wann wird da jetzt  ActionDetector erzeugt und wo müsste ich den sehen wenn ich wann sav mache?

Ich meine: Wie müsste der Eintrag in der fhem.cfg aussehen? Ich finde nix.

[martinp876]

Wann wird da jetzt  ActionDetector erzeugt

wenn du ihn definierst oder wenn du das Attribut actCycle setzt und der ActionDetectro noch nicht exitiert

und wo müsste ich den sehen wenn ich wann sav mache?

eigentlich immer wieder... du solltest dein Konzept ändern - dann kannst du immer save machen:
im fhem.cfg habe ich im wesentlichen includes stehen
include setup/cfg_Heating.cfg
...
das bringt erst einmal ordnung. In den include files habe ich dann nur kommentare, define und attribute stehen. Das beherrscht save sehr gut. Alles andere wird bei save gelöscht! Ich denke das ist dein Problem.
Daher habe ich ein weiteres config-file, das ich per notify starte. Ich definiere ein notify "userCfg", das nach dem init gestartet wird. Im File fhemUser.cfg (mein Name) stehen dann Anweisungen - also alle kommandos und alles, was nach "init" ausgeführt werden soll

define userCfg notify global:INITIALIZED include setup/fhemUser.cfg
attr userCfg group util
attr userCfg room CUL_HM,util,notify

somit kann ich immer save machen - und das halte ich für wichtig.

Wie müsste der Eintrag in der fhem.cfg aussehen?

define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 30
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector

[Zrrronggg!]

... du solltest dein Konzept ändern - dann kannst du immer save machen:

Ich bin nicht sicher, ob ich das will. Ich bin ein grosser Freund manueller Einträge. Ich bearbeite meine fhem.cfg immer offline manuell und kopiere dann das Ergebnis komplett rein (dann mit save). autocreate benutze ich nur da, wo es kaum anders geht, wie HM pairing z.B.

Ich habe so die totale Kontrolle UND ich verstehe auch was in der fhem.cfg steht UND die ist immer so formatiert wie ich es will.

Ich gehe sogar noch weiter: Prozesse die so ausgelegt sind, dass sie NUR mit automatischen Einträgen und "mitten im Betrieb saven" funktionieren halte ich für suboptimal.
Ich würde mir daher ausdrücklich wünschen, das zumindest beides geht und alle Erfordernisse auch dokumentiert sind.

im fhem.cfg habe ich im wesentlichen includes stehen
include setup/cfg_Heating.cfg
...
das bringt erst einmal ordnung. In den include files habe ich dann nur kommentare, define und attribute stehen. Das beherrscht save sehr gut.

Ich verstehe das und habe auch gelegentlich überlegt das zu tun, aber bisher sehe ich das als umständlicher an, weil dann mehrere Dateien gepflegt werden müssen und man Abhängigkeiten von Code hat, den man ggf gerade "nicht sehen" kann.   Nun, ist sicherlich einen Geschmacksfrage  und ab einer bestimmten Grösse geht's vermutlich nicht mehr anders.

Alles andere wird bei save gelöscht! Ich denke das ist dein Problem.

Klar. Darüber hinaus wurde bei mir aber z.T auch Kommentare entfernt und die Reihenfolge der Einträge wild geändert.

Wenn man so wie ich an die 50 Geräte verschiedenster Systeme hat die was senden, ist speziell autocreate sowieso ein Monster, das man nicht unkontrolliert loslassen will... meiner Auffassung nach.

Beispiel: Noch bis vor kurzem hat das Autocreate von FHT als attr retrycount 3 per default angelegt. Der Eintrag ist in den meisten Umgebungen sinnlos und in denen in der überhaupt was bewirkt oft eher konraproduktiv (Rudolf hat das dankenswerterweise kürzlich geändert). Daher habe ich die immer schön entfernt. Autocreate und save im Betrieb hat's dann immer wieder ergänzt.
Wie schön.
Autocreate bei HM packte alle Geräte immer in den Raum "HM", und zwar zum Teil auch dann, wenn das Gerät schon exisitiert und einen attr room hat. etc. etc.


Also kurzum: Ich will nicht einfach Änderungen die FHEM an der fhem-cfg macht sichern.

Daher habe ich ein weiteres config-file, das ich per notify starte. Ich definiere ein notify "userCfg", das nach dem init gestartet wird. Im File fhemUser.cfg (mein Name) stehen dann Anweisungen - also alle kommandos und alles, was nach "init" ausgeführt werden soll

Hm. Ist ne Idee. Ich würde trotzdem gerne manuell schreiben, auch wenn ich das so mache.
Die Idee ist aber nett, da komm ich direkt ins Grübeln.

somit kann ich immer save machen - und das halte ich für wichtig.

Warum?
Warum FHEM selber in der Config rumfuchteln bzw diese verändern lassen? Ich habe damit wie oben beschreiben eher keine guten Erfahrunge gemacht.
Dazu kommt noch, das ich manuell sogar schneller bin.

Ich gehe jede Wette ein, dass ich z.b. ein dutzend FHTs deutlcich schneller anlege, als jemand der autocreate und safe der Ergebnisse verwendet. (gut bei HM sieht das anders aus)

Fazit: Ich hätte da eine andere Meinung.
Wenn im konkreten Fall in der Doku (z.b. commandref) schlicht drinstehen würde, was man für den ActionDetector tatsächlich alles braucht, bzw. aus was für Komponenten der besteht, hätte ich das gelesen und einfach per Hand konfiguriert... fertich.

Anstelle dessen steht in der Doku nur die Hälfte, weil "der Rest legt sich ja von alleine an".
Ich erkenne an, dass das eine philosphische Frage ist, wie man das macht,  und es für viele Nuzer so besser sein mag, weil sie weniger nachdenken müssen bzw weniger Fehler machen können. Ich meine eben nur, dass vollständige Doku beides ermöglichen würde. Ich habe ja nix dagegen, dass define ActionDetector ggf automatisch erzeugt wird, aber es würde ja nicht weh tun zu sagen wie das aussehen MÜSSTE, damit Leute wie ich das auch per Hand anlegen könnten und als Nebeneffekt auch verstehen wie's geht.

Immerhin ist auch bei anderen Devices die commandref so aufgebaut. Auch wie man ein FHT anlegt wird dort ausführlich dargelegt, obwohl man es mit Autocreate komplett erzeugen lassen kann.

define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 30
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector

Genau. Steht das irgendwo? Ich meine in der Commandref das nicht gesehen zu haben, im Wiki auch nicht. Kann aber auch sein, dass ich einfach nur blind bin. 

Ich bin bereit, da einen Wikiartikel draus zu machen, sobald ich das mal getestet und voll kapiert habe.

[martinp876]

autocreate benutze ich nur da, wo es kaum anders geht, wie HM pairing z.B.

legen den ActionDetector einmal an - fertig. dann kommt es nie wieder. Am besten sehr früh im Config - da es sonst automatisch angelegt werden muss.

Ich habe so die totale Kontrolle UND ich verstehe auch was in der fhem.cfg steht UND die ist immer so formatiert wie ich es will.

klar - wer will das nicht. wenn du das Config nach standart anlegst (nur define, attr und komment) ändert sich die Formatierung nicht. Alles andere ist eigentlich nicht zulässig (zwar nicht verboten, aber unsicher bis gefährlich). Immerhin löst du kommandos VOR dem Ende des INIT aus. Ich kann das keinesfalls empfehlen. 
Alles andere gehört in ein separates File - das wird vom save auch NIE angefasst.
Hältst du dich daran ist alles ganz einfach.

Ich gehe sogar noch weiter: Prozesse die so ausgelegt sind, dass sie NUR mit automatischen Einträgen und "mitten im Betrieb saven" funktionieren halte ich für suboptimal.
Ich würde mir daher ausdrücklich wünschen, das zumindest beides geht und alle Erfordernisse auch dokumentiert sind.

hm - wenn du ein Device anlegst - musst du saven. Wenn das Attribut actCycle angelegt wird - musst du save. Wenn du nach dem Anlegen des Attributes actCycle speicherst ist der ActionDetector dabei. Wo also liegt das Problem? Ohne Speichern geht es nicht, da FHEM die Attribute nicht automatisch sichert.
Die gehen nach jedem peeren die peers verloren, so du nicht speicherst. hm - kann ich nichts machen. Vielleicht brauchst du sie nicht?

sehe ich das als umständlicher an, weil dann mehrere Dateien gepflegt werden müssen

Ansichtssache. Ich halte es für einfacher, meine Aktoren in Files zu gruppieren, als ein riesen File zu bearbeiten. Da kann ich schon am Filedatum sehen, in welchem Bereich sich etwas geändert hat.
Man braucht aber nur 2 Files, eins für Config und eins für den Rest.

und man Abhängigkeiten von Code hat, den man ggf gerade "nicht sehen" kann.

welchen Code? Das fhem.cfg ist definitiv der falsche Ort für Code. Wer das macht ist selbst schuld (darf er natürlich, mitleid habe ich keins - sorry)

Nun, ist sicherlich einen Geschmacksfrage und ab einer bestimmten Grösse geht's vermutlich nicht mehr anders.

Sicher Geschmackssache. Es ist auch mit handfesten Unterschieden behaftet. Mit denen musst du Leben - oder bei Rudi ein Anderes Model beantragen. Ist leine CUL_HM Angelegenheit...

Darüber hinaus wurde bei mir aber z.T auch Kommentare entfernt

Rudi befragen

und die Reihenfolge der Einträge wild geändert.

streng nach Alphabet, nicht wild.

Wenn man so wie ich an die 50 Geräte verschiedenster Systeme hat die was senden, ist speziell autocreate sowieso ein Monster, das man nicht unkontrolliert loslassen will... meiner Auffassung nach.

Ich will nicht einfach Änderungen die FHEM an der fhem-cfg macht sichern.

AutoCeate ist m.E. kein Problem. Schalte aber autoSave aus, dann wird nicht gespeichert.

Hm. Ist ne Idee. Ich würde trotzdem gerne manuell schreiben, auch wenn ich das so mache.
Die Idee ist aber nett, da komm ich direkt ins Grübeln.

mit oder ohne autosave - ich empfehle strikt, code aus dem/den "normalen" Config(s) zu entfernen. Ich kenne sicher nicht alles in FHEM - aktuell kenne ich keinen Grund, schon während init code auszuführen.

Warum FHEM selber in der Config rumfuchteln bzw diese verändern lassen? Ich habe damit wie oben beschreiben eher keine guten Erfahrunge gemacht.

wenn du dich an die Konventionen hältst darf es nicht passieren (ausser ein Sort der Attribute vielleicht). Alles andere muss behoben werden (aber nicht in CUL_HM)

Wenn im konkreten Fall in der Doku (z.b. commandref) schlicht drinstehen würde, was man für den ActionDetector tatsächlich alles braucht, bzw. aus was für Komponenten der besteht, hätte ich das gelesen und einfach per Hand konfiguriert... fertich.

hm - ich habe keine einzige Komponente im Commandref beschrieben. Wie bist du also bisher mit den Anderen zurecht gekommen?
Wenn der ActionDetector angelegt ist kannst du alles sehen, was er braucht.

Anstelle dessen steht in der Doku nur die Hälfte, weil "der Rest legt sich ja von alleine an".

wie bei allen Anderen Komponenten auch?

Ich meine eben nur, dass vollständige Doku beides ermöglichen würde.

du willst also einen Wiki-Artikel schreiben? Prima

Ich habe ja nix dagegen, dass define ActionDetector ggf automatisch erzeugt wird, aber es würde ja nicht weh tun zu sagen wie das aussehen MÜSSTE, damit Leute wie ich das auch per Hand anlegen könnten und als Nebeneffekt auch verstehen wie's geht.

Ich verstehe dein Problem nicht. Steht doch schon lange in deinen fhem.cfg - und du löschst es sicher immer wieder

Code Auswählen Erweitern

define ActionDetector CUL_HM 000000
attr ActionDetector model ActionDetector

Ich bin bereit, da einen Wikiartikel draus zu machen, sobald ich das mal getestet und voll kapiert habe.

prima. Da das ganze recht einfach ist (min 2 Zeilen) - wo ist das Problem?
Das ganzegehört sowieso nicht ins kommandref, sondern ins wiki.

[Zrrronggg!]

Danke für deine ausführliche Antwort.
Ich glaube wir reden an 2-3 Stellen aneinander vorbei, vielleicht auch weil ich mich ungenau ausgedrückt habe.

legen den ActionDetector einmal an - fertig. dann kommt es nie wieder. Am besten sehr früh im Config - da es sonst automatisch angelegt werden muss.

Gerne, dazu muss ich nur wissen wie's geht. JETZT weiss ich es dank deinem Post.

klar - wer will das nicht. wenn du das Config nach standard anlegst (nur define, attr und komment) ändert sich die Formatierung nicht. Alles andere ist eigentlich nicht zulässig (zwar nicht verboten, aber unsicher bis gefährlich). Immerhin löst du kommandos VOR dem Ende des INIT aus. Ich kann das keinesfalls empfehlen. 

Das mache ich defintiv nicht. Das ist schon alles richtig sortiert.

Alles andere gehört in ein separates File - das wird vom save auch NIE angefasst.
Hältst du dich daran ist alles ganz einfach.

Das ist meines Wissens weder zwingend noch in irgendeiner Doku so dargestellt.
Selbst eine Standardinstallation von FHEM out of the box hat nur ein File.
Es wird also Leute geben, die nur ein fhem.cfg haben in dem mehr oder weniger alles steht.
Viele.

hm - wenn du ein Device anlegst - musst du saven. Wenn das Attribut actCycle angelegt wird - musst du save.

Wie gesagt: ich editiere offline mein fhem.cfg  (genau genommen einfach eine Textdatei, nennen wir die mal MASTER) die kopiere ich KOMPLETT und paste die mittels Webeditor in meine echte fhem.cfg und dann save ich die.

Dieses Vorgehen mag dir fremd sein, oder sogar sachlich suboptimal, ich weiss aber definitv, dass das einige so machen.

Wenn du nach dem Anlegen des Attributes actCycle speicherst ist der ActionDetector dabei.Wo also liegt das Problem?

Das Problem ist, dass ich die durch autocreate angelegten defines aus meiner speziellen autocreate Datei fische, diese in meine "Master"  paste, dann noch umbenne wie ich es will, die richtigen attrs wie rooms und so dazu mache. Eventuell schon ein paar notifies anlege... Dann nehme ich die ganze angepasste config, paste sie per Webinterface in meine fhem.cfg -> safe.

Das ging bisher immer problemlos und ich weiss wie gesagt, dass das Einige so oder so ähnlich machen.

Nur dann ist natürlich das Define des ActionDetectors (weil nach Autocreate noch nicht angelegt) NICHT dabei und wird auch nie dabei sein. ES SEI DENN in der Dokus stünde, was man in der confg noch stehen haben muss. JETZT weiss ich das und schreibe das in mein Master mit rein. Fertig.

Ohne Speichern geht es nicht, da FHEM die Attribute nicht automatisch sichert.

Muss es auch nicht. Ich trage die attribute manuell in mein MASTER ein, und zwar nur die, die auch auch brauche. Beim nächsten überkopieren sind die drin und werden 1x gesichert.

Die gehen nach jedem peeren die peers verloren, so du nicht speicherst. hm - kann ich nichts machen. Vielleicht brauchst du sie nicht?

Doch doch, ich glaube du hast einfach nicht vor Augen wie ich das mache. Vielleicht wirds ja oben klarer. Ich bearbeite nur meinen offline Master und niemals die aktive fhem.cfg. Gesichert wird nur, nachdem ich meinen veränderten offline Master in die aktive fhem.cfg gesichert habe.

Ansichtssache. Ich halte es für einfacher, meine Aktoren in Files zu gruppieren, als ein riesen File zu bearbeiten. Da kann ich schon am Filedatum sehen, in welchem Bereich sich etwas geändert hat.

Klar, Ansichtsache. Und ich habe auch schon mehrfach geplant zumindest die Sachen die wenig Interaktion mit dem rest haben in eine eigene Datei auszulagern, meine Alarmanlage z.b.

welchen Code? Das fhem.cfg ist definitiv der falsche Ort für Code. Wer das macht ist selbst schuld (darf er natürlich, mitleid habe ich keins - sorry)

Okay, der Begriff Code ist hier eventuell falsch. Ich rede nur von defines (und darin enthaltenen PERL Kram)
Mehr mach ich gar nicht.

Rudi befragenstreng nach Alphabet, nicht wild.

Nope, es fehlen auch Sachen etc. Das haben wir alles immer wieder mal versucht zu durchdringen. Mir ist das am Ende egal, ich lasse autocrate einfach in die ansonsten leer Datei erzeugen und sicher wie gesagt nur.... siehe oben. Damit entsteht das Problem nicht und ich brauche niemand quälen, die wichtigeres zu tun haben. Funktoniert einwandfrei.

Oder sagen wir mal: funktionierte bisher einwandfrei.

AutoCeate ist m.E. kein Problem. Schalte aber autoSave aus, dann wird nicht gespeichert. mit oder ohne autosave - ich empfehle strikt, code aus dem/den "normalen" Config(s) zu entfernen. Ich kenne sicher nicht alles in FHEM - aktuell kenne ich keinen Grund, schon während init code auszuführen.

Ich glaube einfach, dass hier eine Missverständniss vorliegt. Entweder verstehe ich nicht was du meinst oder du nicht wie ich das mache.

hm - ich habe keine einzige Komponente im Commandref beschrieben. Wie bist du also bisher mit den Anderen zurecht gekommen?

Echt? Spannend. Woher kommen dann die ganzen Hinweise zu den HM Sachen in der Commandref?

Egal, HM ist eigentlich in den Grundfunktionen (leider nur da) nicht übertrieben schwer zu druchdringen, wenn man einfach die Ergebnisse des autocreate benutzt. Problematisch ist eben nur, wenn das Autocreate Attribute anlegt, die für sich alleine nicht funktionieren und erst beim Run später noch Dinge nachkreiieren. Das geht bei den Meisten gut, da die so arbeiten wie du es für sinnvoll hälst und praktizierst, aber u.U. nicht, wenn man das etwas anders handhabt.  Ich will hier keineswegs "Falsch oder Richtig" benutzen und nichtmal in Abrede stellen, das deine Methode sinnvoller sein mag oder von der Mehrheit so angewendet wird. Es ist eben nur so, dass ganz offenbar nicht alle die vollautomatischen Features von FHEM nutzen sondern manche ihren Kram manuell anlegen. Da bin ich ganz sicher nicht der Einzige. Und die stehen bei DIESEM Feature dann u.U. etwas im Regen.   Und zwar - das möchte ich nochmal betonen - nicht weil das so ist wie es ist, sondern nur weil nirgends steht was noch angelegt werden muss, sodass sie es nicht selber machen können.

Wenn der ActionDetector angelegt ist kannst du alles sehen, was er braucht. wie bei allen Anderen Komponenten auch?

Genau, WENN er angelegt ist. Bei den Leuten die so oder so ähnlcih wie ich arbeiten ist er aber nicht angelegt und da nirgend steht wie er aussehen müsste können die ihn auch nicht manuell anlegen, darum geht's mir ja gerade.

Es ist ja NULL Problem für mich den da eben einzutragen. Wenn mir einfach einer sagt wie er aussehen muss.


Das hast du dankenswerterweise 2 Posts vorher gemacht. Ich krtisiere also nicht (wenn man von "kritik" überhaupt reden kann) dass sich die ganze Mimik so verhält wie sie sich verhält, oder dass er automatisch angelegt wird, sondern nur, das nirgends mal ein 2 Sätzen beschreiben wird, WAS denn angelegt würde. Und somit stehen die Leute auf dem Schlauch die aus was für wirren Gründen auch immer ihr "life fhem.cfg"s nicht zwischensichern.

Gut, irgendwann hätte ich mal kurz vorm reinwerfen meines manipulierten Mastertextes aus dem Augenwinkel gesehen, da da was Zusätzliches  in der aktiven cfg steht.  Hoffe ich mal.

Anstelle dessen steht in der Doku nur die Hälfte, weil "der Rest legt sich ja von alleine an".

wie bei allen Anderen Komponenten auch?

Naja, also Beispiel FHT. In der Commandref steht drin wie eine komplettes define eines FHT aussehen muss, mit allen attributen und was die machen und welche wErte die haben können. OBWOHL die auch per autocreate angelegt werden. Die meisten nutzen sicher Autocreate, aber ich z.b. hier nie. Ich weiss wie FHTdefines aussehen muss und schreibe es per Hand. Gut - der Vergleich hinkt etwas , da HM Devices so nicht angelegt werden können. Ich hoffe du verstehst was ich meine.

Ich meine eben nur, dass vollständige Doku beides ermöglichen würde.

du willst also einen Wiki-Artikel schreiben? Prima

Hm. Spüre ich hier eine gewisse Feindseligkeit? Warum?  Nur zur Sicherheit: ich komentiere nicht wie der ActionDetector funktioniert oder dass er Teile automatisch erzeugt, sondern NUR - wierklich NUR, dass leider nirgend steht was er noch anlegt/noch da sein sollte.

Und erhlich gesagt: Meines Eindrucks nach liegt das daran, das "der Autor"  nicht in Erwägung gezogen hat, dass nicht alle Leute so arbeiten wie er.
Aber okay. Wiki:
Vielleicht weisst du es ja nicht, aber ich bin nebenher einer der Admins des Wikis und sehr viele Wikiartikel sind von mir, unter anderem die ersten 40 oder so, die das Wiki überhaupt angeschoben haben (das Wiki war unmittelbar nach der Einrichtung zuerst nicht so beliebt und recht verwaist, wenn du dich erinnerst). Also ja, ich schreibe oft Wikiartikel.
Aber erstmal muss ich kapieren wie das funktioniert. Und dazu muss mir ggf derjenige der sich das ausgedacht hat wenigstens minimal 4 Sätze hinwerfen, was alles zum System gehört. (die liegen mir im Grunde im Laufe unserer Diskussion  jetzt vor).
Gerade eben habe ich z.b. erst anhand des Beispiels von HM-sec-SC ins Wiki geschrieben wie man die batt-meldungen erzeugt. (ohne die nebenbei vermutlich der ActionDetector für HM-sec-SC nicht funktioniert, weil der ohne die zyklische Meldungen ggf auch 3 Tage lang nix sagt.) Dazu hatte ich dann dank Hinweisen einen Thread gefunden.

Ich schreibe eigentlich immer was im Wiki, wenn ich irgendwas nicht nach 2 Minuten kapiert hab, weil ich davon ausgehe, dass das anderen dann auch passieren könnte.

Ich verstehe dein Problem nicht. Steht doch schon lange in deinen fhem.cfg - und du löschst es sicher immer wieder
Code:
define ActionDetector CUL_HM 000000
attr ActionDetector model ActionDetector

Exact: Ich lösche das immer wieder. Jetzt hast du's. Wenn du jetzt noch bereit bist zu akzeptieren, dass das eine - von mir aus seltsame - METHODE ist mit der Anlage des fhem.cfg umzugehen, dann sind wir uns einig.

Ich bin bereit, da einen Wikiartikel draus zu machen, sobald ich das mal getestet und voll kapiert habe.
prima. Da das ganze recht einfach ist (min 2 Zeilen) - wo ist das Problem?

Wie ich inzwischen hoffentlich verständlich machen konnte ist das Problem, das ich diese 2 Zeilen nicht gesehen habe und gerne gewusst hätte wie die aussehen müssen und was die genau machen. Ich kann z.B. natürlich raten was
attr ActionDetector actCycle 30
genau macht (scheint naheliegend), drei Sätze vom Entwickler wären einfacher.

Oder wie ist - selbst nach Selbstanlage - deiner Meinung nach der Weg, wie man z.b. rausfindet, ob die Angabe von attr actCycle in Minuten oder Sekunden ist? Sollte nicht wenigstens das irgendwo stehen?

Das ganze gehört sowieso nicht ins kommandref, sondern ins wiki.

Hm. Ich habe das bisher immer so gesehen:

Commandref:
IT - InterTechno

Define
define <name> IT <housecode> <on-code> <off-code> [<dimup-code>] [<dimdown-code>]
oder
define <name> IT <ITRotarySwitches|FLS100RotarySwitches>


Wiki:
www.fhemwiki.de/wiki/Intertechno_Code_Berechnung (langer Artikel dazu, wo man den housecode herbekommt, wie man den einstellt, was zu beachten ist, welche Ausnahmen es gibt li-la-lub)

Aber da habe ich keine echte Meinung zu.



Zuletzt will ich noch mal versuchen, hier etwas Dampf raus zu nehmen:
- ich mecker nicht über die Funktionsweise des ActionDetectors und erst recht nicht über die Leistung der Entwickler, die mir jede Woche eine nette Problemlösung liefern. Ich bin speziell dir für deine Arbeit dankbar.
- ich finde es super, dass das Teil sich mehr oder weniger selber grundkonfiguriert, auch wenn ich dieses Festure eher nicht nutze.
- ich bitte bestenfalls darum, irgendwo aufzuschreiben, was grob an defines zu einer Funktion gehören. Ich will keine Romane - nur den knappen Kram mit korrekter Syntax, der in der commandref so steht. Romane machen dann andere (z.B. ich ) im Wiki draus. Und: "erklärt sich doch von selbst" - ja für den der's gebaut hat sicher. 

[martinp876]

Das mache ich defintiv nicht. Das ist schon alles richtig sortiert.

richtig ist relativ. Wer sich nicht an Konventionen hält muss selbst mit den Konsequenzen leben. Kann ich nichts dran Ändern. Was genau du auch immer nicht machst.

Das ist meines Wissens weder zwingend noch in irgendeiner Doku so dargestellt.

korrekt - leider. wenn man sich nicht daran hält (auch wenn es nicht sauber dokumentiert ist) passiert eben genau das, was dir passiert. Dass Kommandos VOR ende Init ausgeführt werden ist dann fakt. Wenn du es machst ist es mir recht. Ich werde dies jedem abraten. Falls du hierzu Fragen hast, bitte an Rudi.

Selbst eine Standardinstallation von FHEM out of the box hat nur ein File.
Es wird also Leute geben, die nur ein fhem.cfg haben in dem mehr oder weniger alles steht.
Viele.

ja - Grund ist die schlechte/fehlende Anleitung "how to setup config-files". Again -> Rudi

Wie gesagt: ich editiere offline mein fhem.cfg  (genau genommen einfach eine Textdatei, nennen wir die mal MASTER) die kopiere ich KOMPLETT und paste die mittels Webeditor in meine echte fhem.cfg und dann save ich die.
Dieses Vorgehen mag dir fremd sein, oder sogar sachlich suboptimal, ich weiss aber definitv, dass das einige so machen.

So ist es mir Fremd - und suboptimal. Aber gerne. Ich editieren das File immer direkt. Ausserdem setze ich Attribute per Kommando. In diesem Fall habe ich für FHEM auch Checks eingebaut - die systembedingt nur schlecht  auf deinem Weg geprüft werden können. => wer direkt im config-file editiert entzieht sich der Kontrolle und ist somit selbst verantwortlich. Ich mache das auch - ist dann meine Veratwortung

Doch doch, ich glaube du hast einfach nicht vor Augen wie ich das mache. Vielleicht wirds ja oben klarer. Ich bearbeite nur meinen offline Master und niemals die aktive fhem.cfg. Gesichert wird nur, nachdem ich meinen veränderten offline Master in die aktive fhem.cfg gesichert habe.

nach dem peeren wird das Attribut geändert. Das kannst du von Hand nachtragen.
Das Attribut wird bei jeden Lesen (getConfig) Aktualisiert. Du kannst es dann immer und gerne nachtragen in deinen Master - geht, wenn man will.

Nope, es fehlen auch Sachen etc. Das haben wir alles immer wieder mal versucht zu durchdringen.

Sachen? wir? verstehe ich nicht. Es ist ein klarer Ablauf beim Save. Nichts geheimnissvolles.

Echt? Spannend. Woher kommen dann die ganzen Hinweise zu den HM Sachen in der Commandref?

echt. Ist ein einziges Beispiel, wie man einen SD definiert in Commandref? es sind Kommandos, Attribute und events beschrieben. Was zu einer kompletten Definition gehört steht (falls überarbeitet und komplett) in Wiki.

Vielleicht weisst du es ja nicht, ...Also ja, ich schreibe oft Wikiartikel.

prima

Exact: Ich lösche das immer wieder. Jetzt hast du's. Wenn du jetzt noch bereit bist zu akzeptieren, dass das eine - von mir aus seltsame - METHODE ist mit der Anlage des fhem.cfg umzugehen, dann sind wir uns einig

.
Du kannst machen was du willst. Wenn du es aber immer wieder löschst - warum fragst du dann, wie es aussehen soll? Kopiere es dahin, wo du willst, anstatt es zu löschen.

Zur Doku:
Im Commandref versuche ich Kommandos und Attribute zu beschreiben. Keine Zusammenhänge - die gehören in ein anderes Dokument (wiki oder anderes howto). Dazu gehört auch, wie man ein Device definiert. Daher schreiben ich kein how-to-define-a-device in commandref.
Im Wiki beschreiben ich auch (wenn der Artikel von mir ist) wie man ein Device anlegt. Es gibt Attribute, die FHEM "gehören", Attribute die man setzen sollte und Attribute die dem User gehören. Das unterscheide ich immer und weise den User darauf hin. Daran halten muss er sich nicht. Wenn er dennoch FHEM-Attribute ändert muss er da selbst durch.
Leider unterscheidet FHEM hier nicht. z.B. ist model ein FHEM Attribut, das aus dem Device generiert wird - room ist eine Sache den User.

- ich bitte bestenfalls darum, irgendwo aufzuschreiben, was grob an defines zu einer Funktion gehören. Ich will keine Romane - nur den knappen Kram mit korrekter Syntax, der in der commandref so steht. Romane machen dann andere (z.B. ich ) im Wiki draus. Und: "erklärt sich doch von selbst" - ja für den der's gebaut hat sicher.

Zu welchen Funktionen welche defines gehören? Es gibt nur den ActionDetector zur Funktion der Batterie-ist-leer Überwachung. Die Definition hast du jetzt schon - da sollten wir also durch sein.

[Zrrronggg!]

Ich kapier deine Agressivität hier nicht. Wenn's jemand nicht genau so macht wie du es gut findest ist's scheisse, ausserdem bitte an Rudi wenden - kommt bei mir an.
Aber vermutlich verstehe ich dich nur falsch, wir haben irgendwie nicht die selbe Wellenlänge.

Trotzdem: danke für die Hinweise, die geholfen haben, ich denke alle Sachargumente sind ja auch ausgetauscht.

[marvin78]

Komisch, bei mir kommt an

Mache es so, dann funktioniert alles!

[Zrrronggg!]

Genau. Wobei "so" nur so ist, wie Martin meint (selbst Rudi machts ja falsch). Alternativ 3 Sätze schreiben, damit zusätzlich auch Leute die es ein bisschen anders machen zum Ziel kommen ist auf keinen Fall ein gangbarer Weg.

Aber wir sind auf einer Metaebene und das bringt nix.
Ich hab alle Infos die ich brauche glaube ich und hab kein Problem damit das im Wiki zu beschreiben, sobald ich damit ein bisschen rumgespielt habe und es einigermassen kapiert hab.

Die Entwickler müssen ja auch nicht alles alleine machen, das meine ich ja gar nicht.

[marvin78]

Warum soll man jemandem noch 3 Alternativwege beschreiben, wenn man ihm schon einen gezeigt hat, der funktioniert? Das leuchtet mir nicht ein. Aber das ist ja auch nicht unbedingt mein Problem.

[Zrrronggg!]

Ich hab jetzt ein bisschen überlegt, ob ich da noch antworten soll, den im Grunde sind alle Statements gemacht.
Aber vielleicht versuche ich nochmal zu erklären, was mein "Problem" ist:
Ich verlange nämlich nicht, dass mehrere Wege beschrieben werden sollen.

Ich wills mal mit einem Modell versuchen.

Aufgabe: Rasen sprengen.
Entwickler hat einen Rasensprenger und Schlauch und einem Wasserhahn entworfen.

Zrrronggg!:
Ich kapier nicht ganz wie das gehen soll. Wasserhahn irgendwie?

martinp876:
Wasserhahn aufdrehen, den Rest siehst du dann schon.

Zrrronggg!:
Es wäre schön, wenn ich irgendwo lesen könnte, was dann angeblich passieren soll. Bei mir passiert nämlich nix.

martinp876:
Kapier ich nicht, Einfach Wasserhahn aufdrehen. Rest siehst du dann, ist selbsterklärend.

Zrrronggg!:
Könntest du bitte doch mal eben sagen, was passieren soll?

martinp876:
Klar. Das Wasser fliesst durch den Schlauch und dann durch den Rasensprenger und dann wird der Rasen nass.

Zrrronggg!:
Super, danke. Bei mir ging das übrigens nicht, weil ich den Rasensprenger wegen Frostschutz abgebaut hatte.

martinp876:
Das ist nicht gut, dann kann man ja auch nicht zwischensprengen und was machst du wenn es im Herbst mal frühfrost gibt oder im Frühjahr? Das ist doch total unökonomisch. Du must natürlich eine automatische Schlauchentwässerung  benutzen. Das ist doch der einzig gangbare Weg. Gut, jeder kann machen was er will , aber ich kann nur abraten, ohne automatische  Schlauchentwässerung zu arbeiten, das könnte dazu führen das das System nicht arbeitet!

Zrrronggg!:
Hm. Aber im Winter abbauen machen doch viele, auch der bekannte Gartenarchitekt des Königs! Es ist klar, dass das bestimmte Einschränkungen mit sich bringen mag.

Man bemerke, dass die Diskussion bereits abgeglitten ist, die eigentliche Frage war ja nur: "Es wäre schön, wenn ich irgendwo lesen könnte, was dann angeblich passieren soll"

martinp876:
Ja, der bekannte Gartenarchitekt des Königs macht das leider auch nicht so gut. Ich schreibe aber in keinem Fall auf, was passieren soll wenn man den Wasserhahn aufdreht, weil das nicht nötig ist. Wenn man es so macht wie ich es mache klappts ja!

Zrrronggg!: Äh, ich verstehe diese Weigerung nicht und auch nicht, warum dein Weg der einzig gültige sein soll, aber egal ich hab meine Info.

marvin78:
Und ich verstehe nicht, wieso martinp876 drei Alternativwege beschreiben soll, wenn er doch schon gesagt hat: Wasserhahn aufdrehen.

Soll er nicht, war nie Gegenstand der Diskussion, ich wollte nur, dass er aufschreibt, was angeblich passiert, wenn man den Wasserhahn aufdreht.
"Das Wasser fliesst durch den Schlauch und dann durch den Rasensprenger und dann wird der Rasen nass." Reicht.

Das gibt allen, die es ein klein wenig anders machen die Möglichkeit selber dafür Sorge zu tragen, dass alle Voraussetzunge erfüllt sind, also der Haupthahn auf und der Schlauch nicht noch aufgerollt und der Wassersprenger auch dran und was sonst noch alles ein klein wenig anders sein mag.