neues Modul 66_EseraOneWire für den Esera 1-Wire Controller

[pizmus]

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

[Prof. Dr. Peter Henning]

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

[pizmus]

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

[Prof. Dr. Peter Henning]

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

[pizmus]

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

[pizmus]

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

[pizmus]

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

[Morgennebel]

Moin,


ich hab das Modul gerade installiert und wollte es mit einem Dankovi 8-fach 230V Relaismodul, gesteuert von einem DS2408 betreiben.

Die Hilfe zum set-Befehl überfordert mich - wie kann ich denn die einzelnen Ausgänge an- und ausschalten? Ich werde dann später ReadingsProxys benutzen...

Danke, -MN

[pizmus]

Hallo Morgennebel,

hier zunächst die kurze Antwort: Die zwei Parameter <bitMask> und <bitValue> sind Bitfelder. Eine '1' in <bitMask> bedeutet, dass der zugehörige Ausgang geschaltet werden soll. Eine '1' bzw. '0' in <bitValue> bestimmt, welchen Wert der jeweilige Ausgang annehmen soll. Beispiele gibt es weiter unten.

Um den "set" Befehl zu verstehen sollte man sich auch mit dem "define" beschäftigt haben. Du hast grundsätzlich zwei Möglichkeiten den DS2408 aufzusetzen:

Variante A: Du kannst ein FHEM define machen das sich um alle 8 Ausgänge kümmert. Das ist auch das, was autocreate macht. Danach kannst Du mit jedem Schaltbefehl entscheiden, ob Du alle Ausgänge gleichzeitig schalten willst, oder doch lieber nur einzelne Ausgänge oder Teilgruppen.

Beispiele:

define MeinRelaismodul EseraDigitalInOut <ioDevice> <oneWireId> DS2408 - -

oder

define MeinRelaismodul EseraDigitalInOut <ioDevice> <oneWireId> DS2408 0 8

Alle 8 Ausgänge werden durch "MeinRelaismodul" gesteuert.

set MeinRelaismodul on  -> Schaltet alle 8 Ausgänge an.

set MeinRelaismodul off -> Schaltet alle 8 Ausgänge aus.

set MeinRelaismodul out 0xff 0xf0 -> Schaltet alle 8 Ausgänge, die oberen 4 an, die unteren 4 aus

set MeinRelaismodul out 0x02 0x02 -> Schaltet nur den 2. Ausgang ein.

set MeinRelaismodul out 0x02 0x00 -> Schaltet nur den 2. Ausgang aus.

set MeinRelaismodul out 0x04 0x04 -> Schaltet nur den 3. Ausgang ein.

set MeinRelaismodul out 0x08 0x00 -> Schaltet nur den 4. Ausgang aus.

Darauf aufbauend könntest Du nun z.B. ReadingsProxys verwenden, um den einzelnen Ausgängen in FHEM Namen zu geben.


Variante B: Du kannst Dir die ReadingsProxys sparen, indem Du ein EseraDigitalInOut "define" pro Ausgang bzw. Ausgangsgruppe machst.

define MeinRelais1 EseraDigitalInOut <ioDevice> <oneWireId> DS2408 0 1 -> Macht das erste Relais als "MeinRelais1" verwendbar (ein Ausgang ab Index 0).

set MeinRelais1 on -> Ist jetzt hoffentlich selbsterklärend.

set MeinRelais1 off

define MeinRelais2 EseraDigitalInOut <ioDevice> <oneWireId> DS2408 1 1 -> Macht das zweite Relais als "MeinRelais2" verwendbar.

define MeineRelaisgruppe EseraDigitalInOut <ioDevice> <oneWireId> DS2408 4 4 -> Fasst die oberen 4 Ausgänge als "MeineRelaisgruppe" zusammen (4 Ausgänge ab Index 4).

set MeinRelaisgruppe on -> Schaltet alle 4 Ausgänge von MeinRelaisgruppe ein. Zur Erinnerung, das sind jetzt die oberen 4 Ausgänge des DS2408.

