Peeren und wie man es vermitteln kann

Begonnen von martinp876, 29 Juli 2018, 14:35:49

Vorheriges Thema - Nächstes Thema

martinp876

Wie u.a. im Threat
https://forum.fhem.de/index.php/topic,73287.msg822291.html#msg822291
zu lesen ist gibt es immer wieder Probleme mit dem Verständniss zum Peeren und den Optionen.

In Sachen Peeren habe ich keine Probleme - mir ist das alles logisch und konsequent. Nicht etwa, weil ich es so definiert habe - das habe ich ja nicht, es wurde von eq3 erstellt - sondern weil  ich die Konzepte, Notwendigkeinten und die darausfolgende Architektur und Semantik von eq3 zu verstehen glaube.
Klar, dass dies nicht auf jeden zutrifft und dass es einige auch nicht wollen (auch verständlich).

So weit die Vorrede. Ich halte es aufgrund der Menge der Diskussionen und Probleme der Anwender für sinnvoll, das Thema peeren dem Anwender (insbesondere dem Anfänger) in einer anderen Form nahezubringen. Die Methoden sind seit langem implementiert.
1) Das Problem
Der Anwender hat einige Optionen und kann diese nicht unterschieden. Bspw das Peeren single und dual.
2) reduzieren der Empfehlungen beim Peeren
Empfehlt dem Anwender immer "single" zu peeren. Das reduziert die  Optionen, lässt einzelne Buttons "nach-peeren" sollte es ein Problem gegeben haben, lässt peerbulk einfach anwenden,...  Peeren ist dann "single" und nur "wissende" sollten dual peeren.
3) programmieren der Aktoren
Nach peeren-single muss man den Aktor programmieren. Das können die Anfänger nun wieder nicht. Hier haben wir Templates. Es gibt die Wesentlichen - andere kann man schnell nachreichen. Ein Anfänger sollte für alle gängigen Anwendungen ein Template finden. So viele sind das nicht.

Damit ist das vorgehen für einen Anfänger immer und konsequent einfach:
a) peeren (auch Dual ist kein Problem, wird dann wieder überschrieben)
b) aktor programmieren mit einem Befehl.

Gegenstimmen?

Pfriemler

Ja. Die grundlegende Problematik ist hinlänglich beschrieben, und sie ist gut beschrieben. Aber man wird nicht prominent darauf verwiesen. Ich plädiere seit langem dafür einen gepinnten Thread einzuführen, der ggf. in mehreren Etappen die Grundvoraussetzungen für eine funktionierende HM-Installation liefert - er muss und soll nicht ins Detail gehen, aber er sollte Links zu mehr Infos liefern. Insbesondere auf die Inbetriebnahme neuer Geräte sollte besser eingegangen werden:
- wie richte ich eine Zentrale ein, was ist hmID, wozu ist eine vccu gut?
- wie wird richtig gepairt?
- warum reicht autocreate nicht?
- wie prüfe ich das pairing richtig?
- wie peere ich richtig? und wie prüfe ich das?
- welche weiteren Optionen habe ich? z.B. das Programmieren mit Vorlagen (templates)
Wie gesagt: stichwortartig, mit Referenzen in commandref und Wiki.

Aber zum Thema: Ich bin nicht dabei, generell single zu peeren. Ich wäre aber dafür, "single set" (anstatt dual set) zum Standard zu erklären. Das peeren eines Tastenpaares ist zwar bedienhaptisch fast immer sinnvoller - aber dass das dual peeren von der "low-Aktion" eines Tastenpaares heraus mit einem Befehl erfolgt und den darauffolgenden Kanal  (meist "up-Aktion") automatisch einschließt, ist ein Spezialfall des peerens - nicht umgekehrt. Das mag traditionell sinnvoll sein, weil peeren ohne Zentrale normalerweise ebenfalls zwei Tasten peert... Wer dann gezielt "dual" einsetzt, weiß eher was er tut, im Gegensatz zu den Anfängern, die single/dual gänzlich vergessen und sich dann wundern, wenn nichts tut, oder nur die Hälfte, und wieso die Programmierung einer Taste, die ich gar nicht angefasst habe, zerschossen ist.
Außerdem wäre ich dafür, den channel gänzlich abzuschaffen. Die eine Ziffer hinter peerChan vergesse selbst ich regelmäßig. Auch dass peeren einer Einzeltaste sich auf die fortlaufende Einzelnummerung, eines Paares aber auf die Paarnumerierung bezieht, ist alles andere als intuitiv. Man sollte das peeren von der jeweiligen Taste aus (0) zum einzigen Standard deklarieren und gut.

