Wunschliste FHEM Entwicklung

Begonnen von RichardCZ, 16 März 2020, 19:09:53

Vorheriges Thema - Nächstes Thema

rabehd

Zitathabe ich bereits ca. 40x gehört, meist von der mittleren - leicht unflexiblen - Entwicklerriege in Unternehmen,
Kommunikationsformen sind Deine Stärke?

Ich hänge mich fachlich da nicht rein. Dein wie finde ich gewöhnungsbedüftig.
Auch funktionierende Lösungen kann man hinterfragen.

justme1968

ich habe nicht versucht zu diskreditieren. warum auch. das tust du mit deiner art und weise gerade selber.

viel spass noch mit fhem. oder mit was auch immer.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

RichardCZ

Zitat von: rabehd am 17 März 2020, 10:28:26
Kommunikationsformen sind Deine Stärke?

Ich hänge mich fachlich da nicht rein. Dein wie finde ich gewöhnungsbedüftig.

Ich schickte ja vorab, dass sich keiner auf den Schlips getreten fühlen soll. Das passiert häufig, weil man sich dann doch mit dem eigenen Code identifiziert.

Wenn dann jemand kommt und sagt "der code ist scheisse", dann führt das häufig dazu, dass man das als persönlichen Angriff wertet, dann kommen eben so Reaktionen wie von justme "dogmatisch 15 Jahre altes Buch" "Du macht 20 Jahre nix anderes als Perl" "fahrlässig...."

Ich habe nur angemerkt, dass ich diese Reaktionen kenne und auch von wem die meist so kamen. Es gibt durchaus drastischere Vergleiche die ich aber für mich behalten habe - Der Kommunikationsform zuliebe.

---

Ok, machen wir folgendes. Meine Meinung zu dem Code lassen wir erstmal so stehen - als Schrei in die Nacht hinein. Jetzt schaue ich erstmal was ich so bei meiner lokalen Installation umbiegen kann ohne dass es bricht, naja und vielleicht findet dann der ein oder andere "Hobbyentwickler" meine Herangehensweise interessant.

Das ist zwar nichtintrusiv, kann aber früher oder später zu einem Fork führen. Das wäre jetzt nicht meine Absicht, deswegen sondiere ich ja wie so das Sentiment diesbezüglich ist. IMHO müsste sich dazu mal Rudolf König äußern. So wie ich die commit Historie sehe, ist sein Beitrag "ganz überwiegend relevant".
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

rudolfkoenig

ZitatDas ist dort öffentlich und da werde ich ein wenig drauf rumklopfen. Schreibrechte in "FHEM Development", wären nett, weil ich doch einige Fragen zu dem Code habe - die ich vermutlich dort stellen sollte.
Bitte dafuer einen Beitrittsantrag stellen (keine Ahnung wo), bisher wurde der Zugang noch keinem verwehrt.

Zu den anderen Sachen:
- Perl-Stil / Tools / etc moegen veraltet sein, und ich bin dafuer sie zu aendern, wenn das mir oder den Benutzer unter dem Strich was bringt. "modern" oder "entspricht dem PBP Richtlinien" alleine fuer sich rechtfertigt nicht die hunderte von Stunden Aufwand in Entwicklung und Support.
- github: bin dagegen, da ich mit FHEM schon bei zwei unterschiedlichen Cloud-Anbieter Probleme hatte.
- git vs. svn: git bietet Vorteile, die ich in FHEM Umfeld nicht brauche, ist dafuer komplizierter und ein Umstieg Arbeit (und damit meine ich nicht den Inhalt der Repository zu kopieren). pull-requests sind mir zu anonym, ich moechte die Probleme oeffentlich diskutieren.
- trac vs Forum: man kann nie Fragen und Bugreports trennen, und ich will Diskussionen an unterschiedlichen Stellen vermeiden.
- Benutzerzahlen: Hochgerechnet von https://fhem.de/stats/statistics.html, aus Anzahl bestimmter Modulen, wo wir aus anderen Quellen die genauen Zahlen kennen. Klar ist es eine Schaetzung.

FHEM wird nicht per 5-Jahresplan oder Wuensche-Erfuellen gebaut, sondern weil jemand ein Problem loesen muss oder eine Idee ausprobieren will, _und gerade Zeit hat_. Die Mitwirkenden aufzufordern alles umzubauen ist illusorisch, selbst wenn es konkrete Vorteile bringt. Wenn ein Umbau realistisch waere, dann haette ich FHEM vor vielen Jahren in einer anderen Sprache neu implementiert.


