Neues Modul HMCCU für Homematic CCU

[Achiim]

Problem scheint gelöst zu sein. Ich habe es virtuell definiert. Dann hat es sich anlegen lassen mit ... define d_Rauchmelderteam virtual 1 group=AZ-Rauchmelder,SZ-Rauchmelder ... ging es und zeigt mir folgende Werte an:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        virtual 1 group=AZ-Rauchmelder,SZ-Rauchmelder
   IODev      myCCU
   NAME       d_Rauchmelderteam
   NR         4295
   STATE      false
   TYPE       HMCCUDEV
   ccuaddr    VIR0000001
   ccudevstate Active
   ccugroup   MEQ0257246,NEQ0197808
   ccuif      VirtualDevices
   ccuname    none
   ccutype
   channels   0
   statevals  readonly
   Readings:
     2016-04-11 15:08:24   AZ-Rauchmelder.0.CONFIG_PENDING false
     2016-04-11 15:08:24   AZ-Rauchmelder.0.DEVICE_IN_BOOTLOADER false
     2016-04-11 15:08:24   AZ-Rauchmelder.0.DUTYCYCLE false
     2016-04-11 15:08:24   AZ-Rauchmelder.0.LOWBAT false
     2016-04-11 15:08:24   AZ-Rauchmelder.0.RSSI_DEVICE 1
     2016-04-11 15:08:24   AZ-Rauchmelder.0.RSSI_PEER 37
     2016-04-11 15:08:24   AZ-Rauchmelder.0.STICKY_UNREACH false
     2016-04-11 15:08:24   AZ-Rauchmelder.0.UNREACH false
     2016-04-11 15:08:24   AZ-Rauchmelder.0.UPDATE_PENDING false
     2016-04-11 15:08:24   AZ-Rauchmelder.1.INSTALL_TEST N/A
     2016-04-11 15:08:24   AZ-Rauchmelder.1.STATE false
     2016-04-11 15:08:25   SZ-Rauchmelder.0.CONFIG_PENDING false
     2016-04-11 15:08:25   SZ-Rauchmelder.0.DEVICE_IN_BOOTLOADER false
     2016-04-11 15:08:25   SZ-Rauchmelder.0.DUTYCYCLE false
     2016-04-11 15:08:25   SZ-Rauchmelder.0.LOWBAT false
     2016-04-11 15:08:25   SZ-Rauchmelder.0.RSSI_DEVICE 1
     2016-04-11 15:08:25   SZ-Rauchmelder.0.RSSI_PEER 53
     2016-04-11 15:08:25   SZ-Rauchmelder.0.STICKY_UNREACH false
     2016-04-11 15:08:25   SZ-Rauchmelder.0.UNREACH false
     2016-04-11 15:08:25   SZ-Rauchmelder.0.UPDATE_PENDING false
     2016-04-11 15:08:25   SZ-Rauchmelder.1.INSTALL_TEST N/A
     2016-04-11 15:08:25   SZ-Rauchmelder.1.STATE false
     2016-04-11 15:08:25   state           false
Attributes:
   IODev      myCCU
   ccureadings 1
   statechannel 1


Update:
Ist das so gedacht mit "virtuell"? Ich vermisse den unter FHEM möglichen Team_Call für Rauchmelder, die in einem Team sind. Gibt es den irgendwie auch über die XML-Schnittstelle?

[Achiim]

Neues Problem: get myCCU update löst auch mein notify aus, da der update so tut als ob gerade von allen Geräten Events kommen. Das kann im Eventmonitor mitverfolgt werden.... War das im Sinne des Erfinders? Besser wäre, wenn "update" nur die Readings setzt und gut ist.... Oder habe ich etwas nicht bedacht?

Hinweis: Das Attribut updatemode habe ich bei meiner HMCCU nicht gesetzt. Kann das Verhalten etwa darüber beeinflusst werden?

Die Wirkung bei mir war, dass die Rolläden plötzlich runtergefahren sind.... Da ich auf eines der beim update generierten Ereignisse ein notify gesetzt habe.  Ist zum Glück nix passiert, da die Katze und die Frau gerade Mittagsschlaf machen....   

Dann ist mir noch aufgefallen, dass das update einen Fehler wirft und  "1 client device" nicht aktualisieren konnte. Im FHEM Log ist keine Meldung in diesem Zusammenhang zu finden. Siehe Screen-Shot. Kann es sein, dass dass mein soeben definiertes "virutelles" Device ist, das nicht aktualisiert wird. Die Meldung ist zu spärlich, um genaueres sagen zu können. Hier wäre ein Hinweis wünschenswert, welches Device nicht ging.

