Vorschläge für den Developer Guide im Wiki

Begonnen von CoolTux, 07 Oktober 2018, 10:59:26

Vorheriges Thema - Nächstes Thema

CoolTux

Hallo,

Ich würde gerne Erweiterungen im Wiki des Developer Guide anbringen.
1. Empfehlung nicht in $hash->{STATE} zu schreiben sondern das Reading state zu verwenden
2. lieber mit packages zu arbeiten als mit Präfix vor den Funktionsnamen


Wie steht Ihr dazu?



Grüße
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

rudolfkoenig

1. Ja, das sollte auch so sein, sonst kann der Endanwender die zusammengefasste Darstellung nicht aendern.
2. Ich habe damit kein Problem, mir sind aber noch nicht alle Nebeneffekte klar.

dev0

Zitat2. lieber mit packages zu arbeiten als mit Präfix vor den Funktionsnamen
Empfehlung ok, aber bitte nicht zur Pflicht machen.

Ich fände ein gut dokumentiertes Prototyp-Modul, dass man Einsteigern an die Hand geben kann sinnvoller. Vielleicht sogar ein einstufiges und ein zweistufiges Modul.

rudolfkoenig

ZitatIch fände ein gut dokumentiertes Prototyp-Modul, dass man Einsteigern an die Hand geben kann sinnvoller. Vielleicht sogar ein einstufiges und ein zweistufiges Modul.
Ich habe das mal mit contrib/00_TAHR.pm angefangen, allerdings ist die letzte Aendrung auch 5 Jahre alt.

CoolTux

Ich kann mich da gerne mal versuchen im Winter.
Pflicht soll es nicht sein. Aber wäre schön wenn man sich danach richten würde. Bisschen Einheitlichkeit tut gut.
Alte Module sind natürlich davon ausgeschlossen.
Dummerweise nehmen viele Anfänger sich ein bestehendes Modul als Vorlage  ;D
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

dev0

ZitatDummerweise nehmen viele Anfänger sich ein bestehendes Modul als Vorlage
Ich habe auch so angefangen, dass ich mir das eine oder andere Modul zur Vorlage genommen habe, ohne es im Detail zu verstehen. Daher die Anregung des Prototypen. Vielleicht sogar mehrere für unterschiedliche Zwecke (HTTP Abfragen, CULs, MQTT,...)

Sidey

Hi,

Wieso sollte man überhaupt in das Reading State schreiben?
Wäre es nicht besser die Anzeige in State nur noch über stateformat zu steuern?
Das Attribut verwendet der FHEM Admin ja ohnehin um die Darstellung von State zu bestimmen.

Stateformat kann man ja mit einem vordefinierten Wert belegen.

Die Tatsache, dass man mit DEVICENAME und DEVICENAME:state auf Events von state reagieren kann, fand ich auch schon schwer verständlich.

Nebenwirkungen gibt es dadurch in soweit, dass man nicht mehr auf Events von state reagieren kann. Für neue Module kein Problem nehme ich an. Für bestehende schon eher.

Was ich jetzt nicht geprüft habe, wie das Event zu state aussieht, wenn stateformat gesetzt ist.


Die Idee mit einem Beispiel Modul was good practices enthält finde ich gut.
Für neue Module ein Package definieren sollte auch möglich sein.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

CoolTux

Zitat von: Sidey am 07 Oktober 2018, 16:56:09
Hi,

Wieso sollte man überhaupt in das Reading State schreiben?
Wäre es nicht besser die Anzeige in State nur noch über stateformat zu steuern?
Das Attribut verwendet der FHEM Admin ja ohnehin um die Darstellung von State zu bestimmen.

Stateformat kann man ja mit einem vordefinierten Wert belegen.

Die Tatsache, dass man mit DEVICENAME und DEVICENAME:state auf Events von state reagieren kann, fand ich auch schon schwer verständlich.

Nebenwirkungen gibt es dadurch in soweit, dass man nicht mehr auf Events von state reagieren kann. Für neue Module kein Problem nehme ich an. Für bestehende schon eher.

