autocreate: Fhem blockiert bei angeschlossenen Device ohne define-Eintrag

Begonnen von klaus.schauer, 28 April 2019, 21:30:01

Vorheriges Thema - Nächstes Thema

klaus.schauer

# strace für die Konstellation:
- Profil ElsnerWS mit timeout 1.9 s
- Einlesen der Daten mit $answer = DevIo_SimpleReadWithTimeout($hash, $thash->{timeout} ? $thash->{timeout} : 0.5);

# Fhem-LOG:
- 2019.05.07 15:06:39 1: PERL WARNING: Use of uninitialized value $answer in pattern match (m//) at ./FHEM/98_autocreate.pm line 663.

# Ergebnis: Fhem blockiert nicht, legt aber auch kein Device an, da der Empfangsstring nicht zurückgegeben wird und ausgewertet werden kann.

# verwendete autocreate-Datei siehe Anlage

rudolfkoenig

DevIo_TimoutRead wartet solange, bis timeout lang _nichts_ gesendet wird.
DevIo_SimpleReadWithTimeout wartet entweder bis zum timeout, oder bis _etwas_ (mind 1 Byte) zurueckgeliefert wird.
Ich meine in deinem Fall muss man entweder bis zum timeout von 1.1Sekunden warten oder bis ein komplettes Telegramm angekommen ist.
Ich habe DevIo_TimeoutRead erweitert, damit es beim Emfang von bestimmten Datenmenge auch terminiert, und ElsnerWS mit einem maxLen von 32 eingebaut.
Wg. dem .* war ich beim maxLen nicht sicher, deswegen bitte ich Dich es zu kontrollieren.

klaus.schauer

#17
Mit folgenden Parametern geht's:

      timeout   => 0.9,
      maxLen    => 64,

Bei

      timeout   => 1.1,
      maxLen    => 32,

wird Datensatz nicht erkannt, da Datensatz <= 61 Byte ist. autocreate blockiert dabei aber weiterhin. Das Abbruchkriterium maxLen scheint nicht zu greifen.
Bei timeout = 1.1 müsste maxLen >= 122 sein, da in dem Zeitraum zwei Datensätze empfangen werden. Einer der beiden Datensätze kann auch unvollständig sein, falls eine Sendeperiode am Ende oder zu Beginn der Empfangsperiode liegt. Leider blockiert aber auch die Variante

      timeout   => 1.1,
      maxLen    => 128,

rudolfkoenig

0.9/64 klappt, wenn autocreate nicht gerade ein Teilpaket am Anfang erwischt. Die Wahrscheinlichkeit dafuer liegt bei 1-61*9/19200 also ca 97%.
Dass 1.1/128 blockiert, finde ich merkwuerdig, da nach 2-3 Sekunden die 128 Bytes gelesen werden sollten.
Kannst Du bitte fuer den Fall mir ein strace output schicken?

Ich habe jetzt eine neue Variante mit 1.0 und 127 eingecheckt.
Weiterhin hat DevIo_TimeoutRead einen optionalen vierten Parameter (regexp) bekommen, mit dem die Daten geprueft, und evtl. frueher als maxlen zurueckgeliefert werden.

klaus.schauer

Den Wahrscheinlichkeitswert glaube ich gerne. Die Praxis bestätigt dies. Bisher hatte ich während der ganzen Tests nur einen Fall, bei dem der Sensor nicht erkannt wurde. Andererseits liegt meine ernsthafte Beschäftigung mit statistischen Berechnungen im Studium Jahrzehnte zurück.

Mit den Parametern 1.1/128 zeigt sich jetzt ein neuer Effekt. Fhem blockiert wie bisher beim shutdown. Ziehe ich dann aber während der Blockade das Gerät von der Schnittstelle ab, löst sich die Blockade und nach dem erneuten Stecken des Gerätes wird es sofort erkannt und eingerichtet. Bisher wurde es beim Einstecken nicht eingerichtet.

2019.05.11 21:14:50 1: usb create starting
2019.05.11 21:14:50 3: Probing ZWDongle device /dev/serial0
2019.05.11 21:14:51 3: Probing CUL device /dev/ttyAMA0
2019.05.11 21:14:51 3: Probing TCM_ESP3 device /dev/ttyAMA0
2019.05.11 21:14:51 3: Probing ZWDongle device /dev/ttyAMA0
2019.05.11 21:14:51 3: Probing SIGNALDuino device /dev/ttyAMA0
2019.05.11 21:14:51 3: Probing MYSENSORS device /dev/ttyAMA0
2019.05.11 21:14:52 3: Probing ArduCounter device /dev/ttyAMA0
2019.05.11 21:14:52 3: Probing ElsnerWS device /dev/ttyAMA0
2019.05.11 21:14:53 3: Probing FRM device /dev/ttyAMA0
2019.05.11 21:14:58 3: Probing TCM_ESP3 device /dev/ttyUSB1
2019.05.11 21:14:58 3: Probing TCM_ESP2 device /dev/ttyUSB1
2019.05.11 21:14:58 3: Probing FHZ device /dev/ttyUSB1
2019.05.11 21:14:59 3: Probing TRX device /dev/ttyUSB1
2019.05.11 21:14:59 3: Probing ZWDongle device /dev/ttyUSB1
2019.05.11 21:14:59 3: Probing SIGNALDuino device /dev/ttyUSB1
2019.05.11 21:15:00 3: Probing MYSENSORS device /dev/ttyUSB1
2019.05.11 21:15:00 3: Probing ArduCounter device /dev/ttyUSB1
2019.05.11 21:15:00 3: Probing ElsnerWS device /dev/ttyUSB1
...
Aus- und einstecken des Gerätes an der seriellen Schnittstelle
...
2019.05.11 21:16:52 1: define ElsnerWS_1 ElsnerWS comtype=rs485 devicename=/dev/ttyUSB1@19200
2019.05.11 21:16:52 3: Opening ElsnerWS_1 device /dev/ttyUSB1
2019.05.11 21:16:52 3: Setting ElsnerWS_1 serial parameters to 19200,8,N,1
2019.05.11 21:16:52 3: ElsnerWS_1 device opened
2019.05.11 21:16:52 2: ElsnerWS define ElsnerWS_1 ElsnerWS
2019.05.11 21:16:52 2: ElsnerWS define FileLog_ElsnerWS_1 FileLog ./log/ElsnerWS_1-%Y.log ElsnerWS_1
2019.05.11 21:16:52 2: ElsnerWS define SVG_ElsnerWS_1 SVG FileLog_ElsnerWS_1:ElsnerWS:CURRENT
2019.05.11 21:16:52 2: ElsnerWS define SVG_ElsnerWS_1_2 SVG FileLog_ElsnerWS_1:ElsnerWS_2:CURRENT
2019.05.11 21:16:52 2: ElsnerWS define SVG_ElsnerWS_1_3 SVG FileLog_ElsnerWS_1:ElsnerWS_3:CURRENT
2019.05.11 21:16:52 1: usb create end

klaus.schauer

Zitat von: rudolfkoenig am 11 Mai 2019, 17:21:08
Weiterhin hat DevIo_TimeoutRead einen optionalen vierten Parameter (regexp) bekommen, mit dem die Daten geprueft, und evtl. frueher als maxlen zurueckgeliefert werden.
Das hilft. M. E. könnten wir damit starten. An ElsnerWS und ModbusElsnerWS stehen noch ein paar Schönheitskorrekturen an, danach würde ich die Module unmittelbar einchecken.