[zap]

Zu der Gruppe: Mit einem virtuellen Gerät funktioniert das natürlich, da diese Gruppen reine HMCCU Gruppen sind. Von denen weiß die CCU nichts. Daher kommt auch die Fehlermeldung beim "get update", da diese virtuellen Geräte keine gültige Adresse haben, zumindest keine, die die CCU kennt (to be fixed)

Mich würde mal interessieren, ob Deine Rauchmeldergruppe in der CCU unter Einstellungen->Gruppen auftaucht und wenn ja, mit welchem Namen und Adresse. Ich vermute, bei den Rauchmeldergruppen kocht EQ3 wieder mal ein Extra-Süppchen.

Es wäre schöner, Du könntest die Gruppe wie in Deinem ersten Versuch definieren. Diese Gruppen werden nämlich in der nächsten Version von HMCCU ebenfalls per RPC-Server aktualisiert. Grundsätzlich funktioniert das auch mit den virtuellen Geräten, nur kennt die die CCU eben nicht.

Das mit dem Notify habe ich noch nicht verstanden: Bezieht sich das Notify auf das HMCCU-Device? Dann könnte ein updatemode = client helfen. Das sorgt dann auch dafür, dass im IO Device keine Readings gesetzt werden.

Bei den Events musst Du unterscheiden zwischen CCU-Events und FHEM-Events. Ein FHEM-Event (und damit auch ein zugeordnetes Notify) wird immer ausgelöst, wenn ein Reading gesetzt wird. Mit event-on-change-reading und event-on-update-reading kannst Du aber einstellen, ob das FHEM-Event nur kommen soll, wenn ein Readingwert aktualisiert wird oder nur, wenn er sich geändert hat.

[zap]

Ich habe gerade die Version 3.1b eingecheckt. Wer Version 3.1 nutzt, muss nur die Dateien 88_HMCCU.pm und ccurpcd.pl aktualisieren. Vor Version 3.1 müssen alle Dateien aktualisiert werden.

Diese Version behebt Timing-Probleme beim Start des RPC-Servers auf langsamen Systemen. Diese führten dazu, dass der RPC-Server im Status "starting" stecken blieb.

[Achiim]

Zu der Rauchmeldergruppe:

In der CCU ist die als Gerät definiert, nicht als Gruppe. Die Definition hatte ich bereits in Antwort #417 als Screenshot angehängt. Dort habe ich auch den Stern vor dem Namen her.

[Achiim]

zum set ... update und notify:

Mein notify geht auf zwei Kanäle meiner HM-Fernbedienung. Die Kanäle heißen in FHEM c_WZ_Rolladen_hoch und c_WZ_Rolladen_runter...

Hier der code des notify:

Code Auswählen Erweitern


c_WZ_Rolladen_hoch:.*|c_WZ_Rolladen_runter:.* {
Log (3,"HM_Fernbedienung-Notify: $NAME, $EVTPART0, $EVTPART1");
if ($EVTPART0 eq "WZ-Rolladen-hoch.3.PRESS_SHORT:")
{
fhem("set Wohnzimmer_Rolladen_Essen up");
fhem("set Wohnzimmer_Rolladen_Sofa up");
}
if ($EVTPART0 eq "WZ-Rolladen-hoch.3.PRESS_LONG:")
{
fhem("set Wohnzimmer_Rolladen_Essen stop");
fhem("set Wohnzimmer_Rolladen_Sofa stop");
}
if ($EVTPART0 eq "WZ-Rolladen-runter.4.PRESS_SHORT:")
{
fhem("set Wohnzimmer_Rolladen_Essen down");
fhem("set Wohnzimmer_Rolladen_Sofa down");
}
if ($EVTPART0 eq "WZ-Rolladen-runter.4.PRESS_LONG:")
{
fhem("set Wohnzimmer_Rolladen_Essen stop");
fhem("set Wohnzimmer_Rolladen_Sofa stop");
}
}


