event on change reading erzeugt laufend events obwohl kein change da ist.

Begonnen von riker1, 10 Juli 2018, 17:53:02

Vorheriges Thema - Nächstes Thema

riker1

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?

attr cul_rpi_remote_ser2net event-on-change-reading state

FHEM    5.26.1 Ubuntu 18, FHEM    5.26.1 RPI 3 , Actoren: IT ,Tasmota, ESPEasy,
MAX CUBE, MAX HT, MAX WT, Selbstbau nanoCULs, FS 20,Tasmota, Homematic, FTK, SW. DIM, Smoke,KODI,Squeezebox

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

riker1

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

Danke
FHEM    5.26.1 Ubuntu 18, FHEM    5.26.1 RPI 3 , Actoren: IT ,Tasmota, ESPEasy,
MAX CUBE, MAX HT, MAX WT, Selbstbau nanoCULs, FS 20,Tasmota, Homematic, FTK, SW. DIM, Smoke,KODI,Squeezebox

Beta-User

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)?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

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



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

DoTrigger($name, "DISCONNECTED");




Kannst Du mal bitte ein list vom CUL Device machen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

riker1

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
FHEM    5.26.1 Ubuntu 18, FHEM    5.26.1 RPI 3 , Actoren: IT ,Tasmota, ESPEasy,
MAX CUBE, MAX HT, MAX WT, Selbstbau nanoCULs, FS 20,Tasmota, Homematic, FTK, SW. DIM, Smoke,KODI,Squeezebox

riker1

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:


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!!
FHEM    5.26.1 Ubuntu 18, FHEM    5.26.1 RPI 3 , Actoren: IT ,Tasmota, ESPEasy,
MAX CUBE, MAX HT, MAX WT, Selbstbau nanoCULs, FS 20,Tasmota, Homematic, FTK, SW. DIM, Smoke,KODI,Squeezebox