Disconnected und Reappeared bei DevIO

Begonnen von StefanStrobel, 04 Dezember 2016, 22:19:34

Vorheriges Thema - Nächstes Thema

StefanStrobel

Hallo Rudi,

In https://forum.fhem.de/index.php/topic,54771.0.html stören sich Anwender an den Disconnected- / Reappeared-Meldungen, da Ihre Geräte die Modbus-TCP-Verbindungen nach einer gewissen Zeit schließen. Das scheint bei Modbus-TCP-Geräten nicht unüblich zu sein.
Da das Modbus-Modul DevIO verwendet, wüsste ich nicht wie ich das abstellen kann.

Würdest Du einen Patch akzeptieren, der das Loglevel der beiden Meldungen aus dem übergebenen Hash übernimmt?
Dann könnte ich das Loglevel für diese Meldungen bei Modbus TCP z.B. auf 4 setzen.

Gruss
   Stefan

rudolfkoenig

DevIo.pm prueft ab sofort fuer diese beiden Meldungen auf $hash->{devioLoglevel}.

dev0

Spricht etwas dagegen, diese Prüfung auf den Logeintrag "Opening $name device $dev" zu erweitern?
Hintergrund: Wenn man die Verbindung nicht permanent zu einem Device aufbaut, sondern nur bei Bedarf/FHEM-Befehl, dann würde jedes Mal diese Meldung im Log erscheinen.


Index: FHEM/DevIo.pm
===================================================================
--- FHEM/DevIo.pm (revision 14937)
+++ FHEM/DevIo.pm (working copy)
@@ -262,7 +262,8 @@
   }

   $hash->{PARTIAL} = "";
-  Log3 $name, 3, ($hash->{DevioText} ? $hash->{DevioText} : "Opening").
+  my $l = $hash->{devioLoglevel};
+  Log3 $name, ($l ?$l:3), ($hash->{DevioText} ? $hash->{DevioText} : "Opening").
        " $name device $dev" if(!$reopen);

   if($dev =~ m/^UNIX:(SEQPACKET|STREAM):(.*)$/) { # FBAHA


rudolfkoenig

ZitatWenn man die Verbindung nicht permanent zu einem Device aufbaut, sondern nur bei Bedarf/FHEM-Befehl
Kannst du das bitte anders formulieren, ich habe es noch nicht verstanden.

dev0

ZitatKannst du das bitte anders formulieren,
Gerne. Ich entwickle zZ. einen FHEM Command, der Geräte (USB oder im Netz via http/telnet) steuern kann.
Wenn man nun eine (Telnet-)Verbindung zu einem Gerät öffnet (DevIo_Open), dann wird mit verbose 3 eine Logzeile geschrieben, die ich in diesem Fall als störend empfinde. Nach dem der Befehl auf dem Gerät ausgeführt wurde, wird die Verbindung wieder geschlossen (DevIo_CloseDev). Ist etwas schief gegangen, dann wird das vom Befehl/Modul gelogged.

Wenn man nun zB. 5x nacheinander ein Gerät etwas ausführen lässt, dann steht zZ. 5x im verbose 3 Log:
Opening getURL__2011_1a51_50a8_acdc__1__23 device [2011:1a51:50a8:acdc::1]:23"

Diese Logausgaben würde ich gerne per "$hash->{devioLoglevel}" unterdrücken, um bei den bestehenden Mechanismen zu bleiben, da sie in diesem Fall mMn überfüssig und eher störend sind.

Den fast aktuellen Sourcecode findest Du hier: https://github.com/ddtlabs/fhem-getURL


rudolfkoenig

Fuer sowas finde ich DevIo den falschen weg, weil DevIo von einer staendigen Verbindung ausgeht, wie bei einem CUL.

Ich schlage vor, die Verbindung mit HttpUtils_Connect aufzubauen, zunaechst synchron (d.h. ohne callback), und wenn ich mit IPv6 da fertig bin, asynchron, mit $hash->{callback}. Da kann man diese Ausgaben mit $hash->{loglevel} steuern. Falls man bei HttpUtils $hash->{noConn2} setzt, dann wird nichts mit HTTP durchgefuehrt, nur die Verbindung aufgebaut. Die anderen Parameter sind bei HttpUtils_NonblockingGet beschrieben. HttpUtils_Connect wird auch von DevIo_OpenDev verwendet, wenn man einen Callback spezifiziert.

Oder ist das Geraet manchmal via USB (seriell) angebunden?

Das ist nicht als Anweisung sondern als Diskussion zu verstehen. Ich bin auch unsicher, ob ich im FHEM-Framework nur eine Routine fuer eine Aufgabe anbieten soll, oder auch die nicht wirklich passenden Funktionen anpasse, damit man mehr Auswahl hat

dev0

ZitatIch schlage vor, die Verbindung mit HttpUtils_Connect aufzubauen
Ich verstehe noch nicht, wie ich das mit den HttpUtils umsetzen kann.

Mit DevIo bin ich folgendermaßen vorgegangen:
OpenDev -> SimpleWrite -> Antwort in ReadFn auswerten -> SimpleWrite -> Antwort in ReadFn auswerten -> ... -> CloseDev
Beispiel: mit Username/Passwort am Telnet Prompt eines Geräts anmelden, Befehle (aus der Warteschlange) nacheinander ausführen, logoff, Verbindung trennen.

Wenn ich nun die Verbindung mit HttpUtils_Connect aufbaue (incl. noConn2 und callback), dann wird sofort einmal die callbackFn aufgerufen. Mir fehlt nun das HttpUtils Äqui­va­lent zu DevIo_SimpleWrite, um Daten an das Gerät zu schicken. Was übersehe ich?

ZitatOder ist das Geraet manchmal via USB (seriell) angebunden?
Denkbar ist das schon, ein konkreten Anwendungsfall habe ich zZ. nicht.

rudolfkoenig

ZitatMir fehlt nun das HttpUtils Äqui­va­lent zu DevIo_SimpleWrite, um Daten an das Gerät zu schicken.

Es gibt zwar mehrere Alternativen, ich empfehle die Umwandlung in eine DevIo kompatible Variante mit:
      $hash->{TCPDev} = $hash->{conn};
      $hash->{FD} = $hash->{conn}->fileno();
      $selectlist{"$name.$dev"} = $hash;


Ich sehe ein, dass die Sache dadurch nicht einfacher wird, und ich bin weichgeklopft, um deinen urspruenglichen Wunsch einzubauen, wenn du das immer noch fuer sinnvoll haeltst.

dev0

Zitat von: rudolfkoenig am 25 August 2017, 11:25:11
ich bin weichgeklopft
Das hatte ich nicht vor ;)

Ich bin allerdings auch noch nicht dazu gekommen Deinen Vorschalg umzusetzten, da ich dafür einiges umbauen muss, damit es "ordentlich" ist...
Wollte nur kurz 'ne Rückmeldung geben...

KernSani

Hallo Rudi,
das Thema ist zwar schon etwas älter, aber: Bist du immer noch "weichgeklopft"? Ich würde den Vorschlag, die "Opening" message ebenfalls auf einem anderen LogLevel loggen zu können unterstützen. (Hintergrund: Ich baue im Softliq-Modul einmal pro Stunde eine Websocket Connection auf, die mir für 60 Sekunden Daten liefert) Da ist die Meldung etwas störend...
Dadurch würde sich die Realität auch dem Wiki angleichen ;-)
Danke,
Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

rudolfkoenig


KernSani

Zitat von: rudolfkoenig am 07 April 2021, 19:45:35
Habe den obigen Patch eingebaut.
Getestet und für gut befunden :-) Thanks!
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...