OWX asynchronous und Befehlsketten auf OWSWITCH 8fach

[HAL2001]

Hallo zusammen,

sobald ich meinen OWX auf asynchronous=1 schalte, werden Befehlsketten (durch Semikolon getrennt) auf einem OWSWITCH-Device (8fach-Schalter) nicht mehr korrekt ausgeführt. Soweit ich sehen kann, wird immer nur der letzte Befehl der Befehlskette korrekt verarbeitet. Im asynchronous=0-Modus funktioniert alles "normal".

Hintergrund: Ich nutze den 8fach-Schalter mit dem readingsProxy und dem ROLLO-Modul für eine Rolladensteuerung.

Vorab vielen Dank für jeden Hinweis.

Viele Grüße, Jan

[Prof. Dr. Peter Henning]

Wenn man nur einen einzelnen Ausgang setzt, wird trotzdem die gesamte Mimik abgespult: Holen des gegenwärtigen 8Bit-Registerzustands, binäre Kombination mit dem neuen Bit, zurückschreiben des gesamten 8Bit-Registers.

Man sollte also schon aus Performance-Gründen vermeiden, so etwas wie "Befehlsketten" zu erzeugen...

LG

pah

[HAL2001]

Danke für die Rückmeldung.

Ich habe jetzt die Routinen auf einen einzelnen gpio-Befehl in der 8-bit-Logik umgeschrieben. Das funktioniert jetzt auch prima.

Dabei habe ich noch zwei Sachen im Modul anpasst:

(1) Das gpio-Reading wird erst nach dem Schreiben auf dem Device aktualisiert. Das kann im asynchronen Modus sich aber mit anderen Befehlen überschneiden, die dann den "alten" gpio-Wert verwenden. Ich habe entsprechend ein zusätzliches Update des Readings eingefügt. Würde es ggf. sinnvoll sein, das Update standardmäßig im Modul zu integrieren?

(2) Ich habe einige "ältere" 8fach-Aktoren von eService bei denen scheinbar die Eingänge nicht richtig verschaltet sind -- die neueren Geräte von eService funktioneren tadellos; ich erhalte immer ein "ONX" anstelle des "OFF" als Status. Als Konsequenz zeigt mir OWSWITCH auch immer das gpio-Reading mit dem Wert 0 an. Ich habe daher die Auswertung des gpio-Readings von "input"- auf "output"-Werte umgesetzt. Gibt es eine elegantere Möglichkeit, Geräte von eService korrekt einzubinden?

Danke und Gruß, Jan

[cwagner]

an dem Thema "kaue" ich auch schon lange, allerdings ohne ausreichende Programmierkenntnisse. Hast Du das Modul umgeschrieben? Da wäre ich sehr interessiert zu testen. Im Einsatz sind 8 Denkovi-8-Fach-Switche...

Herzliche Grüße

Christian

[HAL2001]

Hi Christian,

ad (2): Es sind nur zwei kleine Eingriffe im 21_OWSWITCH.pm innerhalb der Subroutine "OWSWITCH_FormatValues" notwendig:

1. Die Zeile

Code Auswählen Erweitern

# $gpio   += $hash->{owg_val}->[$i]<<$i; auskommentieren
2. Direkt unter

Code Auswählen Erweitern

$vvax    = $hash->{owg_vax}->[$i]; die Zeile

Code Auswählen Erweitern

$gpio   += $hash->{owg_vax}->[$i]<<$i; einfügen

ad (1): Hier einfach in der Subroutine "OWSWITCH_Set" direkt hinter

Code Auswählen Erweitern

    return "OWSWITCH: Set with wrong value for gpio port, must be 0 <= gpio <= ".((1 << $cnumber{$attr{$name}{"model"}})-1)
      if( ! ((int($value) >= 0) && (int($value) <= ((1 << $cnumber{$attr{$name}{"model"}})-1 ))) ); die Zeile

Code Auswählen Erweitern

readingsSingleUpdate($hash,"gpio",$value,undef); einfügen.

Die direkte Ansteuerung der beiden Kanäle über den gpio-Befehl habe ich mit einer Subroutine in der 99_myUtils.pm wie folgt realisiert:

Code Auswählen Erweitern

sub
shutterOW($$$)
{
    my ($device,$channel,$val) = @_;
    $val = $val ^ 0b11;
    my $gpio = ReadingsVal($device,"gpio",255);
    my $mask = (0b11 << ($channel-1)) ^ 0b11111111;
    my $gpio = ($gpio & $mask) | ($val << ($channel-1));
    fhem("set $device gpio $gpio");
}

