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

[Morgennebel]

Danke pizmus,


wenn ich das richtig verstehe und https://fhem.de/commandref_DE.html#global Abschnitt events hinzuziehe, entspricht das Verhalten Deines Modules nach einem reboot nicht INITIALIZED, sondern DEFINED, oder? Das Gerät ist vorhanden und angemeldet, reagiert aber noch nicht auf Kommandos.

Macht es nicht Sinn, in Deinem Modul INITIALIZED erst zu melden, wenn alle im Controller gespeicherten Geräte auf dem Bus gefunden wurden oder nach 60 sec. einen TIMEOUT/Fehler zu werfen?

Mein DOIF reagiert derzeit auf den INITIALIZED und setzt dann drei explizite "off"-Befehle ab. Diese sind in ReadingsProxys verpackt, damit ich auf der Weboberfläche ein Symbol habe, den Zustand sehen kann, oder im Floorplan-Modul integrieren kann. Nun entspricht (da die Befehle ja verloren gehen), der Zustand der ReadingsProxys nicht der Realität und genau dieses wollte ich mit dem DOIF/RP lösen...

Ich kann temporär eine Verzögerung von 1 Minute hinzufügen, aber das wäre nur ein Workaround...

Danke, -MN

[pizmus]

Mir ist nicht klar, wie sich ein Modul beim Neustart genau verhalten soll. Ich habe eine Anfrage dazu gestartet:
https://forum.fhem.de/index.php/topic,99281.0.html
Gruß,
pizmus

[pizmus]

Hallo Morgennebel,

ich habe den Vorschlag aus dem Developer-Bereich bereits umgesetzt. Wenn keine deutlich besseren Vorschläge mehr kommen lasse ich es dabei. Du findest eine neue Version auf github.

Es gibt jetzt ein Reading "status" von "EseraOneWire", das den Zustand von EseraOneWire anzeigt. Das Reading ist in der CommandRef beschrieben. Für Deinen Zweck kannst Du auf status="ready" testen.

Ich habe mit folgendem Beispiel getestet:
defmod DI_EseraInit DOIF ([owc2:status] eq "ready") (set owc2Sys2Dummy2 on)
"owc2" ist mein "Controller 2" und "owc2Sys2Dummy2" ist ein SYS2 Port des Controllers. Der Ausgang wird automatisch nach jedem Verbindungsaufbau eingeschaltet, auch nach "shutdown restart".

Im gleichen Zusammenhang habe ich noch eine Überwachung der Verbindung zum Controller eingebaut. Der Controller schickt periodisch eine sog. KAL Nachricht (keep alive). Wenn die ausbleibt wird nun versucht, die Verbindung neu aufzubauen. Das wird natürlich auch im "status" Reading reflektiert. Du könntest damit irgendeine Form von Alarm auslösen, falls die Hardware nicht mehr erreichbar ist.

Ich hoffe das löst Dein Problem. Lass mich wissen ob Du damit klarkommst.

Viele Grüße,
pizmus

[pizmus]

Hallo Morgennebel,
ich habe das noch einmal leicht umgebaut. Verwende bitte das Event "READY" für Deinen Zweck. Das DOIF kann dann beispielsweise so aussehen:

Code Auswählen Erweitern

defmod DI_EseraInit DOIF ([owc2:"READY"]) (set owc2Sys2Dummy2 on)
Weitere Infos in der neuen CommandRef.
Gruß,
pizmus

[Morgennebel]

Hi pizmus,


vielen Dank für die Weiterentwicklung des Modules. Ich habe die Updates eingespielt und mein DOIF geändert, es schlägt auch erfolgreich zu.

Jedoch... Am 1-Wire-Bus des Esera One Wire Controllers hängt noch ein Dankovi 8fach Relais-Modul. Ausgang 1 wird im DOIF ebenfalls zurückgesetzt:

Code Auswählen Erweitern

defmod DI_DefinedStateAfterReboot DOIF ([EC_HWRHeizung:"READY"])\
    (set RP_FussbodenPumpe_Sw off, \
     set RP_RadiatorenPumpe_Sw off, \
     set RP_WintergartenFussboden_Sw off, \
     set 1W_HWR.ECOut_Sw1 off)\
DOELSE
attr DI_DefinedStateAfterReboot room SYS_Events


Es geht hierbei um den RP_WintergartenFussboden_Sw:

Code Auswählen Erweitern


defmod RP_WintergartenFussboden_Sw readingsProxy 1W_HWR.Dankovi8Relais_Sw1:out
attr RP_WintergartenFussboden_Sw room R_HWR
attr RP_WintergartenFussboden_Sw setFn {($CMD eq "on")?"on":"off"}
attr RP_WintergartenFussboden_Sw setList on off
attr RP_WintergartenFussboden_Sw valueFn {($VALUE == 0)?"off":"on"}
attr RP_WintergartenFussboden_Sw webCmd on:off


und

Code Auswählen Erweitern


defmod 1W_HWR.Dankovi8Relais_Sw1 EseraDigitalInOut EC_HWRHeizung 110000002529BA29 DS2408 0 1
attr 1W_HWR.Dankovi8Relais_Sw1 room R_HWR,SYS_1Wire


