[HM-Wired] Vereinigung der Versionen "honk" und "gevoo/thorsten"

[Thorsten Pferdekaemper]

Hi honk,
mir ist da noch etwas eingefallen: Wenn man ein Sensor-Device vom Bus nimmt, welches gepeert ist, dann kann man das Peering vom Aktor-Device nicht mehr löschen. Planst Du da was?
Gruß,
   Thorsten

[hglaser]

Hallo

@honk: Könntest Du Dich damit befassen? Ich habe kein solches Device und mir ist nicht ganz klar, wie das mit dem behaviour zusammenhängt.

Ja ich schaus mir an, obwohl ich auch noch nicht so recht weiß an welcher Stelle ich das einbauen soll. Es ist irgendwie eine blöde Stelle im Device.pm. Darum ist es mir wohl auch nie aufgefallen.

mir ist da noch etwas eingefallen: Wenn man ein Sensor-Device vom Bus nimmt, welches gepeert ist, dann kann man das Peering vom Aktor-Device nicht mehr löschen. Planst Du da was?

Eigentlich nicht. Ein Löschen der eeprom Einträge nur im Aktor habe ich eigentlich nicht vorgesehen. Ein "set unpeer unknown" oder so ähnlich könnte man aber wohl in einen Aktorkanal einbauen.

lg Harald.

[Ralf9]

Hi,Das ist mit der aktuellen Version (0.7.9) unterstützt. Ich habe es allerdings etwas anders implementiert, in der Hoffnung damit noch ein paar weitere Eventualitäten abgedeckt zu haben. Kannst Du es mal ausprobieren?

Deine Version gefällt mir nicht so richtig. Ich werde meine Version behalten. Ich werde es trotzdem mal testen.
Mir ist aufgefallen, daß Du recht verschwenderisch mit der Rechenleistung umgehst. Es haben auch noch einige recht schwächliche Rechner wie die Fritzbox oder der Raspi1. Oder ist der aspekt mit der Rechenleistung vernachlässigbar?
Du hast 3 foreach-Schleifen ineinander verschachtelt. Bei dem config Teil dürfte es egal sein, aber ich denke man sollte bei der Verarbeitung der Response und Events einwenig darauf achten, daß man nicht so sehr verschwenderisch mit der Rechenleistung umgeht.

Beim HMW_IO12_SW14_DR reicht für die "info_frequency" folgende Abfrage:

Code Auswählen Erweitern


if ( $frameTypeName eq "info_frequency" && $behaviour eq "digital_input") {
$frameTypeName = "info_level";
}

Noch was @Ralf9: Hat sich das mit dem 'door_sensor.state' erledigt?

Kann es sein, das es mit dem hinzufügen von "state" zusammenhängt? Ohne state funktioniert es.


Ich habe mir mal das mit der Queue Geschichte beim Get Config angeschaut. Dies ist sehr komplex.
Ich habe es bei mir mal so erweitert, daß ich es produktiv auf meinem cubietruck einsetzen kann.

Zum Testen habe ich fhem auf dem cubietruck beendet und den HM485d.pl manuel gestartet.
Nun habe ich einfach im fhem auf meinem PC in der fhem.cfg folgendes eingetragen. Das "x" ist die IP des cubietruck.

Code Auswählen Erweitern

define HM485_LAN HM485_LAN 192.168.0.x:2000
attr HM485_LAN hmwId 00000001
attr HM485_LAN room HM485

Da auf dem cubietruck der Patch mit dem Fehler bei MsgId 252/253 noch nicht drin war, konnte ich sehr schön eine hängende Queue herbeiführen.
Eine hängende Queue dürfte zwar nur selten vorkommen, aber man sollte bei einem Problem mit dem Bus oder der Queue die Möglichkeit haben den Fehler einzugrenzen und die Queue abzubrechen ohne fhem neustarten zu müssen.

Ich habe nun die "sub HM485_SetConfigStatus" so erweitert, daß der configstatus auch im state eingetragen ist.
Damit ist es bei Busproblemen und einer hängenden Queue möglich, festzustellen welches Device probleme macht.
Es gibt jetzt die folgenden configstatus: Get Infos  -  Reading  -  Reading Start  -  Reading ok  -  Get State  -  OK
Mit dem set "'abort_getConfig' kann bei einem Device die Queue abgebrochen werden. Danach kann dann mit "get config all" das Device nochmals geladen werden.
Außerdem habe ich noch die Konstante RESPONSE_TIMEOUT_FLAG hinzugefügt. Bei 0 wird bei einem "response timeout" die config nicht mehr neu geladen.
Mit diesen Anpassungen ist die Version für mich auf dem cubietruck produktiv einsetzbar.