Was ich jetzt nicht geprüft habe, wie das Event zu state aussieht, wenn stateformat gesetzt ist.


Die Idee mit einem Beispiel Modul was good practices enthält finde ich gut.
Für neue Module ein Package definieren sollte auch möglich sein.

Grüße Sidey

Entweder verwechselst Du was oder ich habe falsch gelesen. Es geht ja darum das das Modul das Reading state setzen soll an stelle des Internals STATE. Denn das Internal STATE kann der User durch stateFormat beeinflussen so wie er es sich wünscht. Nur leider wird dann der Userwunsch vom Modul überschrieben wenn $hash->{STATE} gesetzt wird.
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

Markus M.

Ihr verwirrt mich :)
Aber ja: In $hash->{STATE} sollte das Modul im Normalfall nicht direkt schreiben.
Ich habe aber auch Account Devices in zweistufigen Modulen bei denen ich es tue, weil es dort erst gar kein Reading gibt.

Meiner Meinung nach sinnvolle Ausnahme in jedem Modul: Katastrophale Fehler bei der Definition, z.B.:
$hash->{STATE} = "XML::Simple is required!";
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0

rudolfkoenig

Wenn man XML::Simple per use (und nicht require) holt, dann gibt es einen Fehler beim Laden des Moduls, und der Benutzer kann es gar nicht definieren.

CoolTux

Zitat von: Markus M. am 07 Oktober 2018, 17:17:06
Ihr verwirrt mich :)
Aber ja: In $hash->{STATE} sollte das Modul im Normalfall nicht direkt schreiben.
Ich habe aber auch Account Devices in zweistufigen Modulen bei denen ich es tue, weil es dort erst gar kein Reading gibt.

Meiner Meinung nach sinnvolle Ausnahme in jedem Modul: Katastrophale Fehler bei der Definition, z.B.:
$hash->{STATE} = "XML::Simple is required!";

Ob es ein Reading state gibt oder nicht entscheidest doch Du selbst als Modulautor. Jedes Device hat doch einen Status. Diesen kann man (sollte man) doch festhalten.
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

Sidey

Ja ich sag's ja. Ich bin von der Situation immer wieder verwirrt dass es das Internal STATE gibt, was über stateformat definiert wird und das Reading state.

Wenn man kein Reading state hätte wäre die Verwirrung nicht so stark.

Gesendet von meinem XT1650 mit Tapatalk

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

CoolTux

Zitat von: Sidey am 07 Oktober 2018, 18:44:02
Ja ich sag's ja. Ich bin von der Situation immer wieder verwirrt dass es das Internal STATE gibt, was über stateformat definiert wird und das Reading state.

Wenn man kein Reading state hätte wäre die Verwirrung nicht so stark.

Gesendet von meinem XT1650 mit Tapatalk

Merke schon das es verwirrt  ;D
Also das Internal STATE wird über das Reading state gesetzt. Es kann aber mit dem Attribut stateFormat beeinflusst/geändert werden. Ist stateFormat nicht gesetzt richtet sich das Internal STATE immer nach dem Reading state.
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

Sidey

Zitat von: CoolTux am 07 Oktober 2018, 17:57:47
Ob es ein Reading state gibt oder nicht entscheidest doch Du selbst als Modulautor. Jedes Device hat doch einen Status. Diesen kann man (sollte man) doch festhalten.

Wäre das eine gute Idee kein Reading state mehr zu setzen und stattdessen stateformat mit einem Wert zu belegen damit das internal STATE gesetzt ist?

Informationen zum Status befinden sich dann ja in STATE und alles andere in readings, welche zum Gerät passen.
Ich habe vermutlich irgendwas übersehen bei dieser Idee.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

CoolTux

Da Du ja der Modulautor bist kannste das halten wir Du willst.
Aber bedenke bitte das die Devise ist das Attribute dem User gehören.
Persönlich bin ich dafür das es immer ein Reading state geben sollte der einen vernünftigen Status des Devices wieder gibt. Eigentlich sollte selbst einem Modulautor STATE gar nicht interessieren. Darum kümmert sich fhem.pl
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