Der zitierte Thread war aber auch eine besonders mühselige Erscheinung. Normalerweise wird das doch schneller kapiert.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Beta-User

Kann Pfriemler da im wesentlichen nur zustimmen.

Was scheinbar bei vielen Einsteigern in das Thema nicht präsent ist: Es steht ganz viel im Einsteiger-pdf. Neben den grundlegenden Konzepten (direktes Peeren/indirekte Kommunikation über FHEM) vorne gibt es diesen super-Anhang, der allerdings evtl. manchem zu technisch ist. Wenn es also einen gepinnten Beitrag gibt, könnte der am Anfang jedenfalls einfach nur den Hinweis enthalten, dass das ein Startpunkt ist, dazu die Links zu https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen, https://wiki.fhem.de/wiki/Peering_(HomeMatic) und den Beispielen (https://wiki.fhem.de/wiki/Homematic_Peering_Beispiele).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

ich finde zb den aufbau des peerchan befehls alles andere als einfach und intuitiv.
wenn ich da an meine anfäge mit homematic denke, hilfe.

1. es fängt schon mit der vorgeschriebenen reihenfolge von sensor chn und aktor chn an.
einige anfänger haben ja schon ein problem mit dieser unterscheidung. ist der "schalter" hm-lc-sw1pbu-fm nun ein sensor oder aktor?
zusätzlich hat es den nachteil, dass der peerchan befehl heutzutage bei aktoren erst gar nicht auftaucht. einerseits gut, weil es durch die reihenfolge verboten ist. andererseits gibt es wieder einen neuen thread, falls nicht wieder einer "gekapert" wird, mit der frage: wo ist der befehl peerchan?

2. devices mit einem channel haben kein explizites channeldevice.
wieder eine sonderregel, die zusätzlich eigentlich nur weitere missverständnisse bringt und neue fragen aufwirft. es wird also einmal das device gepeert oder ein devicechannel. soweit ich weiss, kann man sogar den channel in einem 1-chn-device explizit angeben. daneben funktionieren auch noch die id's.
ganz zu schweigen von der möglichkeit den devicenamen bei einem multi-chn-sensor zu nutzen und den channel über die "ominöse" nummer im peerchan befehl anzusprechen.

alles in allem zu viele möglichkeiten, deren zusammenhänge einem anfänger nicht sofort klar sind. durch die vielzahl unterschiedlicher beispiele erschliesst sich einem keinerlei regel.

3. zu viele optionen mit diversen abkürzungen.
zb single, single set, single set both ist alles das selbe.
dadurch entstehen wieder dutzende unterschiedliche beispiele, die eigentlich nur verwirrung stiften.

wie wäre es mit einem ganz simplen befehl:

set <channel> peerSet <channel>

der befehl existiert dann in jedem channel, der gepeert werden kann, egal ob sensor oder aktor. bei 1-channel-device natürlich auch im device. zusätzlich generiert fhem eine drop-down select liste mit allen verwendbaren device/channel namen. wenn der befehl in einem aktor aufgerufen wird, sind also nur sensor devices zum auswählen in dem drop-down enthalten.

zum löschen von peers dann einen eigenen befehl:

set <channel> peerUnset <channel>

hier gibt es dann ein drop-down nur mit den bereits vorhandenen peers. hier wäre zu überlegen, ob dadurch beide seiten gelöscht werden oder nur eine.

auf diese weise kann man eigentlich nichts mehr falsch machen, der befehl ergibt sich von selbst.
weiterhin gibt es dann immer noch das problem beim peeren von devices, bei denen man das knöpfchen drücken muss, aber vergisst. das müste man nochmal in einem weiteren thread behandeln, da dieses problem auch mit anderen befehlen existiert.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Pfriemler

#4
Da bin ich fast voll dabei. Gerade eine Dropdownliste wäre genial. Derzeit geht es doch nur mit zusätzlichen Tabs im Browser und Copy&Paste der Namen. Auch die Herauslösung von set|unset in separate Befehle peerSet und peerUnset ist super - für pair und unpair gibt es ja auch schon getrennte Befehle.

