Peeren und wie man es vermitteln kann

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

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

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

[Pfriemler]

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

[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:

Code Auswählen Erweitern

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

[the ratman]

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.

[frank]

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

[Pfriemler]

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.

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.

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.

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

[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

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

[Benni]

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.

[martinp876]

gegen eine gute Doku hat keiner etwas. Wer kann eine Schreiben?
Ich werde nicht FHEM erklären. Mein Teil ist FHEM-Homeatic. Und auch hier habe ich nur die Basics bereitgestellt. Daher hatte ich das Einsteigerdoc verfasst welches aus meiner Sicht immernoch die beste Zusammenfassung und Einführung in HM darstellt. Ok, der Level ist nicht für Anfänger sondern für Anwender mit Systemhintergrund welche in HM einsteigen.

Leider sehe ich mich ausser Stande aus FHEM-HM ein PuP System zu bauen. Das System ist schlicht zu fragil und zu wenig auf Zentral-Kontrolle ausgelegt (u.a. von eq3) als dass man dem Anwender ruhigen Gewissens ersparen könnte ein paar troubelshooting Aktionen zu  erlernen. Dazu wiederum braucht man (ich jendenfalls)ein paar Kentnisse der Architektur.

Zurück zu templates - was eine deutliche Vereinfachtung sein sollte und den PuP einen Schritt näher kommen sollte.
Part I: Systemvoraussetzungen
In der Beschreibung gehe ich davon aus, dass das System aufgesetzt und in stabilem Zustand ist. Das bedeuted:
- FHEM  ist aufgesetzt
- VCCU ist eingerichtet (ok, hat mit templates nichts zu tun)
- IOs sind eingerichtet (eines zumndest)
- HM Devices sind gepairt (Hierzu gerne eine gesonderte Beschreibung)
- HMinfo und HMtemplate sind eingerichtet (define hm HMinfo, define ht HMtemplate)
- HM System ist auf Fehlerfreiheit und  pending tasks geprüft (configCheck, protoEvents)
- Die Register der Devices sind somit eingelesen und stehen zur Modifikation zu Verfügung
=> System ist "stabil"

[martinp876]

templates Part II: Vorbereitung peeren
Der Anwender muss sich klar werden, welche Buttons nun welche Kanäle steuern sollen. Diese werden gepeert. Die Register werden gelesen (der Anwender ist wie oben erwähnt zu diesem Zeitpunkt damit vertraut, dass Register gelesen werden müssen)
Wie das Peeren stattfindet ist egal. PeerChan single, dual, peerBulk, direkt,...
Der Anwender prüft die Peerings und das System auf Stabilität
- get hm peerXref
- get hm configCheck
- get hm protoEvents
sollte alles abdecken

[martinp876]

templates part III: einfach templates für peers
Dem Anwender muss klar gemacht werden, dass die Aktion welche ein Aktor ausführt, wenn er durch einen Sensor getriggert wird im Aktor definiert wird. Typisch erwartet der Anwender dies umgekehrt (der Sensor schickt ein Kommando was zu tun ist).
Dann wird im Klar, das der Aktor-Kanal zu konfigurieren ist, nicht der Sensor.
Weiter macht sich der Anwender klar, was er eigentlich will. Er sucht sich aus dem Template-Repository eine Aktion, also ein template aus. Hat er dies noch nicht holt er sich dies in sein system. Hierzu pastet er das Kommando in die Kommandozeile und kann das Template nutzen (wie immer speichern mit "save". Ein Beispiel:

Code Auswählen Erweitern

set hm templateDef SwOnOff timeOn "sh:on lg:off" lgOffTimeMode:absolut shSwJtDlyOff:dlyOn lgSwJtOn:dlyOff shOnTimeMode:absolut lgActionType:jmpToTarget shOnDly:0 shActionType:jmpToTarget lgMultiExec:off shMultiExec:off shOnTime:p0 lgSwJtOff:no lgSwJtDlyOff:off shSwJtOn:dlyOff lgSwJtDlyOn:dlyOff shSwJtOff:dlyOn shSwJtDlyOn:on lgOffTime:unused lgOffDly:0
Die Templates sollten beschrieben sein - logisch.
Nun kann er es dem/den Aktoren zuweisen. Geführt wird es in ht angeboten

Code Auswählen Erweitern

set ht select SwOnOff
attr ht tpl_entity actorChan
attr ht tpl_ePeer senPeerChn
set ht assign
alles geführt und über pull-down unterstützt.
=> done. Wir immer Systemkontrolle
- configCheck, protoEvents

[martinp876]

PartIII: templates mit Parametern
nun will man einen Treppenhausschalter einbauen. Hier will man die Zeiten individuell festlegen. Meine Lichter schalten übrigens alle nach 6h aus - falls es jemand vergist.
Aktionen:
Alles wie in "partII". Vor dem assing muss man noch die Parameter setzen welche in den Attributen in ht zu sehen sind.

Code Auswählen Erweitern

attr ht tpl_param_timeOn 12000
nun assign und fertig.
Das Ändern eines Parameters nachträglich ist (zugegeben) etwas sperring. Man muss es einfach noch einmal ausführen.
Die aktuellen Werte werden in den ht Readings angezeigt

[martinp876]

part IV: templates ohne peer
natürlich gibt es auch Registerblöcke ohne peer. Typisch kann man RTs oder Blind einstellen.
Hier das Beispiel, wie man die Rollo-laufzeiten einstellen kann:

Code Auswählen Erweitern

set hm templateDef BlSetDrive up:down:turn "drive times up, down and turn plus gen defaults" refRunCounter:0 driveDown:p1 statusInfoMinDly:3 driveUp:p0 driveTurn:p2 confBtnTime:permanent sign:off statusInfoRandom:0 transmitTryMax:6 localResDis:off intKeyVisib:visib

Code Auswählen Erweitern

set ht select BlSetDrive
attr ht myBlind
tpl_param_down 30
tpl_param_turn 1.2
tpl_param_up 31
set ht assign
Auch Climate der RTs verlangen geradeu nach templates - mit Parametern wie boost.

[martinp876]

part V: nachsorge /maintenance
Nun hat der Anwender alle templates definiert
zugewiesene templates sind im Aktor /Kanal sichtbar und können dort gelöscht werden.
"save" ist natürlich notwendig zur Sicherung
wie immer sind configCheck und protoEvents zur kontrolle notwendig
set hm templateExe setzt alle Register in die Devices sollte eines einmal "ausgebüchst" sein. Hat man einen Reset gemacht oder - warum auch immer - ein peering kommando noch einmal ausgeführt - ist das Template aus dem Device verschwunden - nicht aber aus FHEM. Der Anwender hat autoReadReg auf Level 5. Die Register werden (langsam in Hintergrund) gelesen und stehen irgendwann zu Verfügung (oder manuell natürlcih). Ein hm ConfigCheck deckt die Diskrepanz auf. templateExe schreibt auf Wunsche alle (systemweit ALLE) falschen (nur die falschen) registerwerte in das Device.

Weitere Auswertungen und Statistiken zu templates in HMinfo.


=> Anwenderseitig ist nun alles erklärt. M.E. zwar etwas viel text - aber alles ganz einfach. Der Anwender muss halt immernoch wissen, was er will.
=> templates erstellen ist eigentlich auch einfach - aber etwas für fortgeschrittene. Liegt an den vielen Möglichkeiten von eQ3
=> das repository sollte von den erwähnten fortgeschrittenen Anwendern sukzesive erstellt werden.
=> mein Ziel ist es, ALLE notwendigen Register in ALLEN Devices über templates abzudecken (also in meinem System). Warum? Weil hmConfigCheck dann mein system umfänglich auf Gesundheit prüfen kann. Ist das notwendig? Nun, ein paar Mal habe ich schon ein Device wiederherstellen müssen. Mit templates ist das a) peeren und b) templateExe - done.

[the ratman]

einmal nerv ich noch - dann geb ich ruhe, versprochen!

Leider sehe ich mich ausser Stande aus FHEM-HM ein PuP System zu bauen. Das System ist schlicht zu fragil und zu wenig auf Zentral-Kontrolle ausgelegt (u.a. von eq3) als dass man dem Anwender ruhigen Gewissens ersparen könnte ein paar troubelshooting Aktionen zu  erlernen. Dazu wiederum braucht man (ich jendenfalls)ein paar Kentnisse der Architektur.

DAS sollte auch mal wo stehen, würde eventuell den eindruck nicht-wissender zerstreuen, dass der modulautor einfach keine lust hatte, was zu machen. und verdient, eure arbeit mal positiv herausgestellt zu kriegen habts is sowieso ...

jetzt aber, was mich wirklich reizt:
du schreibst hier punkte (part x) auf. anhand dieser sollte man ja schon fast eine art hilfsmodul bauen können. und wenn dann nur ne "halbe gui mit zusatzarbeit" oder "nur" eine interaktive anleitung rauskommen würde, wäre dass für nicht-programmierer und "verkehrt-rum-denker" sicher schon ne irre hilfe, weil man dann zumindest mal einen ansatz hat, nicht gleich alles falsch zu machen.

[martinp876]

Verstehe ich nicht. Ht ist ein hilsfmodul. Das soll es genau leisten.
Du nervst (mich) nicht.
Ht ist in wiki beschrieben. Allerdings ist template erstellen und template anwenden gemischt. Das könnte verrwirren.

Nachdem ich das Vorgehen für Anfänger für einfach erlernbar halte würde mich nun das Feedback von euch Interessieren

[the ratman]

nachdem ich dir nicht wirklich für dich brauchbares feedback geben kann, wenigstens was zum lachen für dich und vielleicht ein bissi einblick in deine "kundschaft":

ich hab in 2 1/2 jahren EINMAL einen schalter mit nem licht erfolgreich gepeert. das peeren war - trotz wiki - so eine derartige hin- und herprobiererei, dass ich am nächsten tag schon nimma sagen konnte, was ich da wie gemacht hab. nachdem der schalter dann auch noch kurz darauf seinen geist aufgegeben hat und ich mir (wie meistens in fhem) mal selber die schuld dran gegeben hatte, hab ich das peeren lieber ganz gelassen - auch wenn ich da so manches von gut gebrauchen könnte.
als ich dann auch noch versucht hab, meiner wetterstation beizubringen, dass sie bitte doch max und min windgeschwindigkeiten in der reg fressen und an die vccu weitergeben sollte und das ums verrecken nicht gefunzt hat, hab ich die finger von der reg allgemein gelassen. ich schalt nicht mal mehr die blöden leds bei den magnetkontakten aus, aus angst, ich könnte was killen.

von templates hab ich nur mal nebenher was gelesen. nachdem templates für mich masken/vorlagen sind, in die ich was einfüllen kann und ich mir nicht vorstellen konnte, wofür ich das bei hm brauchen könnte, bin ich geistig schon ausgestiegen, bevor ich überhaupt nach weiteren infos gesucht hab.

jetzt schreib mal ne anleitung für so nen anti-tech-noob wie mich ... wir treffen uns in 10 jahren wieder *lach*.

[martinp876]

Nun... Schade für mich.
Ich halte peeren für einfach. Wenn es bei manchen nicht funktioniert würde ich gerne helfen und verstehen.
Peeren ist eben nur peeren. Die aktion zu definieren ist ein zweiter Schritt. Alleine dies auseinander zu halten ist evtl schon der erste und wichtigste Schritt das system aufzusetzen
Weiter kann man auf register nicht immer verzichten. Rollo fahrtzeiten, rt regelparameter, und die reaktion der internen peers( so man vom Default abweicht - bei rollos für mich ein muss) geht nur mit registern.
Und exakt für Anwender wie dich sind templates gemacht ( ok, auch für mich). Du sagst, was das teil tun soll. Du bekommst ein template. Das spielst du ein. Dann weisst du es allen gewünschten devices zu. Der rest sind 2 kommandos zur Kontrolle und eines um die templates ggf wieder einzuspielen.
Register solltest du nicht mehr sehen.

[the ratman]

jo, wenns so einfach ist, bin ich voll dabei.
und gut, auch ich hab die fahrzeiten drinnen in den rollos, weil das halt gar nicht anders geht wenn man mehr als steinzeit will.

das beispiel mit der wetterstation ist da schon was anderes - zwar nicht nur ein reg/template-problem, aber so fangts halt immer an:
einfach, weil ich nicht mal so genau weiß, ob nun bei der neuen station die alten sachen gehen. obs generell nicht geht, vielleicht doch mit dem vorspiegeln der alten station, oder, oder, ...
weißt du, das is alles so wischi-waschi, was man sich da erst mal zusammensuchen muß. und wennst dann im forum fragst ob das nun geht oder nicht (mit extra neuen fred https://forum.fhem.de/index.php/topic,87924.msg803710.html#msg803710 ), kriegst 4 monate keine antwort. und da soll ich mich auch noch mit sachen spielen, die bis dahin schon bei "idealbedienungen" nie funktioniert haben?


du muß ich jetzt aber gleich - du zwingst mich ja quasi zu *bg*:

wenn ich jetzt sag, ich hab die HM-WDS100-C6-O-2 und würde gern ein template haben für einstellbare min und max windstärken, die dann an 2 virtuellen schaltern der vccu kleben - würd ich das so simpel bekommen von dir? ein template mit 4 zeilen info, was ich wie wo zu machen habe. dann noch Infos, was beim prüfen stehen sollte und was dort besser nicht stehen soll und du hast mich glücklich gemacht.

und weil ich dich schon dran hab und du es vielleicht weißt - kann man die wetterstation öfter senden lassen? ginge das auch? gibts da nen reg-eintrag für, oder gabs einen? gelesen hab ichs mal, gefunden in der reg nie wirklich. aber das sagt bei mir ja nix ...

[martinp876]

Jetzt habe ich keine wetterstation, es zu testen. Aber ich kann ein template erstellen das theoretisch funkioniert
Schicke mir doch ein regtable des aktuellen Zustands. Mal sehen, was ich zu stande bringe.

Ach ja, die roh Register wären noch interessant.
Hat das peeren funktioniert? Sollte eigentlich
Definiere einen vccu Kanal vccubtn1
Set wds100 peerChan 0 vccubtn1 single
Dann ein getconfig der wds. Schicken der roh register.

[the ratman]

hey super!

du meinst get reglist?

Code Auswählen Erweitern

list:         register | range              | peer     | description
   0: burstRx          |     literal        |          | device reacts on Burst options:off,on
   0: localResDis      |     literal        |          | local reset disable options:on,off
   0: pairCentral      |   0 to 16777215    |          | pairing to central
   1: sign             |     literal        | required | signature (AES) options:off,on
   1: stormLowThresh   |   0 to 200         | required | Storm lower threshold
   1: stormUpThresh    |   0 to 200         | required | Storm upper threshold
   1: sunThresh        |   0 to 255         | required | Sunshine threshold
   1: windSpeedRsltSrc |     literal        | required | wind result source options:average,max
   4: peerNeedsBurst   |     literal        | required | peer expects burst options:off,on

aber nochmal: das ist die neue Version "o2" der wetterstation. da hab nicht nur ich probleme mit den storm-regs.
kannst du hier im forum nachlesen. was nun aber wirklich geht oder nicht, weiß ich nicht. sagt ja jeder was anderes.

[curt]

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.

Ich bin die Zielgruppe.

Als Hauptproblem sehe ich (Dipl-Ing Verfahrensingenieurwesen, EDV/IT, BMSR) übrigens, dass praktisch sämtliche Vokabeln nicht mit dem bisherigen Vokabelraum übereinstimmen. Es ist wie das Erlernen einer neuen Fremdsprache - unter der erschwerenden Bedingung, dass man alle Vokabeln schon kennt - nur unter meist anderer Bedeutung.

Ich weiß, dass das jetzt bestritten werden wird. Das würde ich als Betriebsblindheit abbuchen wollen: FHEM wuchs mit verschiedensten IoT-Farmen und nahm immerzu von dort Vokabeln auf. Ich Anfänger (ein Jahr dabei) stehe staunend vor einem Wirrwarr an Vokabeln:

Devices sind gar keine, jedenfalls nicht immer. Die haben Kanäle, die aber keine sind. Ich paire und peere. Mit formaler Logik hat das nun wirklich nicht immer zu tun.

Für Anfängertexte wäre eine Übersetzung in den bisherig "normalen" Vokabelraum aus meiner Sicht sehr hilfreich.

[curt]

Ich werde nicht FHEM erklären. Mein Teil ist FHEM-Homeatic. Und auch hier habe ich nur die Basics bereitgestellt. Daher hatte ich das Einsteigerdoc verfasst welches aus meiner Sicht immernoch die beste Zusammenfassung und Einführung in HM darstellt.

Das heißt noch lange nicht, dass die gut ist. (Nein, mein Text wird kein Rant.)
Ich erzähle Dir (und allen anderen) mal wie ich zu FHEM kam.

Ich habe ein Haus. Und einen Beruf. Und ab und an Stress. Mehrfach kam es vor, dass unten ein Fenster offen stand ... da dachte ich: Ok, Fenstersensoren habe ich auch in der Firma. Leichte Sache, mache ich über Funk und lerne gleich was über dieses IoT. Etwas recherchiert - alle sagen: FHEM. Ok, leichte Sache. Aufsetzen und los.

Das (ja, homematic) funktioniert ganz fein. Die melden artig ob sie offen oder zu sind. Und irgendwo habe ich einen Code abgeschrieben, er mir auf einer Seite ein Icon zeigt, ob NUR EIN Fenster noch offen ist. - Ich habe nicht die geringste Ahnung, wie ich mit den Dingern irgend etwas schalten kann. Die normale Vokabel ist bei binären Systemen übrigens "schalten" - das ging bei FHEM verloren.

Dann fand ich, dass das sehr schön geht und ich auch noch Temperaturen überwachen könne. Oh, ich brauche da ein weiteres Dingsbums am USB des RPi. Und dann noch Steckdosen schalten. noch ein weiteres Dingsbums an einem weiteren Port des RPI. Ich kann Dir auf die Schnelle wirklich nicht sagen, welches der drei Dingsbumser für genau welches Protokoll zuständig ist. Das mag in der geheiligten Kirche von FHEM peinlich wirken - aber es ist so. Ich muss erstmal das Geld verdienen, welches ich dann für den ganzen Spaß ausgebe. Und Familie habe ich auch noch.

Wenn ich jetzt Deine weiteren Beiträge in diesem Thread lese, packt mich das kalte Grauen:
Ich habe 14 Tage gebraucht, um lausige drei Rauchmelder SD2 zu pairen und zu peeren. Und das lag wirklich nicht an mir (ich bin allen dankbar, die mir in diesem Thread quasi Mut zusprachen.).

Wenn Du mir nun erzählst, dass mit und nach dem peeren ... es ist vermutlich ein Schutzreflex: Ich kann nicht mehr. Faxen dicke. Ich bin heilfroh, dass das endlich tut, ich aktore da nichts mit reaktoren oder wie das auch immer heißen möge - danach ist es eh wieder kaputt. Und wenn ich dann im Forum frage, bekomme ich überhebliche Antworten, die den Antworter ins rechte Licht setzen, mir dummen Jungen aber zeigen, dass ich dumm bin. Brauche ich nicht so wirklich.

Oft habe ich große Lust, den ganzen nicht ganz billigen Scheiß aus dem Fenster zu hauen. Dann denke ich wieder: Hey, Du bist Dipl-Ing, das muss gehen.

Eins noch:
Im Forum (und im Wiki auch) fehlt es an Beispielen. Normale Menschen lernen dadurch, dass man ihnen am Beispiel zeigt, wie etwas geht. Ahhh, es geht! Großes Erfolgserlebnis. - Im Forum (zumindest empfinde ich das so) sind die Antworten aber sehr oft Klugscheißerei, die in die Richtung "ich gehe Dir einen verschlüsselten Hinweis, finde das easteregg!" gehen.

Ja, ok. Mein Text wurde doch ein Rant.
Zu meiner Entschuldigung sei gesagt: Ich schreibe nicht, weil ich keine Frisöse habe. Ich schreibe, weil ich FHEM sinnvoll nutzen und ausnutzen will. (Und anderen mal helfen, vielleicht.)

[martinp876]

Kritik ist immer gut. Konstruktive. Diene sehe ich so.
Das einsteigerdoc habe ich verfasst für hm einsteiger. Nicht für programmiereinsteiger. Ich setze also  voraus, dass der leser ein grundverständniss für eine ähnliche technik mitbringt. Hat er das nicht oder ist nicht bereit sich das anzueignen dann hätte ich grundsätzlich probleme ihm fhem zu empfehlen. Er würde sich m.e. aber auch mit allen andereb systemen schwer tun.
Warum dein pairen so schlecht funktioniert hat kann ich nicht beurteilen. Der sd2 braucht aes. Das ist nicht fhem default.

Da hm rf nun einmal ein funksystem ist bringt es einschränkungen mit. Die übertragung kann gestört sein. Der nachbar funkt rein. Batteriedevices müssen strom sparen. Man muss mit problemen umhehen können. Das kann man nur, wenn man ein verständnis aufgebaut hat oder aufbauen kann.

Leider sehe ich keinen weg, fas zu umgehen ohne rot zu werden

[Pfriemler]

@curt: Du hast bezüglich des Peerens natürlich ein absolutes Negativbeispiel erwischt. Normalerweise geht das beim ersten Mal, manches braucht (eigentlich nicht nachvollziehbar, aber das gehört zu den Dingen, über die nicht einmal nachzudenken aus meiner Sicht sich lohnt) ein zweites, ganz selten ein drittes Mal - meist hat man dann nebenher begriffen, was eventuell hinderlich war.
Zu Deinem Frust: FHEM ist ein Bastelsystem. Aus Deinen Schilderungen mit dem Umgang traue ich mich fast nicht zuzustimmen, dass Du mit anderen Systemen vermutlich schneller Erfolg haben wirst. Das ist keine Abwertung - jeder Mensch hat seine Qualitäten, und Deine liegen offenbar woanders als bei FHEM. Noch. Vor dem Berg haben wir alle mal gestanden. Konkret das peering ist auch für mich das Buch mit 7 Siegeln gewesen, aber zum Glück ist meine Lernkurve noch steil genug und mein Logikdenken noch hinreichend gut, dass ich mir die wesentlichsten Dinge diesbezüglich endlich gemerkt habe und nicht jedesmal in eine commandref sehen muss. Das betrachte ich als persönlichen Glücksfall, und wir sind hier unter uns diesbezüglich, bilden uns aber eigentlich nichts darauf ein. Und Bröckchen an die "weniger Bemittelten" hinzuwerfen ist nur selten üblich, oft genug dann aber als Wink mit dem Zaunpfahl, sich die unverzichtbaren Grundlagen anzulesen, ohne die FHEM immer ein Frusterlebnis bleiben wird.
Hat man diese Hürde erst einmal genommen, sind die Aha-Effekte umso schöner. Selbst wenn man sich nur Codezeilen von irgendwoher kopiert und sich freut, wenn sie das Gewünschte tun, ohne dass man verstanden hat wie. Bei einem Klickibunti-System versteht ja auch keiner, was dahinter steckt: Man wählt aus den gebotenen Möglichkeiten das passendste aus und erwartet, dass es so funktioniert.

Beispiele sind gerade für den Anfänger unverzichtbar. Die finde ich aber im Wiki immerhin ansatzweise und im Forum sind sie doch gerade bei Anfängerhilfen eher die Regel - man lässt sich als Helfer per "list" die Infos geben und zimmert daraus einen konkreten Lösungsbefehl, den der Fragesteller per copy&paste übernimmt - man wird hunderte solche Beispiele finden, wenn man danach richtig sucht. Denn die Forensuche ist diesbezüglich oft keine Hilfe, aber es gibt ja Google als Alternative. 

Über all dem sollten wir aber weiter überlegen, wie man das peeren generell vereinfachen kann. Sowohl die Modulidee als auch die von frank vorgeschlagenen set-Befehle sind gut und schließen sich für mich nicht gegenseitig aus. Neues entsteht nur wenn es angegangen wird. Damian und sein DOIF hat vieles für Anfänger vereinfacht, und Thorsten Pferdekämpers HMW-Bedienoberfläche ist ein kopierenswerter Ansatz.

[Wuppi68]

Hallo Curt,

bin zwar kein Dipl Ing aber kann trotzdem nachvollziehen was Du manchmal durchgemacht hast - war bei mir genauso.

Bei Homematic braucht es mehrere Klicks im Gehirn

Pairen/Peeren: Sieht gleich aus ist es aber nicht - Klick, verstanden - Kennzeichne ich in meinen Antworten meistens mit pAIren oder pEEren
Peeren von wo nach wo und wie überhaupt
Register
Statemachine


@ALL: Wenn Ihr Verbesserungen für die CommandRef habt - der Modulautor ist zu 99% dankbar dafür (siehe z.B. NMap bei der Adresseingabe)
das Wiki kann jeder ändern

[the ratman]

ich möchts aber nur erwähnt haben: lustiger weise hab ich den unterschied zw. pairen und peeren sofort verstanden gehabt und das als quasi vorzeige-noob *g*.
das problem ist eher: nach den div. anleitungen funzt es eher selten bis gar nicht und warum das so ist (um den eventuell begangenen fehler in zukunft vermeiden zu können) steht nirgends (zumindest hab ich nie was gefunden). ich will aber trotzdem keine 1000te anleitung weil:

mein hauptproblem ist da schon, dass ja nirgendwo ne (für noobs) lesbare bestätigung kommt. so nach dem motto: "du hast erfolgreich gepeert", oder "fehler beim peeren zw. gerät x und y [irgend ne brauchbare info]". da wären eben wieder die von mir so oft und nervig erwähnten infos am richtigen ort ...
meistens weiß man ja nicht mal, ob man nun selber blödsinn gemacht hat, sich einfach wo vertippt hat, die kombi zum peeren gar ned geht, man nur was verdreht hat, blaaa blubb blaaa und fragen will man nicht - da geht man gefahr wieder mal recht herablassen als lernunwilliger, gehirnamputierter dödel oder anderes abgestempelt zu werden. das brauch zumindest ich nicht täglich, dazu hab ich viel zu wenig masochistische anteile in meinen genen ... und nö, ich meine niemand hier aus diesem fred!

eig. würd fürs peeren - so viele geräte gibts nun auch wieder nicht - ja sogar ne dumme tabelle reichen ... was "offizielles" von einem, ders wirklich weiß und nicht nur behauptet.
1) gerät a geht mit gerät b in richtung xy mit folgender befehlsfolge
2) gerät b geht mit gerät c in richtung xy mit folgender befehlsfolge
3) ...

