Hallo,
ich habe in den letzten Tagen ein paar von diesen Dimmern installiert. Die Dimmer selbst funktionieren problemlos und wurden von FHEM auch sofort beim Pairing erkannt und angelegt.
Jetzt versuche ich den 2. Taster für Steuerungszwecke zu verwenden, bekomme aber die Kanäle für die Taster nicht richtig aktiviert. Ich habe gestern eine Weile mit mcaAdd etc. experimentiert, muss aber zugegeben, da nicht ganz Sattelfest zu sein.
In den Logs sehe ich folgende Meldungen:
2016-02-19_12:19:37 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 0426010001
2016-02-19_12:20:06 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 042601ff01
2016-02-19_12:20:06 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 042601ff01
2016-02-19_12:20:08 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 0426010001
2016-02-19_12:20:08 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 0426010001
2016-02-19_12:25:44 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 042601ff01
2016-02-19_12:25:44 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 042601ff01
2016-02-19_12:26:10 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 062604484d0401
2016-02-19_12:26:10 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 062604484d0401
2016-02-19_12:26:12 ZWave_Node_6.2 swmEnd
2016-02-19_12:26:12 ZWave_Node_6.2 reportedState: swmEnd
2016-02-19_12:26:12 ZWave_Node_6.2 swmEnd
2016-02-19_12:26:12 ZWave_Node_6.2 reportedState: swmEnd
2016-02-19_12:33:25 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 0426016301
Die Geräte für die zusätzlichen Kanäle wurden beim Pairing nicht mit angelegt. Bei einem erneuten Pairing-Versuch habe ich folgende Log-Einträge beobachtet und vermute, das Problem fängt mit dem mcCreateAll an:
2016-02-19_12:37:50 dim_Tresen modelId: 010f-0102-1000
2016-02-19_12:37:50 dim_Tresen model: FIBARO System FGD212 Dimmer 2
2016-02-19_12:37:50 dim_Tresen modelConfig: fibaro/fgd212.xml
2016-02-19_12:37:50 dim_Tresen power: 59.5 W
2016-02-19_12:37:50 dim_Tresen power: 59.5 W
2016-02-19_12:37:50 dim_Tresen power: 59.5 W
2016-02-19_12:37:50 dim_Tresen power: 59.5 W
2016-02-19_12:37:51 dim_Tresen mcCreateAll
2016-02-19_12:37:51 dim_Tresen UNPARSED: MULTI_CHANNEL 056008000200
Habe ich da etwas falsch konfiguriert oder wird der Dimmer nicht richtig erkannt ?
Viele Grüße
Andreas
Ach so, der Vollständigkeit halber noch die Listings vom Dimmer
ZitatInternals:
CFGFN ./zwave_devices.cfg
DEF ed048f71 6
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 27
NAME dim_Tresen
NR 84
STATE off
TYPE ZWave
ZWDongle_0_MSGCNT 27
ZWDongle_0_RAWMSG 0004000606310504220000
ZWDongle_0_TIME 2016-02-19 14:21:52
homeId ed048f71
isWakeUp
lastMsgSent 1455884489.26643
nodeIdHex 06
Readings:
2016-02-19 12:37:51 UNPARSED MULTI_CHANNEL 056008000200
2016-02-17 21:54:45 alarm PowerManagement: Over-current detected, arg 00
2016-02-19 12:35:39 assocGroup_1 Max 1 Nodes ZWDongle_0
2016-02-19 12:35:39 assocGroup_2 Max 5 Nodes
2016-02-19 12:35:39 assocGroup_3 Max 5 Nodes
2016-02-19 12:35:39 assocGroup_4 Max 5 Nodes
2016-02-19 12:35:39 assocGroup_5 Max 5 Nodes
2016-02-19 12:35:39 assocGroups 5
2016-02-18 23:09:29 basicSet ff
2016-02-19 12:35:42 configAutoCalibrationStatus DimmerOperatesOnAutoCalibration1
2016-02-18 22:01:59 configDimmabilityOfTheLoad LoadRecognizedAsDimmable
2016-02-18 19:37:54 configInputsButtonSwitchConfiguration MonoStableInputButton
2016-02-19 12:35:42 configLoadControlMode trailingEdge
2016-02-19 12:35:42 configMaximumBrightnessLevel 76
2016-02-19 12:35:42 configMethodOfCalculatingTheActive58 powerMeasurementBasedOnThe0
2016-02-19 12:35:42 configMinimumBrightnessLevel 4
2016-02-18 23:14:07 configOnOffMode modeSelectedAutomatically
2016-02-18 23:14:07 config_30 2
2016-02-19 13:42:54 energy 0.56 kWh
2016-02-18 19:45:31 mcaSupportedGroupings 5
2016-02-19 12:37:50 model FIBARO System FGD212 Dimmer 2
2016-02-19 12:37:50 modelConfig fibaro/fgd212.xml
2016-02-19 12:37:50 modelId 010f-0102-1000
2016-02-19 14:21:52 power 0.0 W
2016-02-19 13:21:31 reportedState off
2016-02-19 13:21:31 state off
2016-02-19 13:21:31 transmit OK
Attributes:
IODev ZWDongle_0
alias Tresen
classes ZWAVEPLUS_INFO BASIC VERSION MANUFACTURER_SPECIFIC SWITCH_MULTILEVEL DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL SECURITY FIRMWARE_UPDATE_MD CRC_16_ENCAP CONFIGURATION SENSOR_MULTILEVEL METER MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL PROTECTION ALARM SWITCH_ALL APPLICATION_STATUS MARK SCENE_ACTIVATION
group Licht
room Wohnbereich,ZWave
userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
Und dem 2. Kanal direkt nach dem erneuten Pairing:
Internals:
CFGFN
DEF ed048f71 1538
IODev ZWDongle_0
NAME ZWave_Node_6.2
NR 293
STATE ???
TYPE ZWave
homeId ed048f71
nodeIdHex 0602
Attributes:
IODev ZWDongle_0
room ZWave
Ich kann zu dem eigentlichen Problem leider nicht viel sagen, ich habe aber zwei von den UNPARSED Meldungen (0426010001 und 042601ff01) als setOff und setOn "implementiert".
Moin,
müssen dafür "classes" in dem Gerät gesetzt sein ? Meine Vermutung ist, dass der
2016-02-19_12:37:51 dim_Tresen mcCreateAll
2016-02-19_12:37:51 dim_Tresen UNPARSED: MULTI_CHANNEL 056008000200
nicht funktioniert hat, deswegen die Klassen bei ZWave_Node_6.2 nicht richtig gesetzt werden und als Folge dann die einzelnen Ereignisse des Gerätes nicht geparsed werden können ?
Ich weiss jetzt nur nicht, ob ich das "classes" Attribut einfach nachträglich setzen kann, und wenn worauf.
Oder ob ich völlig auf dem Holzweg bin.
Gruss
Andreas
Das Attribut classes kannst Du nachträglich setzen http://www.fhemwiki.de/wiki/Z-Wave#Hinzuf.C3.BCgen_eines_neuen_Z-Wave_Ger.C3.A4ts_.2F_Inklusion.
Nehme mal SWITCH_MULTILEVEL bei ZWave_Node_6.2 in das Attribut.
Du kannst im Prinzip alles dort aufnehmen.
Musst Dir nur die aktuelle 10_ZWave.pm von heute aus dem svn ziehen und installieren (bitte die Zeile wie hier http://forum.fhem.de/index.php/topic,36102.msg413051.html#msg413051 auskommentieren bis Rudi das geändert hat.)
UNPARSED: MULTI_CHANNEL 056008000200
Die automatische Anlage hat nicht funktionert, da die Nachricht FHEM unbekannt war. Die Nachricht ist V4 der class MULTI_CHANNEL laut pepper1. Infos zu der Version habe ich gestern nicht gefunden. classes enthält die Nachricht nach meinem Verständnis nicht.
Gruß, Christian
Fuer das Parsen der Nachrichten ist das classes Attribut irrelevant, es wird nur fuer die Erstellung der get/set Listen benoetigt.
Danke für das Feedback. Den Hinweis von Christian probiere ich heute Abend mal aus und melde mich dann wieder.
Hi,
die grundsätzliche Frage sollte doch eher lauten WARUM die Node die Klasse nicht meldet. Ist das ein bekanntes Fehlverhalten von dem Ding? Ich meine mich zu erinnern das hier vor kurzem auch schon ein Gerät war das eine Klasse nicht richtig gemeldet hat. Irgendwie ist mir nicht klar wie diese Geräte Ihre Zertifizierung erhalten wenn nicht mal das funktioniert...
Gruß,
Andreas.
So, ich habe jetzt die 10_ZWave.pm aus dem SVN geholt und kurz getestet. Die kurzen Tastendrucke werden jetzt wie von Rudi angekündigt als setOff und setOn gemeldet:
2016-02-21_01:23:33 ZWave_Node_6.2 basicSet: 00
2016-02-21_01:23:33 ZWave_Node_6.2 basicSet: 00
2016-02-21_01:23:33 ZWave_Node_6.2 basicSet: 00
2016-02-21_01:23:33 ZWave_Node_6.2 basicSet: 00
2016-02-21_01:23:33 ZWave_Node_6.2 setOff
2016-02-21_01:23:33 ZWave_Node_6.2 reportedState: setOff
2016-02-21_01:23:33 ZWave_Node_6.2 setOff
2016-02-21_01:23:33 ZWave_Node_6.2 reportedState: setOff
2016-02-21_01:23:36 ZWave_Node_6.2 basicSet: ff
2016-02-21_01:23:36 ZWave_Node_6.2 basicSet: ff
2016-02-21_01:23:36 ZWave_Node_6.2 basicSet: ff
2016-02-21_01:23:36 ZWave_Node_6.2 basicSet: ff
2016-02-21_01:23:37 ZWave_Node_6.2 setOn
2016-02-21_01:23:37 ZWave_Node_6.2 reportedState: setOn
2016-02-21_01:23:37 ZWave_Node_6.2 setOn
2016-02-21_01:23:37 ZWave_Node_6.2 reportedState: setOn
Ein langer Tastendruck sieht jetzt wie folgt aus. Kurz nach dem Beginn kommt das "UNPARSED":
2016-02-21_01:29:28 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 06260448430301
2016-02-21_01:29:28 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 06260448430301
Nach dem Loslassen dann die folgenden Events:
2016-02-21_01:29:29 ZWave_Node_6.2 basicSet: 2b
2016-02-21_01:29:29 ZWave_Node_6.2 basicSet: 2b
2016-02-21_01:29:29 ZWave_Node_6.2 basicSet: 2b
2016-02-21_01:29:29 ZWave_Node_6.2 basicSet: 2b
2016-02-21_01:29:29 ZWave_Node_6.2 swmEnd
2016-02-21_01:29:29 ZWave_Node_6.2 reportedState: swmEnd
2016-02-21_01:29:29 ZWave_Node_6.2 swmEnd
2016-02-21_01:29:29 ZWave_Node_6.2 reportedState: swmEnd
Aktuell habe ich sowohl die Association Group 4, als auch die 5 per mcaAdd assoziiert, so dass auch die "basicSet" gemeldet werden.
Das dritte Byte von hinten scheint den dimWert beim Start anzugeben. Das nächste "UNPARSED" sieht z.B. so aus:
2016-02-21_01:29:35 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 062604002b0301
2016-02-21_01:29:35 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 062604002b0301
Das "2b" war genau der Endwert des vorherigen Dim-Vorganges.
Gruss
Andreas
Hi,
die UNPARSED Nachrichten sind Befehle der Klasse SWITCH_MULTILEVEL aus Version V3 und nicht implementiert, aber das sind eigentlich SET-Befehle, d.h. dieser Befehl wird an Geräte verschickt die man steuern möchte.
Ich vermute das der Dimmer eine AssociationGroup hat mit der er "parallel" zu sich selbst z.B. einen zweiten Dimmer steuern kann. In diese AssociationGroup hast Du anscheinend den Controller eingetragen und versuchst jetzt dadurch FHEM zu dimmen ,-)
Wie Rudi schon mal schrieb, FHEM lässt sich nicht dimmen.
Am besten noch mal die Associationgroups (und deren Bedeutung) anschauen und dann den Controller aus dieser "Control"-Group rausnehmen. Der Controller muss nicht zwingend in jede AssociationGroup, auch bei eventuell mehreren Reporting-Groups muss der nicht zwingend in jede davon. Das basicSet taucht jedesmal 4 mal auf, der reportedState jeweils 2 mal, das ist sicherlich so nicht nötig.
Mir ist aber auch nicht so ganz klar ob Du jetzt noch Probleme hast oder ob schon alles soweit funktioniert wie Du es erwartest/benötigst.
Gruß,
Andreas.
Moin,
Zitatdie UNPARSED Nachrichten sind Befehle der Klasse SWITCH_MULTILEVEL aus Version V3 und nicht implementiert, aber das sind eigentlich SET-Befehle, d.h. dieser Befehl wird an Geräte verschickt die man steuern möchte.
Ja, genauso hatte ich es eigentlich auch verstanden.
ZitatIch vermute das der Dimmer eine AssociationGroup hat mit der er "parallel" zu sich selbst z.B. einen zweiten Dimmer steuern kann. In diese AssociationGroup hast Du anscheinend den Controller eingetragen und versuchst jetzt dadurch FHEM zu dimmen ,-)
Nicht ganz, aber indirekt schon. Am Besten ich erkläre mal kurz mein Nutzungsszenario. Der Dimmer hat zwei Eingänge, an die ich je einen Taster angeschlossen habe. Zum Steuern des Dimmers reicht je nach Konfiguration ein Taster aus. Der Zweite kann über die AssociationGroups ein anderes ZWave-Gerät steuern. Das möchte ich gerade nutzbar machen, um dadurch völlig andere Aktionen auszulösen. Zwei konkrete Beispiele dazu sind, durch Lightscenes zu toggeln oder eine Hue im Fenster mit dem Schalter an der Tür zu dimmen. Im Prinzip ist der zweite Taster eine Mini-Remote.
Also zwar nicht FHEM direkt dimmen, aber indirekt mit Hilfe von FHEM andere Gerätegruppen dimmen/steuern.
Dafür versuche ich zu verstehen, was da über den zweiten Kanal gesendet wird.
ZitatAm besten noch mal die Associationgroups (und deren Bedeutung) anschauen und dann den Controller aus dieser "Control"-Group rausnehmen. Der Controller muss nicht zwingend in jede AssociationGroup, auch bei eventuell mehreren Reporting-Groups muss der nicht zwingend in jede davon. Das basicSet taucht jedesmal 4 mal auf, der reportedState jeweils 2 mal, das ist sicherlich so nicht nötig.
Das stimmt. Ich habe den Controller auch im Moment nur in beide Gruppen eingetragen um zu sehen was dort jeweils ankommt. Tatsächlich werden unabhängig davon einige Sachen doppelt gemeldet, aber das ist eine andere Baustelle. Die muss ich nochmal separat analysieren.
ZitatMir ist aber auch nicht so ganz klar ob Du jetzt noch Probleme hast oder ob schon alles soweit funktioniert wie Du es erwartest/benötigst.
Durch Lightscenes zu toggeln sollte jetzt eigentlich kein Problem mehr sein. Für das Dimmen der Hue's wären die "UNPARSED" Events hilfreich. Gibt es dazu irgendwo Doku ? Und ist es aufwändig die SET-Befehle zu implementieren ?
Gruss
Andreas
Hi,
ok, jetzt verstehe ich was Du eigentlich vorhast.
Diese SET-Befehle zu implementieren dürfte nicht sehr aufwändig sein, ist aber nicht ganz so trivial...
Soetwas ist momentan im Konzept von ZWave-FHEM (meines Wissens nach) (noch) nicht vorgesehen.
Ich könnte mir vorstellen diese Nachrichten zu parsen wie in der Spezifikation vorgesehen und dann ein Reading in dem Device von dem die Nachricht KOMMT mit den Daten aus der Nachricht anzulegen. Dabei kann man dann auch ein Event auslösen auf das Du dann zB. mit einem Notify reagieren kannst. Bei der ganzen Namensgebung müsste man sich aber ein System ausdenken damit hier keine Verwechslung mit den von FHEM gesendeten Befehlen auftreten.
Hierzu müsste sich aber Rudi mal äußern ob/wie er das implementieren würde.
Gruß,
Andreas. (Scheint in letzter Zeit hier 'ne Menge Andreas'se zu geben...)
Hi,
habe mir das gerade noch mal etwas näher angesehen:
2016-02-21_01:29:28 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 06260448430301
2016-02-21_01:29:28 ZWave_Node_6.2 UNPARSED: SWITCH_MULTILEVEL 06260448430301
also das ist händisch übersetzt:
06 Länge
26 SWITCH_MULTILEVEL (Command Class)
04 SWITCH_MULTILEVEL_START_LEVEL_CHANGE (Command)
48 43 03 01 PAYLOAD
Die Payload bedeutet:
48: DOWN | DECREMENT
43: STARTLEVEL = 0x43 = 67 ~2/3
03: DIMMING DURATION = 3 (sekunden?) -> Dauer um von 0 auf 100% zu dimmen
01: STEPSIZE = 1 -> Schrittweite die angesteuert werden soll
Ich sehe hier ein paar "Probleme" auf Dich (und uns) zukommen...
Die Nachricht enthält ja zum einen die "Richtung" des Dimmens, aber auch den Startlevel, also die aktuelle Helligkeit. Ich vermute bzw. befürchte das der Dimmer nun keine Nachricht mehr schickt wenn man bei 100% noch "weiter nach oben" dimmen will.
Könntest Du mal schauen ob Du da beliebig oft / lange nach "oben" dimmen kannst oder ob da wie von mir befürchtet irgendwann keine Nachrichten mehr erzeugt werden?
Gruß,
Andreas.
Moin,
jetzt kommt langsam Klarheit in die Sache.
Die Meldung kommt genau einmal (abgesehen von der Dublette), und zwar beim Beginn des Tastendruckes, sobald der Taster erkannt hat, dass es ein längerer Tastendruck ist. Die müsste man eigentlich relativ leicht in ein Kommando für die Hue umsetzen können, damit sie auch mit dem Dimmen beginnt
Erst beim Loslassen kommt wieder eine Meldung (allerdings auch wieder als Dublette):
2016-02-21_01:29:29 ZWave_Node_6.2 swmEnd
2016-02-21_01:29:29 ZWave_Node_6.2 reportedState: swmEnd
Mit der müsste man dann den Dimmvorgang bei der Hue wieder stoppen. Falls die Hue vorher 100% bzw. 0% erreicht, würde sie halt einfach aufhören zu dimmen.
Der zweite Taster, der den wir beobachten, steuert in dem eigentlichen Dimmer überhaupt nichts. Die Dimmwerte führt er für sich selbst nur intern mit. Quasi wie ein zweiter virtueller Dimmer in dem Gerät.
Kannst Du auch mal nachsehen, was dies hier für ein Kommando ist ?
2016-02-21_16:45:55 pb_Kueche_2 UNPARSED: SWITCH_MULTILEVEL 0426016301
Das bekomme ich bei einem Doppelklick gesendet (leider auch wieder doppelt).
Gruss
Andreas
ZitatHierzu müsste sich aber Rudi mal äußern ob/wie er das implementieren würde.
Ich verstehe das Problem nicht. Du hast ja die Nachricht schon entschluesselt (und mich daran erinnert, wo ich die Doku finde), ich habs jetzt impementiert:
fhem> { ZWave_swmParse("48", "43", "03", "01") }
state:swm Decrement Down Start: 67 Duration: 3 Step: 1
Hi,
Zitat von: ak42 am 21 Februar 2016, 18:39:38
jetzt kommt langsam Klarheit in die Sache.
wenn Du das sagst...
Zitat von: ak42 am 21 Februar 2016, 18:39:38
Die Meldung kommt genau einmal (abgesehen von der Dublette), und zwar beim Beginn des Tastendruckes, sobald der Taster erkannt hat, dass es ein längerer Tastendruck ist. Die müsste man eigentlich relativ leicht in ein Kommando für die Hue umsetzen können, damit sie auch mit dem Dimmen beginnt
Meine Frage war jetzt aber ob diese Nachricht auch kommt wenn der Dimmer bereits auf 100% steht und Du weiter nach oben dimmen willst. Ich kann mir vorstellen das in so einem Fall keine Nachricht verschickt wird da ja bereits das maximum erreicht wurde.
Zitat von: ak42 am 21 Februar 2016, 18:39:38
Erst beim Loslassen kommt wieder eine Meldung (allerdings auch wieder als Dublette):
2016-02-21_01:29:29 ZWave_Node_6.2 swmEnd
2016-02-21_01:29:29 ZWave_Node_6.2 reportedState: swmEnd
Mit der müsste man dann den Dimmvorgang bei der Hue wieder stoppen. Falls die Hue vorher 100% bzw. 0% erreicht, würde sie halt einfach aufhören zu dimmen.
Das "swmEnd" ist das Gegenstück zu dem SWITCH_MULTILEVEL_START_LEVEL_CHANGE, nämlich SWITCH_MULTILEVEL_STOP_LEVEL_CHANGE :-)
Zitat von: ak42 am 21 Februar 2016, 18:39:38
Der zweite Taster, der den wir beobachten, steuert in dem eigentlichen Dimmer überhaupt nichts. Die Dimmwerte führt er für sich selbst nur intern mit. Quasi wie ein zweiter virtueller Dimmer in dem Gerät.
Soweit klar.
Zitat von: ak42 am 21 Februar 2016, 18:39:38
Kannst Du auch mal nachsehen, was dies hier für ein Kommando ist ?
2016-02-21_16:45:55 pb_Kueche_2 UNPARSED: SWITCH_MULTILEVEL 0426016301
Das bekomme ich bei einem Doppelklick gesendet (leider auch wieder doppelt).
04 Länge
26 SWITCH_MULTILEVEL (Command Class)
01 SWITCH_MULTILEVEL_SET (Command)
63 01 PAYLOAD
63: VALUE 0x63 = 99 -> soll laut Spezifikation als 100% interpretiert werden
01: Dimming Duration 1 sekunde
Anscheinend wird hier explizit auch noch mal ein SET auf den identischen Wert gemacht falls bei den Dimmgeschwindigkeiten Unterschiede bestehen und / oder die Tastendrücke unterschiedlich lang interpretiert werden. Gar nicht mal so dumm...
Also wenn das Ding auch noch die Nachrichten schickt wenn es bei 100% angekommen ist (die letzte Nachricht interpretiere ich mal so...) dann sollte es möglich sein darauf zu reagieren und z.B. die Richtung des Dimmens zu nutzen um zwischen verschiedenen Lightscenes zu schalten.
Hmm, während ich das hier geschrieben habe, hat Rudi das anscheinend mal eben implementiert... ,-)
Gruß,
Andreas.
Hi Rudi,
Zitat von: rudolfkoenig am 21 Februar 2016, 18:53:24
Ich verstehe das Problem nicht. Du hast ja die Nachricht schon entschluesselt (und mich daran erinnert, wo ich die Doku finde), ich habs jetzt impementiert:
fhem> { ZWave_swmParse("48", "43", "03", "01") }
state:swm Decrement Down Start: 67 Duration: 3 Step: 1
mein "Problem" war/ist das ich dies in einem ersten Ansatz als eigenes Reading implementiert hätte und nicht als "state". Und da hätte man evtl. über eine geeignete (ZWave-weite) Namensgebung nachdenken können.
Die Idee das einfach als state auszugeben war mir nicht gekommen, so ist natürlich wieder schön kurz ,-)
Manchmal denke ich zu kompliziert, ok, das mit dem manchmal nehme ich zurück.
Gruß,
Andreas.
ZitatKönntest Du mal schauen ob Du da beliebig oft / lange nach "oben" dimmen kannst oder ob da wie von mir befürchtet irgendwann keine Nachrichten mehr erzeugt werden?
Ich habe es gerade mal probiert. Es wird bei jedem längeren Tastendruck die Richtung gewechselt. D.h. nach UP kommt DOWN, dann wieder UP, usw. D.h. wenn er beim letzten UP auf 100% gegangen ist, geht es wieder runter und der Startwert ist 0x63.
Deine Analyse zu dem Doppelklick passt auch. In der Doku zum Dimmer selbst steht, dass er bei einem Doppelklick auf 100% geht. Bei einem Einfachklick, standardmässig auf den ursprünglichen Wert.
Gruss
Andreas
Hi,
Zitat von: ak42 am 21 Februar 2016, 21:23:58
Ich habe es gerade mal probiert. Es wird bei jedem längeren Tastendruck die Richtung gewechselt. D.h. nach UP kommt DOWN, dann wieder UP, usw. D.h. wenn er beim letzten UP auf 100% gegangen ist, geht es wieder runter und der Startwert ist 0x63.
hmm, damit ist das als Steuerung nur bedingt zu gebrauchen... Soetwas hatte ich befürchtet.
Aber ich glaube ich begreife erst jetzt das dies ein einzelner Taster ist und keine "Wippe" mit hoch / runter, richtig?
Dann bleibt Dir für das Auswählen der lightscene nur das Du jeden Befehl, egal ob UP oder DOWN nutzt um in der Auswahl der Lightscene einen weiter zu gehen.
Zitat von: ak42 am 21 Februar 2016, 21:23:58
Deine Analyse zu dem Doppelklick passt auch. In der Doku zum Dimmer selbst steht, dass er bei einem Doppelklick auf 100% geht. Bei einem Einfachklick, standardmässig auf den ursprünglichen Wert.
Geht er denn bei nochmaligen Doppelklick auf 0%?
Gruß,
Andreas.
Moin,
ich hatte die Änderungen von Rudi noch gleich am Sonntag getestet. War nur ein bisschen spät um noch eine halbwegs qualifizierte Antwort hinzubekommen ;-)
Es sieht schon ziemlich gut aus. Bei einem Einfachklick bekomme ich:
2016-02-24_19:58:16 pb_Kueche_2 setOff
2016-02-24_19:58:16 pb_Kueche_2 reportedState: setOff
2016-02-24_19:58:16 pb_Kueche_2 setOff
2016-02-24_19:58:16 pb_Kueche_2 reportedState: setOff
bzw.
2016-02-24_19:58:40 pb_Kueche_2 setOn
2016-02-24_19:58:40 pb_Kueche_2 reportedState: setOn
2016-02-24_19:58:40 pb_Kueche_2 setOn
2016-02-24_19:58:40 pb_Kueche_2 reportedState: setOn
Dimmen sieht wie folgt aus:
2016-02-24_19:55:38 pb_Kueche_2 swm Decrement Down Start: 99 Duration: 5 Step: 1
2016-02-24_19:55:38 pb_Kueche_2 reportedState: swm Decrement Down Start: 99 Duration: 5 Step: 1
2016-02-24_19:55:38 pb_Kueche_2 swm Decrement Down Start: 99 Duration: 5 Step: 1
2016-02-24_19:55:38 pb_Kueche_2 reportedState: swm Decrement Down Start: 99 Duration: 5 Step: 1
2016-02-24_19:55:39 pb_Kueche_2 swmEnd
2016-02-24_19:55:39 pb_Kueche_2 reportedState: swmEnd
2016-02-24_19:55:39 pb_Kueche_2 swmEnd
2016-02-24_19:55:39 pb_Kueche_2 reportedState: swmEnd
Das Spannende daran ist, nachdem ich die Info im Klartext gesehen habe, ist mir aufgefallen, dass die Duration sich verändert. Sie ist abhängig davon, wieweit der Startwert vom Endwert (0 bzw. 100, je nach Richtung) entfernt ist. D.h. man kann sie sehr schön als Ramptime für ein dimUp oder dimDown zur Hue verwenden. Ist es aufwändig die Werte für Start, Duration und Step gleich als Readings abzulegen ?
Bekommt Ihr den Doppelklick, bzw. SWITCH_MULTILEVEL_SET auch noch implementiert ? Das war der hier:
2016-02-24_19:55:50 pb_Kueche_2 UNPARSED: SWITCH_MULTILEVEL 0426016301
2016-02-24_19:55:50 pb_Kueche_2 UNPARSED: SWITCH_MULTILEVEL 0426016301
Und wo schaut Ihr eigentlich nach was die Codes bedeuten ?
Viele Grüße
Andreas
ZitatUnd wo schaut Ihr eigentlich nach was die Codes bedeuten ?
Internetrecherche, Analyse, OpenSource-Projekte...
Einstiegspunkte http://www.fhemwiki.de/wiki/Z-Wave#Links unter "Hilfen zur Einbindung von Command Classes in Fhem"
Da war ich doch schon. Hatte ich wohl Tomaten auf den Augen.
Danke, Andreas
ZitatIst es aufwändig die Werte für Start, Duration und Step gleich als Readings abzulegen ?
Nein, bedeutet aber Overhead bei FileLog/Notify/etc, und ich habe z.Zt. noch keinen Grund, sie zu trennen.
ZitatBekommt Ihr den Doppelklick, bzw. SWITCH_MULTILEVEL_SET auch noch implementiert ?
Das Thema set SWITCH_MULTILEVEL V2 geht es hier weiter: http://forum.fhem.de/index.php/topic,49703.0.html
ZitatZitat
Ist es aufwändig die Werte für Start, Duration und Step gleich als Readings abzulegen ?
Nein, bedeutet aber Overhead bei FileLog/Notify/etc, und ich habe z.Zt. noch keinen Grund, sie zu trennen.
Mein Ansatz war (etwas ins Unreine gesprochen) so ein Konstrukt:
define di_pb DOIF ([pb_Fibaro:"swmDecrement Down"])(set hue_device pct 0 [pb_Fibaro:Duration])
DOELSEIF ([pb_Fibaro:"swmDecrement Up"])(set hue_device pct 100 [pb_Fibaro:Duration])
DOELSEIF ([pb_Fibaro:"swmEnd"])(set hue_device pct [pb_Fibaro:Level])
Wenn es von den Reaktionszeiten hinhaut, könnte man tatsächlich eine Hue mit einem Fibaro Dimmer steuern. Und es wäre sogar noch halbwegs lesbar.
ZitatDas Thema set SWITCH_MULTILEVEL V2 geht es hier weiter: http://forum.fhem.de/index.php/topic,49703.0.html
Dann lese ich da mal weiter.
Aber ich muss nochmal ein Kompliment loswerden. Ich benutze FHEM jetzt seit ca. einem Jahr, weil mir Homematic überhaupt nicht gefallen hat. Und muss dazu sagen, dass ich eher der (Gelegenheits-)Anwender als der Entwickler bin. Trotz des eigentlich komplexen Themas habe ich mit FHEM immer schnell eine recht simple Lösung für die anstehenden Aufgaben gefunden. Habe jetzt das erste Mal die Hilfe von Euch / des Forums in Anspruch genommen und bin über die Reaktionen schwer begeistert. Macht weiter so !
Danke, Andreas