Autor Thema: event on change reading erzeugt laufend events obwohl kein change da ist. (Gelesen 764 mal)

riker1 · « **am:** 10 Juli 2018, 17:53:02 »

Hi,
ich verstehe es nicht.

habe ein cul device mit event on change reading.

trotzdem wird bei dem state disconnect alle 2 minuten ein event und log erzeugt.
wenn connect da ist nicht.

so sieht es aus?
device

Code: [Auswählen]

define cul_rpi_remote_ser2net CUL 192.168.0.59:2022 3721
attr cul_rpi_remote_ser2net event-on-change-reading state

log

Code: [Auswählen]

2018-07-10_14:53:03 cul_rpi_remote_ser2net Initialized
2018-07-10_14:53:03 cul_rpi_remote_ser2net CONNECTED
2018-07-10_15:06:14 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_15:06:35 cul_rpi_remote_ser2net Initialized
2018-07-10_15:06:35 cul_rpi_remote_ser2net CONNECTED
2018-07-10_16:21:57 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:22:27 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:23:43 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:24:55 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:26:07 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:27:19 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:28:31 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:29:44 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:30:56 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:32:08 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:33:20 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:34:32 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:35:44 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:36:56 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:38:08 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:39:20 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:40:32 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:41:44 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_16:43:01 cul_rpi_remote_ser2net Initialized
2018-07-10_16:43:01 cul_rpi_remote_ser2net CONNECTED
2018-07-10_17:01:04 cul_rpi_remote_ser2net DISCONNECTED
2018-07-10_17:01:28 cul_rpi_remote_ser2net Initialized
2018-07-10_17:01:28 cul_rpi_remote_ser2net CONNECTED

leider feuert dann auch ein notify für DISCONNECTED laufend!!!

wo habe ich Tomaten auf den Augen?

Danke für die Hilfe

Danke T

Felix_K · « **Antwort #1 am:** 11 Juli 2018, 10:47:45 »

Tritt das Event denn auch tatsächlich so häufig auf dem Remote-Pi auf?
Verwendet dein Device userReadings und stateFormat?

Ein ähnliches Problem habe ich mit dem SYSMON-Modul: https://forum.fhem.de/index.php/topic,40533.0.html

Zitat

leider feuert dann auch ein notify für DISCONNECTED laufend!!!

Dann solltest du stattdessen ein DOIF anstelle eines notify verwenden, dann gibt es nur einmal Feuer

riker1 · « **Antwort #2 am:** 11 Juli 2018, 11:02:38 »

Zitat von: Felix_K am 11 Juli 2018, 10:47:45

Tritt das Event denn auch tatsächlich so häufig auf dem Remote-Pi auf?
Verwendet dein Device userReadings und stateFormat?

Hallo,
danke für die Rückmeldung.
Problem ist, das beim Reboot / Stromausfall der usb port nicht den Cul erkennt. habe schon einiges probiert, aber noch keine richtige Lösung gefunden.

sobald der Cul nicht da ist , per Ser2net angebunden, meldet das device laufend Disconnected.
Ich verwende nur die userReadings ...

Werde mal mit DOIF arbeiten, danke.
VG T

nils_ · « **Antwort #3 am:** 11 Juli 2018, 11:09:35 »

poste doch mal bitte ein vollständiges list von den devices...

Zitat von: Felix_K am 11 Juli 2018, 10:47:45

Dann solltest du stattdessen ein DOIF anstelle eines notify verwenden, dann gibt es nur einmal Feuer

ob dir DOIF da wirklich weiterhilft....?

Felix_K · « **Antwort #4 am:** 11 Juli 2018, 11:19:55 »

Ich habe einen CUL direkt über die Device Serial by ID in FHEM angebunden. Damit kann ich den CUL sogar im laufenden Betrieb vom USB Port trennen und wieder anstecken und er wird sofort wieder erkannt, eingelesen und ist verwendbar. Ein notify informiert mich über DISCONNECTED, CONNECTED und UNKNOWNCODE.LOVF (wenn die Sendeleistung erreicht ist).

Code: [Auswählen]

Beispiel: 
define CUL_Stick CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1234

@ nils_
Ich denke ja, denn wenn mehrere DISCONNECTED hintereinader kommen, ohne einen anderen Status dazwischen, wie oben im Log zu sehen, dann sollte das entsprechende DOIF_cmd nur einmal ausgelöst werden.

Beta-User · « **Antwort #5 am:** 11 Juli 2018, 13:25:15 »

Das mit "by-id" dürfte bei einem remote mit ser2net angebundenen CUL kaum klappen

.

Was ist das für ein CUL? Selbstbau mit FTDI? (Dann mal auf das Test-PIN-Problem prüfen => Wiki zu Arduino).