[Wuppi68]

eig. würd fürs peeren - so viele geräte gibts nun auch wieder nicht - ja sogar ne dumme tabelle reichen ... was "offizielles" von einem, ders wirklich weiß und nicht nur behauptet.
1) gerät a geht mit gerät b in richtung xy mit folgender befehlsfolge
2) gerät b geht mit gerät c in richtung xy mit folgender befehlsfolge
3) ...

du kannst jeden Sensor mit jedem Aktor peeren ...

also auch einen Wassermelder mit der Winmatic

[marvin78]

Da es nun doch viel rant gab, gibt es auch ein wenig rant zurück: Wenn manche Leute so viel Zeit dafür verwenden würden, sich in die Dinge und Begrifflichkeiten einzulesen, wie für das Beschweren über Helfer (die es tatsächlich fast immer gut meinen, selbst wenn sie angeblich kryptische Antworten geben (was sie natürlich nicht sind, es sind einfach nur Antworten, die davon ausgehen, dass die Basics vorhanden sind oder das jemand in der Commandref oder im Forum suchen kann)), dann hätten wir kein Problem.

Es wird immer diese zwei unterschiedliche Meinung geben:

1. FHEM ist nichts für un-ambitionierte Menschen, die ein System benötigen, dass Out-of-the-box oder mit wenig Aufwand läuft. FHEM ist aber sehr brauchbar, wenn man gewillt ist, sich rein zu denken und etwas bis sehr viel Arbeit rein zu stecken. Macht man das, ist es auch sehr einfach.

