Probleme mit Qubino ZMNHCD1 Flush Shutter Plus

[SnakeZZ]

Hallo Zusammen!

Ich habe zur Steuerung meiner Aussenstoren 2 Qubino ZMNHCD1 Flush Shutter Plus verbaut. Inklusion hat geklappt und theoretisch laufen sie nun.

Es gibt allerdings zwei Betriebsarten - Normale Rolllade oder Storen (Shutter vs. Venetian Blind). Ich habe bereits nach Anleitung den Betrieb auf Storenbetrieb umgestellt (inkl. Exklusion/Inklusion), aber ich bekomme im FHEM einfach keine Steuerungsfunktionen für den Storenwinkel. Laut der Qubino Videos müsste "automatisch" im Storenbetrieb ein zweiter Regler auftauchen, mit dem man den Storenwinkel stellen kann.

Wisst Ihr was ich hier falsch mache?

Beste Grüsse,

SnakeZZ

[krikan]

Es gibt allerdings zwei Betriebsarten - Normale Rolllade oder Storen (Shutter vs. Venetian Blind). Ich habe bereits nach Anleitung den Betrieb auf Storenbetrieb umgestellt (inkl. Exklusion/Inklusion), aber ich bekomme im FHEM einfach keine Steuerungsfunktionen für den Storenwinkel. Laut der Qubino Videos müsste "automatisch" im Storenbetrieb ein zweiter Regler auftauchen, mit dem man den Storenwinkel stellen kann.

Zeigt Qubino im Video wirklich FHEM?
Falls ja: Hast Du einen Link?

Die Frage ist, mit welcher Command Class die Winkelverstellung realisiert wird. Fibaro löst das über eine herstellereigene Erweiterung.
Detaillierte technische Daten des Gerätes, das ich weder bei pepper1 noch bei der Zwave-Allianz finde, wären hilfreich (list "device" und und Doku).

Btw: Hier http://www.zwave-review.com/tests/Qubino-Relais_Dimmer.php findet sich ein Hinweis, warum Qubino-Geräte evtl. nicht in http://products.z-wavealliance.org/ und/oder pepper1 zu finden sind.

Gruß, Christian

[krikan]

Laut dem Handbuch http://www.vesternet.com/downloads/dl/file/id/1134/product/1562/z_wave_qubino_flush_shutter_plus_user_manual_v1_3.pdf nutzt der Aktor V3 der Class SWITCH_MULTILEVEL. Die Version ist mWn nicht in FHEM eingebaut. Laut http://zwavepublic.com/sites/default/files/SDS12657-12%20-%20Z-Wave%20Command%20Class%20Specification%20A-M.pdf wurde mit der Version die Winkeleinstellung in "Multilevel Switch Start Level Change Command" eingeführt.

Wenn Winkelverstellung nicht "zufällig" über die Endpoint-Devices funktioniert, setzt Winkelverstellung wohl eine Anpassung von 10_ZWave.pm voraus.

[A.Harrenberg]

Hi,

und genau diese V3 von SWITCH_MULTILEVEL ist von der ZWave-Alliance "DEPRECATED"...
Da gibt es primary und secondary switch types die dann u.a. auch Sachen wie Clockwise und Counter-Clockwise können, was hierfür anscheinend nötig wäre.

Ich hatte mal angefangen die Implementierung zu vereinheitlichen, hatte mich damals aber eigentlich dagegen entschieden die V3/V4 zu implementieren...
Wenn es jetzt benötigt wird schaue ich mir das noch mal an, wird aber was dauern bis ich dazu komme.

Gruß,
Andreas.

[krikan]

genau diese V3 von SWITCH_MULTILEVEL ist von der ZWave-Alliance "DEPRECATED"...

Das "DEPRECATED" wird in zwapi haeufig angeführt. Es gibt aber regelmaeßig einige Devices, die auch diese Versionen nutzen. Bevor die neuen Versionen sich durchsetzen dauert es ein wenig; wenn überhaupt. Bin mir nicht sicher, ob ich das nicht eher als Sigma-Wunsch auffasse.

Wie der Zufall es will, hat der FGRM-222 auch V3. Bisher ging ich davon aus, dass Winkelverstellung nur über MANUFACTURER_PROPRIETARY funktioniert, jetzt bekomme ich Zweifel.

Das ist die Rückgabe auf "SwitchMultilevelCmd_SupportedGet":

Code Auswählen Erweitern

ARG:0426070302
Demnach sollte es doch einen Primary und Secondary Switch Type geben!?

[A.Harrenberg]

Hi Christian,

