HM-SEC-WIN - zulässige Werte im "level"-Kommando?

[mmattern]

Hallo zusammen,

z.B. unter http://www.meintechblog.de/2013/07/bessere-raumluftqualitaet-durch-fhem-und-homematic-adapter/ wird empfohlen, zum Schließen des Fensters mit anschließender Verriegelung ein "set <HM-SEC-WIN Kanal 1> level ignore 0 20" zu setzen; die Parameter hinter "level" bedeuten dabei Ziel-Öffnungslevel (zwischen 0 und 100 Prozent), Delay bis zum Wiederverschließen und die Geschwindigkeit (Prozent der Maximalgeschwindigkeit).

Das ist wohl ein Workaround:
"
set WZ.Fenster_links ignore 0 20
Hier schließt der Winmatic das Fenster sofort (0 Sekunden) mit 20%iger Motorgeschwindigkeit. (Im Grunde bekommt der Winmatic einen Öffnungsbefehl ohne weitere Info (ignore) und schließt das Fenster direkt nach 0 Sekunden. Dieser Workaround ist notwendig, da der Winmatic mit dem normalen "close"-Befehl das Fenster nicht zusperrt.)
"

Meistens funktioniert das auch, jedoch tauchen im FHEM-Log Einträge der Art

Code Auswählen Erweitern

Argument "ignore" isn't numeric in numeric gt (>) at ./FHEM/10_CUL_HM.pm line 3318. auf.

Ein Blick in den Code von 10_CUL_HM.pm (gemäß aktueller GitHub-Version) zeigt ab Zeile 3315:

Code Auswählen Erweitern

