[HMCCUDEV] Events beim Schalten des Rollladenaktors

Begonnen von Kai-Alfonso, 05 Oktober 2017, 07:49:37

Vorheriges Thema - Nächstes Thema

Kai-Alfonso

Hallo,

ich würde gerne die aktuellen Schaltbefehle (control 0 zum Beispie) meiner HM Rollladenaktoren in ein Logfile schreiben - jetzt habe ich festgestellt, das er beim Aufruf von set HM_Rolllade_Bad control 100 zwei control Events erzeugt:

Hier beim schalten von 90 auf 100%

Zitat2017-10-05 07:40:11 HMCCUDEV HM_Rolllade_Bad control 100
2017-10-05 07:40:12 HMCCUDEV HM_Rolllade_Bad 1.DIRECTION: auf
2017-10-05 07:40:12 HMCCUDEV HM_Rolllade_Bad 1.LEVEL: 90
2017-10-05 07:40:12 HMCCUDEV HM_Rolllade_Bad control: 90
2017-10-05 07:40:12 HMCCUDEV HM_Rolllade_Bad 90
2017-10-05 07:40:12 HMCCUDEV HM_Rolllade_Bad hmstate: 90
2017-10-05 07:40:24 HMCCUDEV HM_Rolllade_Bad 1.LEVEL: 100
2017-10-05 07:40:24 HMCCUDEV HM_Rolllade_Bad 100
2017-10-05 07:40:24 HMCCUDEV HM_Rolllade_Bad 1.DIRECTION: keine
2017-10-05 07:40:24 HMCCUDEV HM_Rolllade_Bad hmstate: 100

Ist  das ein Bug oder ein gewünschtes Verhalten?  Ich hab auch schon mit event-min-interval
control:120
gespielt, scheint aber nix zu bringen  (wenn ich event-min-interval richtig verstanden habe)

Die Raw Definition sieht so aus:

defmod HM_Rolllade_Bad HMCCUDEV XXXXXXXXXX
attr HM_Rolllade_Bad IODev CCU2
attr HM_Rolllade_Bad alias Rolllade Bad
attr HM_Rolllade_Bad ccureadingfilter (LEVEL|INHIBIT|DIRECTION)
attr HM_Rolllade_Bad ccuscaleval LEVEL:0:1:0:100
attr HM_Rolllade_Bad cmdIcon up:fts_shutter_up stop:fts_shutter_manual down:fts_shutter_down
attr HM_Rolllade_Bad controldatapoint 1.LEVEL
attr HM_Rolllade_Bad devStateIcon (0).*:fts_shutter_100 (8$|9$|1[0-8]$).*:fts_shutter_90 (18|19|2[0-8]).*:fts_shutter_80 (28|29|3[0-8]).*:fts_shutter_70 (38|39|4[0-8]).*:fts_shutter_60 (48|49|5[0-8]).*:fts_shutter_50 (58|59|6[0-8]).*:fts_shutter_40 (68|69|7[0-8]).*:fts_shutter_30 (78|79|8[0-8]).*:fts_shutter_20 (88|89|9[0-8]).*:fts_shutter_10 (100):fts_shutter_0
attr HM_Rolllade_Bad event-min-interval control:120
attr HM_Rolllade_Bad eventMap /datapoint 1.STOP 1:stop/datapoint 1.LEVEL 0:down/datapoint 1.LEVEL 100:up/datapoint 1.STOP true:stop/
attr HM_Rolllade_Bad genericDeviceType blind
attr HM_Rolllade_Bad group Rollladen
attr HM_Rolllade_Bad icon fts_shutter_updown
attr HM_Rolllade_Bad room Badezimmer,Obergeschoß,Rollladen
attr HM_Rolllade_Bad statedatapoint 1.LEVEL
attr HM_Rolllade_Bad stripnumber 1
attr HM_Rolllade_Bad substexcl control
attr HM_Rolllade_Bad substitute DIRECTION!0:keine,1:auf,2:ab,3:unbekannt
attr HM_Rolllade_Bad webCmd control:up:stop:down
attr HM_Rolllade_Bad widgetOverride control:slider,0,10,100