2. FHEM muss auch für solche Leute  alles bieten, die ein Klicki-bunti System und die Dinge, die passieren, nicht verstehen möchten. Die freiwilligen Helfer und Entwickler müssen genau für solche Leute da sein und das auch noch ohne zu murren. Sie müssen immer freundlich reagieren und jeden Fragesteller hinten rum heben, damit er sich geliebt fühlt. Jemandem zu sagen, dass er mit einem Begriff die Suche in der commandref nutzen und dann mit konkreten Fragen wieder kommen soll, ist eine Beleidigung.

Erstes trifft vermutlich zu. Ich persönlich mag alles an FHEM, wie es ist, da mit convenience im Grunde immer Probleme entstehen, die man in einem gewissen Umfeld nicht haben möchte, wenn man etwas differenzierter darüber nachdenkt. Jedes System hat seine Zielgruppe. Ob man nun Ingenieur ist oder nicht, es geht nicht um den Bildungsgrad. Ein ambitionierter Maurer kommt mit FHEM ggf. besser zurecht als ein wenig ambitionierter Techniker (oder was auch immer). Wer mehr convenience benötigt, möge es einbauen, jemanden bezahlen, der das tut, jemanden überzeugen, der das tut oder aber ein anderes System verwenden. Meckern ist wenig hilfreich...

