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.
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
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
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
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 (https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Die_wichtigsten_Funktionen_in_einem_Modul), bzw. https://wiki.fhem.de/wiki/Kategorie:Development (https://wiki.fhem.de/wiki/Kategorie:Development). Gibt es noch weiteres?
https://wiki.fhem.de/wiki/DevelopmentModuleIntro
[/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]
Punkt 1 sollte für ein Entwicklerstatus ausreichend sein. Alles andere ist Forenfreundlichkeit.
Aber dann bitte auch ein paar Prüfpunkte zum Thema soziale Kompetenz mit aufnehmen...
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.
[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]
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.
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).
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 :)
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.
Zu offtopic: Gute Diskussion, gute Vorschläge - aber offtopic - Neue Diskussion im Developerforum?
@ujaudio: Du kannst im Midul einen Timer definieren - das ist in der Doku beschrieben (oder du schaust wie existierende Module das machen)
Timer? Readings werden beim ersten verwenden automatisch angelegt.
Timer war bezogen auf:
Zitat von: ujaudio am 31 Dezember 2017, 13:00:50
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.
Alles klar. Absolut richtig, Timer ist die korrekte Empfehlung 😀
Die selben Punkte hatte wir vor ein einhalb Jahren schon mal zur Diskussion.
Ich befürworte sie.
Zitat- Das Modul muss bei mindestens einem weiteren Benutzer über mehrere Tage funktionieren.
Täusche ich mich, oder steht dass nicht eh irgendwo in den Anforderungen für den SVN-Zugang.
Zitat von: KernSani am 31 Dezember 2017, 13:21:49
Zu offtopic: Gute Diskussion, gute Vorschläge - aber offtopic - Neue Diskussion im Developerforum?
@ujaudio: Du kannst im Midul einen Timer definieren - das ist in der Doku beschrieben (oder du schaust wie existierende Module das machen)
Das LGTV_WebOS Modul macht von Timern anständig gebrauch.
Hallo zusammen,
ich hoffe ihr hattet einen guten Rutsch in das Jahr 2018 und verbinde dies mit guten Wünschen an euch für dasselbe, vor allen Gesundheit und Frieden, sowie das notwendige Glück - alles Dinge, die man sich nicht kaufen oder erarbeiten kann.
Ich möchte hier nun 2 Fragen stellen. Die erste bezieht sich ganz allgemein auf "gutes Programmieren". Ich habe zwei Unterprogramme - jeweils übernommen und für meine Zwecke angepasst ;) einmal gibt es am Ende ein
return undef;
ein andermal nicht. Was ist denn nun die bessere Programmierung? Die Funktion ist in beiden Fällen die gleiche, zumindest kann ich keine Unterschiede im Ablauf feststellen, wenn ich es mal so und mal anders mache.
Die 2. Frage: Wo finde ich eine gute, kompakte und übersichtliche Erklärung für Einsteiger, wie die Kommunikation (allgemein, bzw. mit perl) abläuft?
Hintergrund der Frage (nur für den Fall, dass es hilfreich ist, wo ich mich einlesen sollte): wenn ich mit FHEM ein Kommando an den Oppo sende und alles ist gut dann wird nach der WriteFn auch sofort eine ReadFn von FHEM aufgerufen. Ist die Verbindung aber unterbrochen, so folgt nach dem WriteFn erst einmal nichts. Erst wenn der Oppo wieder eingeschaltet ist, wird ReadFn aufgerufen, welches misslingt, nach dem Etablieren der Verbindung wird ein 2. Mal ReadFn erfolgreich aufgerufen. Klingt als Text unverständlich. Im Log sieht es wie nachfolgend aus:
#Gerät eingeschaltet:
2018.01.01 10:08:06 4: Oppo (oppo105) - WriteFn called
2018.01.01 10:08:06 4: Oppo (oppo105) - REMOTE NOP
2018.01.01 10:08:06 4: Oppo (oppo105) - ReadFn started
2018.01.01 10:08:06 3: Oppo (oppo105) - received data @NOP OK
# Gerät ausgeschaltet:
2018.01.01 10:08:59 4: Oppo (oppo105) - WriteFn called
2018.01.01 10:08:59 4: Oppo (oppo105) - REMOTE NOP
# Gerät wurde wieder eingeschaltet:
2018.01.01 10:20:06 4: Oppo (oppo105) - ReadFn started
2018.01.01 10:20:06 4: Oppo (oppo105) - Socket Disconnected #weil Fehler in ReadFn
# Neuaufbau der Verbindung:
2018.01.01 10:21:34 4: Oppo (oppo105) - Socket Connected # danach gleich ein syswrite, um die SW-Version des Oppo zu holen
2018.01.01 10:21:34 4: Oppo (oppo105) - ReadFn started
2018.01.01 10:21:34 3: Oppo (oppo105) - received data @QVR OK 10XEU-83-1226
# Jetzt kommt doch noch die Antwort:
2018.01.01 10:24:20 3: Oppo (oppo105) - received data @NOP OK
1. ohne explizites return ist das zuletzt ausgewertete Ausdruck der Rueckgabewert
2. diese Frage ist zu allgemein, Kommunikation ist mehrdeutig. In deinem speziellen Fall habe ich keine Frage gefunden, und ich rate: du erwartest, dass irgendetwas nach einer Zeit der Nicht-Reaktion der anderen Seite passiert. Dafuer gibt es die Timer: d.h. beim Write InternalTimer setzen, und im ReadFn loeschen.
Ich würde es hier anders machen. Das Write sollte nicht gehen wenn das Modul mitbekommt das die Verbindung beendet wurde. Eigentlich sollte der Socket bei einem normalen ausschalten über Power Off oder so vernünftig abgebaut werden.
Du kannst alternativ noch eine presence Funktion mittels Ping einbauen. Alles im LG Modul vorhanden.
Zitat von: rudolfkoenig am 01 Januar 2018, 12:22:49...
2. diese Frage ist zu allgemein, Kommunikation ist mehrdeutig. In deinem speziellen Fall habe ich keine Frage gefunden
Die Frage war:
ZitatWo finde ich eine gute, kompakte und übersichtliche Erklärung für Einsteiger, wie die Kommunikation (allgemein, bzw. mit perl) abläuft?
Ich möchte einfach mal etwas über die Kommunikation via Ethernet (TCP, UDP, etc.) lernen. Das kann ein Link, ggf. auch ein Buch sein. Ein wenig habe ich schon gefunden, aber noch zu wenig, um es wirklich zu verstehen. Ich erwarte nicht, nein ich will sogar nicht, dass man mir hier meine Herausforderungen löst, denn dann habe ich ja gar nichts gelernt.
https://perldoc.perl.org/IO/Socket/INET.html
Damit arbeitest Du Momentan. Du kannst Dir die Beschreibung durchlesen oder Dir den Code in dem Modul anschauen. Denn nichts anderes ist es. Du bindest einfach nur ein weiteres Perl Modul ein und bediehnst Dich der bereitgestellten Funktionen.