Hier die Definition der Kanäle c_WZ_Rolladen_hoch und c_WZ_Rolladen_runter

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        WZ-Rolladen-hoch:3
   IODev      myHomematicCCU
   NAME       c_WZ_Rolladen_hoch
   NR         4213
   STATE      Initialized
   TYPE       HMCCUCHN
   ccuaddr    MEQ0670565:3
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    WZ-Rolladen-hoch:3
   ccutype    HM-RC-Dis-H-x-EU
   channels   1
   statevals  devstate
   Readings:
     2016-04-11 20:09:19   WZ-Rolladen-hoch.3.INSTALL_TEST 1
     2016-04-11 20:09:19   WZ-Rolladen-hoch.3.PRESS_CONT 1
     2016-04-11 20:09:17   WZ-Rolladen-hoch.3.PRESS_LONG 1
     2016-04-11 20:09:20   WZ-Rolladen-hoch.3.PRESS_LONG_RELEASE 1
     2016-04-11 20:09:17   WZ-Rolladen-hoch.3.PRESS_SHORT 1
     2016-04-11 14:31:53   state           Initialized
Attributes:
   IODev      myCCU
   devStateIcon ok:10px-kreis-gruen alarm:10px-kreis-rot Initialized:10px-kreis-gelb
   event-on-change-reading .*
   group      Fernbedieung
   room       HMCCU


-------------------------------------------------------------------------------------------

Internals:
   CFGFN
   DEF        WZ-Rolladen-runter:4
   IODev      myHomematicCCU
   NAME       c_WZ_Rolladen_runter
   NR         4216
   STATE      Initialized
   TYPE       HMCCUCHN
   ccuaddr    MEQ0670565:4
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    WZ-Rolladen-runter:4
   ccutype    HM-RC-Dis-H-x-EU
   channels   1
   statevals  devstate
   Readings:
     2016-04-11 20:06:25   WZ-Rolladen-runter.4.INSTALL_TEST false
     2016-04-11 20:06:25   WZ-Rolladen-runter.4.PRESS_CONT false
     2016-04-11 20:06:25   WZ-Rolladen-runter.4.PRESS_LONG false
     2016-04-11 20:06:25   WZ-Rolladen-runter.4.PRESS_LONG_RELEASE false
     2016-04-11 20:06:25   WZ-Rolladen-runter.4.PRESS_SHORT false
     2016-04-11 14:32:40   state           Initialized
Attributes:
   IODev      myCCU
   devStateIcon ok:10px-kreis-gruen alarm:10px-kreis-rot Initialized:10px-kreis-gelb
   event-on-change-reading .*
   group      Fernbedieung
   room       HMCCU


Trotz setzen von event-on-change-reading auf .* bei den beiden Kanälen reagiert das notify. event-on-update-reading habe ich bei beiden nicht gesetzt. Oder habe ich das falsch verstanden.

[zap]

Rauchmelder: wieder ein EQ3 Spezialfall. Statt die Gruppen zu verwenden wie bei der Heizung bilden sie hier die Gruppen als Spezialdevice mit Steenchenadresse ab. Mal sehen, wie ich das einfange. Aktuell fällt das Sternchen durch die Syntaxprüfung, daher funktioniert das nicht. Ich werde wohl meine HM Rauchmelder aus der Elektroschrottkiste holen und nochmal anlernen müssen, um das nachzustellen.

event-on-change-reading ist ja eine Standard FHEM Funktion. Für mich sieht Deine Def gut aus. Wie verhält sich das Notify, wenn Du "get update" lokal für einen Rolladen aufrufst?

Für das Setzen der Readings verwende ich FHEM Standardfunktionen. Da lässt sich nichts dran drehen.

Mm, grundsätzlich greift das Notify bei jedem Reading. Erst die IFs filtern dann auf die entsprechenden Tasten. Ich halte IF und DOIF sowieso in FHEM für Teufelszeug. Wie ist es, wenn Du für jede Taste ein eigenes Notify spendierst und in die Bedingung die Taste mit reinpackst?

[Achiim]

Wie verhält sich das Notify, wenn Du "get update" lokal für einen Rolladen aufrufst?

Ääähhhh. Das ist ein Rademacher Rolladenaktor, der hat kein get update... Falls Du das get update auf dem Kanal der Fernbedienung meinst (c_WZ_Rolladen_runter), so kann ich das heute Abend nciht mehr machen, da die Frau unten auf der Coach fern sieht und ich Ärger kriege, wenn sich der Rolladen schon wieder bewegt.... 

Wie heißt es doch so schön in der Werbung... "Meine Frau hat gesagt er soll bitte nicht so dominant sein", daraufhin der Verkäufer "Dann nehmen sie den, der ist auch nicht sooo dominant". 