Was mir an franks Vorschlag fehlt (wobei das dort nicht fehlt, sondern einfach nur nicht explizit genannt ist, aber durch zusätzliche Paramter machbar wäre), ist der actor-remote-both-Mechanismus, also das Festlegen ob beide Peerpartner "bearbeitet" werden sollen oder nur einer. Dabei entsteht der Wunsch nach "einseitiger" Behandlung eigentlich nur in Folge einer nicht erfolgreich abgeschlossenen "zweiseitigen" Behandlung - Dinge, die man alternativ mit peerBulk lösen kann, zumal letzteres ja bisher ohnehin zum Einsatz kommen muss, wenn der Sensor in FHEM nicht mehr definiert ist (und peerChan deswegen dort nicht absetzbar). Zugleich sorgte "remote" bei mir immer für eine Begriffsverwirrung: für mich ist "remote" der "entfernte" Partner, beim bisher zwingenden Einsatz von peerChan in Richtung Sensor->Aktor ist das aber gerade das Gerät an dem ich "arbeite" und "actor" der "entfernte" Partner. "sensor"-"actor" wäre für mich eh passender gewesen.
Wenn wir peerChan/peerSet von beiden Seiten öffnen, bräuchte es neue Bezeichnungen. Im Prinzip würde der optionale Parameter "local" reichen - denn wenn ich bei einem Button einen verwaisten peer killen will, mache ich es eh dort, und bei einem Aktor macht es genauso Sinn es von dort aus zu machen. Lässt man als peer auch eine hmID statt des Namens zu, so wäre "peerUnset xxxxxx(xx)" dann die freundliche Version von peerBulk.

Bliebe noch die Frage mit dem dualen Peeren. Da öffne ich mal die Wunschkiste noch weiter und wünsche mir die Angabe von ein oder zwei <channel> im peerSet-Befehl, deren Reihenfolge dazu festlegt, welcher Sensor/Button dann für welche Aktion zuständig ist. Zu definieren ist, ob die Reihenfolge der Tasten wie bisher liefe (Beispiel Lichtschalter: Peering vom "Aus"-Button aus inkludiert bei dual den benachbarten "Ein-Button" automatisch) oder ob man es nicht in eine menschenlogische Ein-Aus-Richtung bringen sollte, was ich bevorzugen würde.
Das würde auf einer Fernbedienung zugleich die Beschränkung auf Tastenpaare aufheben. Wenn ich das richtig verstehe, sind dual peerings doch nichts weiter als sinnfällig angepasste/funktionskastrierte doppelte single pairings, die der Aktor in völlig getrennten Fächern verwaltet - die beiden Buttons eines dual peerings müssten danach nicht einmal auf dem gleichen Device sein (wobei mir spontan nicht einfällt wofür das Sinn ergeben würde).

Zusammengefasst:
set <actorchannel> peerSet <button_up> <button_down> würde ein duales peering für den Aktor einrichten: oben ein/heller/aufwärts, unten aus/dunkler/abwärts (Schalter/Dimmer/Rolladen)
Wer die Reihenfolge andersherum mag, gibt es dann einfach so an. Für Rolläden etwa gibts ja schon Templates, die das können.
set <actorchannel> peerSet <button> allein würde dies automatisch als single peer mit toggle-Funktion auf der oberen Taste einrichten
set <actorchannel> peerUnset <button_up> <button_down> entspräche dual unset
set <actorchannel> peerUnset <hmID> local würde ein verwaistes Peering aus dem Aktor allein löschen.

Nachtrag: Gibt es da nicht ein Problem mit mehreren Dropdowns nach einem ausgewählten set-Befehl? oder ist das gelöst?
2. Nachtrag: Ähnliche Überlegungen zu regSet hatten wir doch hier schon mal ...



"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Wuppi68

allem gesagten stimme ich vollends zu :-)

Ich würde die Anzeige der Peering Befehle im Dropdown einfach mit an den Expert Level für die Registeranzeige hängen

bei allem größer 2 oder so werden alle Befehle angezeigt :-)

ansonsten peerSet und peerUnSet finde ich genial

kann man die Einkanaliegen Geräte nicht auch wie die Mehrkanaligen behandeln und entsprechend so anzeigen?

Jetzt noch ein angepinnter readonly Beitrag als FAQ (pairen, peeren , vccu ...) wo ganz kurz mit Links zum Wiki o.ä. auf Details hingewiesen wird.
z.B. so:
pAIren:
      - Batteriebetriebenes/240VGerät: HMLAN/VCCU auf hmPairForSec 60 setzen und die Configtaste drücken
      - 240V Gerät: Alternative: HMLAN/VCCU auf hmPairSerial <Seriennummer> setzen
      - wenn die Configlampe "direkt" aus geht sollte es geklappt haben und im Raum CUL_HM sollte dieses Gerät jetzt richtig vorliegen (Register prüfen --> WIKI Link)
