Probleme mit Qubino ZMNHCD1 Flush Shutter Plus

[A.Harrenberg]

Hi,

soo, angehängt mal eine Version der 10_ZWave.pm mit SWITCH_MULTILEVEL V4 Unterstützung.
Könntet Ihr das mal bitte testen? Ich habe leider kein Gerät was die Befehle unterstützt, kann also auch nicht sagen was passieren würde...

Für die Steuerung von Jalusien dürfte "dimUpDownIncDecWithDuration" zuständig sein.

Code Auswählen Erweitern

dimUpDownIncDecWithDuration (UP|DOWN|NOMOTION) (IGNORE|USE) <startlevel> <duration> (INC|DEC|NOINCDEC) <stepsize>
similar to dimUpDownWithDuration, adding support for secondary switch types (e.g. shutter and blind control) (V3).
The dimming/movement of the primary switch type can inhibited by specifying NOMOTION, so that only the secondary switch type is used. The secondary switch type is controlled by the keywords INC, DEC and NOINCDEC, where NOINCDEC will inhibit the dimming/movement of the secondary switch. If NOINCDEC is used, the <stepsize> must be specified as 0.
<stepsize> can be 0..99 or 255.
Note: <stepsize> will be interpreted by the device, most likely to represent a time or position, e.g. to turn blinds.
<duration> can be 0..7620 seconds (127 minutes). Up to a duration of 127 seconds, the (internal) resolution is 1 second, for longer durations the resolution is 60 seconds.
Note: A device SHOULD respect the given duration, however, most devices will use their internal default duration and ignore the specified duration.
Ich vermute das man hier vorab für den "secondary" switch, der ja dann z.B. den Jalusienwinkel einstellen soll, z.B. eine Zeit für das Umstellen der Winkels am Gerät einstellt, und das Gerät dann eine Anforderung von <stepsize> 85 in eine Ansteuerung von 85% dieser Zeit umsetzt. Wie gesagt, reine Vermutung, ich kann es nicht testen...

Gruß,
Andreas.

[krikan]

Hallo Andreas!

Beim FGRM mit V3 kann ich die Logik bei Ausführung des Befehls nicht erkennen. Raffstore faehrt ganz auf/zu, selbst wenn ich nur kurze Laufzeiten angebe. Das liegt wohl nicht an Deiner Aenderung; hatte ich gestern mit raw-Befehlen auch schon. Also schlechtes Testobjekt oder Tester. Fibaros Homecenter steuert den FGRM afaik nicht mit SWITCH_MULTILEVEL an.

Der TE sollte evtl. mal mit dem Qubino testen. Da könnte es besser funktionieren.

Die zunehmende Komplexiataet der höheren Class-Versionen führt nicht unbedingt zu intuitiven Befehlen (dimUpDownIncDecWithDuration).  So etwas laesst sich aber wohl nicht vermeiden.

Gruß, Christian

[A.Harrenberg]

Hi Christian,

Beim FGRM mit V3 kann ich die Logik bei Ausführung des Befehls nicht erkennen. Raffstore faehrt ganz auf/zu, selbst wenn ich nur kurze Laufzeiten angebe. Das liegt wohl nicht an Deiner Aenderung; hatte ich gestern mit raw-Befehlen auch schon. Also schlechtes Testobjekt oder Tester. Fibaros Homecenter steuert den FGRM afaik nicht mit SWITCH_MULTILEVEL an.

Ich bin mir nicht mehr sicher ob ich das beim Fibaro oder Qubino gelesen hatte das des dort ein Configregister gibt in dem man die Zeit einträgt die man bei Jalusien für das Vollständige Umstellen des Winkels benötigt.

Ich hatte das so interpretiert das diese Zeit dann als 100% definiert wird und die Stepsize dann entsprechend daran skaliert wird.

Die zunehmende Komplexiataet der höheren Class-Versionen führt nicht unbedingt zu intuitiven Befehlen (dimUpDownIncDecWithDuration).  So etwas laesst sich aber wohl nicht vermeiden.

Ja, der Befehl schießt den Vogel ab ,-)
Für bessere Vorschläge wäre ich dankbar.

Wenn Befehle mit höheren Klassen weitere Optionen bekommen kann man entweder den Befehl beibehalten und "nur" die Syntax anpassen (muß dann aber auch entsprechend parsen und mit der Version der Klasse abgleichen), oder man macht für die verschiedenen Versionen der Klassen neue Befehle mit eigenständiger Syntax. Hier muss man dann nicht so aufwändig parsen, dafür kommen dann solche Namen dabei raus...

Rudi hat sich ja für die Variante der unterschiedlichen Befehle enstschieden weil er befürchtet das ansonsten Anwender versuchen Beispiele für "höhere" Klassen nachzuvollziehen als das eigene Gerät unterstützt.

