Featurewunsch: EnOcean plugin

[Morg]

Ergänzung: ich habe mal in den Code geschaut - wenn kein enocean_rx_key definiert ist, wird das Item gar nicht geparst. Das geht aus der Doku nicht ansatzweise hervor, das sollte bitte deutlich gemacht werden. Gemäß Doku würden enocean_rx_id und enocean_rx_eep reichen, aber das stimmt nicht.

Mit eep und key geht es...

Achso, und im Hinblick auf restartable Plugins (und damit die Voraussetzung für bearbeitbare Items): das Plugin öffnet das serielle Device schon in init, das sollte aber erst in run erfolgen. Ein Test, ob der Port/das Gerät zugreifbar ist, wäre möglich.

[Sipple]

Meine sehen so aus:

    Griff_Galerie:
        enocean_rx_id: 00001249CA
        enocean_rx_eep: F6_10_00
        Status:
            type: num
            enocean_rx_key: STATUS

Liefert
0 bei geschlossen (Griff nach unten)
1 bei geöffnet (Griff quer)
2 bei gekippt (Griff nach oben)

Sehe grad, du hast es schon gefunden. Deine letzte Nachricht wurde mir bis eben unterschlagen.

[Morg]

Ja, ich habe es der Einfachheit ohne Unteritem gemacht. Trotzdem Danke für die Rückmelsung

Die neue Generation der Griffe meldet nur noch zu/offen, gekippt ist jetzt auch "offen". Aber gut, damit kann ich leben.

[Hasenradball]

aschwith,

ich würde gerne das enocean plugin in kleinen Schritten refracturen, und nach den Vorbild von "Clean Code"
(Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin))
die Software etwas strukturieren.

Was will ich damit bezwecken?
Die Software Pakete in kleine Häppchen teilen, so dass Änderungen, neue Aktoren und Features leichter zu implementieren sind und das das main file etwas übersichtilicher wird.

Um mal etwas konkret zu werden wäre der erste Schritt den ich machen würde zum Beispiel folgendes:

• die Konstanten strukturieren und in ein separates File packen und per import einbinden.

Das main file ("__init__.py") würde dann schon mal etwas übersichtilicher aussehen.

Gerne kann ich das in einem PR mal vorschlagen.
Wäre das gewünscht?

[Morg]

Um die Konstanten auszulagern und ggf. noch weiter auf mehrere Dateien aufzuteilen, halte ich das Plugin für zu "klein". Es würde bestenfalls der Navigierbarkeit in der __init__.py helfen, aber ich halte das enocean-Plugin (dito tasmota, zigbee2mqtt) für zu klein um die "echt" modular aufzuteilen.

Das zigbee2mqtt habe ich beim Neuschreiben schon - funktional - modularisiert, so dass Erweiterungen (aus meiner Sicht) einfacher werden. Ich hatte überlegt, enocean vergleichbar zu bearbeiten, aber das ist derzeit keine Priorität.

Hast du einen Grund, dass du das umschreiben willst, oder brauchst du ein Studienobjekt?

PS: agile Softwareentwicklung ist nicht immer der richtige Weg, es gibt verschiedene sehr kontroverse Meinungen dazu. Kennst du "Weniger schlecht programmieren" (Passig/Jander) oder "The Art of Readable Code" (Boswell)? Beide aus meiner Sicht besser geeignet, um in Umgebungen wie dieser Code zu schreiben, den ggf. später andere (die vielleicht auch nicht mehr Erfahrung haben) lesen oder ändern möchten...

[Hasenradball]

Hi @Morg,

dank für Deine Antwort.
Nein ich brauch kein Studienprojekt. Mir liegt nur das enocean plugin sehr am Herzen, da ich enochean sehr mag.
Ich bin etwas anderer Meinung bei dem Thema "das plugin ist zu klein und kleine Verbesserungen einfließen zu lassen".

Das Ziel ist keineswegs hier agile Softwareentwicklung in das Project zu bringen (ob dies gut oder schlecht ist möchte ich hier gar nicht diskutieren oder bewerten).

Aber ich finde es gibt schon noch etwas Potential.

Die Constanten in ein File auszulagern und dies dann per import einzubinden finde ich ein erster und kein schlechter Schritt.

Schau doch mal in das File prepare_packet_data.
Hier wird noch sehr viel hart codiert was man theoretisch oft mit einer Konstanten abdecken kann.

Beispiel:

 rorg = 0xa5

Die Variable rorg wird hier in jedem Actor neu definiert => ließe sich schön mit Konstanten abdecken die man ganz einfach importiert.

[Hasenradball]

Auch hier:

die Rorgs könnte man als Konstanten anlegen.
Und da auf diese zurückgreifen wo sie gebraucht werden.
Anstatt alle jedesmal neu anzulegen.
Bildschirmfoto vom 2024-01-10 23-11-43.png


Also das mit den Konstanten finde ich schon mal ein erster wichtiger Schritt.

😀

PS: Und es würde der Übersichtilichkeit im main file dienen...

[Morg]

Da hast du mich falsch verstanden. Jedes Plugin hat Potenzial zur Verbesserung, egal wie klein. Hartkodierte Werte durch "Konstanten" zu ersetzen, finde ich eine gute Idee. Konstanten in (Achtung: ) einem so kleinen Plugin (Ende) in eine eigene Datei auszulagern, würde ich nicht machen, weil es meiner Meinung nach unübersichtlicher wird, ich müsste zum Debuggen immer zwei Dateien auf haben.

Wenn du meinst, dass du das tun willst - mach es und stell einen PR.

[Hasenradball]

Hi Morg,

was ich halt etwas ungünstig finde, ist die Konstanten in "__init__.py" definieren, aber dann in den anderen Files diese "hartcodieren" weil ich die Werte ja nicht importieren kann.

[Morg]

Jetzt verstehe ich, was du meinst.. aber wenn ich die eep_parser.py sehe, dann gibt es erstmal noch ganz andere Baustellen, an denen man optimieren könnte...

[Hasenradball]

Hi Morg,

sehe ich genauso, dass es noch mehrere Baustellen gibt.
Aber ich kenne das von dem SH Projekt so, dass man Änderungen in kleinen Schritten einbringen soll.
Ich habe eben mal einen PR gestellt bei dem die CRC Table ausgelagert wurde.

Ich sehe das im Grunde so.
Erst mal den Balast wegschaffen (hier Constanten auslagern), dann lassen sich die anderen Baustellen vielleicht schon einfacher beheben.

Wenn man nie damit anfängt... wird man nie fertig

[Morg]

Ich hätte mich nicht mit den Konstanten aufgehalten, wenn ich "eh" das halbe Plugin neuschreiben will aber das dauert auf meiner Seite noch eine ganze Weile, also mach ruhig...

[Hasenradball]

Morg
Moin, enocean läuft mit dem aktuellen dev ohne Fehler.

Hast Du noch einen Tipp wo man genau hinschauen sollte?
Hast Du noch weitere Änderungen bei enocean geplant?
Vielleicht könnten wir uns austauschen?

[Morg]

Nein, wenn es läuft, habe ich erstmal keinen Änderungsbedarf. Problem war das "Verlieren" der Verbindung und die fehlende Recovery.

Ich denke, meine Schwerpunkte werden erstmal im Bereich core und ggf. sdp liegen...