Dabei gibt $device den OW-8fach-Schaltaktor an, $channel gibt die Position 1-8 der beiden notwendigen Kanäle an und $val setzt die beiden Bits der Kanäle, also 0b11, 0b10, 0b01 oder 0b00 -- bitte darauf achten, dass hier 1=on und 0=off bedeutet.

Viele Grüße, Jan

[cwagner]

Jan, spannend, einen ähnlichen Ansatz hatte ich begonnen, dann aber nicht zu Ende bekommen. Das werde ich mal durchsprobieren und das Ergebnis vermelden. Wird ein paar Tage dauern.

Die Veränderung von 21_OWSwitch.pm nach ad(2) führte jedenfalls schon einmal zu einem sehr positiven Ergebnis: Ich steuere den Zuluft- und den Abluft-Motor unserer Lüftung anhand des CO2-Anteils in der Abluft. Dabei steuern zwei AD-Wandler (DS2408 als Steller) die Lüfter - dort musste ich bisher 15 Sec. zwischen dem Absetzen der Drehzahl für Lüfter 1 und Lüfter 2 warten; tat ich das nicht, ging einer der beiden Set-Befehle verloren. Das ist jetzt nicht mehr notwendig.

Liebe Grüße und einen guten Start ins nächste Jahrzehnt

Christian

[Prof. Dr. Peter Henning]

Werde ich mir mal ansehen.

LG

pah

[cwagner]

ad (2): Es sind nur zwei kleine Eingriffe im 21_OWSWITCH.pm innerhalb der Subroutine "OWSWITCH_FormatValues" notwendig:

1. Die Zeile

Code Auswählen Erweitern

# $gpio   += $hash->{owg_val}->[$i]<<$i; auskommentieren
2. Direkt unter

Code Auswählen Erweitern

$vvax    = $hash->{owg_vax}->[$i]; die Zeile

Code Auswählen Erweitern

$gpio   += $hash->{owg_vax}->[$i]<<$i; einfügen

Nach der dauerhaft positiven Auswirkung auf den DS2408 als setter (Esera Analog-Ausgang auf Basis des DS2408) habe ich nun die Veränderung von 21_OWSWITCH auf den DS2408 im Denkovi geprüft: Hier ist aber eindeutig: Wenn ich eine Serie von Befehlen, z.B.

Code Auswählen Erweitern

set Switch_Lueftung output E ON;set Switch_Lueftung output F ON;set Switch_Lueftung output G ON;set Switch_Lueftung output H ON; über die Kommandozeile abfeuere, kann ich schön sehen was innerhalb von rund 1 Sekunde passiert:

• Annahme: E, F, G, H sind aus
• E wird eingeschaltet
• Im Moment, wo F eingeschaltet wird, wird E ausgeschaltet, F bleibt eingeschaltet
• Im Moment, wo G eingeschaltet wird, wird F ausgeschaltet, G bleibt eingeschaltet
• Im Moment, wo H eingeschaltet wird, wird G ausgeschaltet, H bleibt schließlich als der letzte eingeschaltet

Um das zu vermeiden habe ich bisher nur den Weg eines sekundenlangen Waits zwischen den einzelnen Befehlen gefunden.
Herzliche Grüße

Christian

[Prof. Dr. Peter Henning]

Ich verstehe nicht so ganz, ob ich das jetzt als pro oder contra diese Änderung sehen soll. Erleuchte mich!

LG

pah

[cwagner]

Oh, sorry, PAH, aus meiner Praxis ist die vorgeschlagene Änderung eine Verbesserung (also pro), weil sich zwei direkt hintereinander über GPIO angesprochene DS2408 (set <device1> gpio 233;set <device2> gpio 189) nun korrekt verhalten: Beide GPIOs werden ausgeführt (vorher ging immer einer verloren, es seit dennn, man machte ein wait zwischen den beiden Befehlen).

Sende ich mehrere set output-Befehle wie beschrieben direkt hintereinander an einen DS2408, tritt auch bei dem angepassten 21_OWSWITCH.pm dennoch das in meinem Beitrag beschriebene Verhalten auf.

Eine These - ohne wirklich den Code durchgearbeitet zu haben (geschweige denn, vollständig verstanden zu haben) ist: Der jeweils nächste Set-Befehl hat noch nicht den neuen GPIO des vorherigen Set-Befehls verabeitet, zu früh den nunmehr veralteten GPIO ausgelesen?

LG

cw

[Prof. Dr. Peter Henning]

Dauert noch ein paar Tage, bis ich etwas Zei thabe.

LG

pah