Je mehr ich darüber nachdenke umsomehr komme ich zu dem Schluß das ein aufwändigeres Parsen mit vernünftigen Fehlermeldungen vielleicht doch sinnvoller wären. Dann müsste man das Parsen der Eingabewerte allerdings auch radikal überdenken. Diese Vielfalt an Parametern lässt sich wahrscheinlich nur mit Wertepaaren Parameter=Wert vernünftig parsen. Aber das ist jetzt ein ganz anderes Thema...

Gruß,
Andreas.

[krikan]

Ich bin mir nicht mehr sicher ob ich das beim Fibaro oder Qubino gelesen hatte das des dort ein Configregister gibt in dem man die Zeit einträgt die man bei Jalusien für das Vollständige Umstellen des Winkels benötigt.

Bei Fibaro gibt es das Register und das ist auch richtig gesetzt. Mein Problem ist auch nicht die Winkelverstellung, sondern das immer vollstaendige hoch- bzw. herunterfahren. Habe gerade noch mal kurz probiert, aber ich bekomme es nicht in den Griff und mache jetzt Testpause, bevor der Motor abraucht.

Für bessere Vorschläge wäre ich dankbar.

Momentan keine, sonst haette ich schon geliefert. 

Je mehr ich darüber nachdenke umsomehr komme ich zu dem Schluß das ein aufwändigeres Parsen mit vernünftigen Fehlermeldungen vielleicht doch sinnvoller wären. Dann müsste man das Parsen der Eingabewerte allerdings auch radikal überdenken. Diese Vielfalt an Parametern lässt sich wahrscheinlich nur mit Wertepaaren Parameter=Wert vernünftig parsen. Aber das ist jetzt ein ganz anderes Thema...

Bin dabei (relativ) unentschieden. Das dürfte ihr untereinander regeln. 

Gruß, Christian

[A.Harrenberg]

Hi Christian,

Bei Fibaro gibt es das Register und das ist auch richtig gesetzt. Mein Problem ist auch nicht die Winkelverstellung, sondern das immer vollstaendige hoch- bzw. herunterfahren. Habe gerade noch mal kurz probiert, aber ich bekomme es nicht in den Griff und mache jetzt Testpause, bevor der Motor abraucht.

Passiert das auch bei "NOMOTION"? Auch bei kleinen stepsize Werten? Kann es sein das man das Hoch-Runterfahren mit STOP beenden muss und er erst DANN die Winkelverstellung macht?

Bin dabei (relativ) unentschieden. Das dürfte ihr untereinander regeln. 

Puh, das Fass möchte ich jetzt ehrlich gesagt gar nicht aufmachen. Alleine das Parsen auf Parameter=Wert umzustellen wäre schon eine tierisch große Änderung, danach müsste man sich dann noch mal alle Befehle anschauen und wieder vereinheitlichen. Das kommt schon fast einer Neuentwicklung gleich... Und die Argumente das mit jeweils neuen Befehlen zu machen sind ja weiterhin gültig.

Gruß,
Andreas.

[SnakeZZ]

@SnakeZZ: Ich hoffe Du kannst noch ein wenig warten und kannst dann mit Tests unterstützen.

Hi!

Ich war am WE eh anderweitig beschäftigt. Ich habe gesehen, dass weiter oben im Thread nach einem Test gefragt wird.
Wie mache ich das am Besten (ich bin noch recht neu bei FHEM)?

Beste Grüsse,

SnakeZZ

[krikan]

Hallo!

Du musst die 10_ZWave.pm in Deiner FHEM-Installation durch die oben von Andreas angehaengte Fassung ersetzen. Dann einmal "shutdown restart" und Du solltest dann die neuen Befehle beim Device für den Qubino haben und damit experimentieren können.

Vorher vielleicht für den dümmsten Fall der Faelle Dein FHEM sichern ("backup"), wenn Du kein Testsystem hast.

Gruß, Christian

[krikan]

Wie mache ich das am Besten (ich bin noch recht neu bei FHEM)?

Da heute per update neue Versionen von 00_ZWDongle.pm und 10_ZWave.pm verteilt werden, die Warnung: Die beiden Dateien sind voneinander abhängig und aufeinander abgestimmt. Es kann zu Funktionsproblemen kommen, wenn man nicht zueinander passende Versionen nimmt. Habe nicht ausprobiert bzw. angeschaut, ob Andreas obige 10_ZWave.pm mit der heute verteilten 00_ZWDongle. pm zusammenarbeitet. Wäre aber eher vorsichtig und würde den Test vor einem update machen.

Die Abhängigkeiten kann es auch zu anderen Modul/FHEM-Dateien geben, ist aber nicht so "gefährlich" wie zwischen den ZW*.pm-Modulen.

[A.Harrenberg]

Hi,

ich glaube zwar nicht das es hier Probleme gibt, kann das aber aus Zeitmangel gerade nicht selbst ausprobieren bzw. meine Änderungen in die aktuelle 10_ZWave.pm übertragen. Also entweder Mut zur Lücke oder noch ein paar Tage warten.

Gruß,
Andreas.

[krikan]