Ich übertreibe bewusst ein wenig.

[the ratman]

du kannst jeden Sensor mit jedem Aktor peeren ...

ja, aber sicher kein zwave-gerät mit einem von eq3 - das meinte ich mit "nicht gar so viele geräte".
gut, dann teilen wir halt die geräte ein nach - was weiß ich - richtungen zum peeren und - so dir der ausdruck lieber ist - sinnhaftigkeit/häufigkeit des peerens.

Die freiwilligen Helfer und Entwickler müssen ~snip

nö, müssen tun sie gar nichts. aber wenn sies für alle tun, dann sollte es halt auch für alle sein. wenn sies nur für bestimmte gruppen tun wollen, dann doch bitte auch gleich ein kleines kleberchen drauf: "nichts für weicheier" (oder was immer dir dann gefällt).

Meckern ist wenig hilfreich...

ich hoffe, du hällts meine ergüsse nicht für meckern ... ich hoffe nur auf einen schulterschluss aller kriegsparteien *g*. für micht ist halt die idee eines etwas noob-freundlicheren hm-systems (wobei mich z.b. wirklich nur das peering stört, der rest geht ja wunderbar) der gangbarere weg. weil eines steht fest: die fragenden wirst immer haben und grade du wirst immer und immer wieder die selben fragen beantworten dürfen - bis dir irgendwann mal der geduldsfaden reißen wird. da find ich das vorwegnehmen von problemen als einfacher. das muß man nur einmal machen und hat dann seine ruhe. glaubs mir, ich red da aus erfahrung - nicht nur ihr programmierer habts dieses problem ...

