Inzwischen habe ich mir den OWX Quelltext weiter angeschaut, im Hinblick auf Integration von Esera Controller Support. Der größte mögliche Vorteil dieser Integration wäre ein insgesamt reduzierter Wartungsaufwand, durch gemeinsam verwendeten Source Code. Idee: Bug Fixes nur einmal machen und von neuen Features mit jeder Hardware sofort profitieren.
Dazu habe ich mir den Source Code von 00_OWX und 21_OWSWITCH bzgl. Gemeinsamkeiten mit EseraOneWire angesehen, siehe Anhang. Ich habe angenommen, dass wir die Hardware-Kommunikation mit dem Esera Controller in OWX hinbekommen können. Allerdings sehe ich im Moment noch keine konkrete Lösung für den Umgang mit asynchronen Nachrichten vom Controller.
Hier eine Zusammenfassung der weiteren Analyse:
- Der Esera spezifische Quelltext läßt sich nicht in einer neuen Datei in Anlehnung an OWX_CCC zusammenfassen. Es wären auch Dinge in 00_OWX und in allen Clients (OWTHERM, OWSWITCH, usw.) verteilt.
- Es gibt Aspekte im Source Code, die auch Esera braucht, die man aber nicht nur mit OWX, sondern noch allgemeiner wiederverwenden kann.
- autocreate und 2-stufiges Modell (siehe Wiki) - wird von OWX teilweise selbst implementiert
- DevIo (siehe Wiki) - wird auch von OWX verwendet, aber nicht genau wie im Wiki (siehe Analyse von OWXCCC, write-Funktion)
- Queue für asynchrone Kommunikation. Hier scheint es leider bislang noch keinen Standard zu geben, jedenfalls habe ich auf Anhieb mehrere Implementierungen in anderen Modulen gefunden.
- Es gibt nicht viel Quelltext der für Esera ohne Anpassungen funktionieren würde.
- Wenn man 66_EseraOneWire.pm ansieht findet man darin fast keinen Source Code der nicht Esera-spezifische Dinge tut. Die Ausnahme ist die schon oben erwähnte Queue/TaskList.
- Es gibt konzeptionelle Unterschiede zwischen OWX und dem Esera Controller, die sich in OWX nur schwer abbilden lassen, oder die die Komplexitaet von OWX nochmals erhoehen würden.
Konzeptionelle Unterschiede:
- Periodische Readings werden von der Hardware kontrolliert, nicht von der Software. Die Periode wird pro Controller eingestellt, nicht pro Device.
- Es gibt asynchrone Readings für iButton und digitale Eingänge, für schnelle Reaktion ohne Pollen.
- Device Typen lassen sich nicht allein anhand eines Family Codes in der ID unterscheiden. Devices können Esera Produkte wie ein Multi-Sensor sein, für die der Controller bereits interpretierte Readings liefert.
- Device IDs sind nicht unbedingt gültige 1-wire IDs. Sie werden ausschließlich zur eindeutigen Unterscheidung von Devices verwendet und haben darüber hinaus keine Bedeutung. Mit Standard-Einstellungen kann man mit dem Controller arbeiten ohne 1-wire IDs zu sehen.
- Der Esera Controller kann in regelmäßigen Abständen "keep alive" Nachrichten schicken, die FHEM dann verarbeiten sollte.
- Der Esera Controller abstrahiert alle Eigenschaften von 1-wire. Er stellt eigentlich eher ein Subsystem zur Verfügung, und bietet der Software für dieses Subsystem ein proprietäres Interface an. Software-seitig ist es für den Nutzer belanglos welcher Bus tatsächlich verwendet wird. Statt 1-wire könnte es etwas anderes sein, und in der Software gäbe es keine Änderungen.
Weitere Aspekte:
- Das Wissen über OWX und die bislang unterstützte Hardware und den Esera Controller ist (im Moment) verteilt.
- Auch die verschiedene Hardware ist (im Moment) nicht jedem Entwickler verfügbar.
- Gibt es Regression Tests mit denen man die Qualität von Änderungen an OWX absichern kann?
- Esera würde OWX komplexer machen. Es ist aber bislang nicht klar, wieviel Verwendung der Esera Controller mit einem funktionierenden FHEM Modul finden wird.
Fazit: Die Wartung von OWX und von EseraOneWire würde durch eine Verschmelzung unnötig erschwert. Ich werde daher das EseraOneWire Modul weiterentwickeln.
Viele Grüße,
pizmus
Thema: neues Modul 66_EseraOneWire für den Esera 1-Wire Controller (Gelesen 718 mal)