Wo stellt man Fragen, wenn man ein Modul entwickeln möchte

ujaudio · 31 Dezember 2017, 06:14:31

FHEM ist durchaus gut dokumentiert, manchmal dauert es nur etwas, bis man die Infos findet, die man benötigt. Doch nicht immer findet man eine Antwort auf alle Fragen. Doch wo im Forum stellt man diese dann am besten?
Konkret:
Ich habe ganz viel über Readings gefunden. Eine Frage habe ich aktuell aber noch: muss man ein Reading definieren? Oder wird es beim ersten Verwenden angelegt und danach nur noch aktualisiert?

Ich arbeite eigentlich nicht so gerne nach der "Versuch macht kluch"-Methode. Und manches Wissen wird vermutlich vorausgesetzt (bewusst oder unbewusst), welches ich möglicherweise nicht habe.

CoolTux · 31 Dezember 2017, 06:49:20

Wenn Du den Developer Status hast kannst Du im entsprechenden Forum posten.
Ansonsten kannst du auch versuchen in einem allgemeinen Forum etwas zu posten.

Es gibt auch sowas wie ein inoffizielles Mentorenprogramm. Du suchst Dir einen Entwickler Deines Vertrauens und schreibst ihn an ob er Lust und Zeit hat Dein Mentor zu sein. Dann kannst Du ihn alle Fragen fragen.

Grüße

Icinger · 31 Dezember 2017, 07:10:59

Readings musst du nicht erst extra anlegen.
Beim ersten readingsSingleUpdate oder readingsBeginUpdate....readingsBulkUpdate....readingsEndUpdate werden die in den Hash gelegt und ab diesem Zeitpunkt auch angezeigt.

lg, Stefan

betateilchen · 31 Dezember 2017, 11:00:37

Als erstes solltest Du die aktuellen Development-Guidelines lesen. Da werden eine Menge Fragen bereits beantwortet.

Ansonsten hilft auch immer mal ein Blick in die zentrale Datei fhem.pl

ujaudio · 31 Dezember 2017, 11:42:05

Zitat von: betateilchen am 31 Dezember 2017, 11:00:37
Als erstes solltest Du die aktuellen Development-Guidelines lesen...

Darf ich fragen wo die stehen? ich kenne das Wiki, z.B. https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Die_wichtigsten_Funktionen_in_einem_Modul, bzw. https://wiki.fhem.de/wiki/Kategorie:Development. Gibt es noch weiteres?

CoolTux · 31 Dezember 2017, 11:43:09

https://wiki.fhem.de/wiki/DevelopmentModuleIntro

betateilchen · 31 Dezember 2017, 12:45:15

[/offtopic]

Ich bin dafür, einen Eignungstest für Entwickler einzuführen, bevor künftig irgendwas Neues ins offizielle repository eingecheckt werden darf. Vieles von dem, was dort in den letzten Wochen gelandet ist, ist einfach nur noch haarsträubend.

Testaufgaben:

Findet der Kandidat die existierende Entwicklungsdokumentation?
Kennt der Entwickler die Tasten "Punkt" und "Komma" für eine sinnvolle Interpunktion in seinen Forumbeiträgen?
Kennt der Entwickler sogar schon die Umschalttaste für klein- und GROSSbuchstaben?
...

[/offtopic]

CoolTux · 31 Dezember 2017, 12:48:54

Punkt 1 sollte für ein Entwicklerstatus ausreichend sein. Alles andere ist Forenfreundlichkeit.

vbs · 31 Dezember 2017, 12:51:53

Aber dann bitte auch ein paar Prüfpunkte zum Thema soziale Kompetenz mit aufnehmen...

betateilchen · 31 Dezember 2017, 12:53:27

Zitat von: vbs am 31 Dezember 2017, 12:51:53
Aber dann bitte auch ein paar Prüfpunkte zum Thema soziale Kompetenz mit aufnehmen...

Gute Idee.

herrmannj · 31 Dezember 2017, 12:57:50

[auch offtopic]
naja, so böse sehe ich das nicht. Aber (da bin ich voll bei Betateilchen): im svn finden sich mittlerweile einige module bei denen ich das Gefühl habe das sie eingechecked werden sobald sie (mehr oder weniger) ohne Meldungen zu starten scheinen. Performance, Fehlerfrei, best-practice etc sind da nicht.

Da durch die fhem Architektur aber die komplette Installation betroffen ist wenn ein einzelnes modul lahmt oder aussteigt ist die Gefahr einfach Frust für newcommer. Als newcommer schaust Du in die Doku, siest ein modul für "super-duper-blub" installlierst das und wenn es dann klemmt ist FHEM "doof".

Das ist nichts gegen Neu-Programmierer (explizit auch nichts gegen ujaudio!!! - wir haben ja alle mal angefangen).