set MeinRelaisgruppe out 0xf 0x3 -> Schaltet alle 4 Ausgänge von MeinRelaisgruppe, die oberen zwei aus, die unteren zwei an.


Statt Hex-Notation für die Auswahl der Ausgänge wird auch dezimal und binär unterstützt. Es ist aber immer ein Bitfeld, nicht die Nummer eines Ausgangs. Sonst könnte man mit dem Befehl keine Gruppen schalten.

Viele Grüße,

pizmus

[Morgennebel]

Prima, Danke...

Ich habe meine DS18B20 auch eingebunden bekommen, nachdem ich mir das .pm-File angeschaut hatte.

Code: [Auswählen]

defmod 1W_HWR.Radiator_Ruecklauf EseraTemp EC_HWRHeizung 8E0517C44BD6FF28 DS1820
attr 1W_HWR.Radiator_Ruecklauf room R_HWR,SYS_1Wire

Wobei 8E0517C44BD6FF28 die 1-Wire ID ist. Ohne autocreate macht das nicht sooo viel Spaß...

[Morgennebel]

Noch ein paar Fehlermeldungen aus dem Logfile:

Nach einem Aus-/Anschalten:

Code: [Auswählen]

2019.02.05 10:57:34 1: 192.168.1.24:5000 disconnected, waiting to reappear (EC_HWRHeizung)
2019.02.05 10:57:34 1: 192.168.1.24:5000 reappeared (EC_HWRHeizung)
2019.02.05 10:57:36 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_LOADDEFAULT
2019.02.05 10:57:36 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: set,sys,loaddefault,1, response: 1_RDY|0, ignoring the response
2019.02.05 10:57:36 1: EseraOneWire (EC_HWRHeizung) - error response received, expected: 1_OWDID
2019.02.05 10:57:36 1: EseraOneWire (EC_HWRHeizung) - error response, command: set,owb,owdid,1 , response: 1_ERR|1 , ignoring the response
2019.02.05 10:57:36 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_DATA
2019.02.05 10:57:36 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: set,key,data,2, response: 1_OWDID|1, ignoring the response
2019.02.05 10:57:36 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_DATATIME
2019.02.05 10:57:36 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: set,sys,datatime,10, response: 1_DATA|2, ignoring the response
2019.02.05 10:57:37 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_KALSEND
2019.02.05 10:57:37 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: set,sys,kalsend,1, response: 1_DATATIME|10, ignoring the response
2019.02.05 10:57:37 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_KALSENDTIME
2019.02.05 10:57:37 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: set,sys,kalsendtime,180, response: 1_KALSEND|1, ignoring the response
2019.02.05 10:57:37 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_KALREC
2019.02.05 10:57:37 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: set,sys,kalrec,0, response: 1_KALSENDTIME|180, ignoring the response
2019.02.05 10:57:37 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_SEARCH
2019.02.05 10:57:37 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: set,owb,search,2, response: 1_KALREC|0, ignoring the response
2019.02.05 10:57:37 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_SEARCHTIME
2019.02.05 10:57:37 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: set,owb,searchtime,30, response: 1_SEARCH|2, ignoring the response
2019.02.05 10:57:37 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_POLLTIME
2019.02.05 10:57:37 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: set,owb,polltime,5, response: 1_SEARCHTIME|30, ignoring the response
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_OWDID
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: get,owb,owdid, response: 1_KALSENDTIME|180, ignoring the response
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_OWDIDFORMAT
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: get,owb,owdidformat, response: 1_OWDID|1, ignoring the response
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_SEARCHMODE
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: get,owb,search, response: 1_OWDIDFORMAT|1, ignoring the response
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_SEARCHTIME
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: get,owb,searchtime, response: 1_SEARCHMODE|2, ignoring the response
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_POLLTIME
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: get,owb,polltime, response: 1_SEARCHTIME|30, ignoring the response
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_DS2408INV
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: get,owd,ds2408inv, response: 1_POLLTIME|5, ignoring the response
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_DATA
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: get,key,data, response: 1_DS2408INV|1, ignoring the response
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - unexpected response received, expected: 1_RUN
2019.02.05 10:57:41 1: EseraOneWire (EC_HWRHeizung) - error: unexpected response, command: get,sys,run, response: 1_DATA|2, ignoring the response
2019.02.05 10:57:43 3: EseraOneWire (EC_HWRHeizung) - init complete