[zap]

Ja, ich kenne das. Der WAF ist bei meiner Smart Home Umgebung auch ein ganz großes Thema. Du könntest 3 Dinge probieren:

1. get update auf den FB-Kanal, z.B.  get c_WZ_Rolladen_hoch update

2. Ein notify für eine FB-Aktion definieren

3. DOIF verwenden (das aber als letzte Möglichkeit, das Forum ist voll von DOIF-Fragen)

Dann wäre noch die Frage, warum Du überhaupt ein get update machst. Der RPC-Server liefert doch die Änderungen automatisch. Allerdings führt HMCCU beim Starten des RPC-Servers einmalig ein get update aus, um alle Devices in FHEM mit der CCU zu synchronisieren. Da würden dann ggf. Deine Rolläden hoch/runter fahren => auch blöd.

Eine FB habe ich glaube ich auch noch rumliegen. Muss ich mal testen.

[Achiim]

Kann es sein, dass das Setzen von event-on-change-reading auf .* ein wenig dauert, bis es wirkt oder gar ein reboot von FHEM benötigt, um zu wirken? Jedenfalls habe ich heute überhaupt keine events mehr für den Rolladen bekommen, auch nicht wenn ich die Fernbedienung gedrückt habe....

Da habe ich mal überlegt, was ich hier eigentlich konfiguriert habe.... 

• die Definition der Kanäle c_WZ_Rolladen_hoch und c_WZ_Rolladen_runter hat jeweils ein event-on-change-reading .*
• event-on-change-reading auf .* gesetzt bedeutet doch, dass nur Wertänderungen von allen Readings dieses device oder chanel ein Event erzeugen sollen
• das Reading auf das ich triggere ist z.B. WZ-Rolladen-hoch.3.PRESS_SHORT und hat bei einem Tastendruck den Wert "1"

Der Wert des Readings WZ-Rolladen-hoch.3.PRESS_SHORT ändert sich aber nicht, wenn die Taste wieder losgelassen oder gar nochmal gedrückt wird, sondern verbleibt bei "1". Es ändert sich bei einem Tastendruck nur die Farbe des Readingwertes in FHEM auf rot und die Zeitangabe.

Bei einem langen Tastendruck ist es ähnlich. Hier geht WZ-Rolladen-hoch.3.PRESS_LONG auf "1" und bleibt auf "1". Dafür ändert sich aber der Wert von WZ-Rolladen-hoch.3.PRESS_LONG_RELEASE auf "1", wenn die Taste nach einem langen Tastendruck wieder losgelassen wird. Bei einem kurzen Tastendruck gibt es kein Signal über das Loslassen der Taste. Soweit das was ich beobachtet habe.

Nun eine mögliche Behandlung für die Fernbedienungsherausforderung:

• Statt der "1", die bei jedem Tastendruck im Reading landet, könnte es ein Zähler sein, der sich bei jedem Tastendruck um 1 erhöht
• Dann würde sich das Reading bei jedem Tastendruck auch ändern und das Setzten von event-on-change-reading auf .* würde wieder Sinn machen
• Wenn der rpcserver hochfährt und das update macht bzw. wenn man manuell ein update macht, sollt der Zähler nicht hochgezählt werden
• Dann würde update auch kein Event auslösen, wenn event-on-change-reading auf .* gesetzt ist

Ist meine Überlegung nachvollziehbar und eine mögliche Option zur Implementierung?

update:

Ich habe noch beobachtet, dass bei gesetztem event-on-change-reading auf .*, der Kanäle c_WZ_Rolladen_hoch und c_WZ_Rolladen_runter, folgendes Verhalten auftritt:

• set c_WZ_Rolladen_hoch update setzt mir alle readings auf "false"
• wenn ich die Fernbedieungstasten drücke, gehen die entsprechenden Readings auf "1"

Das ist auch ein für mich nicht nachvollziehbares Verhalten. Welche Bedeutung hat das? Ist das so gewünscht?