setstate HM_Rolllade_Bad 100
setstate HM_Rolllade_Bad 2017-10-05 07:40:24 1.DIRECTION keine
setstate HM_Rolllade_Bad 2017-10-04 12:03:43 1.INHIBIT false
setstate HM_Rolllade_Bad 2017-10-05 07:40:24 1.LEVEL 100
setstate HM_Rolllade_Bad 2017-10-05 07:40:24 control 100
setstate HM_Rolllade_Bad 2017-10-05 07:40:24 hmstate 100
setstate HM_Rolllade_Bad 2017-10-05 07:40:24 state 100



PS: Ich sehe grade, das es einmal control: und einmal control heißt - darauf könnte ich evtl per Regex filtern. Trotzdem würde mich interessieren, warum die events gedoppelt sind (einmal alter Stand, dann neuer Stand)

edit: Natürlich meine ich das setzen des Readings control: das wird einmal auf den alten Stand der Rollladen gesetzt, dann überschrieben mit dem neuem Stand
Raspi2|nanoCul433|nanoCul868|CCU2
Energie-USBZähler|homebrew HM Devices
DBLog|DBRep|Homematic|Baumarktsteckdosen
Hue|Webcams mit DS-Station (Synology)|Bewegungsmelder|Rollladen|Schalter (IT|HM)

zap

#1
Frage doch mal in einem anderen Unterforum, warum bei einigen Events ein Doppelpunkt steht und bei anderen nicht. Meine Vermutung: die Aktualisierung eines Readings wird mit Doppelpunkt nach dem Namen angezeigt. Ohne Doppelpunkt ist es ein Protokollieren des set Befehls. Aber wie gesagt: nur eine Vermutung.

Wenn control vorher 90 war, kannst du das zusätzliche control:90 Event vermutlich vermeiden, indem Du event-on-change-reading auf control oder .* setzt.

Und es dauert wirklich 12 Sekunden vom Schaltbefehl bis das Reading auf 100 gesetzt wird? Benutzt Du den internen RPC Server?
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

Kai-Alfonso

Zitat von: zap am 06 Oktober 2017, 08:23:46
Frage doch mal in einem anderen Unterforum, warum bei einigen Events ein Doppelpunkt steht und bei anderen nicht. Meine Vermutung: die Aktualisierung eines Readings wird mit Doppelpunkt nach dem Namen angezeigt. Ohne Doppelpunkt ist es ein Protokollieren des set Befehls. Aber wie gesagt: nur eine Vermutung.

Guten Morgen :-) Ja, das habe ich auch schon vermutet, bzw jemand im anderen Forum hat mich mit der Nase drauf gestoßen, weil auch das Regex in der Readingsgroup nicht klappte (klar, ich versuchte auch auf den Set Befehl zu matchen)
Zitat von: zap am 06 Oktober 2017, 08:23:46
Wenn control vorher 90 war, kannst du das zusätzliche control:90 Event vermutlich vermeiden, indem Du event-on-change-reading auf control oder .* setzt.

Das hab ich in dem Zuge dann auch gemacht und funktioniert so für mich erstmal.

Zitat von: zap am 06 Oktober 2017, 08:23:46
Und es dauert wirklich 12 Sekunden vom Schaltbefehl bis das Reading auf 100 gesetzt wird? Benutzt Du den internen RPC Server?

Ja, ich glaube schon - zumindest läut er und der Status ist running/OK
Raspi2|nanoCul433|nanoCul868|CCU2
Energie-USBZähler|homebrew HM Devices
DBLog|DBRep|Homematic|Baumarktsteckdosen
Hue|Webcams mit DS-Station (Synology)|Bewegungsmelder|Rollladen|Schalter (IT|HM)