Die Qubino ZMNHCD1 Flush Shutter Plus können mit FHEM nach der korrekten Einbindung und Konfiguration laut Aktor-Bedienungsanleitung Raffstores ansteuern.
Das funktioniert ohne irgendeine Anpassung in FHEM über die Class SWITCH_MULTILEVEL;
Endpoint 1 steuert über "set <device> dim %" die Jalousienhöhe,
Endpoint 2 steuert über "set <device> dim %" die Winkeleinstellung.

Die Anpassung von Andreas ist dazu für diesen Aktor nicht notwendig.

Dennoch fände ich eine Aufnahme von Andreas Änderungen, insb "dimUpDownIncDecWithDuration" in das Modul sinnvoll.  Kann auch -falls gewünscht- gerne einen aktualisierten Patch liefern.

[rudolfkoenig]

Falls Du den Patch liefern willst, bitte beachten:
- die hier angehaengte Version wurde gegen eine andere/aeltere? eingecheckte Version gemacht (und nicht die angezeigte 12546), da es einige sinnvolle Sachen (wie ZWave_BASIC_03_report) ausbaut.
- die neuen Regexps mit ^ am Anfang sollten ein Fehler erzeugen, da das ^ automatisch hinzugefuegt wird.
- switchWithDuration sollte on/off-for-timer heissen (wg. setExtensions), und eine Zeitkonvertierung durchfuehren.
- ZWave_time2duration sollte eine Logmeldung ausgeben, falls die Konvertierung nicht genau erfolgen konnte (analog zu FS20)
- Laut ZWave_duration ist 0xfe "unknown", und ZWave_time2duration setzt alle Werte > 2 Stunden auf 0xFE. Was genau bedeutet 0xFE?

Ich kann die Befehle aus dem angehaengten Version auch integrieren, muss aber Zeit und Musse finden, ich pack das mal auf meine TODO Liste.
Ich bin auf eure Hilfe wg. Testen angewiesen, da ich kein Geraet mit entsprechenden Klassen habe.
Kennt jemand ein Geraet mit SWITCH_BINARY v2? Sowas wuerde ich gerne haben.

[rudolfkoenig]

Habe das Patch integriert.

switchWithDuration ist jetzt on-for-timer/off-for-timer, die Einschraenkungen sind in commandref dokumentiert.
Achtung: Falls jemand ein Geraet mit SWITCH_BINARY V2 hat, dann wird sich das Verhalten von on-for timer/blink aendern, abhaengig vom spezifizierten Parameter.

Da ich keine passenden Geraete habe, konnte ich das Verhalten nicht testen, deswegen waere ich fuer Feedback dankbar.

[ToKa]

Hallo Rudi,

seit der aktualisierten Version funktioniert mein FIBARO System FGS213 Switch nicht mehr richtig bei "on-for-timer". Der Switch schaltet die Lampe an, aber nach der vorgegebenen Zeit nicht mehr aus. Ich setze den Befehl "set ST_fl_US_Wandspot on-for-timer 900" in einem doif an das Hauptgerät ab und habe ansonsten an meiner Konfiguration nichts verändert.

Im state des Hauptgeräts steht auch heute Abend noch
on-for-timer 900
mit der Uhrzeit von heute morgen. Die Lampe ist auch immer noch an und ich kann sie über fhem ausschalten. Ich beobachte das Verhalten nun schon mehrere Tage und würde mich freuen,wenn der alte funktionierende Zustand wieder hergestellt wird.

Sollte ich mit meiner Vermutung,dass die Änderung die Ursache ist daneben liegen, mache och ich gerne einen neuen Thread auf. Falls log Dateien benötigt werden, sag Bescheid.

Beste Grüße

Torsten

[rudolfkoenig]

Ich vermute, dass fuer das besagte Geraet vclasses nicht gesetzt ist, und damit das Modul auf die ZWave Implementation zurueckgegriffen hat, was vom Geraet nicht unterstuetzt wird.

Workaround: mit "get dev versionClassAll" vclasses setzen.

Ab dem morgigen update werden diese "optionalen" Kommandos nur bei vorhandenen vclasses angeboten.

[m8ichael]

Moin!

Kann es sein, dass die Änderung vom 19.07.2018 an der 10_ZWave.pm zu problematischen Quereffekten führt? Ich habe jedenfalls gestern ein Update von FHEM gemacht und wurde heute morgen recht unsanft durch mein Aufwecklicht in den Montag geschickt... 

So nutze ich bereits seit Monaten an meinem Dimmer den Befehl

Code Auswählen Erweitern

set <Aktor> dimWithDuration 60 183

der dann schön langsam das Licht aufblendet. Seit dem Update funktioniert das nicht mehr sauber. Einerseits wird binnen weniger Sekunden aufgedimmt, andererseits wird im Log der Hinweis

Code Auswählen Erweitern

2018.08.13 05:45:00 2: <Aktor>: changing *for-timeout to 180 from 183
2018.08.13 05:45:00 3: ZWave set <Aktor> dimWithDuration 60 183

geschmissen.

Habt ihr da eine Lösung?

Viele Grüße

Michael