Anbei noch die Definition meines Kanals:

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        WZ-Rolladen-hoch:3
   IODev      myHomematicCCU
   NAME       c_WZ_Rolladen_hoch
   NR         4213
   STATE      Initialized
   TYPE       HMCCUCHN
   ccuaddr    MEQ0670565:3
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    WZ-Rolladen-hoch:3
   ccutype    HM-RC-Dis-H-x-EU
   channels   1
   statevals  devstate
   Readings:
     2016-04-12 17:25:31   WZ-Rolladen-hoch.3.INSTALL_TEST false
     2016-04-12 17:25:31   WZ-Rolladen-hoch.3.PRESS_CONT false
     2016-04-12 17:25:31   WZ-Rolladen-hoch.3.PRESS_LONG false
     2016-04-12 17:25:31   WZ-Rolladen-hoch.3.PRESS_LONG_RELEASE false
     2016-04-12 17:25:31   WZ-Rolladen-hoch.3.PRESS_SHORT false
     2016-04-11 14:31:53   state           Initialized
Attributes:
   IODev      myCCU
   devStateIcon ok:10px-kreis-gruen alarm:10px-kreis-rot Initialized:10px-kreis-gelb
   event-on-change-reading .*
   group      Fernbedienung
   room       HMCCU


[Achiim]

Wie kann das passieren?

HMCCUDEV: Arbeitszimmer_Deckenlicht Execution of CCU script or command failed

Ich habe meinen "slider" für meinen Dimmer im Arbeitszimmer mehrmahls hin- und hergeschoben. Beim 3.mal kam obige Meldung und es ging kein Befehl mehr an die CCU durch. Ich habe die Lampe dann direkt in der CCU aus- und eingeschaltet, dann konnte ich sie auch wieder über das HMCCUDEV steuern....

Komisch?

Anbei die Definition des Dimmers

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        AZ-Deckenlicht 1
   IODev      myHomematicCCU
   NAME       Arbeitszimmer_Deckenlicht
   NR         4710
   STATE      OK
   TYPE       HMCCUDEV
   ccuaddr    JEQ0207451
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    AZ-Deckenlicht
   ccutype    HM-LC-Dim1TPBU-FM
   channels   4
   statevals  devstate|on|off
   Readings:
     2016-04-12 19:54:02   AZ-Deckenlicht.0.CONFIG_PENDING false
     2016-04-12 19:54:02   AZ-Deckenlicht.0.DEVICE_IN_BOOTLOADER false
     2016-04-12 19:54:02   AZ-Deckenlicht.0.DUTYCYCLE false
     2016-04-12 19:54:02   AZ-Deckenlicht.0.RSSI_DEVICE 128
     2016-04-12 19:54:02   AZ-Deckenlicht.0.RSSI_PEER 182
     2016-04-12 19:54:02   AZ-Deckenlicht.0.STICKY_UNREACH false
     2016-04-12 19:54:02   AZ-Deckenlicht.0.UNREACH false
     2016-04-12 19:54:02   AZ-Deckenlicht.0.UPDATE_PENDING false
     2016-04-12 20:05:32   AZ-Deckenlicht.1.DIRECTION 0
     2016-04-12 20:05:32   AZ-Deckenlicht.1.ERROR_OVERHEAT 0
     2016-04-12 20:05:32   AZ-Deckenlicht.1.ERROR_OVERLOAD 0
     2016-04-12 20:05:32   AZ-Deckenlicht.1.ERROR_REDUCED 0
     2016-04-12 19:54:02   AZ-Deckenlicht.1.INHIBIT false
     2016-04-12 19:54:02   AZ-Deckenlicht.1.INSTALL_TEST N/A
     2016-04-12 20:05:31   AZ-Deckenlicht.1.LEVEL 1.000000
     2016-04-12 20:05:32   AZ-Deckenlicht.1.LEVEL_REAL 1.000000
     2016-04-12 19:54:02   AZ-Deckenlicht.1.OLD_LEVEL N/A
     2016-04-12 19:54:02   AZ-Deckenlicht.1.ON_TIME N/A
     2016-04-12 19:54:02   AZ-Deckenlicht.1.RAMP_STOP N/A
     2016-04-12 19:54:02   AZ-Deckenlicht.1.RAMP_TIME N/A
     2016-04-12 20:05:32   AZ-Deckenlicht.1.WORKING 0
     2016-04-12 20:05:31   control         1.000000
     2016-04-12 20:05:24   state           OK
Attributes:
   IODev      myHomematicCCU
   ccureadingfilter ^AZ-Deckenlicht!(.*)
   controldatapoint 1.LEVEL
   group      Arbeitszimmer_Licht
   icon       light_ceiling
   room       02_Oben,HMCCU
   statechannel 1
   statevals  on:1.000000,off:0.000000
   webCmd     control
   widgetOverride control:slider,0,0.050000,1,1


