Autor Thema: neues Modul 66_EseraOneWire für den Esera 1-Wire Controller  (Gelesen 719 mal)

Offline pizmus

  • New Member
  • *
  • Beiträge: 9
Hallo zusammen,
ich möchte heute ein neues Modul für den Esera 1-wire Controller mit LAN Schnittstelle vorstellen.
Das Modul gibt es hier:
https://github.com/pizmus/EseraOneWire

Das Modul kann als 3rd Party Modul installiert werden. Als weitere Informationen stehen ein README und die Commandref zur Verfügung.
Im README gibt es neben Installationsanleitung usw. auch Hintergrundinformationen:
Warum mache ich das eigentlich? Warum diese Hardware? usw.

Ich hatte mit 66_ESERA.pm vom Hersteller angefangen, habe aber leider schnell feststellen müssen, dass das meinen
Ansprüchen nicht genügt. Hier ein paar Highlights der neuen Implementierung:
- Es wird DevIo verwendet, keine blockierende Kommunikation mit dem Controller, kein "sleep" wie bei 66_ESERA.
- Zweistufiges Modulkonzept mit autocreate. Ein "define <myEseraController> EseraOneWire <ip-adresse>" reicht und die logischen Module für die Sensoren/Aktoren entstehen automatisch.
- Komplett neu definierte Set/Get Funktionen mit Eingabehilfen im FHEMWEB UI.
- Bislang unterstütze Sensoren/Aktoren und weitere Funktionen sind in der Commandref erläutert. Ich denke ich kann weitere Aktoren/Sensoren mit wenig Aufwand unterstützen.

Die Module laufen zur Zeit noch bei mir im Testbetrieb auf dem Schreibtisch. Etwa ab dem Jahreswechsel will ich produktiv damit arbeiten.
Ich freue mich vorab über Tester und Reviewer (z.B. für die DevIo Benutzung und das 2-stufige Modulkonzept). 1-wire-Protokoll-Wissen
ist hilfreich aber nicht unbedingt erforderlich, weil der Controller einem diesen Teil abnimmt.

pizmus

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6080
Antw:neues Modul 66_EseraOneWire für den Esera 1-Wire Controller
« Antwort #1 am: 06 Oktober 2018, 04:25:35 »
Zitat
OWX dagegen implementiert dagegen das 1-wire Protokoll "low level"
und scheint 1-wire Nachrichten bis an die logischen Module durchzureichen. Ich hoffe ich gebe das so korrekt wieder.

Stimmt nicht und sollte so nirgendwo behauptet werden. OWX arbeitet mit verschiedenen Controller-Modulen: TCP/IP, Seriell und Firmata sind "low level", aber das CCC-Controller-Modul arbeitet mit Strings, ebenso die Connection mit OWServer. Es wäre also ein Aufwand von wenigen Tagen gewesen, ein solches Backendmodul für esera zu schreiben.

LG

pah

Offline pizmus

  • New Member
  • *
  • Beiträge: 9
Antw:neues Modul 66_EseraOneWire für den Esera 1-Wire Controller
« Antwort #2 am: 07 Oktober 2018, 08:33:12 »
Hallo pah,
das könnte eine interessante Alternative sein. Ich werde mir das CCC Controller Modul in der nächsten Zeit mal ansehen. Im README habe ich einen Verweis auf diese Diskussion eingefügt. Würden Sie denn selbst Aufwand spendieren, bzw. mich bei der Implementierung unterstützen?
Viele Grüße,
pizmus

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6080
Antw:neues Modul 66_EseraOneWire für den Esera 1-Wire Controller
« Antwort #3 am: 07 Oktober 2018, 09:14:34 »
Zitat
Würden Sie denn selbst Aufwand spendieren
Würde ich gerne, kann ich aber derzeit nicht. Beruflich stark eingespannt und viele andere Punkte auf der Prioritätenliste.

Modulname ist übrigens 10_OWX_CCC.pm, bedient wird der CUNO mit ASCII-Strings.

LG

pah

Offline pizmus

  • New Member
  • *
  • Beiträge: 9
Antw:neues Modul 66_EseraOneWire für den Esera 1-Wire Controller
« Antwort #4 am: 16 Oktober 2018, 12:29:26 »
Ich habe mir jetzt mal die Zeit genommen 11_OWC_CCC.pm im Hinblick auf eine Implementierung für Esera anzusehen. Im Anhang findet sich eine Analyse aller Funktionen. Da sind noch jede Menge Fragezeichen drin. Über Antworten und Vorschläge freue ich mich.

Im Kern drehen sich alle wichtigen offenen Fragen um die Kommunikation mit dem Controller. Das synchrone Modell von OWC_CCC passt nicht so recht zu den asynchronen Nachrichten vom Esera Controller.

Viele Grüße,
pizmus

Offline pizmus

  • New Member
  • *
  • Beiträge: 9
Antw:neues Modul 66_EseraOneWire für den Esera 1-Wire Controller
« Antwort #5 am: 25 Oktober 2018, 22:06:58 »
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

Offline pizmus

  • New Member
  • *
  • Beiträge: 9
Antw:neues Modul 66_EseraOneWire für den Esera 1-Wire Controller
« Antwort #6 am: 16 November 2018, 20:39:13 »
Es gibt einige Neuerungen in https://github.com/pizmus/EseraOneWire :
  • Das EseraOneWire Modul wurde mit zwei gleichzeitig arbeitenden Controllern getestet.
  • Der “Controller 2” ist jetzt vollständig unterstützt, mitsamt seiner integrierten digitalen Ein- und Ausgänge und seines Analog-Spannungs-Ausgangs.
  • Für Analog-Ports gibt es jetzt das Modul EseraAnalogInOut.
  • Der Esera Temperatur-Feuchte-Licht-Sensor (Unterputz) 11132 wird vom EseraMulti-Modul unterstützt.
  • Das EseraDigitalInOut Modul benutzt SetExtensions.
  • Die Namen vieler Readings haben sich geändert. Redundante Namensbestandteile wie die 1-wire ID wurden entfernt.
  • Um die Dokumentation zu vereinfachen wird unterstütze Hardware nur noch im jeweiligen Modul in der CommandRef aufgelistet.

Weitere neue Hardware in meinem Testaufbau:
  • Stromstoßrelais an Digitalausgang und Koppelrelais an Digitaleingang zur Kontrolle und Überwachung eines 230V Verbrauchers
  • Esera Unterputz-Temperatur-Sensor
  • Esera-Bewegungsmelder an Esera Digitaleingang
Ein Foto meines aktuellen Testaufbaus mit dem 1-wire Controller 1 habe ich angehängt.

pizmus
Gefällt mir Gefällt mir x 2 Liste anzeigen