Ich bin dafür so wie bei perl (FHEM-) core Module zu benennen die dann gut sicher und stabil laufen müssen (ohne externe Abhängigkeiten. Keine CPAN Module ausser einer kleinen, vordefinierten Liste, Qualitiätssicherung! . Andere Module werden als "non-core" (oder wie auch immer) gegekennzeichnet. Damit hat man eine Orientierung.

Was Core wird, darüber wird dann gemeinsam entschieden.
[/auch offtopic]

ujaudio · 31 Dezember 2017, 13:00:50

Zitat von: betateilchen am 31 Dezember 2017, 12:45:15
[/offtopic]

Findet der Kandidat die existierende Entwicklungsdokumentation?
[/offtopic]

Inwiefern ist das jetzt auf mich gemünzt? Ich habe zwar noch nicht alles gelesen (und das was ich gelesen habe auch noch nicht wirklich zu 150% verstanden), aber außer dem Wiki, dem Forum und der commandref kenne ich nichts. Und vieles steht dort nicht, sondern man muss es sich erarbeiten. Das ist erst einmal auch ok!!! Was ich mir erarbeitet habe, habe ich verstanden und das kann ich mir auch ganz gut merken. Aber manchmal tüftelt man an einer Herausforderung lange herum und ist vielleicht sogar auf der falschen Fährte. Da ist es dann angenehm, wenn man auf eine Frage einen guten Hinweis (keine Lösung) bekommt, der einem weiterhilft.

Beispiel: Wenn ich mit FHEM meinen Oppo steuere, dann gibt es theoretisch den Fall, dass mein kleiner Enkelsohn sich am Regal hochzieht und den Oppo ausschaltet. Davon weiß FHEM leider erst einmal nichts. Lösen kann ich das mit einem "at", welches regelmäßig prüft ob der Oppo noch "on" ist oder "absent". Ich würde es aber gerne innerhalb des Moduls lösen. Naja, ich habe von den 20 cm PERL-Literatur auch erst 2-3 cm durchgearbeitet, da wird sich schon noch was finden lassen.

ujaudio · 31 Dezember 2017, 13:06:46

Zitat von: herrmannj am 31 Dezember 2017, 12:57:50
[auch offtopic]
naja, so böse sehe ich das nicht. Aber (da bin ich voll bei Betateilchen): im svn finden sich mittlerweile einige module bei denen ich das Gefühl habe das sie eingechecked werden sobald sie (mehr oder weniger) ohne Meldungen zu starten scheinen. Performance, Fehlerfrei, best-practice etc sind da nicht.

Da durch die fhem Architektur aber die komplette Installation betroffen ist wenn ein einzelnes modul lahmt oder aussteigt ist die Gefahr einfach Frust für newcommer. Als newcommer schaust Du in die Doku, siest ein modul für "super-duper-blub" installlierst das und wenn es dann klemmt ist FHEM "doof".

Das ist nichts gegen Neu-Programmierer (explizit auch nichts gegen ujaudio!!! - wir haben ja alle mal angefangen).

Ich bin dafür so wie bei perl (FHEM-) core Module zu benennen die dann gut sicher und stabil laufen müssen (ohne externe Abhängigkeiten. Keine CPAN Module außer einer kleinen, vordefinierten Liste, Qualitiätssicherung! . Andere Module werden als "non-core" (oder wie auch immer) gekennzeichnet. Damit hat man eine Orientierung.

Was Core wird, darüber wird dann gemeinsam entschieden.
[/auch offtopic]

100% Zustimmung! Ich möchte ja mein Modul so schreiben, dass es richtig gut funktioniert, z.B. einschließlich des Abfangens aller möglicher Sonderfälle. Gerade auch Performance-Aspekte sind wichtig. Worauf es da ankommt, habe ich (als Neuling von perl und mit meinem unzureichenden Wissen über die Interna von FHEM) eben keine Ahnung. Das habe ich auch noch nirgends kompakt in der Doku gefunden (obschon es da durchaus Hinweise an verschiedenen Stellen gibt).

betateilchen · 31 Dezember 2017, 13:13:08

Zitat von: ujaudio am 31 Dezember 2017, 13:00:50
Inwiefern ist das jetzt auf mich gemünzt?

Überhaupt nicht.

Deshalb ist mein Text auch eindeutig als "offtopic" gekennzeichnet.
Es handelt sich um ein allgemeines, aber immer größer werdendes Problem, für das es bald eine Lösung geben muss, bevor FHEM komplett "kaputtprogrammiert" (wie auch schön von hermannj beschrieben) wird.

Es ist in aller Regel einfach nicht sinnvoll, irgendein vorhandenes Modul zu kopieren, ein paar Codezeilen anzupassen und dann als eigenes Modul einzuchecken.

Zitat von: herrmannj am 31 Dezember 2017, 12:57:50
Ich bin dafür so wie bei perl (FHEM-) core Module zu benennen die dann gut sicher und stabil laufen müssen (ohne externe Abhängigkeiten. Keine CPAN Module ausser einer kleinen, vordefinierten Liste, Qualitiätssicherung! . Andere Module werden als "non-core" (oder wie auch immer) gegekennzeichnet. Damit hat man eine Orientierung.

Sehr gute Idee

rudolfkoenig · 31 Dezember 2017, 13:14:51

Ich bin auch fuer eine Einstiegshuerde, aber die Bedingungen muessen generell akzeptiert und niedergeschrieben werden. Vorschlag zur Diskussion (die Punkte stammen urspruenglich nicht von mir):
- Entwickler-in-Spe postet sein Modul in dem passenden Forums-Bereich
- Das Modul muss bei mindestens einem weiteren Benutzer über mehrere Tage funktionieren.
- Mindestens ein eingetragener Entwickler muss sein OK geben, nachdem er die Quellen durchgelesen hat.
Erst danach erhaelt der Entwickler-in-Spe den Zugang.

Und ich haette auch gerne zusaetzliche Pruefungen (die man am besten maschinell durchfuehren kann), um Module als problematisch zu kennzeichnen, oder gar das Einchecken zu verweigern.