Danach folgt minutenlang:

Code: [Auswählen]

2019.02.05 10:58:06 1: EseraOneWire (EC_HWRHeizung) - info: received data for 110000002529BA29 but device list does not exist. Ignoring data. Triggering re-reading of list of devices from controller.
2019.02.05 10:58:06 1: EseraOneWire (EC_HWRHeizung) - info: received data for 110000002529BA29 but device list does not exist. Ignoring data. Triggering re-reading of list of devices from controller.
2019.02.05 10:58:06 1: EseraOneWire (EC_HWRHeizung) - info: received data for 110000002529BA29 but device list does not exist. Ignoring data. Triggering re-reading of list of devices from controller.
2019.02.05 10:58:06 1: EseraOneWire (EC_HWRHeizung) - info: received data for 110000002529BA29 but device list does not exist. Ignoring data. Triggering re-reading of list of devices from controller.
2019.02.05 10:58:06 1: EseraOneWire (EC_HWRHeizung) - info: received data for 8E0517C44BD6FF28 but device list does not exist. Ignoring data. Triggering re-reading of list of devices from controller.
2019.02.05 10:58:16 1: EseraOneWire (EC_HWRHeizung) - info: received data for 110000002529BA29 but device list does not exist. Ignoring data. Triggering re-reading of list of devices from controller.
2019.02.05 10:58:16 1: EseraOneWire (EC_HWRHeizung) - info: received data for 110000002529BA29 but device list does not exist. Ignoring data. Triggering re-reading of list of devices from controller.
2019.02.05 10:58:16 1: EseraOneWire (EC_HWRHeizung) - info: received data for 110000002529BA29 but device list does not exist. Ignoring data. Triggering re-reading of list of devices from controller.
2019.02.05 10:58:16 1: EseraOneWire (EC_HWRHeizung) - info: received data for 110000002529BA29 but device list does not exist. Ignoring data. Triggering re-reading of list of devices from controller.
2019.02.05 10:58:16 1: EseraOneWire (EC_HWRHeizung) - info: received data for 8E0517C44BD6FF28 but device list does not exist. Ignoring data. Triggering re-reading of list of devices from controller.
2019.02.05 10:58:26 1: EseraOneWire (EC_HWRHeizung) - info: received data for 110000002529BA29 but device list does not exist. Ignoring data. Triggering re-reading of list of devices from controller.
2019.02.05 10:58:26 1: EseraOneWire (EC_HWRHeizung) - info: received data for 110000002529BA29 but device list does not exist. Ignoring data. Triggering re-reading of list of devices from controller.
2019.02.05 10:58:26 1: EseraOneWire (EC_HWRHeizung) - info: received data for 110000002529BA29 but device list does not exist. Ignoring data. Triggering re-reading of list of devices from controller.
2019.02.05 10:58:26 1: EseraOneWire (EC_HWRHeizung) - info: received data for 110000002529BA29 but device list does not exist. Ignoring data. Triggering re-reading of list of devices from controller.
2019.02.05 10:58:26 1: EseraOneWire (EC_HWRHeizung) - info: received data for 8E0517C44BD6FF28 but device list does not exist. Ignoring data. Triggering re-reading of list of devices from controller.

Hmmmm...

Danke, -MN

[pizmus]

Hallo MN,

Zu den Fehlermeldungen:

Den ersten Block von Meldungen verstehe ich nicht. Ich habe so einen ähnlichen Effekt mal gesehen, als ich mit einer anderen Firmware Version des Controllers gespielt habe. Als erstes würde ich daher gerne die Firmware-Version Deines Controllers prüfen. Die siehst Du u.a. in der Ausgabe von „get info“. Der Vollständigkeit halber wäre es nett wenn Du mir (auch gerne Offline) die Ausgabe von „get info“, „get settings“ und „get devices“ schicken könntest.