pEEren:
      - Wichtig: Es wird immer vom Sender zum Empfänger gepeert
      - Sender Gerät/Device aufrufen
      - set SenderDevice peerSet EmpfängerDevice
      - die Aktionen des Empfängers können durch die Registereinstellungen des "Peers" innerhalb der Statemachine geändert werden --> Einsteigerdoku 2. Abschnitt oder --> WIKI



Just my 2 Cents

Ralf
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

the ratman

#6
ne ganze dumme idee von nem noob in solchen sachen:
ließe sich nicht einfach in fhemweb ein modul fürs peeren basteln, ähnlich den doif-tools fürs doif? <-- dies nur als beschreibung der idee, nicht als vorlage

. modul sucht alle "peer-baren" devices.
.. "noob" kriegt ne auswahl an devices (ähnlich dem popup zum aussuchen der räume oder gruppen) mit denen gepeert werden kann.
... anschließend ein popup, was mit dem ausgewählten gepeert werden kann, mit passenden parametern (und als kür eventuellen kurzinfos, was mit was passieren wird/kann).
.... noob klickt seine häckchen bei den parametern, peering ist fertig.

ich denke, dass würde das leben aller erleichtern. das der "noobs", weil sie auch mal selber ein erfolgserlebnis haben, dass der "wissenden", weil sie wieder ein paar freds mit den immer gleichen fragen weniger im forum zum x-ten mal zu beantworten haben.
→do↑p!dnʇs↓shit←

frank

#7
ich würde die peerbefehle wirklich nur auf das nötigste minimieren.

da peeren immer eine 2-seitige verbindung bedeutet, finde ich, sollte dann auch immer mit den peer befehlen beidseitig gepeert/entpeert werden.
falls eine seite bereits mit dem zu peerenden channel gepeert ist, sollte fhem so schlau sein und es nicht noch mal auf dieser seite probieren.

einseitiges peeren/entpeeren ist doch eher ein spezialfall und wird von peerbulk bestens unterstützt. optionen wie remote, actor, both oder local würde ich vermeiden.

auch dual peering würde ich nicht extra integrieren.
der vorteil ist ja eigentlich "nur" das gleichzeitige spezielle konfigurieren eines peers des aktors. das gilt aber auch nur für einige devices.

dann doch besser gleich die konfigurationen für jedes single peering wählbar machen. hier könnten dann zb die "unbeachteten" templates zum einsatz kommen.

ich denke aber, das wenige cmds in folge beim funk insgesamt schneller zum ziel führen. falls mal ein cmd in der liste versagt, muss nicht immer alles wiederholt werden. siehe zb ein getconfig auf ein rt device. dazu vielleicht noch ein timingproblem mit cul.

daher erst ein einfaches "set <actor> peerSet <peer>" ohne konfiguration. und danach dann zb ein "set <actor> templateSet shToggle_lgToggleDim <peer>".
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Pfriemler

Zitat von: frank am 31 Juli 2018, 17:58:50
ich würde die peerbefehle wirklich nur auf das nötigste minimieren.
Das hatte ich auch schon versucht  ;) - und einen Kompromiss für eine einfache Bedienbarkeit.
Und im Gegensatz zu Dir halte ich einen dual-peer-Mechanismus wie bisher für unverzichtbar, weil er beispielsweise bei einer üblichen Dimmer- oder Schalterinstallation mit den -PBU-Aktoren bei einer Ergänzung  mit zusätzlichen Bedienelementen (Wandtaster) für einen hohen WAF eigentlich der Regelfall sein dürfte. Insofern ist dual peer eigentlich Einsteigerniveau und sollte daher so einfach wie möglich gehalten werden. Daher auch mein Vorschlag, mit der Angabe von wahlweise einem oder zwei Sensoren im Peering - ohne zusätzlichen Parameter - die Unterscheidung in single und dual zu treffen. Indem der User beide dual-peer-Partner im Befehl explizit angibt, hat er die volle Kontrolle darüber welche beide Tasten mit Werksfunktion vorbelegt werden. Beispiel: Meinen PB6 habe ich um 90 Grad gedreht und habe so drei nebeneinander liegende vertikale Tastenpaare (1-2, 3-4, 5-6). Man könnte ihn auch in Originalposition belassen und oben je vertikales Paar (3-1) und 2-4) bilden oder für Rolläden aus (5-1) und (6-2), und die Tasten 3 und 4 etwa zum Stoppen zusätzlich einsetzen. Benennt man die Tasten nach der Ersteinrichtung sinnfällig (bei Originalmontage etwa _leftUp, _rightUp, leftDown, _leftMid, usw. oder bei gedrehter entsprechend _leftDown, leftUp, _midDown, _midRight usw.) braucht einen später nie wieder zu interessieren, welche interne Kanalnummer die Taste nun eigentlich hat. Das gilt für 2er Taster entsprechend.