DEPRECATED heißt hier nur das es keine weiteren neuen Zertifizierungen mit der Klassenversion geben wird.
Aber eigentlich muss die V4 ja abwärtskompatibel zur V3 sein, so verstehe ich das PDF jedenfalls auch, was jetzt auf Anbieb erst mal keinen Sinn macht dann die V3 auszugrenzen. Kann höchstens sein das sie in Ihrer Implementierung einen "Fehler" haben und den in der V4 Implementierung gefixed haben und nicht wollen das jemand mit dem SDK noch eine V3 erzeugt...

Da die Geräte jetzt ja anscheinend doch nicht die Ausnahme sind, schaue ich mir das auf jeden Fall noch mal an. Dürfte nicht so schwierig sein das zu implementieren, sind aber wohl etliche neue Möglichkeiten die es zu unterscheiden gibt. Dürfte dann wieder das Bennungsproblem (state on/off, 0..99 etc.) aufwerfen, da jetzt ja auch up/down, clockwise/counter-clockwise etc. hinzukommen...

Dein

Code Auswählen Erweitern

ARG:0426070302 sollte ein primary "Close/Open" und secondary "Down/Up" Type sein. Hat das Ding denn wirklich zwei Ausgänge? Der Name 222 deutet ja eigentlich darauf hin...

Gruß,
Andreas.

[krikan]

Hat das Ding denn wirklich zwei Ausgänge? Der Name 222 deutet ja eigentlich darauf hin...

Ja, ist ein Jalousieaktor. Steuere damit Raffstoremotoren über die herstellerspezifische Class an.

[A.Harrenberg]

Hi,

was ist denn die herstellerspezifische Klasse??
Kannst Du damit denn schon sowas wie Position + Winkel vorgeben? Macht bei Raffstores wahrscheinlich keinen Sinn...

Muss mir die Klasse mal in Ruhe ansehen, beim Drüberfliegen sind da noch ein paar Fragezeichen offen geblieben.

Aber mal was anderes zu der Anleitung von dem Fibaro Teil... In der Anleitung steht das man die Eingänge S1/S2 auf keinen Fall mit Netzstrom verbinden darf da ansonsten das Gerät zerstört wird?? Wie denn sonst? Das Anschlussschema zeigt ja auch genau das die Taster/Schalter die Phase an S1/S2 legen... Oder habe ich da was falsch verstanden?

Gruß,
Andreas.

[krikan]

was ist denn die herstellerspezifische Klasse??
Kannst Du damit denn schon sowas wie Position + Winkel vorgeben? Macht bei Raffstores wahrscheinlich keinen Sinn...

Ja:

Class MANUFACTURER_PROPRIETARY
Fibaro FGR(M)-222 only:
positionBlinds
drive blinds to position %
positionSlat
drive slat to position %

Sind Außenraffstores und dort ist die Winkelverstellung zwingend.

Aber mal was anderes zu der Anleitung von dem Fibaro Teil... In der Anleitung steht das man die Eingänge S1/S2 auf keinen Fall mit Netzstrom verbinden darf da ansonsten das Gerät zerstört wird?? Wie denn sonst? Das Anschlussschema zeigt ja auch genau das die Taster/Schalter die Phase an S1/S2 legen... Oder habe ich da was falsch verstanden?

Das verstehe ich gerade auch nicht. Habe mich damit aber nicht beschaeftigt, da ich den FGRM ohne angeschlossene Taster/Schalter betreibe.

[A.Harrenberg]

Hi,

ah, jetzt raff ich es auch... Das ist keine herstellerspezifische Klasse (das wäre mir nämlich ein völlig neues Konzept...) sondern eine "Ausnahme bzw. Erweiterung" in FHEM über die Einträge in %zwave_deviceSpecial.
Aber guter Hinweis, im Idealfall sollte die V3/V4 ja kompatibel dazu werden, dann müsste nichts umgestellt werden.

Gruß,
Andreas.

[krikan]

Aber guter Hinweis, im Idealfall sollte die V3/V4 ja kompatibel dazu werden, dann müsste nichts umgestellt werden.

Kein Ahnung, ob das wirklich wichtig ist. Bei mir läuft die Ansteuerung des FGRM mit Class MANUFACTURER_PROPRIETARY problemlos. Umstellen würde ich deshalb beim FGRM nicht unbedingt auf Class SWITCH_MULTILEVEL, wenn es mir keine Vorteile bietet. Mein persönliches Interesse ist eher die Weiterbildung und Forschung  . Bei anderen Aktoren (hier Qubino) wird so eventuell erst die volle Unterstützung durch FHEM erreicht.

SWITCH_MULTILEVEL ist ja auch für weitere Geräte als Jalousieaktoren verwendbar, wobei mir gerade kein sinnvolles, anderes Beispiel für mehrere SwitchTypes in einem Aktor einfällt.

