Ich glaube da gibt es ein Problem im Zusammenspiel der 00_CUL.pm und culfw.
Die Meldung "GOT CUL fhtid: TMODE" kommt aus diesem Codeabschnitt:
CUL_WriteInit($hash);
# FHTID
if(defined($hash->{FHTID})) {
my $fhtid;
CUL_SimpleWrite($hash, "T01");
($err, $fhtid) = CUL_ReadAnswer($hash, "FHTID", 0, undef);
return "$name: $err" if($err);
$fhtid =~ s/[\r\n]//g;
Log3 $name, 5, "GOT CUL fhtid: $fhtid";
if(!defined($fhtid) || $fhtid ne $hash->{FHTID}) {
Log3 $name, 2, "Setting $name fhtid from $fhtid to " . $hash->{FHTID};
CUL_SimpleWrite($hash, "T01" . $hash->{FHTID});
}
}
Bei CUL_WriteInit wird bei euch
brt
gesendet.
Der CUL antwortet mit
TMODE
Die Antwort wird aber dort nicht ausgewertet sondern steht noch im Empfangspuffer.
Dann wird mit CUL_SimpleWrite($hash, "T01");
T01
gesendet, der CUL antwortet mit 1234.
Jetzt steht
TMODE\r\n1234
im Empfangspuffer.
Als Antwort auf das Kommando T01 wird jetzt TMODE ausgewertet, was falsch ist.
Da das nicht der fhtid in CUL Modul entspricht wird erneut mit T011234 die fhtid gesetzt.
Was dann passiert ist mir allerdings auch unklar.
Das
2019.09.27 09:17:27 5: SW: T011234
2019.09.27 09:17:27 1: 192.168.1.32:2323 reappeared (MAPLECUL1_868)
sieht fast so aus als ob der CUL neu startet und dann der WMBUS Empfangsmodus nicht mehr eingestellt ist.
Wegen des ersten Problems solltet ihr vielleicht einen separaten Thread aufmachen den Rudolf als Autor von 00_CUL.pm dann liest.
Als ersten Lösungsansatz könnte vielleicht nach CUL_WriteInit der Empfangspuffer gelöscht werden.
Das zweite Problem ist evtl. in der culfw des MAPLECUL. Ich weiß nicht wer davon der Autor ist.
