Warum Event? (HM-LC-Bl1-FM)

[rapster]

Servus,

Verständnissproblem, By Design, oder doch nicht normal?

Davon ausgehend, wir haben:

Code Auswählen Erweitern

define blind CUL_HM 123456
attr blind IOgrp vccu
attr blind event-on-change-reading .*
attr blind firmware 2.5
attr blind model HM-LC-BL1-FM
attr blind peerIDs 00000000,
attr blind subType blindActuator
mit einem momentanen Reading

state = off

und wir haben ein notify auf den Device-State off & on:

Code Auswählen Erweitern

define ntfy_blind notify blind:\s*(off|on) {  Log 1, "notify: $EVENT"; }

Warum wird das notify dann bei einem

Code Auswählen Erweitern

set blind on zwei mal getriggert, und erzeugt 2 Logeinträge?

Das erste mal löst das notify wenige ms nachdem der set Befehl abgesetzt wurde mit dem aktuellen state aus.

00:00:00.591 3: CUL_HM blind on
00:00:00.760 1: notify: off
XX:XX:XX.XXX 1: notify: on

___________________________
Wenn ich bei das ganze z.B. bei einem HM-LC-SW1-FM nachstelle wird das notify nur einmal ausgelöst, d.H. wenn das licht state=off war wird bei einem 'set licht on' ein event 'on' getriggert und nicht ebenfalls 'off' des aktuellen state's wie beim LC-Bl1.

Gruß

[martinp876]

Muesste man die messages ansehen. Moeglich, dass das device den empfang des kommandos quittiert und den state vor ausfuehren sendet. Dann kommt eine statusmessage nach der aktion. Eq3 ist hier nicht immer konsistent, hat auch mit timern zu tun... manchmal macht es auch sinn.
Das erste off sollte nicht kommen, wenn das licht schonaus ist. Muesste man alles wissen und die messages dazu sehen

[rapster]

... manchmal macht es auch sinn.

Hab bischen überlegt, aber so richtig ein Sinn ist mir nicht eingefallen, eher Verwirrung und Verkomplizierung so mancher Sachen
... mir wäre jetzt auch keines meiner anderen HM-Geräte bekannt welches dieses Verhalten aufweist, zumindest ist es mir noch nicht bewusst aufgefallen.

Habe mit 'logIDs sys,BlindID' die messages aufgezeichnet, falls das nicht genügt könnte ich noch bei Bedarf mit einem zweiten HMLAN sniffen.
Folgendes notify war zusätzlich zur Verdeutlichung aktiv: 

Code Auswählen Erweitern

BlindAktor:\s*(off|on) { Log 1, "notify:$EVENT" }

Test-1
- der BlindAktor hatte zu Beginn den 'state = on'
- Über Fhem wurde ein 'set BlindAktor off' ausgeführt, und gewartet bis er seine driveDown-Zeit gefahren ist und selbständig 'state = off' gemeldet hat.

Code Auswählen Erweitern


2015.07.10 01:47:00.137 0: HMLAN_Send:  HMLAN1 S:S753712F6 stat:  00 t:00000000 d:01 r:753712F6 m:76 A011 376514 3688EF 0201000000
2015.07.10 01:47:00.298 0: HMLAN_Parse: HMLAN1 R:R753712F6 stat:0001 t:135D1508 d:FF r:FFBC     m:76 8002 3688EF 376514 0101C82047
2015.07.10 01:47:00.307 1: notify:on
2015.07.10 01:47:08.720 0: HMLAN_Send:  HMLAN1 I:K
2015.07.10 01:47:08.723 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0578974 d:2BACE5 O:376514 t:135D35F7 IDcnt:000C L:3 %
2015.07.10 01:47:30.884 0: HMLAN_Parse: HMLAN1 R:E3688EF   stat:0000 t:135D8C82 d:FF r:FFB7     m:77 A410 3688EF 376514 06010000
2015.07.10 01:47:30.891 1: notify:off

Test-2
- der BlindAktor hatte zu Beginn den 'state = off'
- Über Fhem wurde ein 'set BlindAktor on' ausgeführt, und gewartet bis er seine driveUp-Zeit gefahren ist und selbständig 'state = on' gemeldet hat.

Code Auswählen Erweitern


2015.07.10 01:48:05.180 0: HMLAN_Send:  HMLAN1 S:S75381109 stat:  00 t:00000000 d:01 r:75381109 m:78 A011 376514 3688EF 0201C80000
2015.07.10 01:48:05.341 0: HMLAN_Parse: HMLAN1 R:R75381109 stat:0001 t:135E1326 d:FF r:FFC2     m:78 8002 3688EF 376514 0101001047
2015.07.10 01:48:05.353 1: notify:off
2015.07.10 01:48:08.997 0: HMLAN_Send:  HMLAN1 I:K
2015.07.10 01:48:09.019 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0578974 d:2BACE5 O:376514 t:135E2178 IDcnt:000C L:3 %
2015.07.10 01:48:33.999 0: HMLAN_Send:  HMLAN1 I:K
2015.07.10 01:48:34.002 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0578974 d:2BACE5 O:376514 t:135E8325 IDcnt:000C L:3 %
2015.07.10 01:48:36.761 0: HMLAN_Parse: HMLAN1 R:E3688EF   stat:0000 t:135E8DE2 d:FF r:FFB8     m:79 A410 3688EF 376514 0601C800
2015.07.10 01:48:36.768 1: notify:on


