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
define cul_rpi_remote_ser2net CUL 192.168.0.59:2022 3721
attr cul_rpi_remote_ser2net event-on-change-reading state
log
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
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
Zitatleider 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 ;)
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
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....?
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).
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.
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).
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
Genug Strom?
...dann gehen mir ziemlich die Ideen aus. Letzter Versuch: Netzwerkproblem? (Bekannte Störenfreide: PowerLAN oder die Kombi PI+Fritzbox per WLAN)
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
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.
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.
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...
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.
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
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.
ok, danke, das übersteigt mein "Level", eh,
kann man da einen speziellen Entwickler eventuell ansprechen?
Danke
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)?
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.
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
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!!