[zap]

Kann es sein, dass das Setzen von event-on-change-reading auf .* ein wenig dauert, bis es wirkt oder gar ein reboot von FHEM benötigt, um zu wirken? Jedenfalls habe ich heute überhaupt keine events mehr für den Rolladen bekommen, auch nicht wenn ich die Fernbedienung gedrückt habe....

Nein, event-on-change-reading greift sofort. Vermutlich bekommst Du Events beim Drücken der Taste, aber der Wert der Readings ändert sich nicht. Das kannst Du prüfen, indem Du statt ...-on-change... das Attribut event-on-update-reading setzt (nicht beide!). Dann sollte sich beim Drücken einer Taste der Zeitstempel des Readings ändern.

Ich habe zwar eine Fernbedienung, aber leider keine Zeit, das momentan zu testen.

Nun eine mögliche Behandlung für die Fernbedienungsherausforderung:
...
Ist meine Überlegung nachvollziehbar und eine mögliche Option zur Implementierung?

Wie gesagt, bevor ich das nicht selbst nachvollzogen habe, kann ich da nichts versprechen. Allerdings habe ich mit HMCCU von Anfang an einen generischen Ansatz verfolgt. Da passt eine Sonderbehandlung für einen Gerätetyp nicht so recht rein. Das wäre dann der Ansatz von CUL_HM.

Ich habe noch beobachtet, dass bei gesetztem event-on-change-reading auf .*, der Kanäle c_WZ_Rolladen_hoch und c_WZ_Rolladen_runter, folgendes Verhalten auftritt:

• set c_WZ_Rolladen_hoch update setzt mir alle readings auf "false"
• wenn ich die Fernbedieungstasten drücke, gehen die entsprechenden Readings auf "1"

Das ist auch ein für mich nicht nachvollziehbares Verhalten. Welche Bedeutung hat das? Ist das so gewünscht?

Ein get update liefert bei Datenpunkten vom Typ bool entweder true oder false zurück (liegt am verwendeten Homematic Script). Der RPC-Server liefert hingegen 1 oder 0. Daher das unterschiedliche Verhalten und deshalb auch solche Definitionen in meinen Beispielen für substitute:  (true|1):an,(false|0):aus. Theoretisch ginge auch 1:true,0:false. Damit werden die RPC-Werte durch Homematic Script Werte ersetzt.

Ich habe übrigens auch mal get update beim HMCCU IO Device getestet. Bei mir verhält sich event-on-change-reading korrekt, d.h. nur geänderte Werte werden upgedated.

[zap]

Wie kann das passieren?

HMCCUDEV: Arbeitszimmer_Deckenlicht Execution of CCU script or command failed

Ich habe meinen "slider" für meinen Dimmer im Arbeitszimmer mehrmahls hin- und hergeschoben. Beim 3.mal kam obige Meldung und es ging kein Befehl mehr an die CCU durch. Ich habe die Lampe dann direkt in der CCU aus- und eingeschaltet, dann konnte ich sie auch wieder über das HMCCUDEV steuern....

Komisch?

Bei vielen schnellen Sets kommen sich vermutlich die Sets mit den RPC-Server Updateevents ins Gehege. Du könntest im HMCCU Device das Attribut rpcinterval auf 3 setzen (Default ist 5 Sekunden). Ob das hilft weiß ich nicht.

[Achiim]

Anwendungsfall "Fernbedienungstastendruck durch notify auswerten"

Ich habe jetzt eine Lösung dank deiner Hinweise implementiert. Ausgenutzt habe ich dabei folgende Sachverhalte:

• rpcserver liefert unterschiedliche Werte bei update und bei einem echten Event aus der CCU ("1" bei echtem Tastendruck; "false" bei get c_WZ_Rolladen_... update)
• rpcserver aktualisiert die Readings sowohl bei echten Events als auch bei "get ... update" oder beim "Start des rpcserver"