Ist dieses Verhalten bei diesem HM-Device abstellbar, oder by design und nicht umgehbar?

Danke schonmal für deine Mühe!

[martinp876]

Das verhalten gibt es haeufiger wie gesagt. Sinn hat es in jeden fall bei timern und rampen (dimmer, blind ).es wird der ist zustand gemelder. Beim schalter ist es grenzwertig, aber wenn man eine einschaltverzoegerung eingestellt hat in jedem fall nptwendig. Abstellen kann man es nicht. Aber damit umgehen ist kein problem. Du solltest das reading level haben. Bei eventonreadingchange overall wuerde das level 0 des ack keinen trigger generieren, ist ja noch aus. Das set kommt nur in den state. Somit generiert nur ein stateinfo einen trigger auf level.

[rapster]

ja, so hätte ich es gedacht, ....wenn ich dich richtig verstanden habe

Am Device ist ja "event-on-change-reading .*" gesetzt, siehe obige definition.

Also sollte doch eigentlich das level 0 da er ja in dem Moment schon diesen state hat, kein event generieren? Aber genau das tut das device...

[martinp876]

in state steht dann set_... also eine Änderung. Solltest du nachvollziehen können. Falls kein ACK käme wäre das die Indikation dass ein Kommando gesetzt wurde aber der Zustand komplett unklar ist, da das ACK nicht empfangen wurde. Maginaler - evtl entscheidender Unterschied.

[rapster]

richtig, der state geht von 'off' kurz nach 'set_on' und anschließend (beim Ack?) wieder nach 'off' und es wird ein Event ausgelöst.

Und anschließend wird nochmal ein Event bei 'on' Ausgelöst nachdem der Blindaktuator bis auf on gefahren ist.


Also ist dieses 1. Event 'off' kurz nach dem set_on normal und by design?
Weil so ist es ja schwer ein notify für den 'state' zu schreiben, da ja der nicht mehr aktuelle alte Zustand ein Event auslöst, obwohl der Blindaktuator gerade in Bewegung ist?

[frank]

Also ist dieses 1. Event 'off' kurz nach dem set_on normal und by design?
Weil so ist es ja schwer ein notify für den 'state' zu schreiben, da ja der nicht mehr aktuelle alte Zustand ein Event auslöst, obwohl der Blindaktuator gerade in Bewegung ist?

deswegen ja der tip, das notify auf das reading "level" lauschen zu lassen.

[rapster]

Ja, Wege Workarounds zu bauen gibt es genug, mir ging es hier eher darum wie das Design bezüglich der state-Events ist, da dies anscheinend unter verschiedenen Geräten nicht ganz konsistent gehandhabt wird, und ob dies eher am EQ-3 Design, oder HM-Modul liegt. (Das verhalten ist mir zumindest beim BlindAktuator zum ersten mal aufgefallen.)


(In meinem akuten Problem werde ich erstmal bei Gelegenheit Martin's Vorschlag mit den Statemachines testen, nach bischen Einlesen sollte dies hierüber noch besser zu Lösen sein.)

[martinp876]

Es wurde jetzt mehrfach wiederholt und ist hoffentlich klar: es ist eine Eigenschaft der Devices, also ein eQ3 Verhalten (Problem würde ich nicht sagen)
statemchine ist immer interessant - das Problem (welches eigentlich genau?) wird es eher nicht oder nur kompliziert  lösen.

[rapster]

Ja, danke für deine Mühe, (schon|hoffe) kapiert

Fhem sendet on => setzt 'state = set_on' (kein Event) => Gerät meldet 'off zurück' => fhem setzt 'state = off' (1.Event) => Gerät meldet irgendwann 'on zurück' => fhem setzt 'state = on' (2.Event)

Für das erste off Event kann Fhem natürlich nichts, meldet ja das Device zurück.

Problem war in einem anderen Thread http://forum.fhem.de/index.php/topic,38905.0.html, in welchem ich das mit einer Zeitberechnung im Notify gelöst hatte:

Code Auswählen Erweitern

BlindActuator(01|02|03):\s*([\d.]{1,4}|off|on|set_.*)\s*$ {
if($EVENT =~ /(?!set_stop)set_.*/) {
    CommandSetReading(undef, "$NAME myState moving");
    CommandSetReading(undef, "$NAME myStateTime ". time);
    }elsif( time_str2num(ReadingsTimestamp($NAME,'state',0)) - ReadingsVal($NAME,'myStateTime',0) >= 0.5 ) {
    CommandSetReading(undef, "$NAME myState $EVENT");
    }
}

Würde das mit Statemachines versuchen zu lösen (ja das es kompliziert ist habe ich gemerkt, versuch ists wert  ) damit ich das gewünschte Verhalten nicht nur bei anderen Wandtastern habe (wie i.M. mit dem notify), sondern auch bei Self01 und Self02.

Grüße

[martinp876]

ok - das stop beim tastendruck würde ich unbedingt mit der statemachin lösen - habe ich schon. Sollte im Einsteigerdoc schon beschrieben sein - schon lange her.
Klappt bei mir.