OWX asynchron überarbeitet

sweetie-pie · 06 August 2014, 15:13:38

Heute Vormittag per fhem UPDATE gezogen:

$Id: 00_OWX_ASYNC.pm 6362 2014-08-04 21:08:27Z ntruchsess $

ntruchsess · 06 August 2014, 22:44:30

hm... grade selber noch mal getestet, mit DS2480 Busmaster tuts, mit FRM gibt's Timeout. Sorry, da muss mir irgendein Seiteneffekt reingefluscht sein - da ich am frm-spezifischen code nix geändert hatte, habe ich damit auch nicht getestet, als ich die Bussuche für DS9097 überarbeitet habe.

Ich such dann mal genauer, krieg ich schon hin

Gruß,

Norbert

ntruchsess · 06 August 2014, 23:27:37

das Timeout-problem ist jetzt gefixed in r6368. Der Fehler kam schon vor 2 Wochen mit Rev. 6289 rein, als ich die Erkennung von Disconnects/Reconnects beim OWX_SER eingebaut habe.

Gruß,

Norbert

sweetie-pie · 07 August 2014, 09:32:36

Hallo,

sorry, ich glaube das war es noch nicht, es kommt der gleiche Fehler.

Frisch ausgescheckt und getestet:

Code Auswählen

# $Id: 00_OWX_ASYNC.pm 6362 2014-08-04 21:08:27Z ntruchsess $
# $Id: 11_OWX_FRM.pm 2013-03 - ntruchsess $
# $Id: OWX_DS2480.pm 6361 2014-08-04 21:08:18Z ntruchsess $
# $Id: OWX_Executor.pm 5927 2014-05-21 21:56:37Z ntruchsess $
# $Id: OWX_FRM.pm 6368 2014-08-06 21:22:43Z ntruchsess $
# $Id: OWX_SER.pm 6368 2014-08-06 21:22:43Z ntruchsess $

Screenshot vom Device im Anhang.

Ich habe so einen China-Adapter mit USB zu Seriell Chip ( USB-id 1a86:7523 -> HL-340 Chip) und einem DS2480.
OWX läuft zwar, aber bremst das System aus wie APPTIME zeigt.

Code Auswählen

                 name             function    max  count    total  average maxDly 
tmr-OWTHERM_GetValues      HASH(0x9e2c048)   1139      6     6795  1132.50    909 HASH(OWX_28_ACAF2B040000) 
tmr-OWTHERM_GetValues      HASH(0x9e2a0f8)   1138      6     6800  1133.33   1013 HASH(OWX_28_59C72B040000) 
tmr-OWTHERM_GetValues      HASH(0x9e29eb8)   1136      6     6782  1130.33   1143 HASH(OWX_28_15AB2B040000) 
tmr-OWTHERM_GetValues      HASH(0x9e2a338)   1136      6     6784  1130.67    678 HASH(OWX_28_121A2B040000) 
tmr-OWTHERM_GetValues      HASH(0x9e2be08)   1136      6     6784  1130.67    514 HASH(OWX_28_C2D540040000) 
tmr-OWTHERM_GetValues      HASH(0x9d109a8)   1133      6     6789  1131.50      3 HASH(OWX_10_E68C26000800) 
tmr-OWTHERM_GetValues      HASH(0x9e2c288)   1133      6     6778  1129.67   1173 HASH(OWX_28_347D2B040000) 
tmr-OWTHERM_GetValues      HASH(0x9e2c4c8)   1132      6     6777  1129.50    930 HASH(OWX_28_688A41040000) 
tmr-OWTHERM_GetValues      HASH(0x9e2ee50)   1131      6     6782  1130.33    502 HASH(OWX_10_85FF2B000800) 
tmr-OWTHERM_GetValues      HASH(0x9e2c708)   1130      6     6774  1129.00    789 HASH(OWX_28_68722B040000) 
tmr-OWTHERM_GetValues      HASH(0x9e2c948)   1129      6     6770  1128.33    646 HASH(OWX_10_EB2D99010800)

ntruchsess · 07 August 2014, 10:36:08

Attribute 'buspower' steht aber nicht zufällig auf 'parasitic'?

sweetie-pie · 07 August 2014, 10:44:38

Nein, habe ich nicht gesetzt.

ntruchsess · 07 August 2014, 12:00:55

bleibt das reading 'state' der OWTHERM-devices auf 'defined' stehen?

sweetie-pie · 07 August 2014, 12:37:02

Soweit komme ich nicht...

Mein Ansatz war:

OWX_ASYNC Device anlegen
get OWio1 devices

dann kommt der Fehler "Timeout at /opt/fhem/FHEM/00_OWX_ASYNC.pm line 1059."