Es werden auf der Fernbedienung zwei Kanäle verwendet und damit zwei Tasten (eine für hoch und eine für runter) mit kurzem oder langem Tastendruck (der lange Tastendruck wird bei beiden Tasten als "stop" der Rolladenfahrt genutzt:

• c_WZ_Rolladen_hoch:WZ-Rolladen-hoch.3.PRESS_SHORT ==> Rolladen hoch
• c_WZ_Rolladen_hoch:WZ-Rolladen-hoch.3.PRESS_LONG ==> Rolladen stop
• c_WZ_Rolladen_runter:WZ-Rolladen-runter.4.PRESS_SHORT ==> Rolladen runter
• c_WZ_Rolladen_runter:WZ-Rolladen-runter.4.PRESS_LONG ==> Rolladen stop

Ich habe das notify, nun auf genau diese 4 Events ausgelegt und mit der Prüfung von Parameter $EVTPART1 eq "1" festgestellt, dass eine Taste auf der Fernbedieung das Event ausgelöst hat und nicht ein update oder ein Start des rpcserver.

Code Auswählen Erweitern


c_WZ_Rolladen_hoch:WZ-Rolladen-hoch.3.PRESS_SHORT:.*|c_WZ_Rolladen_hoch:WZ-Rolladen-hoch.3.PRESS_LONG:.*|c_WZ_Rolladen_runter:WZ-Rolladen-runter.4.PRESS_SHORT:.*|c_WZ_Rolladen_runter:WZ-Rolladen-runter.4.PRESS_LONG:.* {
Log (3,"HM_Fernbedienung-Notify: $NAME, $EVTPART0, $EVTPART1");

# #################################################
# ### nur wenn eine Taste gedrückt wird
# ### dann ist $EVTPART1 = "1" bei update "false"
# #################################################
if ($EVTPART1 eq "1"){

if ($EVTPART0 eq "WZ-Rolladen-hoch.3.PRESS_SHORT:")
{
Log (3,"HM_Fernbedienung-Notify: Rolladen hochfahren");
# fhem("set Wohnzimmer_Rolladen_Essen up");
# fhem("set Wohnzimmer_Rolladen_Sofa up");
}
if ($EVTPART0 eq "WZ-Rolladen-hoch.3.PRESS_LONG:")
{
Log (3,"HM_Fernbedienung-Notify: Rolladen stop(hoch)");
# fhem("set Wohnzimmer_Rolladen_Essen stop");
# fhem("set Wohnzimmer_Rolladen_Sofa stop");
}
if ($EVTPART0 eq "WZ-Rolladen-runter.4.PRESS_SHORT:")
{
Log (3,"HM_Fernbedienung-Notify: Rolladen runterfahren");
# fhem("set Wohnzimmer_Rolladen_Essen down");
# fhem("set Wohnzimmer_Rolladen_Sofa down");
}
if ($EVTPART0 eq "WZ-Rolladen-runter.4.PRESS_LONG:")
{
Log (3,"HM_Fernbedienung-Notify: Rolladen stop(runter)");
# fhem("set Wohnzimmer_Rolladen_Essen stop");
# fhem("set Wohnzimmer_Rolladen_Sofa stop");
}
}
}


Zusammenhang mit gesetztem event_on-Attributen:

Setzt man beim HMCCUCHN das Attribut event-on-change-reading auf .*, so wird ein Event nur ausgelöst, wenn sich der Wert des Readings von "false" auf "1" ändert oder umgekehrt. Das passiert im Normalbetrieb (eine manuells update wird wohl im Normalbetrieb nicht erfolgen) nur, wenn der rpcserver gestartet wird und dann beim ersten Tastendruck. Alle weiteren Tastendrucke lösen kein Event mehr aus, da sich der Wert des Readings nicht ändert. Somit ist das Setzen von "event-on-change-reading auf .*" ungeeignet für diesen Anwendugnsfall.

Setzt man beim HMCCUCHN das Attribut event-on-update-reading auf .*, so wird immer ein Event ausgelöst. Bei jedem Tastendruck, beim update und beim rpcserver-Start. Das Verhalten ist allerdings auch so, wenn event-on-update-reading  und event-on-change-reading garnicht gesetzt sind.

Ergo: Für diesen Anwendungsfall "Fernbedienungstastendruck durch notify auswerten" erscheint das Setzten von event-on-update-reading und event-on-change-reading nicht sinnvoll.

[Achiim]

Bei vielen schnellen Sets kommen sich vermutlich die Sets mit den RPC-Server Updateevents ins Gehege. Du könntest im HMCCU Device das Attribut rpcinterval auf 3 setzen (Default ist 5 Sekunden). Ob das hilft weiß ich nicht.

Mit gesetztem Attribut rpcinterval auf 3 konnte ich keine Verklemmung mehr provozieren, auch wenn ich im Sekundentakt den Dimmwert verändert habe.