riker1 · « **Antwort #6 am:** 11 Juli 2018, 18:25:37 »

Zitat von: Beta-User am 11 Juli 2018, 13:25:15

Was ist das für ein CUL? Selbstbau mit FTDI? (Dann mal auf das Test-PIN-Problem prüfen => Wiki zu Arduino).

ist ein selbstbau CUL. Habe beide Versionen im einsatz FTDI und CHG
der testpin ist nachgelöstet. Danke für den Hinweis.

Habe mehrere Raspi (B, V3, B+) im Einsatz, bei manchen geht es bei manchen nicht merkwürdig.

VG T

Beta-User · « **Antwort #7 am:** 11 Juli 2018, 18:30:09 »

Genug Strom?

riker1 · « **Antwort #8 am:** 11 Juli 2018, 20:28:39 »

Zitat von: Beta-User am 11 Juli 2018, 18:30:09

Genug Strom?

Hallo,
ja extra 3A Netzteil

Beta-User · « **Antwort #9 am:** 11 Juli 2018, 21:55:43 »

...dann gehen mir ziemlich die Ideen aus. Letzter Versuch: Netzwerkproblem? (Bekannte Störenfreide: PowerLAN oder die Kombi PI+Fritzbox per WLAN)

riker1 · « **Antwort #10 am:** 12 Juli 2018, 11:39:45 »

Zitat von: Beta-User am 11 Juli 2018, 21:55:43

...dann gehen mir ziemlich die Ideen aus. Letzter Versuch: Netzwerkproblem? (Bekannte Störenfreide: PowerLAN oder die Kombi PI+Fritzbox per WLAN)

Hi
Danke,

der RPI ist mit LAN angebunden.
kein PowerLan

Beta-User · « **Antwort #11 am:** 12 Juli 2018, 11:55:27 »

Zitat von: riker1 am 11 Juli 2018, 18:25:37

Habe mehrere Raspi (B, V3, B+) im Einsatz, bei manchen geht es bei manchen nicht merkwürdig.

Das klingt aber sehr danach, als wäre die Ursache ggf. die ser2net-Definition auf dem jeweiligen Pi. Du solltest mal nachsehen, wo da die Unterschiede sind und dann nach und nach Hardwareprobleme ausschließen.

riker1 · « **Antwort #12 am:** 12 Juli 2018, 12:51:46 »

habe genau die gleiche config definition für ser2net bei den RPIs

habe da schon Tage mit verbracht. und keine Lösung gefunden.

usb aktivieren und deaktivieren per corn-shell script und ähnliches, ohne Erfolg. verschiedene selbstculs....

Danke nochmal.

Allerdings das urspüngliche Thema, warum bei state disconnect laufend events feuern ist noch unklar, bei connect ist es ok.

nils_ · « **Antwort #13 am:** 12 Juli 2018, 13:37:10 »

ich wiederhole mich mal:

Zitat von: nils_ am 11 Juli 2018, 11:09:35

poste doch mal bitte ein vollständiges list von den devices...

Beta-User · « **Antwort #14 am:** 12 Juli 2018, 13:53:12 »

Das dauernde Triggern nach 1 Min dürfte von der normalen DevIo.pm-Routine kommen (Zeile 545): Ist ein über DevIo angebundenes Device nicht verfügbar, versucht FHEM immer wieder, dieses zu erreichen (die 60 Sek. kommen aus Zeile 226).

Soweit also so normal (imo).

Das Problem liegt daher m.E. nicht bei FHEM, sondern bei dem zu erreichenden Device bzw. dem Weg dahin.

riker1 · « **Antwort #15 am:** 12 Juli 2018, 14:18:26 »

Zitat von: Beta-User am 12 Juli 2018, 13:53:12

Das dauernde Triggern nach 1 Min dürfte von der normalen DevIo.pm-Routine kommen (Zeile 545): Ist ein über DevIo angebundenes Device nicht verfügbar, versucht FHEM immer wieder, dieses zu erreichen (die 60 Sek. kommen aus Zeile 226).

Soweit also so normal (imo).

Das Problem liegt daher m.E. nicht bei FHEM, sondern bei dem zu erreichenden Device bzw. dem Weg dahin.

ok,

aber sollte nicht das attrib dann den event verhindern?

Code: [Auswählen]

attr cul_rpi_remote_ser2net event-on-change-reading state

Beta-User · « **Antwort #16 am:** 12 Juli 2018, 14:51:27 »

Zitat von: riker1 am 12 Juli 2018, 14:18:26

aber sollte nicht das attrib dann den event verhindern?