[Benni]

also auch einen Wassermelder mit der Winmatic

... also wird wenn im Keller die Waschmaschine ausläuft, direkt die Kellertür geöffnet, damit das Wasser auch schnellstmöglich abfließen kann (SCNR)

Aber BTT:

du kannst jeden Sensor mit jedem Aktor peeren ...

Genau genommen sind es die Kanäle, die gepEErt werden und zwar i.d.R. Sensor-Kanäle mit den Aktorkanälen. Was hier vielfach Verwirrung stiftet ist wahrscheinlich, dass der Anfänger diese Kanäle erst mal gar nicht wahrnimmt, da sie bei den einfachen Sensoren (Bspw. HM-SEC-SC-2) und bei einfachen Aktoren (Bspw. HM-LC-SW1-FM) gar nicht zu sehen sind. Diese Geräte haben jeweils nur einen Kanal, so gesehen sind die Geräte selbst auch gleichzeitig der Kanal.

Beim PEEren gibt es so eine Art Peer-Richtung (betreffend den Aufruf des set peerChan-Befehls), dort wird i.d.R. zuerst der Sensorkanal genannt und dann der Aktorkanal, so gesehen wird vom Sensor auf den Aktor gepEErt. Das kann man sich eigentlich ganz leicht merken, denn die Benachrichtigungsrichtung ist nachher im Betrieb ja auch immer die, dass der Sensor den Aktor über eine Zustandsänderung informiert.

