Peeren und wie man es vermitteln kann

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

Vorheriges Thema - Nächstes Thema

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

ZitatLeider 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.
→do↑p!dnʇs↓shit←

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

#23
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*.
→do↑p!dnʇs↓shit←

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 ...
→do↑p!dnʇs↓shit←

martinp876

#26
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?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.
→do↑p!dnʇs↓shit←

curt

Zitat von: Prof. Dr. Peter Henning am 02 August 2018, 20:08:07
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.
RPI 4 - Jeelink HomeMatic Z-Wave

curt

Zitat von: martinp876 am 04 August 2018, 06:03:42
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.)
RPI 4 - Jeelink HomeMatic Z-Wave