Guter Einwand. Bin leider nicht so tief im Code drin, dass mir dazu was handfestes einfallen würde, kann aber sein, dass derartig schwere Probleme einen anderen "Trigger-Level" haben und daher von dem Attribut nicht erfaßt werden.

riker1 · « **Antwort #17 am:** 12 Juli 2018, 15:06:55 »

ok, danke, das übersteigt mein "Level", eh,
kann man da einen speziellen Entwickler eventuell ansprechen?

Danke

Beta-User · « **Antwort #18 am:** 12 Juli 2018, 15:25:13 »

Zitat von: riker1 am 12 Juli 2018, 15:06:55

kann man da einen speziellen Entwickler eventuell ansprechen?

Keine Ahnung.

Aber noch was anderes: wenn es DevIo ist, das alle 60 Sek. die Meldung bringt, sollten eigentlich die timestamps auch halbwegs im Minutentakt kommen. Dem ist aber nicht wirklich so, es sieht eher so aus, als wäre dein System dauerhaft ziemlich beschäftigt. Vielleicht solltest du dich darum zuerst kümmern.

Hast du MQTT oder FHEM2FHEM im Einsatz (=>unbemerkte Triggerschleife)? Oder ein älteres dewpoint (reagiert auf alle Events)?

CoolTux · « **Antwort #19 am:** 12 Juli 2018, 15:26:27 »

Deine Events DISCONNECTED und CONNECTED kommen eigentlich vom DevIO Modul. CUL Verwendet das DevIO Modul zum Aufbau eines TCP Sockets.

Code: [Auswählen]


sub
DevIo_Disconnected($)
{
  my $hash = shift;
  my $dev = $hash->{DeviceName};
  my $name = $hash->{NAME};
  my $baudrate;
  ($dev, $baudrate) = split("@", $dev);

  return if(!defined($hash->{FD}));                 # Already deleted or RFR

  my $l = $hash->{devioLoglevel}; # Forum #61970
  Log3 $name, ($l ? $l:1), "$dev disconnected, waiting to reappear ($name)";
  DevIo_CloseDev($hash);
  $readyfnlist{"$name.$dev"} = $hash;               # Start polling
  DevIo_setStates($hash, "disconnected");
  $hash->{DevIoJustClosed} = 1;                     # Avoid a direct reopen

  DoTrigger($name, "DISCONNECTED");
}

Das hier ist das entscheidene

Code: [Auswählen]

DoTrigger($name, "DISCONNECTED");

Kannst Du mal bitte ein list vom CUL Device machen.

riker1 · « **Antwort #20 am:** 12 Juli 2018, 17:58:20 »

Zitat von: Beta-User am 12 Juli 2018, 15:25:13

Hast du MQTT oder FHEM2FHEM im Einsatz (=>unbemerkte Triggerschleife)? Oder ein älteres dewpoint (reagiert auf alle Events)?

ja habe fhem2fhem und mqtt im Einsatz.

ja mache mal die Last etwas runter. Verbose zu oft 5, lösche dies mal

riker1 · « **Antwort #21 am:** 12 Juli 2018, 18:00:44 »

Zitat von: CoolTux am 12 Juli 2018, 15:26:27

Deine Events DISCONNECTED und CONNECTED kommen eigentlich vom DevIO Modul. CUL Verwendet das DevIO Modul zum Aufbau eines TCP Sockets.

Kannst Du mal bitte ein list vom CUL Device machen.

so hier das list:

Code: [Auswählen]

Internals:
   CMDS       ABCEeFfGhiKklMmRTtUVWXxYZz
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        192.168.0.95:2022 3841
   DeviceName 192.168.0.95:2022
   FD         24
   FHTID      3841
   NAME       cul_wohn_ser2net_rpi
   NR         659
   PARTIAL    
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.67 nanoCUL868
   initString X21
Ar
   owner_CCU  VCCU
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2017-11-05 15:44:51   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2018-07-12 17:52:22   cmds             A B C E e F f G h i K k l M m R T t U V W X x Y Z z
     2017-10-25 23:46:29   credit10ms      8
     2018-07-10 22:49:40   fhtbuf          AE
     2018-07-12 08:30:00   raw             is00000F0FFF0F
     2018-07-12 17:52:22   state           Initialized
     2017-11-04 08:34:08   uptime          0 21:30:42
     2017-09-25 14:22:27   version         V 1.66 nanoCUL433
   helper:
Attributes:
   addvaltrigger 1
event-on-change-reading state
   hmId       AABBCC
   hmProtocolEvents 3_dumpTrigger
   icon       cul_868
   model      nanoCUL
   rfmode     HomeMatic

danke fürs checken!!

Neuigkeiten:

Autor Thema: event on change reading erzeugt laufend events obwohl kein change da ist. (Gelesen 764 mal)