Andere Geräte haben mehrere Kanäle wie bspw. das Wandthermostat (HM-TC-IT-WM-W-EU) und der Heizungsregler (HM-CC-RT-DN). Hier kann ich sinnvollerweise jeweils die beiden _Climate und die beiden _Weather-Kanäle miteinander peeren, damit kann über den Wandthermostat dann der Heizungsregler sinnvoll gesteuert werden (und umgekehrt!) Die Peer-Richtung ist in diesem Fall grundsätzlich egal!
ABER: Ich kann hier auch einen einfachen Fensterkontakt (oben gelernt: Gerät ist in dem Fall = Kanal) mit dem _WindowRec (=Fenstererkennung) -Kanal des Wandthermostates pEEren, damit das weiß wann ein Fenster offen ist und darauf hin die Temperatur auf die Fensteroffen-Temperatur festsetzt (normalerweise 12°C) und dies bei nächster Gelegenheit dann dem Heizungsregler mitteilen kann damit der entsprechend den Heizkörper regelt (=schätzungsweise erst mal Ventil schließen).
NOCH EIN ABER: Ich kann genauso gut den Fensterkontakt (Gerät=Kanal) mit dem _WindowRec-Kanal des Heizungsreglers direkt pEEren, damit weiß dann der Heizungsregler beim Fensteröffnen sofort, was zu tun ist und muss nicht erst auf die "Ansage" des Wandthermostates warten.
Genau genommen würde ich einen Fensterkontakt immer mit beidem Peeren, dem Wandthermostat UND dem Heizungsregler (also natürlich den jeweiligen _WindowRec-Kanälen )