Ich habe u.a. folgendes geändert, siehe auch in der Anlage:

in der "sub HM485_Parse($$)" und "sub HM485_SetStateNack($$) "habe ich die folgende Abfrage eingefügt:

Code Auswählen Erweitern

if (RESPONSE_TIMEOUT_FLAG == 1) { # die Config wird nur neu gelesen, wenn FLAG = 1

In der "sub HM485_SetStateAck($$$)" habe ich eine Abfrage eingefügt, daß der state nur beim CONFIG_STATUS =  'OK' verändert wird.

In der "sub HM485_QueueProcessStep()" und "sub HM485_QueueStepSuccess($)" habe ich Abfragen zum Setzen des ConfigStatus eingefügt.

Ich hoffe ich habe nichts vergessen. Die Änderungen sind leider nur als Datei, die ich nicht mit dem GitHub arbeite.

Gruß Ralf

[Thorsten Pferdekaemper]

Du hast 3 foreach-Schleifen ineinander verschachtelt. Bei dem config Teil dürfte es egal sein, aber ich denke man sollte bei der Verarbeitung der Response und Events einwenig darauf achten, daß man nicht so sehr verschwenderisch mit der Rechenleistung umgeht.

Ich habe immer nur zwei Ebenen gezählt. Außerdem kommt ja normalerweise nach der ersten Abfrage (mit event, frame type, direction) kaum noch was in Frage. D.h. die Schleifen haben nachher maximal noch zwei Durchläufe. Außerdem dürften da nur Referenzen rumgeschaufelt werden, das dürfte nicht so weh tun.
Ich habe halt versucht, alle Eventualitäten zu unterstützen, auch wenn sich jemand mal ein Homebrew-Device mit nicht ganz so perfektem Device-File baut. Außerdem könnten ja auch noch neue Devices von HM kommen. (Theoretisch...) 

Beim HMW_IO12_SW14_DR reicht für die "info_frequency" folgende Abfrage:

Code Auswählen Erweitern


if ( $frameTypeName eq "info_frequency" && $behaviour eq "digital_input") {
$frameTypeName = "info_level";
}

@honk: Die kompliziertere Abfrage in "meinem" Coding habe ich von Dir übernommen. Könntest Du mal nachsehen, ob das wirklich auch einfacher geht?

Kann es sein, das es mit dem hinzufügen von "state" zusammenhängt? Ohne state funktioniert es.

Hier geht's um den Türsensor. Theoretisch kann das sein. Dann müsste aber im Reading "state" irgend was anderes erscheinen. Mit 0.7.11 habe ich da nochmal was geändert, es kann gut sein, dass das jetzt besser funktioniert.

Ich habe mir mal das mit der Queue Geschichte beim Get Config angeschaut. Dies ist sehr komplex.

Naja, nicht gerade Rocket Science.

Eine hängende Queue dürfte zwar nur selten vorkommen, aber man sollte bei einem Problem mit dem Bus oder der Queue die Möglichkeit haben den Fehler einzugrenzen und die Queue abzubrechen ohne fhem neustarten zu müssen.

Du hättest auch einfach "reload 10_HM485.pm" machen können.
Außerdem darf das wirklich nicht passieren. Das bedeutet nämlich auch, dass kein NACK erzeugt wird und das ist schon ziemlich zentral.

Ich habe nun die "sub HM485_SetConfigStatus" so erweitert, daß der configstatus auch im state eingetragen ist.
Damit ist es bei Busproblemen und einer hängenden Queue möglich, festzustellen welches Device probleme macht.
Es gibt jetzt die folgenden configstatus: Get Infos  -  Reading  -  Reading Start  -  Reading ok  -  Get State  -  OK

Normalerweise könnte man das vielleicht auch mit "stateFormat" machen. Ich denke aber auch, dass man im Device state etwas mehr als nur ACK und NACK anzeigen könnte. Vielleicht übernehme ich das mal.

Außerdem habe ich noch die Konstante RESPONSE_TIMEOUT_FLAG hinzugefügt. Bei 0 wird bei einem "response timeout" die config nicht mehr neu geladen.

Ja, so etwas ähnliches hatten wir mal diskutiert. Ich würde das zwar als Attribut machen, aber im Prinzip sinnvoll.

Mit diesen Anpassungen ist die Version für mich auf dem cubietruck produktiv einsetzbar.

Wieso erwähnst Du, dass es ein Cubietruck ist? Ist das Teil besonders problematisch?

Gruß,
   Thorsten

[Ralf9]

Hier geht's um den Türsensor. Theoretisch kann das sein. Dann müsste aber im Reading "state" irgend was anderes erscheinen.

Ich habe es nicht weiter untersucht warum der Türsensor nicht funktioniert hat. Ich habe es jetzt umgeschrieben, siehe unten. Es müsste jetzt alle Fälle abdecken.

Außerdem darf das wirklich nicht passieren. Das bedeutet nämlich auch, dass kein NACK erzeugt wird und das ist schon ziemlich zentral.

Das wirst Du nie ganz ausschließen können, das es bei der Queue Abarbeitung zu Problemen kommen kann. Eine Ursache könnte auch ein nicht ganz sauber programmiertes Homebrew Modul sein.
   

Wieso erwähnst Du, dass es ein Cubietruck ist? Ist das Teil besonders problematisch?

Nein es hat keinen besonderen Grund, warum ich den Cubietruck erwähnt habe. Er läuft vollkommen problemlos.


Ich habe die  "sub HM485_ChannelDoUpdate($)" so umgeschrieben, daß damit alle Fälle abgedeckt sein müssten.
Ich habe es mit zwei Konstanten konfigurierbar gemacht. Ich habe die Konstanten an den Anfang der 10_HM485.pm geschrieben, ist dies so ok, oder gibt es dafür einen besseren Platz?

Code Auswählen Erweitern


use constant CHANNEL_UPDATE_STATE_FLAG   => 0;  # 1 = state readings auch bei keys und sensors
use constant CHANNEL_UPDATE_WORKING_FLAG => 1;  # 0 = keine working readings, 1 = ondelay und on_time readings, 2 = working readings


Mit dem CHANNEL_UPDATE_STATE_FLAG kann das zusätzliche state in den readings deaktiviert werden. Es gibt hier einige die recht viele Notifys haben.  Evtl funktionieren mit diesem zusätzlichen state die Notify nicht mehr richtig.
Mit dem CHANNEL_UPDATE_WORKING_FLAG=1 wird aus der kombination von state und working die neuen state ondelay und on_time erzeugt. Die passenden Icons sind in der Anlage.

Code Auswählen Erweitern

sub HM485_ChannelDoUpdate($) {
my ($params)    = @_;

my $chHash    = $params->{chHash};
my $valueHash = $params->{valueHash};
my $name      = $chHash->{NAME};
my $doTrigger = $params->{doTrigger} ? 1 : 0;

my $state   = undef;
my $working = undef;
my $otherState = undef;

#print Dumper ($valueHash);
readingsBeginUpdate($chHash);

my $valueKey;
foreach $valueKey (keys %{$valueHash}) {
my $value = $valueHash->{$valueKey};

if (defined($value)) {
HM485::Util::logger( 'HM485_ChannelDoUpdate', 4, 'name = ' . $name . ' valueKey = ' . $valueKey . ' value = ' . $value . ' Alter Wert = ' . $chHash->{READINGS}{$valueKey}{VAL});

if ($valueKey eq 'working') {
if (CHANNEL_UPDATE_WORKING_FLAG > 0) {
$working = $value;
}
if (CHANNEL_UPDATE_WORKING_FLAG == 2) {    # working ins readings
readingsBulkUpdate( $chHash, $valueKey, $value);
$working = undef;
}
} elsif ($valueKey eq 'state') {
$state = $value;
} else {
if (substr($valueKey,0 ,5) eq 'press') {
$chHash->{STATE} = $valueKey . '_' . $value;
} else {
$chHash->{STATE} = $value;
}
if (CHANNEL_UPDATE_STATE_FLAG == 1) {
$otherState = $chHash->{STATE};
}
readingsBulkUpdate( $chHash, $valueKey, $value);
}
}
}
if (defined($otherState)) {
readingsBulkUpdate( $chHash, 'state', $otherState);
}
if (defined($state)) {
if (defined($working) && $working eq 'on') {
HM485::Util::logger( 'HM485_ChannelDoUpdate', 4, 'working = on,  state = ' . $state);
if ($state eq 'off') {
$chHash->{STATE} = 'ondelay';
} else {
$chHash->{STATE} = 'on_time';
}
} else {
$chHash->{STATE} = $state;
}
readingsBulkUpdate( $chHash, 'state', $chHash->{STATE});
}
readingsEndUpdate($chHash, $doTrigger);
}


Nachtrag:

Hi,Das ist mit der aktuellen Version (0.7.9) unterstützt. Ich habe es allerdings etwas anders implementiert, in der Hoffnung damit noch ein paar weitere Eventualitäten abgedeckt zu haben. Kannst Du es mal ausprobieren?

Ich habe es inzwischen getestet, es funktioniert bei mir.

Gruß Ralf

[hglaser]

Beim HMW_IO12_SW14_DR reicht für die "info_frequency" folgende Abfrage:
    Code: [Auswählen]

       if ( $frameTypeName eq "info_frequency" && $behaviour eq "digital_input") {
          $frameTypeName   = "info_level";
       }

@honk: Die kompliziertere Abfrage in "meinem" Coding habe ich von Dir übernommen. Könntest Du mal nachsehen, ob das wirklich auch einfacher geht?

Hallo

Das Problem dabei ist, daß "$frameTypeName" (wo kommt das denn nun wieder her? bei mir heißt es "$frame"), einmal zuerst als "info_frequency" dann wieder einmal als erstes "info_level" daher kommt. Es wechselt also, da es im hash nicht sortiert ist. In dieser Version wird es also mal funktionieren und mal nicht.

Mein Vorschlag wäre
$ioHash->{'.waitForResponse'}{$requestId}{requestType}
zusätzlich um ein
$ioHash->{'.waitForResponse'}{$requestId}{requestTypeName}
zu erweitern. Dann ginge das parsen leichter.
Das gleiche auch bei .waitForAck, wenn das richtig funktioniert.

lg Harald

[Thorsten Pferdekaemper]

Das Problem dabei ist, daß "$frameTypeName" (wo kommt das denn nun wieder her? bei mir heißt es "$frame"),

Das ist aus Ralfs Coding, ist im Prinzip dasselbe wie $frame.

einmal zuerst als "info_frequency" dann wieder einmal als erstes "info_level" daher kommt. Es wechselt also, da es im hash nicht sortiert ist. In dieser Version wird es also mal funktionieren und mal nicht.

Ah ja, sowas habe ich mir fast gedacht. In meiner Version ist es sogar so, dass immer alle Frame-Definitionen durchgegangen werden, da ist es dann sogar egal, wie die Reihenfolge ist. Es würde nie funktionieren. Also lassen wir das mal besser so.

Mein Vorschlag wäre
$ioHash->{'.waitForResponse'}{$requestId}{requestType}
zusätzlich um ein
$ioHash->{'.waitForResponse'}{$requestId}{requestTypeName}
zu erweitern. Dann ginge das parsen leichter.
Das gleiche auch bei .waitForAck, wenn das richtig funktioniert.

Wie schon per Mail: Meiner Meinung nach darf das Verarbeiten eines empfangenen Frames nicht davon abhängen, was man vorher gesendet hat. Ich habe es aber sowieso inzwischen so umgebaut, dass es immer funktionieren sollte. Im Prinzip werden immer alle Frame-Definition getestet. Wenn es mehrere gibt, dann wird in der Definition des Channel nachgesehen, welche die richtige ist.

Ich habe die  "sub HM485_ChannelDoUpdate($)" so umgeschrieben, daß damit alle Fälle abgedeckt sein müssten.
Ich habe es mit zwei Konstanten konfigurierbar gemacht. Ich habe die Konstanten an den Anfang der 10_HM485.pm geschrieben, ist dies so ok, oder gibt es dafür einen besseren Platz?

Naja, Konstanten sind nie ein guter Weg, um irgendwas konfigurierbar zu machen. Dann müsste man das ja nach jedem Upgrade nachziehen.

Mit dem CHANNEL_UPDATE_STATE_FLAG kann das zusätzliche state in den readings deaktiviert werden. Es gibt hier einige die recht viele Notifys haben.  Evtl funktionieren mit diesem zusätzlichen state die Notify nicht mehr richtig.

Warum sollte das so sein?

Mit dem CHANNEL_UPDATE_WORKING_FLAG=1 wird aus der kombination von state und working die neuen state ondelay und on_time erzeugt. Die passenden Icons sind in der Anlage.

Naja...
1. Das dürfte für Rolloaktoren nicht so ganz richtig aussehen
2. Bei Devices, die ihr Haupt-Reading im state haben, sollte man das nicht machen. Da gehört einfach on oder off rein, sonst funktionieren die notifies tatsächlich nicht mehr. (Ich habe den state-Update inzwischen so geändert, dass working oder direction nicht mehr dort landet.)
3. Ich denke, dass STATE nicht direkt geändert werden soll. Das macht FHEM zentral aus state und stateFormat.
3. Das mit den Icons müsste man doch auch mit FHEM-Bordmitteln hinbekommen. Gibt's da nicht ein Attribut, mit dem man das regeln kann?

Nachtrag:Ich habe es inzwischen getestet, es funktioniert bei mir.

Danke für's Testen.

Gruß,
   Thorsten

[Ralf9]

Warum sollte das so sein?

Einige Notify mit sehr einfachen Bedingungen, werden durch das zusätzliche state wahrscheinlich doppelt ausgeführt.
Hätte ich bei mir das zusätzliche state aktiviert, müsste ich einige Notify umschreiben, damit sie nicht doppelt ausgeführt werden.

Naja...
1. Das dürfte für Rolloaktoren nicht so ganz richtig aussehen
3. Das mit den Icons müsste man doch auch mit FHEM-Bordmitteln hinbekommen. Gibt's da nicht ein Attribut, mit dem man das regeln kann?

Bei den Modulen wie den Rolloaktoren, die keine state haben, wird das working ignoriert.
Die Info für ondelay und on_time kann nur aus der Kombination von state und working geholt werden.

Ralf

[hglaser]

Wie schon per Mail: Meiner Meinung nach darf das Verarbeiten eines empfangenen Frames nicht davon abhängen, was man vorher gesendet hat. Ich habe es aber sowieso inzwischen so umgebaut, dass es immer funktionieren sollte. Im Prinzip werden immer alle Frame-Definition getestet. Wenn es mehrere gibt, dann wird in der Definition des Channel nachgesehen, welche die richtige ist.

Ja danke sehr, das ist natürlich schöner und gefällt mir auch viel besser.

lg Harald

[Ralf9]

kann sich mal jemand in der "00_HM485_LAN.pm" die KeepAlive Geschichte anschauen. Da mir aufgefallen ist, daß es nicht funktioniert, habe ich es mir mal angeschaut. Dabei ist mir aufgefallen, daß "$hash->{keepalive}{ok}" nirgends auf "0" gesetzt wird.

Wenn ich in der "sub HM485_LAN_KeepAlive($)" bei "$hash->{keepalive}{ok} = 1;" aus der 1 eine 0 mache, funktioniert es.
Es passt aber noch nicht ganz. Wenn ich vom LAN-Gateway das LAN abziehe zählt zwar der "keepalive retry" von 0 auf 3 hoch, dies aber innerhalb von 3 Sekunden. Es sollte aber genauso wie beim keepAlive ein Abstand von 20 Sekunden sein.

Code Auswählen Erweitern

2015.08.17 17:21:49 3: SW: fd024d4b
2015.08.17 17:21:49 3: HM485_LAN: RX: fd024d6100
2015.08.17 17:22:09 3: SW: fd024e4b
2015.08.17 17:22:09 3: HM485_LAN: RX: fd024e6100
2015.08.17 17:22:29 3: SW: fd024f4b
2015.08.17 17:22:30 3: HM485_LAN: KeepAliveCheckRetry 0
2015.08.17 17:22:30 3: HM485_LAN: keepalive retry = 0
2015.08.17 17:22:30 3: SW: fd02504b
2015.08.17 17:22:31 3: HM485_LAN: KeepAliveCheckRetry 1
2015.08.17 17:22:31 3: HM485_LAN: keepalive retry = 1
2015.08.17 17:22:31 3: SW: fd02514b
2015.08.17 17:22:32 3: HM485_LAN: KeepAliveCheckRetry 2
2015.08.17 17:22:32 3: HM485_LAN: keepalive retry = 2
2015.08.17 17:22:32 3: SW: fd02524b
2015.08.17 17:22:33 3: HM485_LAN: KeepAliveCheckRetry 3
2015.08.17 17:22:33 3: HM485_LAN: keepalive retry count reached. Disonnect
2015.08.17 17:22:33 1: 192.168.0.94:1000 disconnected, waiting to reappear (HM485_LAN)

Gruß Ralf

[Ralf9]

Ich habe zusätzlich noch in der "sub HM485_LAN_KeepAlive($)" folgendes geändert. Nun müsste das keepalive funktionieren.

Code Auswählen Erweitern

# start timeout for next keepalive check
InternalTimer(
gettimeofday() + KEEPALIVE_TIMEOUT ,'HM485_LAN_KeepAlive', KEEPALIVE_TIMER . $name, 1
);

Code Auswählen Erweitern

2015.08.18 19:48:05 3: HM485_LAN: TX: fd024e4b
2015.08.18 19:48:05 3: HM485_LAN: RX: fd024e6100
2015.08.18 19:48:25 3: HM485_LAN: TX: fd024f4b
2015.08.18 19:48:25 3: HM485_LAN: RX: fd024f6100
2015.08.18 19:48:45 3: HM485_LAN: TX: fd02504b
2015.08.18 19:48:45 3: HM485_LAN: RX: fd02506100
2015.08.18 19:49:05 3: HM485_LAN: TX: fd02514b
2015.08.18 19:49:06 3: HM485_LAN: KeepAliveCheckRetry 0
2015.08.18 19:49:06 3: HM485_LAN: keepalive retry = 0
2015.08.18 19:49:26 3: HM485_LAN: TX: fd02524b
2015.08.18 19:49:27 3: HM485_LAN: KeepAliveCheckRetry 1
2015.08.18 19:49:27 3: HM485_LAN: keepalive retry = 1
2015.08.18 19:49:47 3: HM485_LAN: TX: fd02534b
2015.08.18 19:49:48 3: HM485_LAN: KeepAliveCheckRetry 2
2015.08.18 19:49:48 3: HM485_LAN: keepalive retry = 2
2015.08.18 19:50:08 3: HM485_LAN: TX: fd02544b
2015.08.18 19:50:09 3: HM485_LAN: KeepAliveCheckRetry 3
2015.08.18 19:50:09 3: HM485_LAN: keepalive retry count reached. Disonnect
2015.08.18 19:50:09 1: 192.168.0.94:1000 disconnected, waiting to reappear (HM485_LAN)
2015.08.18 19:53:24 1: 192.168.0.94:1000 reappeared (HM485_LAN)
2015.08.18 19:53:24 3: HM485_LAN: connected to device 192.168.0.94:1000


Hier sind die geänderten "sub HM485_LAN_KeepAlive($)" und "sub HM485_LAN_KeepAliveCheck($)"

Code Auswählen Erweitern

sub HM485_LAN_KeepAlive($) {
my($param) = @_;

my(undef,$name) = split(':',$param);
my $hash = $defs{$name};

my $msgCounter = $hash->{msgCounter};

$hash->{keepalive}{ok} = 0;

if ($hash->{FD}) {
HM485_LAN_Write($hash, HM485::CMD_KEEPALIVE);

# Remove timer to avoid duplicates
RemoveInternalTimer(KEEPALIVE_TIMER . $name);

# Timeout where foreign device must response keepalive commands
my $responseTime = AttrVal($name, 'respTime', 1);

# start timer to check keepalive response
InternalTimer(
gettimeofday() + $responseTime, 'HM485_LAN_KeepAliveCheck', KEEPALIVECK_TIMER . $name, 1
);

# start timeout for next keepalive check
InternalTimer(
gettimeofday() + KEEPALIVE_TIMEOUT ,'HM485_LAN_KeepAlive', KEEPALIVE_TIMER . $name, 1
);
}
}

=head2
Check keepalive response.
If keepalive response is missing, retry keepalive up to KEEPALIVE_MAXRETRY count.

@param string    name of keepalive timer
=cut
sub HM485_LAN_KeepAliveCheck($) {
my($param) = @_;

my(undef,$name) = split(':', $param);
my $hash = $defs{$name};

if (!$hash->{keepalive}{ok}) {
# we got no keepalive answer
HM485::Util::logger($name, 3, 'KeepAliveCheckRetry ' . $hash->{keepalive}{retry});
if ($hash->{keepalive}{retry} >= KEEPALIVE_MAXRETRY) {
HM485::Util::logger($name, 3, 'keepalive retry count reached. Disonnect');
# keepalive retry count reached. Disonnect.
DevIo_Disconnected($hash);
} else {
HM485::Util::logger($name, 3, 'keepalive retry = ' . $hash->{keepalive}{retry});
$hash->{keepalive}{retry} ++;

# Remove timer to avoid duplicates
RemoveInternalTimer(KEEPALIVE_TIMER . $name);

# start timeout for repeated keepalive check
InternalTimer(
gettimeofday() + KEEPALIVE_TIMEOUT, 'HM485_LAN_KeepAlive', KEEPALIVE_TIMER . $name, 1
);
}
} else {
$hash->{keepalive}{retry} = 0;
}
}


Gruß Ralf