Zitatfalls eine seite bereits mit dem zu peerenden channel gepeert ist, sollte fhem so schlau sein und es nicht noch mal auf dieser seite probieren.
Wiederholtes Setzen oder Entfernen einer Verknüpfung sollte so oder so kein Problem sein.
Im Falle eines "local" würde ja nur explizit vorgeschrieben, keinen entfernten Partner zu suchen und zu bearbeiten. Wenn FHEM das sinnvoll abfängt und außer eventuellen Warnhinweisen trotzdem alles erforderliche abarbeitet, ist "local" auch entbehrlich. Dann wäre auch eine (ohnehin selten erforderliche) Reparatur mit peerBulk hinfällig.

Zitatich denke aber, das wenige cmds in folge beim funk insgesamt schneller zum ziel führen.
Auch hier ACK, aber ich kenne wenige Templates mit sehr großem Datenumfang. Und wenn die Übertragung einmal steht, geht seltener etwas verloren, zumindest nach meiner Erfahrung. Weniger Funk wird es dadurch nicht, aber mehr "am Stück". Allerdings bringt gerade das die timingproblematischen IOs eher an ihre Grenze.

Beim dual peeren frage ich mich zudem noch, wer hier die Defaults vorgibt. Wenn ich das richtig verstehe, haben die peers hierfür ab Werk eigene Vorgaben (nämlich die, die sie bei einer Direktverknüpfung ohne Zentrale auch einsetzen würden). Hier noch extra Vorgaben machen zu wollen könnte den Prozess unnötig verkomplizieren.
Martin?

Und die Idee mit dem Hilfsmodul finde ich auch einen gangbaren Weg. Das erfordert vermutlich weit weniger Änderungen an den Basics.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

martinp876

Dualpeer wird es narürlich weiter geben. Es ist dennoch definitiv verzichtbar. Den default im kommando gibt fhem vor, können wir ändern.
Peering hat auch sonst eon paar Fallen. Peert man mit peerbulk ist es immer single. Jedes peeren setzt die register auf einen der defaults. Peere ich also einen peer noch einmal sind meine Einstellungen überschreiben. Ein anwender muss das allew berücksichtigen oder auf sei  glück vertrauen.
=>alles nett für meine Vorredner. Die wissen was sie tun. Aber zu komplex für eingache Anwender. Den es geht auch einfacher und sicherer.

Wie oben beschrieben richtet der anwender die verknüpfungen ein (peeren). Faktisch egal wie. Dual, single oder alle im Bulk. Braucht er 2  Buttons peert er 2.
Dann weist er die funktion zu. An/aus/rauf/runter/onfortimer/runterwenn/dimwithspeed...... Dazu braucht er das template welches er sich layen kann.

Löst er nun warum auch immer noch einmal ein peeren aus sind die register überschrieben. Ein configcheck findet das systemweit. Ein templateexe korrigiert es systemweit.

Warum ist es einfach? Weil der nur wissen muss a) wer mit wem b) was soll er tun c) wie prüfe und korrigiere ich das.

Details wie das entfernen der 0 aus den peerchan kommando kann man machen, sind aber kein Bringer. Peeren nur auf einer seite ausführen dagene ist essentiell. Wer das nicht sieht hat  nicht verstanden, dass das peeren die register überschreibt und somit arbeiten nach sich zieht. Mit templates natürlich halb so schlimm.

Wuppi68

Hallo Martin,

eigentlich fühle ich mich recht fit in Homematic ;-) Jedoch haben sich mir die Templates noch nicht wirklich erschlossen

Im Wiki gibt es diesen https://wiki.fhem.de/wiki/Homematic_Peering_Beispiele Eintrag - könnte man z.B. dort zentral ein paar Beispiele deponieren?