Ich habe das jetzt mal absichtlich versucht sehr Bildhaft zu beschreiben, damit vielleicht manchem doch noch die eine oder andere Vokabel etwas verständlicher wird. Das lässt sich natürlich auf andere Geräte und deren Kanäle übertragen.

Was ich am Anfang zum Beispiel nicht geblickt habe ist, dass bei Geräten, die mehrere Buttons haben (HM-PB-6-WM55 = 6 Kanäle) i.d.R. meist gleich  Button-Paare (=Kanalpaare also _Btn1+_Btn2 / _Btn3+_Btn4 ...) ver-pEErt werden und nicht die einzelnen Buttons.

Was hier weiterhin noch oft Probleme macht sind die Begrifflichkeiten (Vokabeln) Gerät, bzw. Device. Es gibt einmal das Gerät als physikalisches Gerät (im Englischen auch ein Device) und dann gibt es das entsprechende Abbild in FHEM, dort immer Device genannt. Bei Geräten, die Mehrere Kanäle haben, besteht das Abbild in FHEM aus dem Device selbst (=Haupt-Device) und den einzelnen Kanälen, die zum Einen in den Internals des Devices eingetragen sind UND die Ebenfalls auch als Devices in FHEM abgebildet sind. Diese sind normalerweise aber nicht sichtbar, können aber durch einen Klick auf den Namen des Kanals in den Internals des Hauptdevices angezeigt werden, zum Anderen aber auch durch Zuweisung eines Raums im room-Attribut, ganz normal als Device in der Raumübersicht dargestellt werden.
Es handelt sich bei dieser Repräsentation in FHEM quasi um eine hierarchische Abstufung zwischen Haupt-Device und dessen Unter-Devices (=Kanäle)

Zu guter letzt ist ein weiterer Fallstrick der, dass das was durch die Benachrichtigung einer Zustandsänderung passieren soll ("was soll der Aktor machen, wenn der Sensor ihm auf dem gepEErten Kanal-Weg was meldet") im Aktor festgelegt und gespeichert wird und nicht im Sensor. Damit wären wir dann auch bei den State-Machines und den Templates angekommen. Sensoren selbst sind grundsätzlich erst mal dumm.

Ich hoffe, ich habe hier in Wirklichkeit keinen Stuss erzählt, aber das ist mein Verständnis vom Peeren, Kanälen und Devices und damit bin ich bisher immer zurecht gekommen. (Wie ich weiter oben schon geschrieben habe "Verständnis in der Anwendung") Vielleicht kommt damit ja auch jemand anders besser zurecht.

gb#

[Benni]

ja, aber sicher kein zwave-gerät mit einem hm

Dass es hier erst mal NUR um HM geht sollte aber schon klar sein!

[the ratman]

Ich habe das jetzt mal absichtlich versucht sehr Bildhaft zu beschreiben, damit vielleicht manchem doch noch die eine oder andere Vokabel etwas verständlicher wird.

hätt ich nicht gedacht, aber ich muß benny doch mal loben *g*.
sind nette beschreibungen, die verdammt verständlich auch für techn. schwachmaten kommen. wäre ein netter ansatz zum helfen ...

Ich hoffe, ich habe hier in Wirklichkeit keinen Stuss erzählt,

wenn doch, dann hast du zumindest gezeigt, wie es beschrieben werden könnte, um größeres Verständnis hervorzubringen. für die ganz dummen könnte man das dann sogar noch schematisch ein bissi aufzeichnen.

[marvin78]

ja, aber sicher kein zwave-gerät mit einem von eq3 - das meinte ich mit "nicht gar so viele geräte".
gut, dann teilen wir halt die geräte ein nach - was weiß ich - richtungen zum peeren und - so dir der ausdruck lieber ist - sinnhaftigkeit/häufigkeit des peerens.
nö, müssen tun sie gar nichts. aber wenn sies für alle tun, dann sollte es halt auch für alle sein. wenn sies nur für bestimmte gruppen tun wollen, dann doch bitte auch gleich ein kleines kleberchen drauf: "nichts für weicheier" (oder was immer dir dann gefällt).
ich hoffe, du hällts meine ergüsse nicht für meckern ... ich hoffe nur auf einen schulterschluss aller kriegsparteien *g*. für micht ist halt die idee eines etwas noob-freundlicheren hm-systems (wobei mich z.b. wirklich nur das peering stört, der rest geht ja wunderbar) der gangbarere weg. weil eines steht fest: die fragenden wirst immer haben und grade du wirst immer und immer wieder die selben fragen beantworten dürfen - bis dir irgendwann mal der geduldsfaden reißen wird. da find ich das vorwegnehmen von problemen als einfacher. das muß man nur einmal machen und hat dann seine ruhe. glaubs mir, ich red da aus erfahrung - nicht nur ihr programmierer habts dieses problem ...

Du warst nicht angesprochen...

Aber zu deinem "Gruppensupport": Es geht nicht darum, "Weicheier" auszusortieren, sondern darum, dass man als Helfer Hilfe beim Helfen benötigt. Es gibt jedoch Leute, die sind schon beleidigt, wenn man mehr Informationen von Ihnen verlangt, als sie zunächst geliefert haben und das nicht mit 23 Bitte und Danke garniert. Auch helfe ich ungern Leuten, die ihr Posts einleiten mit "Ich bin Anfänger..." oder "Ich kann programmieren, will mich aber nicht mit Perl rumschlagen..." und dann einen Post schreiben, der ganz klar zeigt, dass nie in die Doku geschaut wurde. Anfänger darf es geben, eine Entschuldigung für Faulheit ist es aber nicht. Auch bin ich der Meinung, dass man solchen Leuten sagen muss, dass sie das Thema falsch angehen. Ach und: Die Arbeit wurde meist schon vorweg genommen. Es gibt nicht viel, das nicht dokumentiert ist oder hier im Forum steht.

