Hallo Entwicklerkollegen,
da in 98_help.pm inzwischen auch der Maintainer und das entsprechende Unterforum zu einem Modul ermittelt und in der Hilfe ausgegeben werden, wäre es hilfreich, wenn wir uns auf folgende Konventionen bezüglich des Inhalts und der Formatierung der Datei MAINTAINER.txt verständigen könnten.
- keine Tabulatoren in der Datei. (Vielleicht kann man das in den pre-commit hook einbauen, analog zur vorhandenen Prüfung bei CHANGED)
- keine absoluten URLs zu einzelnen Forumbeiträgen in der letzten Spalte der Datei, sondern nur die Angabe des richtigen Unterforums
Die Tabulatoren habe ich heute alle durch Leerzeichen ersetzt. Nach Rücksprache mit Rudi habe ich heute außerdem den in jeder Zeile vorkommenden Eintrag
http://forum.fhem.de
entfernt, wodurch die Datei massiv an Übersichtlichkeit gewinnt.
(wo ist eigentlich die Editor-Option "Keine automatische Umwandlung in Links" geblieben?)
Zitat von: betateilchen am 16 September 2017, 18:55:53keine absoluten URLs zu einzelnen Forumbeiträgen in der letzten Spalte der Datei, sondern nur die Angabe des richtigen Unterforums
Einspruch!
Ich habe nicht umsonst einen Thread je Modul angelegt und keine grosse Lust auf eine Thread-Schnitzeljagd zu jedem einzelnen Problem.
Das ist für mich nicht schön und für die Benutzer der Module auch nicht.
Zitat von: Markus M. am 16 September 2017, 19:11:48
Ich habe nicht umsonst einen Thread je Modul angelegt und keine grosse Lust auf eine Thread-Schnitzeljagd zu jedem einzelnen Problem.
Das ist für mich nicht schön und für die Benutzer der Module auch nicht.
Es geht nicht um schön oder nicht schön. Das Eintragen von URL in diese Datei widerspricht den von Rudi veröffentlichten Hinweisen in diesem Beitrag:
https://forum.fhem.de/index.php/topic,13092.0.html
Darin geht es nicht um einzelne Threads, sondern um Unterforen (als Nachfolger der früheren Google-"Gruppen")
der hardlink auf einen thread mach keinen sinn. ich habe zb keine lust zich verschiedene fragen in einem, dann unübersichtlichem thread zu folgen/beantworten. sinnvoller ist das unterforum anzugebrn. dort kann jeder hilfesuchende explizit für sein problem ein thread pro problem öffnen. theoretisch sollten user mit dem selben problem diesesn findne und sich dort anhängen. so hat man pro issue eine thread und es ist schön übersichtlich. rudi hat in den richtlinien meine ich ja auch geschrieben das man das unteforum seines modules abonieren soll um nachricht bei neuen threads zu bekommen.
gerade als es die performanceprobleme mit großen threads gab war das sehr hilfreich (da haben viele, auch der übersicht zu gute kommend, die großen threads in denen eh keiner was wieder findet geschlossen).
Zitat von: chris1284 am 16 September 2017, 20:30:07
sinnvoller ist das unterforum anzugebrn. dort kann jeder hilfesuchende explizit für sein problem ein thread pro problem öffnen.
Genau darum geht es. Danke!
@Rudi: wir sollten dafür Sorge tragen, dass die Datei MAINTAINER.txt sowohl im Makefile als auch im update-Prozess berücksichtigt wird.
Siehe Hinweis hier: https://forum.fhem.de/index.php/topic,76734.0.html
Am Makefile arbeite ich gerade, das update wäre Deine Baustelle.
Zitat von: chris1284 am 16 September 2017, 20:30:07rudi hat in den richtlinien meine ich ja auch geschrieben das man das unteforum seines modules abonieren soll um nachricht bei neuen threads zu bekommen.
Kann und werde ich bei "Sonstige Systeme" und "Unterstützende Dienste" (und darin liegen alle meine Module) aber nicht tun, weil mich 99.9% nicht betreffen.
Der verlinkte Post ist von 2013 - mit der heutigen Menge an neuen Threads geht das schlicht nicht mehr ohne Keyword Alerts etc.
Es ergibt für mich überhaupt keinen Sinn, sämtliche Fragen zu einem Modul in einem einzigen Thread behandeln zu wollen. Das dient weder der Übersichtlichkeit noch ist es für Hilfesuchende tatsächlich hilfreich.
Wenn ein Anwender einen neuen Thread mit einer Frage zu Deinem Modul eröffnet, nützt es Dir die Eingabe eines bestimmten Threads in der MAINTAINER.txt überhaupt nichts. Da Du das Unterforum nicht abonniert hast, bekommst Du die Frage vermutlich erstmal gar nicht mit.
Das ist nicht der Weg, wie man als maintainer eines Moduls denken und arbeiten sollte, wenn man sich wirklich um Problemfälle kümmern möchte.
(Meine persönliche Meinung)
Hallo Markus,
Ich denke auch das es ein falscher Ansatz ist alle Probleme eines Modules in einem Thread lösen zu wollen. Das führt am Ende zu mehr Aufwand. Könnte ein Problem zu Deinem Modul in einem separaten Thread mit 3 Antworten gelöst werden und ein Suchender mit selben Problem so schnell zur Lösung finden, würde es in einem 100 Antwort Thread sicherlich ewig dauern zu suchen und somit kommt es zu mehr Fragen mit dem selben Inhalt.
Ich stimme daher Udos Aussage voll und ganz zu.
Grüße
Wir reden glaube ich ein wenig aneinander vorbei.
Der Grund warum der Einzel-Thread besser funktioniert ist für mich keinesfalls ideeller sondern rein technischer Natur.
Darauf habe ich Push Notifications und die durchschnittliche Antwortzeit liegt daher eher bei Minuten statt Stunden.
Das Unterforum kann ich so aber nicht abonnieren, da ich sonst zu viele davon bekomme.
Einzelnen Threads würden das Forum übersichtlicher machen, ich habe aber keine Möglichkeit dass die Informationen automatisch zu mir kommen - ich müsste sie mir aktiv suchen. Und das geht eben nicht in der Zigarettenpause im Büro sondern ich muss dafür extra Zeit aufwenden - die ich ehrlich gesagt nicht habe :(
Gibt es seitens der Forum Software eine Möglichkeit dieses Dilemma technisch zu lösen, z.B. über Keyword Alerts?
Zitat von: Markus M. am 17 September 2017, 10:40:52
Gibt es seitens der Forum Software eine Möglichkeit dieses Dilemma technisch zu lösen, z.B. über Keyword Alerts?
Das kann man doch sicherlich mit FHEM und dem rssFeed Modul lösen ;)
Es ist also ein sagen wir persönliches Einzelschicksal was Dich zu Deinem berechtigten Einspruch gebracht hat. Verstehe.
Nichts desto trotz hoffe ich das Du auch verstehst wenn mehrheitlich oder durch Rudi entschieden/vorgeschrieben wird das in Zukunft solche Einträge in der Maintainer Datei nicht mehr zu stehen haben.
Grüße
Zitat von: Markus M. am 17 September 2017, 10:40:52
Gibt es seitens der Forum Software eine Möglichkeit dieses Dilemma technisch zu lösen, z.B. über Keyword Alerts?
Ich habe es bisher selbst so gelöst, dass mein MTA auf dem Mailserver in den eingehenden Email-Benachrichtigungen nach Schlüsselwörtern sucht und die Mails, dann in entsprechende Unterordner verschiebt. Das wird auch ein normales Emailprogramm können, aber dann halt dezentral. Eine Lösung auf Forumsebene wäre für die meisten Entwickler sicher elegnater...
Zitat von: CoolTux am 17 September 2017, 10:47:56
Es ist also ein sagen wir persönliches Einzelschicksal was Dich zu Deinem berechtigten Einspruch gebracht hat.
Wie kommst Du zu dem Schluss, ohne die anderen Schicksale zu kennen?
Das Problem ist, dass man einen viel zu breiten Raum abonnieren muss.
Ich kümmere mich um (um mal nur zwei rauszugreifen) LaCrosse und Elero, beides in "Sonstige Systeme".
Da ist aber auch "Xiaomi", "G-Homa WiFi-Steckdose", "Signalduino", "Schellenberg Smart Home Zentrale", und eine gefühlt unendlich lange Liste mehr, was mich absolut nicht interessiert / betrifft.
Aktuell ist es kaum möglich, gezielt das zu bekommen, worauf man reagieren sollte und den ganzen Rest nicht.
Zitat von: HCS am 17 September 2017, 11:07:33
Wie kommst Du zu dem Schluss, ohne die anderen Schicksale zu kennen?
Die Antwort zu Deiner Frage hast Du bereits selbst gegeben. Ich kannte keine anderen Schicksale daher mein Schluss. Man kann nichts betrachten was einem nicht bekannt ist.
Wenn sich mehr melden muss die Betrachtung erweitert/überdacht werden.
Nur weil ich irgendwannmal etwas vorgeschlagen/vorgeschrieben habe, heisst nicht, dass es bei Bedarf nicht geaendert werden kann bzw. muss. Wir haben angefangen mit einer Google-Gruppe und kurz bevor ich ausgetickt bin wg. den im Winter ueber 100 Emails am Tag, hat Martin das Forum gestartet, damit war es moeglich nur Teile zu abonnieren, und ich hatte meine Ruhe.
Ich kann das Problem von Markus gut nachvollziehen: manchmal ignoriert man ein Thema dann doch nicht sofort, verfolgt die Diskussion einige Tage lang, nur im nachhinein ein schlechtes Gewissen zu haben, weil man zu viel Zeit verschwendet hat. Ich moechte die Wuensche der Entwickler soweit moeglich, respektieren, um die Leute vom Publizieren/Spendieren ihrer Module nicht abzuschrecken.
Es gibt im Maintainer einen Fall, wo bei Problemen der Maintainer eine PM haben will. Waere das eine Loesung? Weiterhin sollten wir in "Sonstigen Systeme" aufraeumen bzw. Untergruppen einrichten, die 126 Module, die da behandelt werden wollen, ist eindeutig zu viel.
Auch fuer Sonstiges (78) und Automatisierung (53) koennte man das angehen.
Wenn jemand sich die Arbeit machen wuerde, und Untergruppen ueberlegen wuerde, waere ich dankbar.
Zitat von: CoolTux am 17 September 2017, 11:26:58Ich kannte keine anderen Schicksale daher mein Schluss. Man kann nichts betrachten was einem nicht bekannt ist.
Wenn sich mehr melden muss die Betrachtung erweitert/überdacht werden.
Sorry aber der Ansatz ist Quatsch.
Du solltest stattdessen davon ausgehen dass hier jemand mehrere Module in den breit gestreuten Unterforen betreut, dabei noch einen Vollzeitjob arbeitet, anderen Hobbies nachgeht sowie Frau und Kinder hat, mit denen er ebenfalls noch Zeit verbringen möchte.
Dann kannst du anfangen darüber nachzudenken, wie sich das ganze für diesen theoretischen (und wahrscheinlich sogar real existierenden) Fall so einfach wie möglich gestalten lässt.
Ständig das Forum manuell zu durchsuchen oder die komplette Informationsflut filtern zu müssen kann nicht die Lösung sein.
Das ist schnell ermüdend und damit frustrierend für alle Beteiligten.
Ich habe den Anspruch, auf Probleme mit meinen Modulen in meiner nächsten freien Zeit zu reagieren. Zigarettenpause, Strassenbahn, etc.
Das geht nur wenn der Vorfilter sehr gut ist und die Informationen gepusht werden.
Zitat von: rudolfkoenig am 17 September 2017, 11:42:23Es gibt im Maintainer einen Fall, wo bei Problemen der Maintainer eine PM haben will. Waere das eine Loesung? Weiterhin sollten wir in "Sonstigen Systeme" aufraeumen bzw. Untergruppen einrichten, die 126 Module, die da behandelt werden wollen, ist eindeutig zu viel.
Auch fuer Sonstiges (78) und Automatisierung (53) koennte man das angehen.
Ein paar Unterforen mehr würden wahrscheinlich schon helfen, ich weiss aber spontan nicht welche Sinn machen würden.
Vielleicht lassen sich die Themen die unter Sonstiges liegen ja noch sinnvoll gruppieren. Neuer Thread dazu?!
PM macht maximal Sinn als Hinweis auf einen Thread.
Ich würde jetzt erst mal eine Lösung mit RSS probieren und berichten.
Eventuell gibt es ein paar passende Apps die ich noch nicht kenne.
Was nutzt ihr eigentlich alle?
Bei mir ist es auf dem Telefon Tapatalk. Das funktioniert recht gut, kennt aber nur Benachrichtigungen für Threads, Unterforen und PMs.
Mentions sollten auch funktionieren, ich weiss aber nicht wie.
Man könnte im Hauptthread eines Modules darum bitten ein bestimmtes Präfix für einen neuen Thread zu verwenden. So mach ich das. Auf dieses kann man dann filtern.
Aktuell betreue ich 11 Module in 3 Forenbereichen. Es ist machbar, auch mit wenig Zeit.
Vielleicht wäre das ja ein Ansatz für einige. Für Weitere Unterforen in sonstigen Systeme und sonstiges wäre ich auch.
Grüße
Zitat von: Markus M. am 17 September 2017, 12:17:53
Was nutzt ihr eigentlich alle?
Ich hatte ja schon geschrieben, dass ich die abonnierten Boards auf meinem Mailserver "filtern" lasse.
Die einfachste Variante wäre mMn aber in der MAINTAINER.txt das zuzulassen was der Maintainer wünscht: Boards, Threads, Email mit einem Hinweis auf einen Thread oder sogar externe Hosts wie Github, etc...
Ich habe überhaupt keine Unterforen abonniert und ich habe sämtliche email-Benachrichtigungen abgeschaltet.
Trotzdem schaffe ich es, die von mir betreuten Module zu supporten.
Es ist eine Frage der Selbstdisziplin und des methodischen Vorgehens bei solchen Aufgaben. Man muss nicht immer alles auf vermeintlich fehlende Möglichkeiten der Forumsoftware schieben.
Von der Einrichtung weiterer Unterforen unterhalb der jetzt bestehenden Struktur halte ich wenig, weil momentan die Übersichtlichkeit der gesamten Forumübersicht komplett über den Haufen geworfen wird, weil man nicht mehr erkennen kann, ob ein letzter Beitrag nun in einem Bereich der 4. Unterebene oder in der Forumrubrik selbst geschrieben wurde. Vor Einführung der weiteren Bereichsebenen war es erheblich einfacher, relevante Beiträge zu finden.
Zitat von: dev0 am 17 September 2017, 12:35:47
Die einfachste Variante wäre mMn aber in der MAINTAINER.txt das zuzulassen was der Maintainer wünscht: Boards, Threads, Email mit einem Hinweis auf einen Thread oder sogar externe Hosts wie Github, etc...
Das würde dem aktuell hier im Forum propagierten Paranoia-Sicherheits-Denken widersprechen, weil man nicht beeinflussen kann, was dann an dieser Stelle wirklich steht. Da könnte auch ein Link zu Schadsoftware oder eine URL zur Auslösung von FHEM Aktionen selbst auftauchen.
Und da Rudi ja vor wenigen Tagen mehrfach darauf hingewiesen hat, dass er nicht als "Schuldiger" für bösartige Anwendungen von FHEM verantwortlich gemacht werden möchte, hoffe ich sehr, dass er so einen Quatsch auch an dieser Stelle nicht zulässt. Nachdem selbst eine Demokonfiguration Sicherheitslevel "Fort Knox" bleiben muss... ;)
Man sollte überlegen, ob ein Forum für das, was man hier gerne möchte, nämlich, dass Anwender Fehler und Erweiterungswünsche in einer strukturierten Art einmelden, und Entwickler diese bearbeiten, das richtige Werkzeug ist.
Ein Forum ist prima zum diskutieren geeignet aber halt kein Ticket-System, das die dazu erforderlichen Eigenschaften wie Kategorisierung (Fehler, Wunsch, ...), Status (Akzeptiert, in Arbeit, Behoben, ...) usw. bietet.
Das würde dann auch Verrenkungen wie "schreibe bitte [gelöst] in den ersten Beitrag" und ähnliches wie Präfixe, was hier gerade aufkommt, nicht benötigen.
Ich führe die issues (also was meine Module betrifft) hier in einem internen Ticketsystem, in das ich sie, wenn ich sie im Forum erkenne, übernehme, wüsste nicht, wie ich das sonst managen sollte, was noch (dringend/irgendwann/...) zu tun ist. Aber es ist eigentlich nicht schön, dass jeder das in Eigenregie mit irgend was oder auch mit nichts oder gar nicht verwaltet und Statusrückmeldungen in prosa dann wieder in Forenbeiträge zurückgibt.
Falls man sich mittelfristig mit dem Gedanken "Ticketsystem" anfreunden könnte, dann müsste man jetzt im Forum nicht allzuviele "Krücken" für dieses Thema einbauen.
@betateilchen: Deinen letzten Beitrag empfinde ich als "an den Haaren herbei gezogen".
@HCS, all: Ein Ticketsytsem fände ich sehr sinnvoll.
Zitat von: dev0 am 17 September 2017, 14:47:44
@betateilchen: Deinen letzten Beitrag empfinde ich als "an den Haaren herbei gezogen".
Du warst am Freitag bei der "Sicherheits"-Diskussion in Hamburg nicht dabei. Da wurden noch ganz andere Szenarien "an den Haaren herbeigezogen".
Zum Thema Ticketsystem: Ich hatte für FHEM sowas schonmal vollständig funktionsfähig aufgesetzt und zur Nutzung bereitgestellt. Das Interesse und die Nutzung daran hielten sich aber sehr in Grenzen, dafür wurde dann einfach der Wartungsaufwand (für das Ticketsystem) zu hoch.
zu den präfixen und gelöst einträgen: das ist nur sinnvoll wenn es ganz konsequent einen thread pro problem gibt und dieser dann geschlossen wird.
threads die gelöst heißen und sich nachträglich noch 5 andere mit ganz unterschiedlichen dingen dran hängen seins eine katastrophe und schlimmer als konsequent einen thread pro modul zu haben. deshalb bin ich auch gegen diese gelöst markierungen ohne zu schliessen.
einen einzigen thread im auge zu haben finde ich persönlich deutlich einfacher als x neue threads. vielleicht sogar noch im falschen bereichen. ich weiß es ist für neueinsteiger nicht optimal 100 seiten auf ein mal zu lesen. aber für mich ist es einfacher als 100 einzelne threads.
die anforderungen sind vermutlich auch unterschiedlich für module mit 30 anwendern oder solchen mit 3000.
auch sind probleme die direkt in einem fhem modul ihre ursache haben deutlich einfacher zu handhaben als probleme mit der installation von dritt software dir zum x-ten mal durchgekaut werden oder dir ganz allgemein mit schnittstellen zu dritten zu tun haben.
Ein Ticketsystem würde nur noch mehr Aufwand und Streuung der Informationen bedeuten.
Ich bin dafür, das Forum besser zu sortieren.
Wenn ich einen Blick auf die Module unten werfe, sehe ich sofort folgendes:
- Anwesenheitserkennung braucht ein eigenes Unterforum
- Kommunikationsdienste brauchen ein Unterforum
- Manche Module sind aktuell falsch einsortiert
Es gibt weitere Gruppen von Modulen die man recht einfach sehen kann:
- Komplettsysteme mit Bridges oder Sticks vom Hersteller (Xiaomi Bridge, DuoFern)
- Cloud connected consumer devices (Netatmo, Nokia Health, Xiaomi WiFi, NUKI, Gardena, Nello)
- Protokolle für Selbstbau-Hardware oder Chips
Aktuell wird alles was nirgendwo anders passt einfach in Sonstige Systeme, Unterstuetzende Dienste oder Automatisierung geworfen.
Das ist suboptimal. Gehören z.B. DoorPi und at ins selbe Forum bzw. haben sie irgendwas gemeinsam? Mit Sicherheit nicht.
FHEM/00_HXB.pm neubert Sonstige Systeme
FHEM/00_KM271.pm physikus Sonstiges
FHEM/00_LIRC.pm rudolfkoenig Sonstiges
FHEM/00_MYSENSORS.pm ntruchsess Sonstige Systeme
FHEM/00_NetzerI2C.pm klausw Sonstige Systeme
FHEM/00_SIGNALduino.pm Sidey Sonstige Systeme
FHEM/10_DUOFERNSTICK telekatz Sonstige Systeme
FHEM/10_EQ3BT.pm dominikkarall Sonstige Systeme
FHEM/10_FRM.pm ntruchsess Sonstige Systeme
FHEM/00_HXBDevice.pm neubert Sonstige Systeme
FHEM/10_Itach_IR ulimaass Sonstige Systeme
FHEM/10_KOPP_FC.pm raspii Sonstige Systeme
FHEM/10_MYSENSORS_DEVICE ntruchsess Sonstige Systeme
FHEM/10_SOMFY.pm viegener Sonstige Systeme
FHEM/10_RESIDENTS.pm loredo Automatisierung <- Anwesenheitserkennung
FHEM/10_pilight_ctrl.pm risiko Sonstige Systeme
FHEM/14_Hideki.pm Sidey/Ralf9 Sonstige Systeme <- 4334MHz
FHEM/14_SD_WS.pm Sidey/Ralf9 Sonstige Systeme
FHEM/14_SD_WS_Maverick.pm Sidey79/Cruizer Sonstige Systeme
FHEM/14_SD_WS07.pm Sidey/Ralf9 Sonstige Systeme
FHEM/14_SD_WS09.pm Sidey/pejonp Sonstige Systeme
FHEM/19_VBUSIF.pm Tobias/pejonp Sonstige Systeme
FHEM/20_FRM_AD.pm ntruchsess Sonstige Systeme <- Was ist FRM?
FHEM/20_FRM_ROTENC.pm ntruchsess Sonstige Systeme
FHEM/20_FRM_I2C.pm ntruchsess Sonstige Systeme
FHEM/20_FRM_IN.pm ntruchsess Sonstige Systeme
FHEM/20_FRM_LCD.pm ntruchsess Sonstige Systeme (deprecated)
FHEM/20_FRM_OUT.pm ntruchsess Sonstige Systeme
FHEM/20_FRM_PWM.pm ntruchsess Sonstige Systeme
FHEM/20_FRM_RBG.pm ntruchsess Sonstige Systeme
FHEM/20_FRM_SERVO.pm ntruchsess Sonstige Systeme
FHEM/20_FRM_STEPPER.pm ntruchsess Sonstige Systeme
FHEM/20_ROOMMATE.pm loredo Automatisierung <- Anwesenheit
FHEM/20_GUEST.pm loredo Automatisierung
FHEM/20_N4HBUS.pm okoerber Sonstige Systeme
FHEM/21_N4HMODULE.pm okoerber Sonstige Systeme
FHEM/21_VBUSDEV.pm Tobias/pejonp Sonstige Systeme
FHEM/22_ALL3076.pm sachag Sonstiges
FHEM/22_HOMEMODE.pm DeeSPe Automatisierung <- Anwesenheit?
FHEM/23_ALL4027.pm sachag Sonstiges
FHEM/23_KOSTALPIKO.pm john CodeSchnipsel
FHEM/23_LUXTRONIK2.pm tupol Sonstiges (link als PM an tupol)
FHEM/23_WEBIO.pm sachag Sonstiges
FHEM/23_WEBIO_12DIGITAL.pm sachag Sonstiges
FHEM/24_NetIO230B.pm rudolfkoenig/orphan Sonstiges
FHEM/24_TPLinkHS110.pm VolkerKettenbach Sonstige Systeme
FHEM/26_tahoma.pm mike3436 Sonstige Systeme
FHEM/30_DUOFERN telekatz Sonstige Systeme
FHEM/30_ENECSYSGW.pm akw Sonstige Systeme
FHEM/30_pilight_dimmer.pm risiko Sonstige Systeme <- Ist Pilight nicht eigentlich ein eigenständiges Fremdsystem?
FHEM/30_pilight_switch.pm risiko Sonstige Systeme
FHEM/30_pilight_temp.pm risiko Sonstige Systeme
FHEM/30_pilight_raw.pm risiko Sonstige Systeme
FHEM/30_pilight_smoke.pm risiko Sonstige Systeme
FHEM/30_pilight_contact.pm risiko Sonstige Systeme
FHEM/31_Nello.pm neumann Sonstige Systeme
FHEM/31_ENECSYSINV.pm akw Sonstige Systeme
FHEM/31_LightScene.pm justme1968 Automatisierung <- Beleuchtung?!
FHEM/32_SYSSTAT.pm justme1968 Unterstuetzende Dienste
FHEM/32_mailcheck.pm justme1968 Automatisierung <- Kommunikation
FHEM/32_TechemWZ.pm herrmannj Sonstiges <- Heizung?
FHEM/32_TechemSD.pm herrmannj Sonstiges
FHEM/32_yowsup.pm justme1968 Unterstuetzende Dienste
FHEM/32_withings.pm markus-m Sonstiges
FHEM/33_readingschange.pm rudolfkoenig Automatisierung
FHEM/33_readingsProxy.pm justme1968 Automatisierung
FHEM/32_speedtest.pm justme1968 Sonstiges
FHEM/34_NUT.pm creideiki Sonstige Systeme <- Anwesenheit
FHEM/34_panStamp.pm justme1968 Sonstige Systeme
FHEM/34_SWAP.pm justme1968 Sonstige Systeme
FHEM/35_SWAP_0000002200000003.pm justme1968 Sonstige Systeme
FHEM/35_SWAP_0000002200000008.pm justme1968 Sonstige Systeme
FHEM/36_EC3000.pm justme1968 Sonstige Systeme
FHEM/36_EleroDrive.pm HCS Sonstige Systeme
FHEM/36_EleroStick.pm HCS Sonstige Systeme
FHEM/36_JeeLink.pm justme1968 Sonstige Systeme
FHEM/36_KeyValueProtocol.pm HCS Sonstige Systeme
FHEM/36_PCA301.pm justme1968 Sonstige Systeme
FHEM/36_LaCrosse.pm HCS Sonstige Systeme
FHEM/36_LaCrosseGateway.pm HCS Sonstige Systeme
FHEM/36_EMT7110.pm HCS Sonstige Systeme
FHEM/36_Level.pm HCS Sonstige Systeme
FHEM/36_Vallox.pm Skjall http://forum.fhem.de/index.php/topic,71325.0.html
FHEM/36_WMBUS.pm kaihs Sonstige Systeme
FHEM/37_SHC.pm rr2000 Sonstige Systeme
FHEM/37_SHCdev.pm rr2000 Sonstige Systeme
FHEM/37_dash_dhcp.pm justme1968 Sonstige Systeme
FHEM/38_Broadlink.pm daniel2311 http://forum.fhem.de/index.php/topic,71972.0.html
FHEM/38_netatmo.pm markus-m http://forum.fhem.de/index.php/topic,53500.0.html
FHEM/38_CO20.pm markus-m Sonstiges
FHEM/38_JawboneUp.pm domschl Sonstiges
FHEM/41_OREGON.pm Sidey/Ralf9 Sonstiges
FHEM/42_SMARTMON.pm hexenmeister Unterstuetzende Dienste
FHEM/42_SYSMON.pm hexenmeister Unterstuetzende Dienste
FHEM/42_Nextion.pm viegener Bastelecke
FHEM/44_S7.pm charlie71 Sonstige Systeme
FHEM/44_S7_ARead.pm charlie71 Sonstige Systeme
FHEM/44_S7_AWrite.pm charlie71 Sonstige Systeme
FHEM/44_S7_Client.pm charlie71 Sonstige Systeme
FHEM/44_S7_DRead.pm charlie71 Sonstige Systeme
FHEM/44_S7_DWrite.pm charlie71 Sonstige Systeme
FHEM/44_S7_S5Client.pm charlie71 Sonstige Systeme
FHEM/44_S7_S7Client.pm charlie71 Sonstige Systeme
FHEM/44_TEK603.pm eisler Sonstige Systeme
FHEM/45_Plugwise.pm icinger Sonstige Systeme
FHEM/46_PW_Circle.pm icinger Sonstige Systeme
FHEM/46_PW_Scan.pm icinger Sonstige Systeme
FHEM/46_PW_Sense.pm icinger Sonstige Systeme
FHEM/46_PW_Switch.pm icinger Sonstige Systeme
FHEM/46_SmartPi.pm CoolTux Sonstige Systeme
FHEM/47_OBIS.pm icinger Sonstige Systeme
FHEM/49_IPCAM.pm mfr69bs Sonstiges
FHEM/49_SSCAM.pm DS_Starter Sonstiges
FHEM/49_TBot_List.pm viegener Unterstuetzende Dienste
FHEM/50_TelegramBot.pm viegener Unterstuetzende Dienste <- Kommunikation
FHEM/51_I2C_BH1750.pm arnoaugustin Einplatinencomputer (bitte auch PM)
FHEM/51_I2C_BMP180.pm Dirk Einplatinencomputer
FHEM/51_Netzer.pm klausw Sonstige Systeme
FHEM/52_I2C_DS1307 ntruchsess Sonstige Systeme <- Einplatinencomputer?
FHEM/52_I2C_EEPROM.pm klausw Sonstige Systeme
FHEM/52_I2C_LCD ntruchsess Sonstige Systeme
FHEM/52_I2C_BME280 klausw Sonstige Systeme
FHEM/52_I2C_K30 yoda_gh Sonstige Systeme
FHEM/52_I2C_LM75A clumsy Sonstige Systeme
FHEM/52_I2C_MCP23008 klausw Sonstige Systeme
FHEM/52_I2C_MCP23017 klausw Sonstige Systeme
FHEM/52_I2C_MCP342x klausw Sonstige Systeme
FHEM/52_I2C_MMA845X jensb Sonstige Systeme
FHEM/52_I2C_PCA9532 klausw Sonstige Systeme
FHEM/52_I2C_PCA9685 klausw Sonstige Systeme
FHEM/52_I2C_PCF8574 klausw Sonstige Systeme
FHEM/52_I2C_SHT21 klausw Sonstige Systeme
FHEM/52_I2C_SHT3x macs Sonstige Systeme
FHEM/52_I2C_TSL2561 jensb Sonstige Systeme
FHEM/53_GHoma.pm klausw Sonstige Systeme
FHEM/55_InfoPanel.pm betateilchen Unterstuetzende Dienste
FHEM/56_POKEYS.pm axelberner Sonstiges
FHEM/59_HCS.pm mfr69bs Automatisierung
FHEM/59_LuftdatenInfo igami Bastelecke <- Sensoren o.ä.
FHEM/60_allergy.pm markus-m Unterstuetzende Dienste
FHEM/66_ECMD.pm neubert Sonstige Systeme
FHEM/67_ECMDDevice.pm neubert Sonstige Systeme
FHEM/70_EGPM.pm alexus Sonstiges
FHEM/70_Jabber.pm BioS Unterstuetzende Dienste <- Kommunikation
FHEM/70_JSONMETER.pm tupol Sonstiges (Link als PM an tupol)
FHEM/70_SCIVT.pm rudolfkoenig/orphan Sonstiges
FHEM/70_SISPM.pm real-wusel Sonstiges
FHEM/70_SML.pm bentele Sonstiges
FHEM/70_STV.pm bentele Sonstiges
FHEM/70_TellStick.pm real-wusel Sonstiges
FHEM/70_USBWX.pm wherzig Sonstiges
FHEM/70_VIERA.pm teevau Sonstiges
FHEM/70_WS3600.pm Josch Sonstiges
FHEM/70_WINCONNECT.pm michael.winkler Sonstige Systeme
FHEM/70_Pushbullet.pm fhainz Unterstuetzende Dienste <- Kommunikation
FHEM/70_Pushover.pm loredo Unterstuetzende Dienste <- Kommunikation
FHEM/70_PushNotifier.pm xusader Unterstuetzende Dienste <- Kommunikation
FHEM/70_Pushalot.pm Talkabout Unterstuetzende Dienste <- ...
FHEM/70_Pushsafer.pm markusbloch Unterstuetzende Dienste
FHEM/70_DoorPi.pm pahenning Automatisierung
FHEM/72_FB_CALLMONITOR.pm markusbloch Unterstuetzende Dienste <- Fritzbox
FHEM/72_FB_CALLLIST.pm markusbloch Frontends <- Fritzbox
FHEM/73_ElectricityCalculator.pm Sailor http://forum.fhem.de/index.php/topic,57106.0.html
FHEM/73_GasCalculator Sailor http://forum.fhem.de/index.php/topic,47909.0.html
FHEM/73_km200.pm Sailor http://forum.fhem.de/index.php/topic,25540.0.html
FHEM/73_PRESENCE.pm markusbloch Unterstuetzende Dienste <- Anwesenheit
FHEM/73_AMADCommBridge.pm CoolTux Sonstige Systeme
FHEM/73_GardenaSmartBridge.pm CoolTux Sonstige Systeme
FHEM/74_NUKIBridge.pm CoolTux Sonstige Systeme
FHEM/74_AMADDevice.pm CoolTux Sonstige Systeme
FHEM/74_GardenaSmartDevice.pm CoolTux Sonstige Systeme
FHEM/74_HOMBOT.pm CoolTux sonstige Systeme
FHEM/74_NUKIDevice.pm CoolTux Sonstige Systeme
FHEM/74_Nmap.pm igami Unterstuetzende Dienste
FHEM/74_XiaomiFlowerSens CoolTux Sonstige Systeme
FHEM/74_THINKINGCLEANER.pm loredo Unterstuetzende Dienste
FHEM/74_Unifi.pm rapster Automatisierung
FHEM/75_MSG.pm loredo Automatisierung
FHEM/75_msgConfig.pm loredo Automatisierung
FHEM/76_MSGFile.pm gandy Automatisierung
FHEM/76_MSGMail.pm gandy Automatisierung
FHEM/76_SMAInverter.pm DS_Starter Sonstige Systeme
FHEM/77_SMAEM.pm VolkerKettenbach Sonstige Systeme
FHEM/77_SMASTP.pm VolkerKettenbach Sonstige Systeme
FHEM/80_M232.pm neubert Sonstige Systeme
FHEM/81_M232Counter.pm neubert Sonstige Systeme
FHEM/82_M232Voltage.pm neubert Sonstige Systeme
FHEM/87_WS2000.pm tdressler Sonstiges
FHEM/86_Robonect.pm andi291 Sonstige Systeme
FHEM/88_ALL4000T.pm sachag Sonstiges
FHEM/88_IPWE.pm tdressler Sonstiges
FHEM/88_Itach_Relay.pm sachag Automatisierung
FHEM/88_Itach_IRDevice ulimaass Sonstige Systeme
FHEM/88_VantagePro2.pm sachag Sonstiges
FHEM/88_WEBCOUNT.pm sachag Sonstiges
FHEM/89_HEATRONIC.pm heikoranft Sonstige Systeme <- Heizung
FHEM/90_at.pm rudolfkoenig Automatisierung
FHEM/14_SIGNALduino_un.pm Sidey Sonstige Systeme
FHEM/93_DbLog.pm Tobias Automatisierung
FHEM/93_DbRep.pm DS_Starter Sonstiges
FHEM/95_Alarm.pm pahenning Unterstützende Dienste
FHEM/95_Astro.pm pahenning Unterstützende Dienste
FHEM/95_PostMe.pm pahenning Unterstützende Dienste <- Kommunikation?
FHEM/95_YAAHM.pm pahenning Unterstützende Dienste
FHEM/95_PachLog.pm rudolfkoenig/orphan Sonstiges
FHEM/95_holiday.pm rudolfkoenig Sonstiges
FHEM/95_remotecontrol.pm ulimaass Frontends
FHEM/96_SIP.pm wzut,plin Sonstiges <- Kommunikation
FHEM/97_TrashCal.pm Tobias Unterstuetzende Dienste <- Kalender
FHEM/97_SprinkleControl.pm Tobias Unterstuetzende Dienste
FHEM/98_Text2Speech.pm Tobias Unterstuetzende Dienste
FHEM/98_Sprinkle.pm Tobias Unterstuetzende Dienste
FHEM/98_apptime.pm martinp876 Sonstiges
FHEM/98_alarmclock.pm FlorianZ Unterstuetzende Dienste
FHEM/98_ComfoAir.pm StefanStrobel Sonstiges
FHEM/98_CULflash.pm rudolfkoenig Sonstiges
FHEM/98_EDIPLUG.pm Wzut Sonstige Systeme
FHEM/98_FReplacer.pm stefanstrobel Sonstiges
FHEM/98_GEOFANCY.pm loredo Unterstuetzende Dienste <- Anwesenheit
FHEM/98_HMinfo.pm martinp876 HomeMatic
FHEM/98_Heating_Control.pm dietmar63 Unterstuetzende Dienste <- Heizung
FHEM/98_HTTPMOD.pm stefanstrobel Sonstiges
FHEM/98_Arducounter.pm stefanstrobel Sonstiges
FHEM/98_IF.pm damian-s Automatisierung
FHEM/98_JsonList.pm mfr69bs Automatisierung
FHEM/98_JsonList2.pm rudolfkoenig Automatisierung
FHEM/98_Modbus.pm stefanstrobel Sonstiges
FHEM/98_ModbusAttr.pm stefanstrobel Sonstiges
FHEM/98_ModbusSET.pm stefanstrobel Sonstiges
FHEM/98_PID20.pm John Automatisierung
FHEM/98_RandomTimer.pm dietmar63 Unterstuetzende Dienste/Kalendermodule
FHEM/98_THRESHOLD.pm damian-s Automatisierung
FHEM/98_TRAFFIC.pm jmike Unterstuetzende Dienste
FHEM/98_UbiquitiPM.pm Wzut Sonstige Systeme
FHEM/98_UbiquitiOut.pm Wzut Sonstige Systeme
FHEM/98_Verkehrsinfo.pm martins Unterstuetzende Dienste
FHEM/98_WeekdayTimer.pm dietmar63 Unterstuetzende Dienste
FHEM/98_WOL.pm dietmar63 Unterstuetzende Dienste
FHEM/98_backup.pm rudolfkoenig Sonstiges
FHEM/98_cloneDummy.pm Joachim Automatisierung
FHEM/98_configdb.pm betateilchen Sonstiges
FHEM/98_copy.pm justme1968 Sonstiges
FHEM/98_count.pm betateilchen Sonstiges
FHEM/98_CustomReadings.pm HCS Unterstuetzende Dienste
FHEM/98_dewpoint.pm Joachim Automatisierung
FHEM/98_Dooya.pm Jarnsen/ralf9/darkmission Sonstige Systeme
FHEM/98_dummy.pm rudolfkoenig Automatisierung
FHEM/98_expandJSON.pm dev0 Unterstuetzende Dienste
FHEM/98_fheminfo.pm betateilchen Sonstiges
FHEM/98_fhemdebug.pm rudolfkoenig Sonstiges
FHEM/98_GoogleAuth.pm betateilchen Unterstuetzende Dienste
FHEM/98_help.pm betateilchen Sonstiges
FHEM/98_HourCounter.pm john MAX
FHEM/98_logProxy.pm justme1968 Frontends/SVG Plots logProxy
FHEM/98_mark.pm betateilchen Sonstiges
FHEM/98_monitoring.pm igami Automatisierung
FHEM/98_notice.pm mfr69bs Sonstiges
FHEM/98_pilight.pm andreas-fey Unterstuetzende Dienste
FHEM/98_powerMap loredo Unterstuetzende Dienste
FHEM/98_QRCode.pm Benni Unterstuetzende Dienste
FHEM/98_rain.pm baumrasen Sonstiges
FHEM/98_restore.pm rudolfkoenig Sonstiges
FHEM/98_rssFeed.pm Benni Unterstuetzende Dienste
FHEM/98_statistics.pm tupol Unterstuetzende Dienste (Link als PM an tupol)
FHEM/98_STOCKQUOTES.pm vbs Unterstuetzende Dienste
FHEM/99_SUNRISE_EL.pm rudolfkoenig Automatisierung
FHEM/99_Venetian.pm Christian.Kühnel Automatisierung
FHEM/Blocking.pm rudolfkoenig Automatisierung
FHEM/DevIo.pm rudolfkoenig Sonstiges
FHEM/Color.pm justme1968 Sonstiges
FHEM/HOMESTATEtk.pm loredo Automatisierung
FHEM/HttpUtils.pm rudolfkoenig Automatisierung
FHEM/msgSchema.pm loredo Automatisierung
FHEM/RESIDENTStk.pm loredo Automatisierung
FHEM/SetExtensions.pm rudolfkoenig Automatisierung
FHEM/SHC_datafields.pm rr2000 Sonstige Systeme
FHEM/SHC_parser.pm rr2000 Sonstige Systeme
FHEM/SubProcess.pm neubert FHEM Development
FHEM/TcpServerUtils.pm rudolfkoenig Automatisierung
FHEM/TimeSeries.pm neubert /jensb FHEM Development
FHEM/UConv.pm loredo FHEM Development
FHEM/Unit.pm loredo FHEM Development
FHEM/lib/Device/Firmata/* ntruchsess Sonstige Systeme
FHEM/lib/Device/MySensors/* ntruchsess Sonstige Systeme
FHEM/lib/MP3/* Reinerlein Multimedia
FHEM/lib/ProtoThreads.pm ntruchsess FHEM Development
contrib/23_WEBTHERM.pm betateilchen/sachag Sonstiges
contrib/92_rsyslog.pm DS_Starter Automatisierung
contrib/98_exportdevice.pm loredo Sonstiges
contrib/98_FileLogConvert.pm DeeSPe Automatisierung
holiday/by_ext.holiday loredo Sonstiges <- Kalender?
holiday/de_social.holiday loredo Sonstiges
contrib/PRESENCE markusbloch Unterstuetzende Dienste
contrib/PRESENCE/lepresenced PatrickR Unterstuetzende Dienste
contrib/SIP/* wzut Sonstiges
contrib/WebViewControl/* Dirk Mobile Devices
docs/fhem-floorplan-* ulimaass Sonstiges <- Floorplan
Ich kann Markus nur zustimmen. Ich lese nicht regelmäßig komplette Forumsbereiche, um Fehlermeldungen zu meinen Modulen herauszufiltern, reagiere aber meist schnell auf Einträge im jeweiligen "Bug-Melde"-Thread.
Wie wäre es für jedes Modul ein eigenes Unterforum zu machen. Dann wäre es doch sauber getrennt.
Module welche noch nicht im offiziellen SVN sind bleibt dann halt das Sonstiges übrig.
Zitat von: michael.winkler am 18 September 2017, 14:11:47
Wie wäre es für jedes Modul ein eigenes Unterforum zu machen. Dann wäre es doch sauber getrennt.
Module welche noch nicht im offiziellen SVN sind bleibt dann halt das Sonstiges übrig.
Das wären aber eine riesen Menge Foren!
Zitat von: CoolTux am 18 September 2017, 14:16:58
Das wären aber eine riesen Menge Foren!
Da gebe ich Dir recht, aber es wäre sauber getrennt und du könntest einfach dein Modul abonnieren. Wenn wir es aber sauber Strukturieren kann man es eventuell trotzdem übersichtlich gestalten.
Bisher war ich ja der Meinung, das Forum soll in erster Linie eine Hilfe für die Anwender darstellen und nicht dem Wohlbefinden der Entwickler und deren Wünsche dienen...
Wenn man die Forumstrukturen immer weiter komplizierter macht, findet sich doch ein Neuling noch weniger zurecht als das jetzt schon der Fall ist.
Zitat von: betateilchen am 18 September 2017, 14:53:30
Bisher war ich ja der Meinung, das Forum soll in erster Linie eine Hilfe für die Anwender darstellen und nicht dem Wohlbefinden der Entwickler und deren Wünsche dienen...
Meine Wünsche als Entwickler sind, dass ich den Anwendern in kürzestmöglicher Zeit helfen kann.
Und dazu brauche ich nun mal eine Möglichkeit, die richtigen Informationen (und möglichst nur die) vorgefiltert zu bekommen.
Die Unterforen je Modul finde ich zu weit ausgeholt. Aber ein paar Aufteilungen werden wir noch brauchen.
Ein Modul bei dem ich irgendwas zusammenlöten oder kompilieren muss hat z.B. nichts im gleichen Unterforum verloren wie ein Modul zu einem Gerät das ich im Laden kaufe und nur auspacke und anstecke.
Zitat von: Markus M. am 18 September 2017, 15:30:11
Ein Modul bei dem ich irgendwas zusammenlöten oder kompilieren muss hat z.B. nichts im gleichen Unterforum verloren wie ein Modul zu einem Gerät das ich im Laden kaufe und nur auspacke und anstecke.
Selbst das passt nicht immer, einen JeeLink kann man kaufen oder basteln oder ein LGW nehmen und es hat mit Sensoren zu tun, die man kaufen kann, usw., usw.
Beispiel: Irgendwie müsste aber das ganze Thema LaCrosse, PCA301, EC3000, JeeLink, LaCrosseGateway, ... zusammengefasst werden, was aber schon zeigt, dass die Gruppierung eine sehr individuelle Sache ist.
Wenn es für den Anwender passt, passt es aber evtl. für die Entwickler nicht mehr, weil PCA301 "gehört" justme1968 und da muss ich nicht reagieren und umgekehrt.
Für den Anwender passend gruppiert ist oft nicht für die Entwickler richtig gruppiert.
Also könnte man erst mal für den Anwender sinnvoll gruppieren und für die Entwickler eine andere Lösung suchen.
Neue Idee dazu:Wäre es möglich, dass man beim Anlegen eines Beitrags so, wie man ein Symbol auswählen kann, auch ein Modul (00_WasAuchImmer.pm ... 99_Sonstnochwas.pm) aus einer Liste auswählen kann, und dann generell der automatisch aus maintainer.txt ermittelte zugehörige Entwickler eine Benachrichtigung bekommt?
Und dass man dann evtl. danach filtern kann?
Zitat von: HCS am 18 September 2017, 16:04:19
Für den Anwender passend gruppiert ist oft nicht für die Entwickler richtig gruppiert.
Also könnte man erst mal für den Anwender sinnvoll gruppieren und für die Entwickler eine andere Lösung suchen.
Neue Idee dazu:
Wäre es möglich, dass man beim Anlegen eines Beitrags so, wie man ein Symbol auswählen kann, auch ein Modul (00_WasAuchImmer.pm ... 99_Sonstnochwas.pm) aus einer Liste auswählen kann, und dann generell der automatisch aus maintainer.txt ermittelte zugehörige Entwickler eine Benachrichtigung bekommt?
Und dass man dann evtl. danach filtern kann?
Die Gruppierung sollte für den Anwender Sinn machen, sonst könnten wir gleich jedem Entwickler ein Unterforum geben.
Wichtig ist erst mal, dass gruppiert wird, um die Anzahl der Module je Unterforum ein wenig runter zu bekommen.
Dein anderer Vorschlag geht wieder Richtung Forum, Keywords, Tags etc. nach denen benachrichtigt wird.
Das würde das Problem für mich als Entwickler lösen, allerdings nicht für den Anwender, der trotzdem irgendwann den Überblick verliert wenn wir weiter alles neue in die üblichen zwei Unterforen werfen.
Ja. Ich meinte eigentlich auch, dass man beides machen müsste.
Jeder Entwickler sollte ja selber einschätzen können ob es sinnvoll ist ein Modulboard oder eine Gruppe zu definieren.
Aus Sicht es Anwenders und auch aus meiner, ist es definitiv die beste Möglichkeit die gesuchten Infos am schnellsten zu finden.
Ich habe mal ein Beispiel für ein Gruppierung versucht.
Dabei ist mir aufgefallen, dass doch glatt mein 36_EleroSwitch.pm gefehlt hat, habe ich gleich mal nachgetragen :-[
Das ist nicht einfach, bei bestimmt 50% der Module sagt mir der Name nichts, was es schwer macht, herauszufinden, was noch IT+ wäre und welche Module sich noch mit Rollläden beschäftigen.
Und dann noch einen passenden Namen für die Gruppe zu finden ... :)
File Maintainer Forum
=========================================================================
868 MHz IT+ Sender und Empfänger
FHEM/36_EC3000.pm justme1968 Sonstige Systeme
FHEM/36_JeeLink.pm justme1968 Sonstige Systeme
FHEM/36_PCA301.pm justme1968 Sonstige Systeme
FHEM/36_LaCrosse.pm HCS Sonstige Systeme
FHEM/36_LaCrosseGateway.pm HCS Sonstige Systeme
FHEM/36_EMT7110.pm HCS Sonstige Systeme
FHEM/36_Level.pm HCS Sonstige Systeme
Rollladensteuerung
FHEM/10_UNIRoll.pm C_Herrmann SlowRF
FHEM/10_SOMFY.pm viegener Sonstige Systeme
FHEM/36_EleroDrive.pm HCS Sonstige Systeme
FHEM/36_EleroStick.pm HCS Sonstige Systeme
FHEM/36_EleroSwitch.pm HCS Sonstige Systeme
Ich glaube, dass da jemand mit Gruppen mal anfangen müsste und dann weitere Entwickler schauen müssten, ob sie auch Module haben oder kennen, die da noch dazu gehören.
Und wie auf Kommando ist gleich mal wieder "zum Thema passend" eine mail mit:
"[FHEM - Sonstige Systeme] SOMFY und das richtige IO: nur 1 von 3 geht"
bei mir eingeschlagen.
Selbst mit der Gruppierung "Rollladensteuerung" wäre das dann noch so.
Wenn man es aber noch weiter aufteilt, ist man nicht mehr weit von "eine Gruppe pro Modul" entfernt, was dann auch keinen Sinn macht.
Schwierig ...
Ich bin gegen ein Ticketsystem, weil man oft ein Bug nicht von einem Bedienungsfehler oder Feature unterscheiden kann, und im Zweifelsfall noch ein System mehr durchsuchen muss. Es gibt auch der Fall, dass etwas, was als Frage angefangen hat, zu einem Bugfix fuehrt. Weiterhin wird dadurch das hier genannte Problem nicht geloest, weil ein MAINTAINER auch Fragen zu seinem Modul beantworten muesste.
Sonst zu dem direkten URL auf einem konkretes Thema: was spricht dagegen, das als solches zuzulassen?
Kompromissvorschlag...
Wenn jemand unbedingt meint, einen konkreten Thread angeben zu müssen, dann in der vierten Spalte die URL und in der dritten Spalte trotzdem das Unterforum auflisten
fhem.pl rudolfkoenig Sonstiges https://forum.fhem.de/<...>
Das Help Modul ist übrigens aktuell scheinbar noch darauf ausgelegt, dass es zu jedem Modul mit Hilfe auch tatsächlich einen Eintrag in der MAINTAINER.txt findet.
Bei Bastellösungen und anderen Modulquellen gibt es allerdings keinen Match, sieht dann so aus:
2017.09.26 21:00:37 1: PERL WARNING: Use of uninitialized value $line[2] in pattern match (m//) at /opt/fhem/FHEM/98_help.pm line 262.
2017.09.26 21:00:37 1: stacktrace:
2017.09.26 21:00:37 1: main::__ANON__ called by /opt/fhem/FHEM/98_help.pm (262)
2017.09.26 21:00:37 1: main::cref_findInfo called by /opt/fhem/FHEM/98_help.pm (42)
2017.09.26 21:00:37 1: main::CommandHelp called by /opt/fhem/fhem.pl (1174)
2017.09.26 21:00:37 1: main::AnalyzeCommand called by /opt/fhem/fhem.pl (1027)
2017.09.26 21:00:37 1: main::AnalyzeCommandChain called by /opt/fhem/FHEM/01_FHEMWEB.pm (2499)
2017.09.26 21:00:37 1: main::FW_fC called by /opt/fhem/FHEM/01_FHEMWEB.pm (862)
2017.09.26 21:00:37 1: main::FW_answerCall called by /opt/fhem/FHEM/01_FHEMWEB.pm (548)
2017.09.26 21:00:37 1: main::FW_Read called by /opt/fhem/fhem.pl (3448)
2017.09.26 21:00:37 1: main::CallFn called by /opt/fhem/fhem.pl (692)
2017.09.26 21:00:37 1: PERL WARNING: Use of uninitialized value $line[2] in concatenation (.) or string at /opt/fhem/FHEM/98_help.pm line 265.
2017.09.26 21:00:37 1: stacktrace:
2017.09.26 21:00:37 1: main::__ANON__ called by /opt/fhem/FHEM/98_help.pm (265)
2017.09.26 21:00:37 1: main::cref_findInfo called by /opt/fhem/FHEM/98_help.pm (42)
2017.09.26 21:00:37 1: main::CommandHelp called by /opt/fhem/fhem.pl (1174)
2017.09.26 21:00:37 1: main::AnalyzeCommand called by /opt/fhem/fhem.pl (1027)
2017.09.26 21:00:37 1: main::AnalyzeCommandChain called by /opt/fhem/FHEM/01_FHEMWEB.pm (2499)
2017.09.26 21:00:37 1: main::FW_fC called by /opt/fhem/FHEM/01_FHEMWEB.pm (862)
2017.09.26 21:00:37 1: main::FW_answerCall called by /opt/fhem/FHEM/01_FHEMWEB.pm (548)
2017.09.26 21:00:37 1: main::FW_Read called by /opt/fhem/fhem.pl (3448)
2017.09.26 21:00:37 1: main::CallFn called by /opt/fhem/fhem.pl (692)
Gruss, Markus
Mag sein, aber ich hab grade Urlaub.
Zitat von: betateilchen am 17 September 2017, 09:35:44
Es ergibt für mich überhaupt keinen Sinn, sämtliche Fragen zu einem Modul in einem einzigen Thread behandeln zu wollen. Das dient weder der Übersichtlichkeit noch ist es für Hilfesuchende tatsächlich hilfreich
Diese Monsterthread Eigenheit (oder Unsitte) hat mich im FHEM Forum von Anfang an gestört. Kenne ich von keinem anderen Forum. Insofern kann ich Deine Initiative nur unterstützen.
Auf Grund eines aktuellen Falls (https://forum.fhem.de/index.php/topic,77391.0.html) ist mir aufgefallen, dass es unglücklich ist, wenn in der Maintainer.txt das Development Forum als Anlaufstelle genannt wird. Die wenigsten User können hier schreiben und müssten somit ihr Problem wo anders nennen. Daher mein Vorschlag darüber nachzudenken, ob es Sinn macht bei manchen Modulen dies als Forum anzugeben.
TimeSeries.pm wird nicht direkt von den Benutzer verwendet, und ich gehe davon aus, dass in diesem Fall das Problem auch nicht da ist, da es seit knapp einem Jahr nicht mehr geaendert wurde. Selbst wenn doch, kann der Maintainer des ausloesenden Moduls das Problem besser beschreiben, und er sollte hier Schreibrechte haben.
Da gebe ich dir Recht, aber es läuft bei einem User als Meldung von TimeSeries auf, das heißt der denkt erst Mal, dass es daran liegt. Schaut er nun in die Maintainer, weil er dazu etwas sagen will, dann sieht er Developer. Da kann er nicht schreiben, was er dann im Anfängerforum macht. Dies ist eigentlich auch kein Problem soweit, ich frage mich nur, ob es Sinn macht, dass die Module in der Maintainer auf Developer verweisen, wenn dort nicht jeder schreiben kann?
Da ich deine Argumentation jedoch nachvollziehen kann und wohl mit dem Anfängerforum (als "Notlösung") leben kann, lassen wir es so. Der User muss ja eh über stacktrace finden wo das eigentliche Problem liegt.
Alle Jahre wieder... ;-)
Meta.pm hat folgende Module als fehlend in MAINTAINER.txt gemeldet, sollten die dann nachgepflegt werden?
Meinem Impuls die dann implizit unserem "root" Rudi zuzuordnen widerstehe ich gerade noch ;D
FHEM/00_SmartMeterP1.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/16_STACKABLE.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/20_FRM_RGB.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/26_KM273.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/70_NEUTRINO.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/71_PIONEERAVRZONE.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/73_WaterCalculator.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/84_IOhomecontrolDevice.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/88_HMCCURPC.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/88_HMCCURPCPROC.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/89_VCLIENT.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/93_RFHEM.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/97_PiXtendV2.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/98_ArduCounter.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/98_EDIPLUG.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/98_HMtemplate.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/98_livetracking.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/98_template.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/98_UbiquitiMP.pm has defined VCS data but is not registered in MAINTAINER.txt
FHEM/98_uptime.pm has defined VCS data but is not registered in MAINTAINER.txt
Hallo,
das erinnert an den Thread zur Restrukturierung der Foren. Ich schlage also vor:
Wir fangen einfach an und legen einzelne Foren an bei Systemen/Modulen mit viel Trafik. Warum gibt es 6 CUL-Foren, warum gibt es kein Signalduino-Forum?
Ich finde als Ziel sinnvoll:
FHEM
...
Frontends (gibt es schon)
Module (Neu, hier schreibt, wer es nicht zuordnen kann/will)
... (Wenn ein Modul viel Trafic macht oder der Autor es will)
FHEM-Hardware (gibt es schon)
FHEM - Hausautomations-Systeme (gibt es schon)
Gateways (vielleicht neben Sonstige Systeme)
Signalduino
...
Geräte
Xiomi
Shelly
...
Wenn das so denkbar wäre und jemand in "FHEM - Hausautomations-Systeme" ein Unterforum Gateways mit dem Unter-Unterforum Signalduino anlegt, dann ist sonstige Systeme plötzlich übersichtlich.
Horst
Thema verfehlt.
Es geht nur um den fehlenden Eintrag in MAINTAINER.txt. Die Zuordnung zu bestehenden Foren sollte machbar sein.
In meinem Kopf war ein Bezug zum Thema da.
Die Diskussion Unterforum <-> Thread war ja wegen des Trafiks in den Unterforen und der wäre überschaubarer.
Das war mein Bezug, trotzdem Tschuldigung fürs abschweifen.
Horst
Huch!
98_livetracking.pm ist meins, Eintrag kommt mit dem nächsten Checkin.
Ein paar Einträge hatten Tippfehler, die ich korrigieren konnte.
Es bleiben trotzdem noch eine ganze Menge Module ohne Maintainer übrig:
FHEM/00_SmartMeterP1.pm has defined VCS data but is not registered in MAINTAINER.txt.
FHEM/26_KM273.pm has defined VCS data but is not registered in MAINTAINER.txt.
FHEM/73_WaterCalculator.pm has defined VCS data but is not registered in MAINTAINER.txt.
FHEM/93_RFHEM.pm has defined VCS data but is not registered in MAINTAINER.txt.
FHEM/97_PiXtendV2.pm has defined VCS data but is not registered in MAINTAINER.txt.
FHEM/98_EDIPLUG.pm has defined VCS data but is not registered in MAINTAINER.txt.
FHEM/98_HMtemplate.pm has defined VCS data but is not registered in MAINTAINER.txt.
FHEM/98_livetracking.pm has defined VCS data but is not registered in MAINTAINER.txt.
FHEM/98_template.pm has defined VCS data but is not registered in MAINTAINER.txt.
FHEM/98_uptime.pm has defined VCS data but is not registered in MAINTAINER.txt.
Im FHEM Installer wird nun derjenige, der zuletzt was an dem jeweiligen Modul geändert hat, als Co-Author aufgeführt.
Oh, übersehen. Ich reiche das nach (88_HMCCU.*)
Zitat von: Loredo am 17 März 2019, 11:02:54
FHEM/98_EDIPLUG.pm has defined VCS data but is not registered in MAINTAINER.txt.
Das Modul wurde von mir letztes Jahr im März nach contrib verschoben und das auch so in der MAINTAINER.txt dokumentiert.
Wenn sich das jetzt auch noch immer im FHEM Dir befindet werde ich wohl Mithilfe benötigen wie das dort endgültig verschwindet.
ZitatWenn sich das jetzt auch noch immer im FHEM Dir befindet werde ich wohl Mithilfe benötigen wie das dort endgültig verschwindet.
svn delete FHEM/98_EDIPLUG.pm
svn commit
einige Korrekturen konnte ich selbst an MAINTAINER.txt vornehmen.
Trotzdem bleiben folgende Dateien bzw. sind noch ein paar aus den FHEM Packages hinzugekommen:
FHEM Modules:
98_HMtemplate.pm (zuletzt geändert von: martinp876)
26_KM273.pm (zuletzt geändert von: mike3436)
97_PiXtendV2.pm (zuletzt geändert von: PiXtend)
93_RFHEM.pm (zuletzt geändert von: chris1284)
00_SmartMeterP1.pm (zuletzt geändert von: fhemmiv)
98_template.pm (zuletzt geändert von: neubert)
98_uptime.pm (zuletzt geändert von: betateilchen)
73_WaterCalculator.pm (zuletzt geändert von: Sailor)
FHEM Packages:
RTypes.pm (zuletzt geändert von: borisneubert)
WMBus.pm (zuletzt geändert von: kaihs)
Solange diese Dateien in MAINTAINER.txt keinen Eintrag haben, behandle ich diese als herrenlos in 98_Installer.pm.
Dabei wird derjenige, der die letzte Änderung durchgeführt hat, als Co-Author aufgeführt.
Sollen in der MAINTAINER.txt wirklich alle Dateien stehen oder nur die Module die ein Anwender direkt verwenden kann?
WMBus.pm ist nur ein Hilfsmodul für 36_WMBUS.pm und kann alleine vom einem Anwender nicht verwendet werden.
Ich kenne die definitive Antwort darauf nicht.
Was ich jedoch beobachte ist, dass bis auf diese beiden Dateien (und einige wenige, die Rudi eingecheckt hat, jedoch nicht offiziell betreut) bisher keine Referenz haben.
Wenn du also 36_WMBUS.pm betreust, dann solltest du auch WMBus.pm entsprechend mit aufführen.
Ich persönlich denke, dass FHEM Packages in erster Linie nicht für Anwender gedacht sind, sondern für Modulentwickler (egal ob diese dann nur privat genutzt oder auch veröffentlicht werden). Für diesen Fall sollten Modulentwickler wissen, wen sie dafür wo ansprechen können, wenn es Fragen gibt. Wo oder wie dieser Support stattfindet, ist IMHO dabei nicht so wichtig wie bei einem FHEM Modul. Ich selbst verlinke deshalb lieber das FHEM Development Board und keines der Anwender Boards. Wahrscheinlich kann man auch einfach kein Forum verlinken und nur seinen Benutzernamen - dafür gibt es aber derzeit glaube ich keine vereinbarte Konvention für MAINTAINER.txt. Zumindest wäre ich im Sinne von Meta.pm da sehr dankbar, wenn diese Kennzeichnungen einheitlich blieben, um sie auch entsprechend auswerten zu können ;-)
MAINTAINER.pm dokumentiert auch, wer z.Zt. der Zustaendige fuer eine Datei ist, es sollten mAn alle Dateien aufgelistet sein.
Zitat von: Loredo am 23 März 2019, 09:48:54
Ich selbst verlinke deshalb lieber das FHEM Development Board und keines der Anwender Boards. Wahrscheinlich kann man auch einfach kein Forum verlinken und nur seinen Benutzernamen - dafür gibt es aber derzeit glaube ich keine vereinbarte Konvention für MAINTAINER.txt. Zumindest wäre ich im Sinne von Meta.pm da sehr dankbar, wenn diese Kennzeichnungen einheitlich blieben, um sie auch entsprechend auswerten zu können
die Einheitlichkeit der MAINTAINER.txt wurde bereits bei Einführung des Befehles "help" diskutiert, denn dieser Befehl versucht, aus der Datei die zum Modul gehörenden Informationen (wie heißt, das Modul genau, wer ist der Maintainer und welches Unterforum ist für Fragen vorgesehen) zu lesen und anzuzeigen.
"help infopanel" liefert beispielsweise
Module: 55_InfoPanel.pm Maintainer: betateilchen Forum: Unterstuetzende Dienste
Die Angabe des Developer-Forums zu einem Modul in der MAINTAINER.txt macht m.E. wenig Sinn, da reguläre Benutzer in diesem Forum keine Fragen stellen können.
Zitat von: Loredo am 22 März 2019, 18:55:26
WMBus.pm (zuletzt geändert von: kaihs)
Ist jetzt eingetragen.