[A.Harrenberg]

Hi,

so, jetzt habe ich mal etwas genauer hingeschaut und auch versucht das Hirn einzuschalten...

Also die Erweiterung für den Fibaro ist gerätespezifisch in FHEM und implementiert die Befehle positionSlat, positionBlinds und position. Hier kommt die Class MANUFACTURER_PROPRIETARY ins Spiel, allerdings NUR für die Rückmeldung (parse). Die SET/GET Befehle sind ganz normal aus der SWITCH_MULTILEVEL Klasse, allerdings >V1.

Code Auswählen Erweitern

   Fibaro_FGRM222 => {
     MANUFACTURER_PROPRIETARY => {
      set   => { positionSlat=>"010f26010100%02x",
                 positionBlinds=>"010f260102%02x00"},
      get   => { position=>"010f2602020000", },
      parse => { "0891010f260303(..)(..)" =>
                  'sprintf("position:Blind %d Slat %d",hex($1),hex($2))',
                 "0891010f260302(..)00" =>'"position:".hex($1)' } } },
D.h. wenn SWITCH_MULTILEVEL in >=V3 implementiert ist, könnten diese set/get Befehle entfallen, da sie dann über die normale Klasse verfügbar wären. Wenn ich die Anleitung richtig verstanden haben müsste man die Rückmeldung des Fibaro zwischen ZWAVE-Standard und MANUFACTURER_PROPRIETARY umschalten können. Ob das auch für den Quibino gilt glaube ich eher nicht, da ist in der Anleitung keine MANUFACTURER_PROPRIETARY Klasse erwähnt.

Ich schau mir jetzt die Doku der Klasse mal genauer an.

Gruß,
Andreas.

[krikan]

Die SET/GET Befehle sind ganz normal aus der SWITCH_MULTILEVEL Klasse, allerdings >V1

Ah, soweit hatte ich noch nicht nachgedacht und gelesen. Die SET/GET Befehle, die ich unter MANUFACTURER_PROPRIETARY eingeordnet habe, sind also standardmäßige SWITCH_MULTILEVEL-Befehl V3 und keine Eigenerweiterung von SWITCH_MULTILEVEL durch Fibaro (=MANUFACTURER_PROPRIETARY).

Rückmeldung des Fibaro zwischen ZWAVE-Standard und MANUFACTURER_PROPRIETARY umschalten können

Korrekt. Nur enthielt Rückmeldung ZWAVE-Standard mEn keinen Winkel (schaue ich mir heute abend noch mal am Objekt an)

[A.Harrenberg]

Hi,

Ah, soweit hatte ich noch nicht nachgedacht und gelesen. Die SET/GET Befehle, die ich unter MANUFACTURER_PROPRIETARY eingeordnet habe, sind also standardmäßige SWITCH_MULTILEVEL-Befehl V3 und keine Eigenerweiterung von SWITCH_MULTILEVEL durch Fibaro (=MANUFACTURER_PROPRIETARY).

und ich hatte zu Anfang nur die SWITCH_MULTILEVEL bemerkt und nicht das beim Parse MANUFACTURER_PROPRIETARY gemacht wird. Also haben wir beide nicht so ganz aufgepasst ,-)

Winkel, also Status des secondary switch, ist im Report von SWITCH_MULTILEVEL nicht vorgesehen, auch nicht in V4! D.h. für die Rückmeldung bist Du mit der Fibaro Meldung glücklicher... Das Parse muss man dann ja trotzdem in dem deviceSpecial drin lassen.

In der Anleitung von dem Quibino sind 4 Endpoints erwähnt, bin mir nicht sicher ob da die secondary switches vielleicht über einen weiteren Endpoint kontrolliert bzw. getrennt abgefragt werden können.

Na ich fange die Tage mal an das zu implementieren, dann werden wir ja sehen was da so alles vom Gerät zurückkommt.

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

Gruß,
Andreas.

[A.Harrenberg]

Hi Christian,

ok, noch mal Gehirn rebootet...