Die Frage, die man sich stellen muss: Welche Motivation haben Entwickler und Helfer, zu FHEM beizutragen!? Ist es die, ein "noob-System" zu bauen oder die, ein sehr gutes System noch besser zu machen und ggf. breiter aufzustellen? Wovon hat der Entwickler oder der Helfer ggf. auch selbst etwas? Welche Motivation hat er überhaupt, etwas beizutragen? Die Antwort darauf ist nicht: Jeder "noob" soll glücklich sein.

Es gibt eben hier viele Menschen, die fordern Dinge, die andere nicht leisten können oder wollen, weil es für sie selbst nicht sinnvoll ist und dazu noch einen riesigen Aufwand bedeutet. Ich kann aktuell nur mich als Beispiel nehmen: Als ich ein Modul für wunderlist benötigt habe (später todoist), habe ich keinen Wunschzettel an andere geschrieben sondern ich habe Perl gelernt, mich mit den FHEM Developer Guidelines und der API beschäftigt und danach bzw. dabei etwas gebaut. Und ich gehöre auch zu den Menschen, die eine 60-70 Stunden Woche UND Familie haben. Wenn man den fordernden Leuten aber sagt, dass sie sich ja auf den Hosenboden setzen können, dann erlebt man meist eine große Schimpftirade. Eine Schimpftirade, die so lang, ist, dass man in der Zeit dreimal Perl lernen könnte...

Und ja, HM komplett zu verstehen ist nicht leicht, FHEM zu verstehen ist nicht leicht, ABER es ist auch nicht so schwer, wie es auch in diesem Thread erzählt wird. Es ist auch nicht so durcheinander oder konfus, wie teilweise beschrieben. Auch ist es nicht schlecht dokumentiert. Im Gegenteil. Für die Art und Größe des Projekts, ist es außerordentlich gut dokumentiert. Es ist eine Frage der Perspektive.

[martinp876]

Fhem ist nach meinem verständniss als offenes system gedacht. Hm ist der kommunikationslayer, so entworfen und gebaut. Alles was möglich ist kann man machen auch wenn sinnlos.
Hminfo ist ein vierel Layer darüber. Hier wird aiuf grobe fehler hin geprüft.

Nun komme ich wieder zu templates. Das ist einen halben layer weiter. Nein, eigentlich ein ganzer. Wenn auch nur ein teil des layers.
Will sagen: die frage ob das peeren funktioniert hat und auch noch bestand hat wird über templates unterstützt und über hminfo config check verifiziert.
Pairen und peeren ist im wiki erklärt.

Unschön ist immer im forum zu suchen. Da sind viele varianten, auch falsche oder ungrschickte enthalten. Im wiki sollte das sinnvolle vorgehen stehen.
Wiki ist  granular aufgebaut. Hier sollte strickt mit verweisen gearbwitet werden. Ich schaue nicht oft rein. Persönlich bekomme ich aber die Kriese wenn in jedem device das peeren erklärt wird. Und jedes mal leicht unterschiedlich.

Der ambitionierte bestler findet einen weg. Leider jeder 3. einen anderen.
Mein Resümee: die doku in Wiki muss strukturiert werden. Ein starter guide hm existiert nur partiell.
Anäm ende muss ein admin einer heiminstallation aber immer zeit investieren und ein Konzept entwickeln. Ein selbst läufer ist das vernetzte System nie.

[Bison]

Hallo zusammen,

ich traue mich in diesen Tread fast nichts zu schreiben, weil es nur Hero-Member sind. Aber nachdem ich nun eine ganze Woche (gefühlt 100 Km zwischen meinen Devices hin und her gerannt bin) mit peeren/ Missing Register/ Peer not befinde usw. zugebracht habe, möchte ich den Beitrag von Benni loben. Er hat das für einen Anfänger wie mich ganz gut beschrieben.

Ich glaube das jemand als Hero-Member manchmal zu weit von dem Problem eines Anfänger entfernt ist. Daher sollten gerade die Anfänger sich gegenseitig helfen (Einbeiniger sucht Einbeinge zum Paartanz).

Meine Anregung daher:

Jede Nutzergruppe (Skillbasierend)  sollten Aktiv Tread bewerten (1-5) die ihnen weiter geholfen haben. Damit könnte man nach und nach die Anleitungen für jede Skillgruppe verbessern (die Beschreibungen oder Lösungen mit der Wertung 1 werden in den Tread nach vorne gebracht).

Gruß

Bison

[Prof. Dr. Peter Henning]

Ganz falscher Weg.

Wenn zwei Anfänger sich gegenseitig helfen, kann das ganz gut sein - kann aber genauso gut zu einer vollkommen wirren Installation führen, die nicht mehr zu retten ist. Und es ist weder vorhersagbar, noch kontrollierbar, wie das Ergebnis sein wird.

Das ist übrigens auch meine Erfahrung aus 45 Jahren Erwachsenenbildung: Unüberwachtes Peer-Lernen von Unwissenden birgt die Gefahr des Abirrens.

Der richtige Weg ist: Durch Experten solche Texte zu verfassen, dass diese auch für Anfänger geeignet sind.

LG

pah

P.S.: Übrigens, es heißt Thread, nicht Tread - das macht von der Bedeutung einen wesentlichen Unterschied.