... mehrere Events von Devices mit einem Ausdruck erfassen?

M_I_B · 27 Oktober 2016, 14:50:22

... nett, das ich DAU auch mal was weiß, was andere nicht wissen

Nun gut. So wie ich das sehe existiert hier wohl irgendwie ein Problem, wenn die Devices auf direkter Hardware/GPIO's basieren. Ich kann mir zwar nicht erklären, was da dann anders ist, aber da der besagte PERL- Fehler ausschließlich bei Abfragen von direkter Hardware auftaucht, ansonsten aber funktioniert, schrammt das DOIF da wohl kurz die berühmte Wand...

Lange Rede, kurzer Sinn: Da ansonsten die Sache funktioniert, soll mich die Fehlermeldung im Log nicht kümmern. Ich bin aber sehr wohl bereit, das mir möglich zur Klärung und ggf. Beseitigung beizutragen...

abc2006 · 27 Oktober 2016, 15:03:09

Du könntest ja nochmal probieren, ob ein dummy HWirgendwas den gleichen fehler produziert. Also obs am Namen liegt, oder am GPIO/Modul (ggf noch ein andersnamiges GPIO-Device definieren. Wenn du dann weisst, woher es kommt, schaust du in die MAINTAINER.txt und postest im entsprechenden Forum einen Link, dann kann sich derjenige das mal anschauen (und vielleicht auch eine Begründung liefern;)

Grüße
Stephan

M_I_B · 27 Oktober 2016, 15:18:21

... hatte ich ja schon gemacht mit verschiedenen Dummy's, vorhandenen und neu dafür angelegten Dummy's so wie mit vorhandenen "anderen" Devices ...
Es taucht tatsächlich nur bei Devices auf, die auf GPIO's zugreifen. Bei meiner Hauptinstanz kann ich das so nicht testen, aber auf dem Heizungs-PI ist das reproduzierbar

M_I_B · 28 Oktober 2016, 17:57:38

... jetzt wird es aber ganz schräg

Code Auswählen

define Bt_set DOIF (["HW"]) (set Bt | [HWBR:state] | [HWi1:state] | [HWi2:state] | [HWi3:state] |) DOELSE
#attr Bt_set do always
attr Bt_set verbose 4

define FileLog_Bt FileLog ./log/%Y-%m_BR-Test.log Bt
attr FileLog_Bt logtype text
attr FileLog_Bt room _Logdateien_

Varianten:
1.: Mit und ohne DOELSE -> Macht nie einen Unterschied
2.: Mit den Varianten ["HW"], ["HW:state"], ["^HW"], ["^HW:state"] -> Macht keinen Unterschied. Es wird NIE ein Event generiert
3.: Mit do always wird im halb- Sekunden - Takt ins Log geballert, egal ob ein Event da ist oder nicht

Nehme ich die weiter vorher beschriebene DOIF aus der Config, generiert diese Definition keinen PERL- Fehler (macht aber auch nicht was sie soll und hüllt sich in Schweigen).

Damian · 28 Oktober 2016, 19:06:09

Zitat von: M_I_B am 28 Oktober 2016, 17:57:38
... jetzt wird es aber ganz schräg

Code Auswählen Erweitern
define Bt_set DOIF (["HW"]) (set Bt | [HWBR:state] | [HWi1:state] | [HWi2:state] | [HWi3:state] |) DOELSE #attr Bt_set do always attr Bt_set verbose 4 define FileLog_Bt FileLog ./log/%Y-%m_BR-Test.log Bt attr FileLog_Bt logtype text attr FileLog_Bt room _Logdateien_

Varianten:
1.: Mit und ohne DOELSE -> Macht nie einen Unterschied
2.: Mit den Varianten ["HW"], ["HW:state"], ["^HW"], ["^HW:state"] -> Macht keinen Unterschied. Es wird NIE ein Event generiert
3.: Mit do always wird im halb- Sekunden - Takt ins Log geballert, egal ob ein Event da ist oder nicht

Nehme ich die weiter vorher beschriebene DOIF aus der Config, generiert diese Definition keinen PERL- Fehler (macht aber auch nicht was sie soll und hüllt sich in Schweigen).

Zum Verständins:

1. ["HW"] ist ein Ereignistrigger, hier wenn irgendwo im Eventmonitor HW im Device erscheint wird getriggert.

2. [HW] ist der Inhalt des Status des Devices HW, also etwas ganz anders im Vergleich zu Punkt 1.

3. ["HW:state"] wirst du normalerweise nicht im Eventmonitor sehen, da State dort nicht erscheint.

Gruß

Damian

M_I_B · 28 Oktober 2016, 20:30:52

... naja ebend, nich' nackend

Wenn ich ["HW"] oder ["^HW"] sach', dann sollte doch bei jedem Ereignis von irgend einem Device, welches HW im Namen trägt resp. mit HW im Namen beginnt und seinen Zustand ändert (hier von on zu off oder umgekehrt) ein s.g. Ereignis statt finden und dem Ganzen den Startschubser geben... oder nicht?

... ich will ja nichts weiter, als einem Dummy die aktuellen Zustände aller Devices mit HWxy übergeben, wenn eines der mit HW- beginnenden Devices was zu sagen hat...

Damian · 28 Oktober 2016, 20:34:00

Zitat von: M_I_B am 28 Oktober 2016, 20:30:52
... naja ebend, nich' nackend

Wenn ich ["HW"] oder ["^HW"] sach', dann sollte doch bei jedem Ereignis von irgend einem Device, welches HW im Namen trägt resp. mit HW im Namen beginnt und seinen Zustand ändert (hier von on zu off oder umgekehrt) ein s.g. Ereignis statt finden und dem Ganzen den Startschubser geben... oder nicht?

Nicht unbedingt. Das hängt davon ab, wie die Definition bzw. die Attribute gesetzt sind. Insb. ohne do always wird ja nur nach Zustandswechsel (des DOIF-Moduls) geschaltet.

M_I_B · 28 Oktober 2016, 20:41:07

... puhhh ... der Winni

Also...
[HWBR] ist ein GPIO-out, welcher so definiert ist:

Code Auswählen

define HWBR RPI_GPIO 16
attr HWBR alias Öl- Brenner
attr HWBR devStateIcon off:sani_boiler@gray on:sani_boiler@orange
attr HWBR direction output
attr HWBR group Aktoren
attr HWBR room KG.Heizung
attr HWBR sortby 1
attr HWBR webCmd :

[HWix] sind ebenfalls GPIO-in, die bis auf den Index identisch so aussehen:

Code Auswählen

define HWi1 RPI_GPIO 17
attr HWi1 active_low yes
attr HWi1 alias Brenner Betrieb
attr HWi1 devStateIcon off:sani_boiler@gray on:sani_boiler@green
attr HWi1 direction input
attr HWi1 group Rückmeldungen
attr HWi1 interrupt both
attr HWi1 pud_resistor off
attr HWi1 room KG.Heizung
attr HWi1 sortby 6
attr HWi1 toggletostate yes

Wenn ich also manuell oder über ein DOIF HWBR on setze, dann ist das doch ein Ereignis, oder nicht? Und wenn HWi1 vom Brenner von off zu on gesetzt wird (Flamme erkannt), dann ist das doch auch ein Ereignis. Und in beiden Fällen wird doch auch ein Event ausgelöst, sonst könnte ich ja nicht drauf reagieren...

Was verstehe ich denn hier falsch? Mach ma' meinen Knoten aus'm Hirn raus bidde ...

Damian · 28 Oktober 2016, 20:56:02

Zitat von: M_I_B am 28 Oktober 2016, 20:41:07

Wenn ich also manuell oder über ein DOIF HWBR on setze, dann ist das doch ein Ereignis, oder nicht? Und wenn HWi1 vom Brenner von off zu on gesetzt wird (Flamme erkannt), dann ist das doch auch ein Ereignis. Und in beiden Fällen wird doch auch ein Event ausgelöst, sonst könnte ich ja nicht drauf reagieren...

Was verstehe ich denn hier falsch? Mach ma' meinen Knoten aus'm Hirn raus bidde ...

Poste doch einfach mal einen Auszug aus dem Eventmonitor, wo dein "HW" im Device zu erkennen ist und dann ein list vom betreffenden DOIF-Modul, dann kann ich ziemlich genau sagen, warum das Modul nicht das gemacht hat, was du erwartet hast.

M_I_B · 28 Oktober 2016, 21:03:00

... kein Problem:

Code Auswählen

...
2016-10-28 20:58:13.389 DOIF set_BRa cmd_event: HWBR
2016-10-28 20:58:13.410 RPI_GPIO HWBR on
2016-10-28 20:58:17.933 DOIF set_BRa cmd_event: HWBR
2016-10-28 20:58:17.945 RPI_GPIO HWBR off
2016-10-28 20:58:19.811 RPI_GPIO HWBR off
2016-10-28 20:58:19.828 DOIF HWBR_D cmd_nr: 4
2016-10-28 20:58:19.828 DOIF HWBR_D cmd: 4
2016-10-28 20:58:19.828 DOIF HWBR_D cmd_event: hzsp
2016-10-28 20:58:19.828 DOIF HWBR_D cmd_4
2016-10-28 20:58:19.928 RPI_GPIO HWBR off
2016-10-28 20:58:19.945 DOIF HWBR_D cmd_nr: 4
2016-10-28 20:58:19.945 DOIF HWBR_D cmd: 4
2016-10-28 20:58:19.945 DOIF HWBR_D cmd_event: hzsp
2016-10-28 20:58:19.945 DOIF HWBR_D cmd_4
...

Code Auswählen



Internals: 
   CFGFN      ./_SW/erfassung.cfg 
   DEF        (["HW"]) (set Bt | [HWBR:state] | [HWi1:state] | [HWi2:state] | [HWi3:state] |) DOELSE 
   NAME       Bt_set 
   NR         116 
   NTFY_ORDER 50-Bt_set 
   STATE      cmd_1 
   TYPE       DOIF 
   Readings: 
     2016-10-28 21:01:39   Device          HWWP_on 
     2016-10-28 14:38:00   cmd             1 
     2016-10-28 14:38:00   cmd_event       HWWP_on 
     2016-10-28 14:38:00   cmd_nr          1 
     2016-10-28 21:01:39   matched_event_c1_1 cmd_nr: 4,cmd: 4,cmd_event: wwsp,cmd_4 
     2016-10-28 14:38:00   state           cmd_1 
   Condition: 
     0          EventDoIf('HW',$hash,'',0) 
   Devices: 
   Do: 
     0: 
       0          set Bt | [HWBR:state] | [HWi1:state] | [HWi2:state] | [HWi3:state] | 
     1: 
       0 
   Helper: 
     event      cmd_nr: 4,cmd: 4,cmd_event: wwsp,cmd_4 
     globalinit 1 
     last_timer 0 
     sleeptimer -1 
     timerdev   HWWP_on 
     timerevent cmd_nr: 4,cmd: 4,cmd_event: wwsp,cmd_4 
     triggerDev HWWP_on 
     timerevents: 
       cmd_nr: 4 
       cmd: 4 
       cmd_event: wwsp 
       cmd_4 
     timereventsState: 
       cmd_nr: 4 
       cmd: 4 
       cmd_event: wwsp 
       state: cmd_4 
     triggerEvents: 
       cmd_nr: 4 
       cmd: 4 
       cmd_event: wwsp 
       cmd_4 
     triggerEventsState: 
       cmd_nr: 4 
       cmd: 4 
       cmd_event: wwsp 
       state: cmd_4 
   Internals: 
   Itimer: 
   Readings: 
   Regexp: 
     0: 
       0          HW 
     All: 
       0          HW 
   State: 
   Trigger: 
Attributes: 
   verbose    4

Damian · 28 Oktober 2016, 21:21:28

Zitat von: M_I_B am 28 Oktober 2016, 21:03:00
... kein Problem:

Code Auswählen Erweitern
... 2016-10-28 20:58:13.389 DOIF set_BRa cmd_event: HWBR 2016-10-28 20:58:13.410 RPI_GPIO HWBR on 2016-10-28 20:58:17.933 DOIF set_BRa cmd_event: HWBR 2016-10-28 20:58:17.945 RPI_GPIO HWBR off 2016-10-28 20:58:19.811 RPI_GPIO HWBR off 2016-10-28 20:58:19.828 DOIF HWBR_D cmd_nr: 4 2016-10-28 20:58:19.828 DOIF HWBR_D cmd: 4 2016-10-28 20:58:19.828 DOIF HWBR_D cmd_event: hzsp 2016-10-28 20:58:19.828 DOIF HWBR_D cmd_4 2016-10-28 20:58:19.928 RPI_GPIO HWBR off 2016-10-28 20:58:19.945 DOIF HWBR_D cmd_nr: 4 2016-10-28 20:58:19.945 DOIF HWBR_D cmd: 4 2016-10-28 20:58:19.945 DOIF HWBR_D cmd_event: hzsp 2016-10-28 20:58:19.945 DOIF HWBR_D cmd_4 ...

Code Auswählen Erweitern
Internals: CFGFN ./_SW/erfassung.cfg DEF (["HW"]) (set Bt | [HWBR:state] | [HWi1:state] | [HWi2:state] | [HWi3:state] |) DOELSE NAME Bt_set NR 116 NTFY_ORDER 50-Bt_set STATE cmd_1 TYPE DOIF Readings: 2016-10-28 21:01:39 Device HWWP_on 2016-10-28 14:38:00 cmd 1 2016-10-28 14:38:00 cmd_event HWWP_on 2016-10-28 14:38:00 cmd_nr 1 2016-10-28 21:01:39 matched_event_c1_1 cmd_nr: 4,cmd: 4,cmd_event: wwsp,cmd_4 2016-10-28 14:38:00 state cmd_1 Condition: 0 EventDoIf('HW',$hash,'',0) Devices: Do: 0: 0 set Bt | [HWBR:state] | [HWi1:state] | [HWi2:state] | [HWi3:state] | 1: 0 Helper: event cmd_nr: 4,cmd: 4,cmd_event: wwsp,cmd_4 globalinit 1 last_timer 0 sleeptimer -1 timerdev HWWP_on timerevent cmd_nr: 4,cmd: 4,cmd_event: wwsp,cmd_4 triggerDev HWWP_on timerevents: cmd_nr: 4 cmd: 4 cmd_event: wwsp cmd_4 timereventsState: cmd_nr: 4 cmd: 4 cmd_event: wwsp state: cmd_4 triggerEvents: cmd_nr: 4 cmd: 4 cmd_event: wwsp cmd_4 triggerEventsState: cmd_nr: 4 cmd: 4 cmd_event: wwsp state: cmd_4 Internals: Itimer: Readings: Regexp: 0: 0 HW All: 0 HW State: Trigger: Attributes: verbose 4

Dein DOIF-Modul Bt_set tut natürlich nichts, weil es ja schon seit 2016-10-28 14:38:00 im Zustand cmd_1 steht. Das Modul arbeitet mit Zuständen und schaltet ohne do always nur nach Zustandswechsel, wie bereits geschrieben (das steht aber ausführlich in der Commandref zu DOIF).

Wenn do always einschaltest, dann wird das vermutlich deswegen zu einem "Feuerwerk" bei dir kommen, da du ja die anderen DOIF auch mit HW im Namen definiert hast und dann triggern sich die Dinger gegenseitig.

M_I_B · 28 Oktober 2016, 21:28:53

... ähhhh ... da muss ich mal intensiv drüber nachdenken

ZitatZustandswechsel, wie bereits geschrieben

Vermutlich liegt da mein Verständnisproblem? Ist der Wechsel von z.B. HWBR von off zu on denn kein Zustandwechsel? Oder wie ist das gemeint?

Damian · 28 Oktober 2016, 21:38:25

Zitat von: M_I_B am 28 Oktober 2016, 21:28:53
... ähhhh ... da muss ich mal intensiv drüber nachdenken
Vermutlich liegt da mein Verständnisproblem? Ist der Wechsel von z.B. HWBR von off zu on denn kein Zustandwechsel? Oder wie ist das gemeint?

Nein. Hier geht es um den eigenen Zustand des DOIF-Moduls. Das Modul führt die Befehle von cmd_1 nur dann aus, wenn es die nicht zuvor schon ausgeführt hat. Bei dir müsste also zunächst der DOELSE-Fall kommen (cmd_2) damit das Modul die Befehle von cmd_1 wieder ausführt. Allerdings wirst du mit der Definition ["HW"] niemals den DOELSE-Fall erreichen können.

Vermutlich ist also in deinem Vorhaben das do always erforderlich, aber dann musst du drauf achten, dass du keine Kettenreaktion auslöst (einen Loop)

DOIF1 -> DOIF2-> DOIF1 -> DOIF2 -> usw.

M_I_B · 28 Oktober 2016, 22:06:48

... AHHHH ... Jetzt hab ich das kapiert! Menno, ich werde echt älter

Habe ich schon mal erwähnt, das Altwerden echt schei.. ist?!

Ok, dann baue ich das mal um und eliminiere alles, was irgendwie eine Loop bauen könnte... Ich werde berichten, was geworden ist, und dann kommen wir wieder auf den PERL- Fehler zurück

Vielen Dank für deine Geduld!

Damian · 28 Oktober 2016, 22:41:08

Zitat von: M_I_B am 28 Oktober 2016, 22:06:48
... AHHHH ... Jetzt hab ich das kapiert! Menno, ich werde echt älter Habe ich schon mal erwähnt, das Altwerden echt schei.. ist?!

Ok, dann baue ich das mal um und eliminiere alles, was irgendwie eine Loop bauen könnte... Ich werde berichten, was geworden ist, und dann kommen wir wieder auf den PERL- Fehler zurück

Vielen Dank für deine Geduld!

Ich denke der Fehler kommt durch diese Loops, denn die Fehlermeldung besagte es ja.