Beispiele die jeder Verstehen sollte weil er sie aus der realen Welt kennt und damit das ganze auch entsprechend nachvollziehen kann 8-)

Spontan fallen mir da zwei ein:

Bewegungsmelder, der eine Lampe nur bei "Dunkelheit" einschaltet

Treppenhausautomat mit 1 Aktor und mehrere Sensoren (vielleicht auch mit einem Helligkeitswert)

wenn ich das ganze Verstehen würde, hätte ich dieses auch schon getan


Idee?

Sonnog warme Grüße

Ralf
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Benni

#11
Hallo zusammen,

Mir geht es im Prinzip wie Ralf, ich konnte meine Anwendungsfälle bisher stets mit den bekannten Peering-Methoden und Registeranpassungen umsetzen. Ich glaube, dass ich das weitgehend verstanden habe, zumindest in der Anwendung.

Ich hatte bisher also auch noch keine Notwendigkeit Templates zu verwenden. Auch ich habe mir den Wiki-Artikel bereits durchgelesen (überflogen) um festzustellen, dass ich es nicht auf anhieb verstehe und habe mich deswegen auch nicht eingehender damit beschäftigt.

Überhaupt liest sich auch der Rest des Threads für mich in weiten Teilen so, als ob sich Experten in Expertensprache darüber unterhalten, wie man für Nicht-Experten die Dinge einfacher machen kann. Es erweckt aber eher den Eindruck, als ob die Dinge nicht einfacher, sondern nur anders komplex werden.

Bitte nehmt das nicht persönlich! Grundsätzlich hätte ich das ganze auch lieber einfacher. Da ich aber nur den aktuellen Modus Operandi in der Anwendung verstanden habe und das Thema in der zugrunde liegenden Theorie sicher bei Weitem nicht verstanden habe, kann ich leider auch keinen konkreten Vorschlag dazu machen, wie man das Thema greifbarer machen kann.

Ich schreibe das nur, um meinen persönlichen Eindruck dieser Vereinfachungsversuche zu beschreiben mit dem Hinweis, dass diese womöglich ihr Ziel verfehlen, da vermeintlich einfache Dinge doch wieder zu komplex beschrieben werden.

Wie gesagt, bitte nicht persönlich nehmen!

Gruß Benni.


Prof. Dr. Peter Henning

In dem in Arbeit befindlichen "FHEM-Kochbuch" wird es dazu ein Kapitelchen geben, einfach und für Anfänger erklärt. Gerne können wir danach den Text (mit leichten Änderungen...) für alle freigeben.

LG

pah

martinp876

Bei templates muss man zwischen Ersteller und Anwender unterscheiden. Sicher sollte man 2 Anleitungen machen.
Der Ersteller muss die register kennen. Der Anwender muss register nicht kennen. Er bekommt fertige Templates für seine Anwendung.
Das erstellen ist für erfahrene und sollte das procrammieren der Register auch vereinfachen. Ich versuche am wochenende eine anleitung für 1-2 Templates zu erstellen. Dann könnt ihr testen und Verbesserungen vorbringen.

the ratman

ohne unken zu wollen - nur mal meine 0.02€: benni hat da schon sehr recht ...

und "fhem-kochbuch", "2 anleitungen schreiben" - wäre ich jetzt ein gemeiner mensch, würd ich mal fragen: "wie viele anleitungen zu fhem (die eh keiner ders wirklich braucht liest weil er sie meistens nicht mal findet und/oder versteht), wollts den noch machen?"

wärs nicht wirklich anwenderfreundlicher etwas mit ein paar knöpfchen anstelle seitenlanger anleitungen zu lösen?
siehe "meine" modul-idee. der unwissende hat erfolgserlebnisse ohne euch zu nerven und ihr machts dessen holde glücklich, der wissende kann ja weiterhin irgendwas über irgendwelche register peeren, bis ihm die haare ausfallen und dabei über die unwissenden milde ablächeln.

und ja, ich geb euch recht: ne gute doku is echt was wert - aber so weit kommt der 08/15 user doch erst gar ned und fragt dann erst wieder die 1000 blöden fragen im forum, die schon 1000 mal (meist unverständlich oder varaltet) beantwortet wurden.

sorry, ich will hier echt keinem auf die füße steigen und das ganze ist je eher ein fhem-allumfassendes problem, aber ich wollts nur mal in die runde werfen.
→do↑p!dnʇs↓shit←