Ich wuerde empfehlen einen neuen oder verwaisten Modul zu nehmen, und diesen vorbildhaft zu gestalten. Wir koennen dieses Modul als Grundlage fuer neue Module nennen, und wenn einem aktiven Maintainer klar wird, welche konkreten Vorteile es bringt, wird er das auch uebernehmen.

RichardCZ

Zitat von: rudolfkoenig am 17 März 2020, 11:11:46
Ich wuerde empfehlen einen neuen oder verwaisten Modul zu nehmen, und diesen vorbildhaft zu gestalten. Wir koennen dieses Modul als Grundlage fuer neue Module nennen, und wenn einem aktiven Maintainer klar wird, welche konkreten Vorteile es bringt, wird er das auch uebernehmen.

Yep. So werde ich das auch machen - ist wohl der pragmatischste Ansatz.

Nur zu zwei/drei Punkten, die ich doch anders sehe

Zitat
- trac vs Forum: man kann nie Fragen und Bugreports trennen, und ich will Diskussionen an unterschiedlichen Stellen vermeiden.

Verstehe ich, allerdings ist m.E. die Kopplung patches/Bugreports/Wishlist wichtiger als die Kopplung Diskussion/Frage/Bugreport. Instebesondere, weil Trac das ja schön integriert.

Zitat
- github: bin dagegen, da ich mit FHEM schon bei zwei unterschiedlichen Cloud-Anbieter Probleme hatte.

GitHub bin ich auch dagegen, bin auch kein Freund von Cloud. https://gl.petatech.eu/root/FHEM ist auf meinem Server, self-hosted. So wie man das eben früher mit Trac gemacht hat. Also die GitLab CE (Community Edition) kann der FHEM e.V. auch selbst hosten. Ist wie Trac - nur besser.

Zitat
Die Mitwirkenden aufzufordern alles umzubauen ist illusorisch, selbst wenn es konkrete Vorteile bringt.

Das würde ich nie machen, bzw. würde ich mir nicht anmaßen mit der Zeit anderer Leute zu disponieren. Was ich aber auf jeden Fall vermeiden wollte, wäre ein "Ich ändere die Sachen und dann wäre das vergebene Liebesmüh' - weil das den Leuten 'zu viel wäre'".

Aber mittlerweile bin ich zu dem Schluss gekommen, dass ich es mit FHEM "so oder so" für mein Häuschen probieren will. Da kann ich dem schon ein Arbeitskontingent widmen ohne erstmal darauf zu schauen ob das in den Entwicklungszweig aufgenommen wird oder nicht.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

CoolTux

Zitat von: RichardCZ am 17 März 2020, 10:27:28
Ich habe mir erlaubt mal trunk in ein privates Git unter GitLab zu exportieren.

https://gl.petatech.eu/root/FHEM

Das ist dort öffentlich und da werde ich ein wenig drauf rumklopfen. Schreibrechte in "FHEM Development", wären nett, weil ich doch einige Fragen zu dem Code habe - die ich vermutlich dort stellen sollte.

FHEM Development kannst einfach über das Forum beantragen. Musst nur ne Gruppenanfrage machen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

mahowi

Zu Schreibrechten im Development Forum: https://forum.fhem.de/index.php/topic,9658.0.html
ZitatDu kannst über Dein persönliches Profil den Beitritt zu obigen Gruppen beantragen, sofern Du noch keine Berechtigungen in diesem Board hast.

Das geht recht zügig.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

curt

Zitat von: RichardCZ am 17 März 2020, 11:28:00
ZitatIch wuerde empfehlen einen neuen oder verwaisten Modul zu nehmen, und diesen vorbildhaft zu gestalten.

Yep. So werde ich das auch machen - ist wohl der pragmatischste Ansatz.

Hast Du zufällig so einen Rasenmähroboter (mit dem zusätzlichen Wlan-Modul)? In meiner Erinnerung ist das Modul Robonect verwaist: Den Maintainer gibt es schon noch, aber er hat keinen Robot mehr. Gleichzeitig hat das Wlan-Interface weitere Funktionen bekommen.
RPI 4 - Jeelink HomeMatic Z-Wave