Autor Thema: Peeren und wie man es vermitteln kann  (Gelesen 1481 mal)

Offline martinp876

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 10316
Antw:Peeren und wie man es vermitteln kann
« Antwort #30 am: 10 August 2018, 08:57:29 »
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

Offline Pfriemler

  • Hero Member
  • *****
  • Beiträge: 2627
  • geht nich gips nich
Antw:Peeren und wie man es vermitteln kann
« Antwort #31 am: 10 August 2018, 09:45:10 »
@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.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Jessie@Raspi(2), HMLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Offline Wuppi68

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1697
  • Wuppertaler Wimpelbeauftragter
Antw:Peeren und wie man es vermitteln kann
« Antwort #32 am: 10 August 2018, 10:06:03 »
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
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

Offline the ratman

  • Hero Member
  • *****
  • Beiträge: 1668
  • cosmoprolet & intelligenzdiabetiker
Antw:Peeren und wie man es vermitteln kann
« Antwort #33 am: 10 August 2018, 13:01:03 »
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) ...
« Letzte Änderung: 10 August 2018, 13:06:17 von the ratman »
→do↑p!dnʇs↓shit←

Offline Wuppi68

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1697
  • Wuppertaler Wimpelbeauftragter
Antw:Peeren und wie man es vermitteln kann
« Antwort #34 am: 10 August 2018, 13:20:30 »
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
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

Online marvin78

  • Hero Member
  • *****
  • Beiträge: 5230
Antw:Peeren und wie man es vermitteln kann
« Antwort #35 am: 10 August 2018, 13:32:14 »
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.
Zustimmung Zustimmung x 2 Liste anzeigen

Offline the ratman

  • Hero Member
  • *****
  • Beiträge: 1668
  • cosmoprolet & intelligenzdiabetiker
Antw:Peeren und wie man es vermitteln kann
« Antwort #36 am: 10 August 2018, 14:16:15 »
Zitat
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.

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

Zitat
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 ...
« Letzte Änderung: 10 August 2018, 14:33:56 von the ratman »
→do↑p!dnʇs↓shit←

Offline Benni

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1852
  • FHEMinist
Antw:Peeren und wie man es vermitteln kann
« Antwort #37 am: 10 August 2018, 14:21:04 »
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 ;D (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#
« Letzte Änderung: 10 August 2018, 15:07:21 von Benni »
FHEM (FL 9.9) (configDB+DbLog) auf Debian Wheezy.
Jede Menge HM mit 2x HMUART (WeMos+esp-link) über VCCU.
UniRoll an CUL868. Sebury F2-2 RFID über ESPEasy
Module: 98_rssFeed und 98_QRCode

Offline Benni

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1852
  • FHEMinist
Antw:Peeren und wie man es vermitteln kann
« Antwort #38 am: 10 August 2018, 14:21:54 »
ja, aber sicher kein zwave-gerät mit einem hm

Dass es hier erst mal NUR um HM geht sollte aber schon klar sein!
« Letzte Änderung: 10 August 2018, 14:28:21 von Benni »
FHEM (FL 9.9) (configDB+DbLog) auf Debian Wheezy.
Jede Menge HM mit 2x HMUART (WeMos+esp-link) über VCCU.
UniRoll an CUL868. Sebury F2-2 RFID über ESPEasy
Module: 98_rssFeed und 98_QRCode

Offline the ratman

  • Hero Member
  • *****
  • Beiträge: 1668
  • cosmoprolet & intelligenzdiabetiker
Antw:Peeren und wie man es vermitteln kann
« Antwort #39 am: 10 August 2018, 14:40:03 »
Zitat
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 ...
Zitat
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.
« Letzte Änderung: 10 August 2018, 14:42:26 von the ratman »
→do↑p!dnʇs↓shit←

Online marvin78

  • Hero Member
  • *****
  • Beiträge: 5230
Antw:Peeren und wie man es vermitteln kann
« Antwort #40 am: 10 August 2018, 14:48:45 »
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.
« Letzte Änderung: 10 August 2018, 15:05:17 von marvin78 »
Gefällt mir Gefällt mir x 4 Zustimmung Zustimmung x 1 Liste anzeigen

Offline martinp876

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 10316
Antw:Peeren und wie man es vermitteln kann
« Antwort #41 am: 10 August 2018, 15:13:46 »
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.
Gefällt mir Gefällt mir x 1 Liste anzeigen

 

decade-submarginal