Den zweiten Block mit den „info“ Meldungen erwarte ich. Die Funktion ist nicht beeinträchtigt. Bei mir dauert es einige Sekunden bis die Phase durch ist. Hintergrund: Wenn ein Reading von einem unbekannten Device kommt, wirft das Modul die Liste der Devices weg und holt sich neue Daten aus dem Controller. Eine Verbesserung ist in Arbeit.

Es würde mich noch interessieren welche Information Dir genau in der Hilfe gefehlt hat. Sowohl für DS2408 als auch für DS18B20. Hat autocreate für DS18B20 nicht funktioniert?

Gruß,
pizmus

[Morgennebel]

Hi pizmus,


die Angaben schicke ich gerne heute abend. Jetzt habe ich mit dem Wechsel auf Dein Modul meine Fußbodenheizung zerspielt...

Ich habe die Ausgänge des Controllers als einzelne Schalter definiert:

Code: [Auswählen]

defmod 1W_HWR.ECOut_Sw1 EseraDigitalInOut EC_HWRHeizung SYS2 SYS2 0 1
attr 1W_HWR.ECOut_Sw1 comment Controller OUT1 - Heizungspumpe Radiatoren
attr 1W_HWR.ECOut_Sw1 room R_HWR,SYS_1Wire
setstate 1W_HWR.ECOut_Sw1 2019-02-05 16:03:19 out 1


Code: [Auswählen]

defmod 1W_HWR.ECOut_Sw2 EseraDigitalInOut EC_HWRHeizung SYS2 SYS2 1 1
attr 1W_HWR.ECOut_Sw2 comment Controller OUT2 - Heizungspumpe
attr 1W_HWR.ECOut_Sw2 room R_HWR,SYS_1Wire
setstate 1W_HWR.ECOut_Sw2 2019-02-05 16:04:09 out 1

usw. Meine PWMR-Definition wünscht sich aber on/off im SATE/state - dort habe ich nur Initialized stehen. Nur im out-Reading kann ich mit 0 oder 1 auf den Zustand schliessen.

Könntest Du Dein Modul vielleicht so ergänzen, daß on/off im state/STATE gesetzt wird?

Danke, -MN

[Morgennebel]

Den ersten Block von Meldungen verstehe ich nicht. Ich habe so einen ähnlichen Effekt mal gesehen, als ich mit einer anderen
Firmware Version des Controllers gespielt habe. Als erstes würde ich daher gerne die Firmware-Version Deines Controllers prüfen.

ergibt:

FW version: 11903
HW version: 20
ESERA product number: 11340
date of manufacturing: 2018

Es würde mich noch interessieren welche Information Dir genau in der Hilfe gefehlt hat. Sowohl für DS2408 als auch für DS18B20. Hat autocreate für DS18B20 nicht funktioniert?

Das autocreate benötigt einige Zeit. Wie Du geschrieben hast, erkennt der Controller ein neues Gerät, scannt ab und legt dann irgendwann (teilweise mehrere Minuten) das neue Gerät mit autocreate an. Dafür bin ich vielleicht zu ungeduldig...?

Beim DS2408 fehlte mir das Verständnis der Bitmasken. Ich verstehe den Sinn, würde das aber wahrscheinlich einfach wegwerfen und jeden Kanal als einzelnen Ein- oder Ausgang definieren. Möchte ich mehrere auf einmal schalten, würde ich das in FHEM mit einer structure oder set DEV1,DEV5,DEV7,... lösen - nicht mit Bitmasken. Macht das Leben für mich nur kompliziert...

Mit echten Ausgängen (subType switch) wäre auch das Problem mit dem out/in-Reading und STATE/state nicht.

Zum DS18B20 seht nichts in der Hilfe. Erst im Sourcecode habe ich die Anweisung gefunden...

Danke, -MN

[Morgennebel]

Hi pizmus,


darf ich auch noch anregen, als set-Kommandos:

• close
• open
• disable
• enable

zu integrieren?

open/close für die Verbindung via Ethernet, um z.B. zeitweise einem anderen FHEM-Server Zugriff zu geben.
disable/enable für die Aktualisierung der 1Wire-Werte.

Danke, -MN