Nach dem shutdown restart ist Ausgang 1 auch erfolgreich auf 0 gesetzt - jedoch Ausgang 2-8 alle auf 1. Das war vor dem Update nicht so - dort blieben alle Ausgänge in den vorherigen Zuständen.

Hast Du evtl. eine Bitmasken-Operation im Update eingebaut...?

Danke, -MN

[pizmus]

Hallo Morgennebel,
nein, in der Ecke habe ich schon lange nichts mehr geändert. Ich behaupte, die Bits 2..8 werden nicht aktiv vom EseraDigitalInOut Modul programmiert da Deine Definition nur Bit 1 umfasst.

Wenn Du die Bits 2..8 nicht als EseraDigitalInOut definiert und auch initialisiert hast, solltest Du keine Annahmen darüber treffen, welchen Zustand die Ausgänge nach einem Neustart haben.

Es könnte sein, dass wir es hier mit einer Eigenschaft Deines Relais-Moduls zu tun haben, die Du nur bislang noch nicht beobachtet hast. Bislang gab es ja keinen Zugriff auf Bit 1 beim Neustart. Dieser Zugriff sorgt vielleicht dafür, dass eine Art "Output enable" für alle 8 Bits gesetzt wird, so dass es so aussieht, als ob die Ausgänge 2..8 geschaltet würden. Ist nur eine Idee. Auch das Zusammenspiel zwischen Esera Controller und dem Relais Modul bzw. dem DS2408 könnte eine Rolle spielen. Falls der Controller immer alle 8 Bits schreibt und nach einem Neustart eine Annahme über den Zustand der Bits 2..8 trifft, kann die falsch sein.

Wenn eine Initialisierung der Bits 2..8 nach dem READY Event funktioniert, würde ich mir die Zeit für die Detail-Analyse gerne ersparen.

Gruß,
pizmus

[Morgennebel]

Danke,


teste ich morgen mittag (wenn das Haus warm ist .

Ciao, -MN

[Morgennebel]

Hi pizmus,


unterstützt Dein Modul devspec (https://fhem.de/commandref_DE.html#command)?

Ich hatte mein DOIF geändert auf

     set 1W_HWR.ECOut_Sw1,1W_HWR.ECOut_Sw2,1W_HWR.ECOut_Sw3,1W_HWR.ECOut_Sw4 off

d.h. mehrere Geräte auf einmal. Das gab im Logfile aber Fehlermeldungen.

devspec würde auch FILTER erlauben...

Danke, -MN

[Morgennebel]

Wenn eine Initialisierung der Bits 2..8 nach dem READY Event funktioniert, würde ich mir die Zeit für die Detail-Analyse gerne ersparen.

... Deleted ... Ich bin a Depp.

Danke, -MN

[pizmus]

Hallo Morgennebel,
das hätte ich jetzt so nicht gesagt 
Ist denn Dein Problem mit devspec damit auch gelöst? Für devspec ist nach meinem Verständnis nicht das Modul zuständig. Ich habe es mit einem ähnlichen "set .... on" wie Du getestet und es hat funktioniert.
Gruß,
pizmus

[pizmus]

Es gibt eine neue Version von 66_EseraOneWire.pm auf github, die mit der aktuellen FW Version 1.20_27 von Esera arbeitet.
Weitere Änderungen:

• EseraOneWire: Retry-Mechanismus für die Controller-Initialisierung. Das war notwendig, weil bei einer EseraStation nach dem Start zunächst korrupte Daten über das serielle Interface beim FHEM Modul ankommen. Die erste Initialisierung des Controllers schlägt fehl und sie wird nach einem Timeout erfolgreich wiederholt.
• EseraCount: Attribute für Umrechnungsfaktoren von Readings

[skynet]

Hat sonst noch jemand diesen Fehler bei Nutzung des Moduls.
Bei mir wird es nicht geladen
Aktuelles FHEM.

Can't use a hash as a reference at ./FHEM/66_ESERA.pm line 887.

[Morgennebel]

Bei mir läuft es...

Wie sieht Deine Definition und Dein Logfile aus?

Ciao, -MN

[pizmus]

Hallo skynet,
ist Dir bewusst dass es zwei verschiedene Module für die Esera 1-wire Controller gibt (66_ESERA.pm und 66_EseraOneWire.pm)? Gibt es einen bestimmten Grund warum Du Dich für 66_ESERA.pm entschieden hast? Welchen Controller hast Du, und für welche Anwendung willst Du ihn einsetzen?
Gruß,
pizmus

[Morgennebel]

Hi Pizmus,

darf ich auch noch anregen, als set-Kommandos:

• close
• open
• disable
• enable

zu integrieren?

nach dem FHEM-Update gestern meckert das System über ein Firmware-Update des ESERA-Controllers. Mit dem Configtool kann ich nicht auf den Controller zugreifen, da dieser von FHEM verwaltet wird.

Wie ist Deine Empfehlung für ein Firmware-Update des Controllers? FHEM ausschalten?

Danke, -MN