OWX verursacht Fhem-Freezes > 1 Sek / Attribut "asynchronous" funktioniert nicht

Begonnen von Cybers, 18 Oktober 2023, 09:59:40

Vorheriges Thema - Nächstes Thema

Cybers

Hallo,

bei mir verursacht das Abrufen der 1Wire-Sensoren über OWX, bzw OWTHERM immer einen Fhem-Freeze von einer guten Sekunde pro Sensor. Bei etwa 20 Sensoren die Regelmäßig ausgelesen werden, kommt da schon was zusammen...
Wenn ich das Attribut "asynchronous" auf "1" setzte, werden alle Temperaturen komplett falsch angezeigt. Statt 21°C steht dann da 85°C.
Die ganzen DS18B20-Sensoren sind parasitär angeschlossen.

list "1WireMaster":
Internals:
   ALARMED    10
   ASYNCHRONOUS 0
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E0-if00-port0
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE003E0-if00-port0
   FD         38
   FUUID      652e8ee1-f33f-6bed-4c7c-c3bc78524c80b0bc
   INITDONE   1
   INTERFACE  DS2480
   NAME       1WireMaster
   NR         874
   PARTIAL   
   PRESENT    1
   ROM_ID     FF
   STATE      opened
   TYPE       OWX
   eventCount 1
   interval   300
   timeout    2
   DEVHASH:
     1WireMaster Busmaster
     Temperatur_Bad_Kinder 28.585A59080000.D7
     Temperatur_Esszimmer 28.AAD03A3C1401.6C
     Temperatur_Flur_DG 10.BFE935030800.AA
     Temperatur_Flur_EG_Treppe 28.FC7D58080000.71
     Temperatur_Flur_OG 28.C18758080000.CD
     Temperatur_Gaeste_WC 28.AACADD381401.FC
     Temperatur_Schlafzimmer_Bett 28.5C5358080000.77
     Temperatur_Svenja 10.9EBAC2020800.AC
     Wassertemperatur_Einlauf 28.31464F632001.15
     Wassertemperatur_Skimmer 28.B20F6B632001.C2
   DEVS:
     10.9EBAC2020800.AC
     10.BFE935030800.AA
     28.585A59080000.D7
     28.5C5358080000.77
     28.FC7D58080000.71
     28.B20F6B632001.C2
     28.AAD03A3C1401.6C
     28.AACADD381401.FC
     28.C18758080000.CD
     28.31464F632001.15
   READINGS:
     2023-10-17 15:40:49   queue           0
     2023-10-17 15:40:49   state           opened
Attributes:
   asynchronous 0

list eines Temperaturfühlers:
Internals:
   ALARM      1
   DEF        DS1820 BFE935030800
   ERRCOUNT   0
   FUUID      5e708a45-f33f-e675-73c3-223123b03e44ca83
   INTERVAL   300
   IODev      1WireMaster
   NAME       Temperatur_Flur_DG
   NOTIFYDEV  global
   NR         887
   NTFY_ORDER 50-Temperatur_Flur_DG
   OW_FAMILY  10
   OW_ID      BFE935030800
   PRESENT    1
   ROM_ID     10.BFE935030800.AA
   STATE      T: 22.88 °C ↓
   TYPE       OWTHERM
   eventCount 219
   owg_temp   22.875
   owg_th     75
   owg_tl     70
   READINGS:
     2023-10-17 15:40:50   IODev           1WireMaster
     2023-10-17 15:39:43   alarm           1
     2023-10-17 15:39:40   present         1
     2023-10-18 09:46:24   state           T: 22.88 °C ↓
     2023-10-18 09:46:24   temperature     22.875
     2023-10-18 09:46:24   temperature_avg_day 22.5
     2023-10-18 09:46:24   temperature_avg_month 23.2
     2023-10-18 09:46:24   temperature_cum_day 790053.1875
     2023-10-18 09:46:24   temperature_cum_month 36843943.125
     2023-10-18 07:51:23   temperature_max_day 23.0
     2023-10-08 13:34:53   temperature_max_month 85.0
     2023-10-18 00:31:22   temperature_min_day 22.1
     2023-10-17 00:19:00   temperature_min_month 20.8
   tempf:
     factor     1
     offset     0
Attributes:
   IODev      1WireMaster
   genericDeviceType thermometer
   model      DS1820
   room       Homekit,Temperatur
   tempHigh   75
   tempLow    70

Hat jemand eine Idee woran die Freezes liegen, bzw. wie ich das Ganze "nonblocking" abrufen kann?

Gruß, Sascha
FHEM 6.2 auf Raspberry PI 4 / Smartvisu
Eltako Serie 14: FAM14, FGW14-USB, FSB14, FSR14-4x, FSR14-2x, FDG14, FTS14-EM in Kombination mit Jung F50 24V Tastern
1-Wire Temperatursensoren
aus alter Zeit:
Gott sei Dank nur noch 3 Homematic Jalousie- & Schaltaktoren! Wer sich mit Funk auskennt, legt Kabel

Prof. Dr. Peter Henning

Erst einmal sind das keine "Freezes". Sondern FHEM wartet schön brav auf die Rückmeldung vom Sensor. Wenn der Sensor nicht richtig angeschlossen ist ("alle parasitär") und die Verkabelung nicht den Richtlinien des Herstellers entspricht, kann das durchaus dauern...

Also bitte erst ordentlich anschließen, dann "asynchronous=1" setzen. Und dann reden wir gerne weiter.

LG

pah

JuanPCarter

Die Verwendung von OWX mit FHEM führt zu einer Verzögerung von mehr als 1 Sekunde beim Lesen von Daten von 1Wire-Sensoren, insbesondere wenn die Eigenschaft ,,asynchron" gesetzt ist.
Einige Benutzer empfehlen, die Sensoranschlüsse erneut zu überprüfen, um sicherzustellen, dass sie korrekt sind, bevor diese Eigenschaft geändert wird.

Prof. Dr. Peter Henning

#3
Das ist großer Unsinn. >:(

Erstens kommen die Verzögerungen zu Stande, wenn das Attribut asychnchron NICHT gesetzt ist. Das liegt am 1-Wire-Protokoll, denn die Sensoren benötigen etwa eine Sekunde bis zur vollständigen Antwort.

Zweitens gibt es im asynchronen Betrieb keine Verzögerungen.

Und drittens haben Verzögerungen beim 1-Wire Betrieb fast nichts mit der "Korrektheit der Anschlüsse" zu tun. Auch dass "einige Benutzer" die Überprüfung empfehlen würden, ist schlicht die Unwahrheit. So etwas brauchen wir hier nicht - möglicherweise ein Bot?

pah

Beta-User

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Dr. Boris Neubert

Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!