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
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
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
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
Hi Christian,
ad (2): Es sind nur zwei kleine Eingriffe im 21_OWSWITCH.pm innerhalb der Subroutine "OWSWITCH_FormatValues" notwendig:
1. Die Zeile # $gpio += $hash->{owg_val}->[$i]<<$i; auskommentieren
2. Direkt unter $vvax = $hash->{owg_vax}->[$i]; die Zeile $gpio += $hash->{owg_vax}->[$i]<<$i; einfügen
ad (1): Hier einfach in der Subroutine "OWSWITCH_Set" direkt hinter 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 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:
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
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
Werde ich mir mal ansehen.
LG
pah
Zitat von: HAL2001 am 30 Dezember 2019, 16:06:08
ad (2): Es sind nur zwei kleine Eingriffe im 21_OWSWITCH.pm innerhalb der Subroutine "OWSWITCH_FormatValues" notwendig:
1. Die Zeile # $gpio += $hash->{owg_val}->[$i]<<$i; auskommentieren
2. Direkt unter $vvax = $hash->{owg_vax}->[$i]; die Zeile $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.
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
Ich verstehe nicht so ganz, ob ich das jetzt als pro oder contra diese Änderung sehen soll. Erleuchte mich!
LG
pah
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
Dauert noch ein paar Tage, bis ich etwas Zei thabe.
LG
pah