Die Befehle für den Fibaro sind doch alle aus der MANUFACTURER_PROPRIETARY Klasse... Ich hatte mich durch die "26" verwirren lassen. Das sind anscheinend ja zwei unabhängige Parameter möglich, das geht in SWITCH_MULITILEVEL nicht ,-(

Nicht mein Tag heute...

Andreas.

[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

[krikan]

Die Umrechnung/Umwandlung  von dec/hex hat mMn eine "Macke".

Die Rohnachricht für Deinen Befehl

Code Auswählen Erweitern

2018.08.13 17:57:18.078 5: ZWDongle_Write 0013130426015a520506 (e345c452)
Die Dauer wird mit 0x52, d.h. 82 Sekunden, verschickt. Es müsste aber 0x82 für 183 Sekunden, was ungefaehr 3 Minuten entspricht, sein.

[m8ichael]

Hi!

Die Umrechnung/Umwandlung  von dec/hex hat mMn eine "Macke".

Die Rohnachricht für Deinen Befehl

Code Auswählen Erweitern

2018.08.13 17:57:18.078 5: ZWDongle_Write 0013130426015a520506 (e345c452)
Die Dauer wird mit 0x52, d.h. 82 Sekunden, verschickt. Es müsste aber 0x82 für 183 Sekunden, was ungefaehr 3 Minuten entspricht, sein.

Hmm...das verstehe ich nun nicht. Dann muss der Fehler ja mit einem der letzten Updates (<=4 Wochen --> letztes Update bei mir) gekommen sein, denn bisher funzte ja alles. Der Befehl sorgte jedenfalls auch bisher nicht dafür, dass nach 3 Minuten aufgedimmt wird, sondern nach knapp einer Stunde (so habe ich zumindest die Anleitung verstanden und so hat mein Dimmer das bisher auch umgesetzt):

Code Auswählen Erweitern

dimWithDuration <value> <duration>
dim to the requested <value> (0..99) in <duration> seconds. (V2)
<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.

Viele Grüße

Michael

[m8ichael]

Hallo,

gerade noch mal in die Änderungshistorie der 10_ZWave.pm geguckt. Offenbar wird nun neuerdings - im Vergleich zu bisher - alles in Sekunden angegeben, wobei eine Dimmdauer > 2 Minuten durch 60 Sekunden teilbar sein muss. Nun habe ich die etwas kryptische Beschreibung auch verstanden... 

Viele Grüße

Michael

[m8ichael]

Hallo,

gerade noch mal in die Änderungshistorie der 10_ZWave.pm geguckt. Offenbar wird nun neuerdings - im Vergleich zu bisher - alles in Sekunden angegeben, wobei eine Dimmdauer > 2 Minuten durch 60 Sekunden teilbar sein muss. Nun habe ich die etwas kryptische Beschreibung auch verstanden... 

Viele Grüße

Michael

...funktioniert allerdings auch nicht 

@Rudi
Kannst du die Änderung noch mal validieren?

Gruß

Michael

[krikan]

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

Das betrifft nach meiner Beobachtung nur das Maindevice. Bei den Subdevices werden immer alle Befehle -egal was in vclasses des SubDevices steht- angeboten.

[rudolfkoenig]

Bitte um etwas Geduld...

[rudolfkoenig]

Die Dauer wird mit 0x52, d.h. 82 Sekunden, verschickt. Es müsste aber 0x82 für 183 Sekunden, was ungefaehr 3 Minuten entspricht, sein.

Habs gefixt, jetzt kommt auch 0x82

Bei den Subdevices werden immer alle Befehle -egal was in vclasses des SubDevices steht- angeboten.

Ja, weil die kein vclasses haben. Ich habe jetzt die Pruefung ueber den endpointParent hinzugefuegt, habe aber kein Geraet, womit ich sowas testen koennte, bin fuer Feedback dankbar.

[krikan]

Ich habe jetzt die Pruefung ueber den endpointParent hinzugefuegt, habe aber kein Geraet, womit ich sowas testen koennte, bin fuer Feedback dankbar.

Funktioniert.
Irritierend könnte sein, dass vclasses im endpointParent die Befehle im SubDevice bestimmt, obwohl auch im SubDevice vclasses gesetzt/abgerufen werden kann.

[rudolfkoenig]

Irritierend könnte sein, dass vclasses im endpointParent die Befehle im SubDevice bestimmt, obwohl auch im SubDevice vclasses gesetzt/abgerufen werden kann.

Ok, habs angepasst: bei Vorhandensein von vclass im subdevice wird diese genommen, sonst vom endpointParent.
Habs angenommen, dass kein subdevice VERSION anbietet. Gibt es solche Geraete doch?

[krikan]

Habs angenommen, dass kein subdevice VERSION anbietet. Gibt es solche Geraete doch?

Habe VERSION in subDevices sowohl bei einigen ZWavePlus-Qubino- als auch Fibaro FGS213-Geraeten. Der ZWavePlus Philio PAN04 hat es andererseits nicht. System erkenne  ich nicht.

[FunkOdyssey]

Ich kapiere "dimUpDownIncDecWithDuration" nicht.
Auch mit der CommandRef zur Hand schaffe ich keine gültige Syntax.

Hat jemand ein Beispiel für eine korrekte Syntax für "dimUpDownIncDecWithDuration"!

Danke.