Testweise hatte ich auch probiert, ein bereits definiertes (und mit OWX genutztes) OWTHERM-Device auf das IODev auf OWio1 umzubiegen.
Der Erfolg war, dass fhem sich dann nach kurzer Zeit ganz weggehängt hat. Leider muss ich immer auf meinem Produktivsystem testen, deshalb kann ich das jetzt nicht nochmal nachvollziehen.

det. · 07 August 2014, 14:14:19

Hallo Norbert,
bei mir geht auch nur das Produktivsystem mit dem Stand vom 2.8.14 - auf den ich das zurückgesetzt hatte. Der RPI mit den letzten Änderungen war heute morgen nicht erreichbar, Gas und Wasser nicht geloggt etc. Da ist was passiert. Ich werde produktiv erst wieder updaten, wenn hier zu lesen ist, dass es stabil läuft und natürlich auf dem RPI mittesten.

ntruchsess · 07 August 2014, 14:24:36

Zitat von: det. am 07 August 2014, 14:14:19
bei mir geht auch nur das Produktivsystem mit dem Stand vom 2.8.14 - auf den ich das zurückgesetzt hatte.

Kannst Du das präzisieren (sprich: welche SVN-revision ist das genau)? Gibt es Fehlermeldungen im Log oder auf STDOUT/STDERR?

det. · 07 August 2014, 19:05:53

Hallo Norbert,
oh ist nicht so einfach zu erklären... # $Id: 00_OWX_ASYNC.pm 6338 2014-07-31 20:29:24Z ntruchsess $ läuft produktiv ohne Beanstandungen mit 2 DS2480b auf dem Cubie2.
nach update force heute auf dem RPI # $Id: 00_OWX_ASYNC.pm 6362 2014-08-04 21:08:27Z ntruchsess $ scheint es auch wieder zu laufen.
Da ich auf dem RPI parallel noch OWServer laufen habe, bringt das die Listbox von OWX_ASYNC offenbar durcheinander - die sehen beide wie bei OWServer aus, nur das bei OWX_ASYNC der letzte Eintrag - get devices - fehlt...
Zusätzlich hatte das update vom 5.8. noch die regexp bei FHEM2FHEM vermurkst, was mit Deinen Modulen garnichts zu tun hat. Das hat zusätzlich noch verhindert, das die OWCOUNT Werte im Produktivsystem Kurven zeichnen konnten. Wie gesagt, nicht so einfach, manchmal kommt eben mehreres Übel zusammen.
und zum Schluss - Fehlermeldungen...keine

ntruchsess · 08 August 2014, 00:10:20

das ist für mich leider nicht so ganz greifbar, bei mir reproduziert sich das nicht. Ich habe daher erst mal das TimeoutHandling dahingehend verbessert, dass jetzt nicht mehr der Task an sich, sondern jede individuelle Kommunikation Ihren eigenen Timeout bekommt, damit z.B. Bussuchen mit vielen Devices nicht wg. vorzeitigem Timeout abbrechen, sondern nur, wenn die Kommunikation tatsächlich deutlich gestört oder verzögert abläuft. Zusätzlich ist der Timeout-wert jetzt nicht mehr hartcodiert, sondern per Attribut 'timeout' am OWX_ASYNC-device konfigurierbar.

Gruß,

Norbert

ntruchsess · 08 August 2014, 00:37:48

In der Initialisierung-sequence der Devices habe ich auch noch was gefunden (und in rev 6379 behoben), das die saubere Initialisierung übersprungen hat...

Gruß,

Norbert

det. · 08 August 2014, 16:24:35

Hallo Norbert,
kurze Zwischenmeldung - vielen Dank für Deine Arbeit - Rev. 6379 macht es auf beiden Systemen und die Erkennung aller angeschlossenen Device funktioniert auch.

det. · 09 August 2014, 09:16:10

neuer Zustand heute morgen,
auf dem Cubie2 haben die Thermometer gestern 23.29 Uhr die letzten Werte geliefert, die anderen Sensoren gehen alle, im Log steht natürlich nix. Gefunden werden bei get devices alle und als present angezeigt.
Auf RPI auch mit mehreren Busmastern u.a. das Kristech Teil ist dieses Verhalten bisher nicht zu beobachten.
Ist mir klar, das eine hilfreiche Fehlerbeschreibung anders aussieht - wie soll ich testen, damit die Log ausgabe zu gebrauchen ist?

noch was aufgefallen: die Thermometer haben alle um 23.24 Uhr ein Alarm Reading - also genau 5min vor dem letzt ausgelesenen Wert - wobei bei keinem die Alarmbedingungen erfüllt waren

Fehler ist reproduzierbar, heute 10.11 Uhr FHEM Neustart - Thermometer funktionieren bis 11.11 Uhr, genau 5 min davor um 11.06 Uhr wieder ein Alarm Reading auf allen

Fix: ohne dokick und mit onread geht's