elsif($cmd eq "level") { ####################################################
    #level        =>"<level> <relockDly> <speed>..."
    my (undef,undef,$lvl,$rLocDly,$speed) = @a;
    return "please enter level 0 to 100" if (!defined($lvl)    || $lvl>100);
    return "reloclDelay range 0..65535 or ignore"
                                         if (defined($rLocDly) &&
                                             ($rLocDly > 65535 ||
                                              ($rLocDly < 0.1 && $rLocDly ne 'ignore' && $rLocDly ne '0' )));
    return "select speed range 0 to 100" if (defined($speed)   && $speed>100);
    $rLocDly = 111600 if (!defined($rLocDly)||$rLocDly eq "ignore");# defaults
    $speed = 30 if (!defined($rLocDly));
    $rLocDly = CUL_HM_encodeTime8($rLocDly);# calculate hex value
    CUL_HM_PushCmdStack($hash,'++'.$flag.'11'.$id.$dst.'81'.$chn.
                        sprintf("%02X%02s%02X",$lvl*2,$rLocDly,$speed*2));

Wenn ich das richtig lese, wird für $lvl immer ein numerischer Wert erwartet und der Eintrag "ignore" nicht gesondert behandelt. Beim abschließenden CUL_HM_PushCmdStack wird dann ein "$lvl*2 rausgeschickt an das Device... und "ignore * 2" ist m.E. 0.

Meine Frage also: Ist "ignore" als möglicher Wert für den Level überhaupt sinnvoll oder funktioniert das aktuell eher zufällig?

Vielen Dank & beste Grüße
Michael

[martinp876]

Hi,

ich kann nicht sehen, dass 'ignore' zugelassen ist - und was es bedeuten soll.
Commandref besagt
level:  range is 0 to 100%

An dieser Stelle soll m.E. der Öffnungswinkel stehen. "Fahre nach delay mit speed in in den Zustand 'ignore'" soll was bedeuten?

[mmattern]

Hi,

ich kann nicht sehen, dass 'ignore' zugelassen ist - und was es bedeuten soll.
Commandref besagt
level:  range is 0 to 100%

An dieser Stelle soll m.E. der Öffnungswinkel stehen. "Fahre nach delay mit speed in in den Zustand 'ignore'" soll was bedeuten?

Hallo Martin,

das ist eben genau die Frage - unter http://www.meintechblog.de/2013/07/bessere-raumluftqualitaet-durch-fhem-und-homematic-adapter/ ist Jörg der Meinung, man müsste das so machen...
Ich denke aber, dass am Ende FHEM ein "set <device> level ignore 0 20" äquivalent zu "set <device> level 0 0 20" behandelt und das Verriegeln trotzdem funktioniert...

Da der Artikel schon älter ist, hatte ich vermutet, dass es vielleicht damals in FHEM anders umgesetzt war...

[martinp876]

ich habe jetzt eingebaut, dass "ignore" zu einem ordentlichen reject führt.

[mmattern]

ich habe jetzt eingebaut, dass "ignore" zu einem ordentlichen reject führt.

Vielen Dank für die Klärung!

[speedy_gonzales]

Hallo Zusammen,

dies ist heute mein erster Beitrag im Forum. Ich habe seit 2 Jahren mit fhem begonnen und würde mich als Nutzer mit ausbaufähigen Kenntnissen bezeichnen.

Meine Installation hat bis heute einen gewissen Reifegrad erreicht und war bisher extrem zuverlässig. Tja, bis heute, bis ich das Update gemacht habe.

Ich habe sehr lange gebraucht, bis ich diesen Thread gefunden habe als Erklärung für die nicht mehr funktionierende Winmatic.

Das Fenster wurde geöffnet über den Befehl "set WZ_Fenster_Win level 100 ignore 100".
Geschlossen wurde das Fenster über "set WZ_Fenster_Win level ignore 0 100".

Ursprünglich hatte ich versucht, statt ignore den Wert 0 zu verwenden. Dabei traten jedoch Fehler auf. Erst das Lesen des Blogs meintechblog.de brachte die Lösung, eben die Verwendung von ignore anstelle der Null. Dies hat mmattern ja bereits beschrieben.

Klar, dass wenn ignore nicht mehr zugelassen ist, die von mir  verwendeten Befehle nicht mehr funktionieren können. Es wird sicherlich noch einige mehr gegeben, die jetzt anfangen zu verzweifeln, weil die Winmatic plötzlich, ohne dass etwas an der Konfiguration geändert wurde, nicht mehr funktioniert.

Der Grund, warum ich diesen Beitrag schreibe, ist dass mir nicht einleuchtet, warum "ignore" keine sinnvolle Option ist.

Ich habe den Befehl für das Schliessen nun geändert und das Ignore durch Null ersetzt.

"set WZ_Fenster_Win level 0 0 100"

führt zu der Fehlermeldung, dass ein Wert zwischen 0 und 100 nur erlaubt ist. Allerdings führen auch die Werte 1 bis 9 zu derselben Fehlermeldung. Erst ab dem Wert 10 bis 100 schliesst das Fenster, wobei eigentlich zu erwarten wäre, dass die Werte dazu führen, dass ein in Prozent angegebener Kippwinkel zwischen 0 und maximalen Öffnungswinkel angefahren wird. Aber dies ist nicht der Fall. Jeder Wert führt zum vollständigen Schliessen des Fenster. Die integer Werte, die zum Schliessen führen sind also beliebig oder ungültig. Der eingesetzte Wert kann ignoriert werden, also warum sollte die Option "ignore" anstelle eines integer keinen Sinn machen?

Ein weiteres sehr merkwürdiges Verhalten zeigt sich beim Öffnen des Fensters:

"set WZ_Fenster_Win level 100 0 100"

führt dazu, dass das Fenster sofort mit grösster Geschwindigkeit voll öffnet und, nachdem der maximale Kippwinkel erreicht ist, direkt wieder vollständig schliesst. Der Wert 0 gibt die Öffnungsdauer an. Deshalb wird hier "ignore" als Option verwendet, damit das Fenster geöffnet bleibt.

Zusammenfassung: "Ignore" sollte als Option erlaubt sein, weil die beschriebenen Fehler vermieden werden und für viele die  Verwendung auch einen Sinn ergibt, weil der Wert 0 zu unlogischem Verhalten der Winmatic führt.

Ansonsten bedanke ich mich für die tolle Arbeit, die hier geleistet wird.

Viele Grüsse
Norbert

[speedy_gonzales]

So, ich habe jetzt das Verhalten der WinMatic noch einmal genauer untersucht.

"Set WZ_Fenster_Win level 100 0 100"

bewirkt, dass das Fenster voll öffnet, für die Dauer von 0 Sekunden geöffnet bleibt und dann sofort voll schliesst. Der Vorgang läuft mit maximaler Geschwindigkeit ab.

"Set WZ_Fenster_Win level 100 ignore 100"

bewirkt, dass das Fenster voll öffnet, und geöffnet bleibt (es wurde keine Öffnungsdauer angegeben). Das Öffnen läuft mit maximaler Geschwindigkeit ab.

"Set WZ_Fenster_Win level 10 0 100"

Im Prinzip passiert das Gleiche, wie beim 1. Befehl (level 100 0 100).
Allerdings sind hier 2 Fälle zu unterscheiden.
Das Fenster ist geschlossen: Das Fenster öffnet zu 10% und schliesst dann sofort wieder.
Das Fenster ist geöffnet (100%): Das Fenster fährt zu auf 10% und schliesst dann sofort (nach einer Gedenksekunde).

Mit dem Verhalten bei geöffneten Fenster kann man leben. Das Verhalten bei geschlossenem Fenster ist ein Ärgernis. Der gewünschte Schliessbefehl bewirkt, dass das Fenster auffährt, damit es anschliessend schliesst.

Dieses Verhalten muss über eine zusätzliche Routine abgefangen werden:
Wenn Fenster zu, dann mache gar nichts.
Wenn Fenster auf, dann schliesse.

Umständlich. Wie gesagt, dieses Problem gab es mit der Option "ignore" nicht.

Der Befehl
"Set WZ_Fenster_Win level 100 ignore 100" öffnete das Fenster.
"Set WZ_Fenster_Win level ignore 0 100" schloss das Fenster.
In Abhängigkeit vom Kippstand (geschlossen/geöffnet) bewirkte der Schliessbefehl nichts/das Schliessen.
Analog arbeitete der Öffnungsbefehl.

Also das jetzige Verhalten ist irgendwie fehlerhaft. Eine Rückentwicklung auf den alten Stand ist wünschenswert. Alternativ sollte die Null als Optionswert für den Kippwinkel eingeführt werden, damit ein echter Schliessbefehl realisiert werden kann. Siehe Fehlermeldung:

fhem> set WZ_Fenster_Win level 0 0 100
please enter level 0 to 100
fhem>

fhem> set WZ_Fenster_Win level ignore 0 100
please enter level 0 to 100
fhem>

So, ich hoffe, ich konnte klar machen, was das Reject von Ignore bewirkt.

Als ich die WinMatic installierte, wollte ich eigentlich über das Triggern der Funktionstasten an der Winmatic die entsprechenden Aktionen auslösen, um so eine Fehlfunktion (Fenster ist offen und gedreht und bekommt von fhem den Befehl zu kippen) zu verhindern. Dabei gehe ich davon aus, dass die WinMatic die jeweiligen Zustände erkennt und entsprechend keine Aktion ausführt bei Betätigen einer falschen Taste.

Dies ist mir jedoch nicht gelungen. In den Readings zeigt R-intKeyVisibl auf invisib. Ein entsprechender

"set WZ_Fenster setReg intKeyVisibl visib"

erzeugt keinen Fehler, bewirkt aber auch nichts inKeyVisibl bleibt invib.
Damit bleiben die Buttons der WinMatic verborgen und das Triggern der Tasten ist nicht möglich. Und umgekehrt ist es nicht möglich, einen direkten Tastendruck an der WinMatic in FHEM als event zu signalisieren.

"set ... level" ist eine Krücke. Vielleicht verstehe ich aber einfach nicht die Methode, wie die winMatic auf dieser Ebene angesprochen wird.

Viele Grüße
Norbert

[mmattern]

@martinp876:

Ich glaube, es ist einfach in Zeile 3346 in 10_CUL_HM.pm ein Bug...

Im Moment heißt es dort:

Code Auswählen Erweitern

return "please enter level 0 to 100" if (!defined($lvl)    || $lvl !~ m/^\d+\.?\d+$/ || $lvl>100);

Ich würde dies vorschlagen:

Code Auswählen Erweitern

return "please enter level 0 to 100" if (!defined($lvl)    || $lvl !~ m/^(1)?\d{1,2}(\.\d+)?$/ || $lvl>100);

Dann lässt er auch 0..9 zu...

Viele Grüße
Michael

[martinp876]

das sollte jetzt alle Nummern mit einem Punkt erlauben.
danke Martin

[speedy_gonzales]

Hallo,

ich habe den bug fix getestet. Bei Eingabe von 0 für den Schliesswinkel kommt keine Fehlermeldung. Danke für den Fix.

Allerdings ändert sich nicht das beschriebene Verhalten der Winmatic. Ist das Fenster geschlossen und verriegelt, entriegelt es und verriegelt sofort wieder bei Eingabe von "level 0 0 100".

Dies ist dasselbe Verhalten, dass sich auch bei jedem anderen Wert zwischen 1 und 100 zeigt. Der Schliessbefehl öffnet zuerst das Fenster, um es danach sofort zu schliessen. Es ist also egal, ob ich 0, 50 oder 100 eingebe. Bei 50 kippt das Fenster 50%, bei 0 kippt es 0%. Entriegelt wird aber in beiden Fällen.

Ich denke, das Problem liesse sich lösen, wenn ich die buttons auf der homematic triggern könnte, aber das gelingt einfach nicht. Vielleicht kann mich hier jemand in die richtige Richtung schubsen. Was übersehe ich, wenn ich intKeyVisible auf visibl setzen möchte, um die buttons in den Readings sehen zu können.

Danke erstmal

Norbert

[martinp876]

hast du den "press" Befehl schon probiert?

[speedy_gonzales]

Martin,

danke für die Nachfrage.

Ich habe den Befehl press probiert. Im Log steht dann:

2014.07.20 12:26:17 3: CUL_HM set WZ_Fenster_Win press self01
2014.07.20 12:27:15 3: CUL_HM set WZ_Fenster_Win press self02
2014.07.20 12:33:41 3: CUL_HM set WZ_Fenster_Win press self01
2014.07.20 12:36:50 3: CUL_HM set WZ_Fenster_Win press self03

aber es passiert gar nichts.

Und das liegt, so vermute ich aufgrund Deiner Diskussion vom März mit pusche,l daran, dass intKeyVisibl sich nicht auf visilb setzen lässt.

Viele Grüsse

Norbert

[mmattern]

Ich denke, das Problem liesse sich lösen, wenn ich die buttons auf der homematic triggern könnte, aber das gelingt einfach nicht. Vielleicht kann mich hier jemand in die richtige Richtung schubsen. Was übersehe ich, wenn ich intKeyVisible auf visibl setzen möchte, um die buttons in den Readings sehen zu können.

Hallo zusammen,

ggf. könnte man vor Weitergabe des Kommandos prüfen, ob ein Schließen die Konsequenz wäre und es nur dann weitergeben, wenn das Fenster nicht geschlossen ist...

Viele Grüße
Michael

[speedy_gonzales]

Hallo Michael,

genau das meinte ich, als ich schrieb:

Dieses Verhalten muss über eine zusätzliche Routine abgefangen werden:
Wenn Fenster zu, dann mache gar nichts.
Wenn Fenster auf, dann schliesse.

Diese Routine habe ich bereits eingebaut. Es mindert ein wenig das unnötige Öffnen bevor die winmatic schliesst. Aber das Verhalten ist auch bei gekippten Fenster nicht richtig.
Der Befehl z.B. level 10 0 100 wird interpretiert als "Kippe auf 10%, Fahre dann unverzüglich auf 0%, Verriegel". Entsprechend wird bei Null auf 0% gekippt, was faktisch ein Schliessen ist.

Der Befehl ist m.E. von der Logik her nicht richtig, deshalb meine Wunsch das "ignore" wieder einzuführen.

Bei einem "Öffnen" Befehl erwarte ich, dass das Fenster in positive Richtung kippt, beim Schliessen in negative Richtung. Der Schliessbefehl kippt jedoch in jede Richtung in Abhängigkeit vom angegebenen %-Wert und ausgehend von der Ist-Stellung und schliesst erst im Anschluss. Der Grund ist, dass es sich eigentlich um den "Öffnen" Befehl handelt, der aufgrund des Timers 0 Sekunden geöffnet bleibt.

Ist alles nicht dramatisch. Funktioniert ja, nur eben gefühlt nicht richtig.

Viele Grüße

Norbert

[martinp876]

das Kommando will einen wert haben.
111600 ist der "ignore" wert. das sollte das relock abschalten - ist aber schwer zu merken. '0' ist in jedem Fall falsch.

kannst du dennoch probieren, dass es klappt? mache 2 Versuche und logge die rohmessages
level 10 1000 100
statusRequest

level 10 111600 100
statusRequest

der statusRequest nachdem das Fenster in der position ist hätte ich gerne gesehen (die messages)