OWX asynchron überarbeitet

[Prof. Dr. Peter Henning]

Gut, also wieder herausziehen.

LG

pah

[ext23]

Guten Morgen,

ich habe vor zwei Tagen auch von OWX auf OWX-ASYNC umgestellt. Ich habe das Empfinden, dass die GUI ein wenig flotter reagiert, aber so 100% sicher bin ich mir nicht. Ansonsten merke ich bei meiner Konstellation von MP00202 und 3x iButtonID sowie LCD kein wirklichen Unterschid. Sprich es funktioniert alles wie es soll. Einzig das AppTime sieht etwas anders aus. Vorher hatte ich immer ein maxDly von 3500 pro iButton jetzt ist es immer 0, finde ich auch etwas komisch aber nunja.

Code Auswählen Erweitern

                                name             function    max  count    total  average maxDly
                       RPi_RFXTRX433      FHEM2FHEM_Ready  31064 1196429    34065     0.03      0 HASH(RPi_RFXTRX433)
                             MP00202       OWX_ASYNC_Read   5463 1639414 11607913     7.08      0 HASH(MP00202)
            Notify_Schluessel_Daniel          notify_Exec   5462     11    19193  1744.82      0 HASH(Notify_Schluessel_Daniel); HASH(fl_iButton_blau)
                          az_OW_LCD1            OWLCD_Get   5445     30    43480  1449.33      0 HASH(az_OW_LCD1); az_OW_LCD1; gpio
                             RPi_CUL       FHEM2FHEM_Read   5002   4424    17018     3.85      0 HASH(RPi_CUL)
                       RPi_RFXTRX433       FHEM2FHEM_Read   5002   4423    12242     2.77      0 HASH(RPi_RFXTRX433)
                                 WEB              FW_Read   4018    343    29170    85.04      0 HASH(WEB)
             Notify_Schluessel_Anett          notify_Exec   3349      9    12172  1352.44      0 HASH(Notify_Schluessel_Anett); HASH(fl_iButton_gelb)
                           AVRNETIO2           ECMD_Ready   3003 1933177548  7948228     0.00      0 HASH(AVRNETIO2)
                              HMLAN1          HMLAN_Ready   3001 628626     3006     0.00      0 HASH(HMLAN1)
                             RPi_CUL      FHEM2FHEM_Ready   1262 544688     1264     0.00      0 HASH(RPi_CUL)
                              HMLAN1           HMLAN_Read   1155  16028    78571     4.90      0 HASH(HMLAN1)
                    Fester_Alarm_Bad          notify_Exec   1139     32    12855   401.72      0 HASH(Fester_Alarm_Bad); HASH(bz_Fenster)
                                CUL1             CUL_Read    922   1258     4538     3.61      0 HASH(CUL1)
   Notify_FS20_FB_02_Kanal_10_toggle          notify_Exec    918      2     1835   917.50      0 HASH(Notify_FS20_FB_02_Kanal_10_toggle); HASH(FS20_FB_02_Kanal10)
                          az_SISPM_4          SIS_PMS_Set    914     36     4209   116.92      0 HASH(az_SISPM_4); az_SISPM_4; toggle
             FB_FS20_01_Taste_02_off          notify_Exec    789      2     1577   788.50      0 HASH(FB_FS20_01_Taste_02_off); HASH(Fernbedienung01_Taste02)
                         tmr-at_Exec     HASH(0x299167f0)    556      1      556   556.00    108 HASH(Alarm_PushMessage_OpenDoor_Eingang_SGS2)
                            PushSGS2     PushNotifier_Set    546      4     1058   264.50      0 HASH(PushSGS2); PushSGS2; message; Türalarm!
                         tmr-at_Exec     HASH(0x293ce668)    526      1      526   526.00      0 HASH(Alarm_PushMessage_OpenDoor_Eingang_SGS2)
                         tmr-at_Exec     HASH(0x2ecb22b8)    398      1      398   398.00    515 HASH(Alarm_PushMessage_OpenDoor_Eingang_OPO)

Gruß
Daniel

[Scotty80]

Hallo,

nachdem ich auf meiner Test-Station problemlos mehrere Temperatursensoren mit OXY_ASYNC zum Laufen bekommen habe, mag es mir nun in der "Praxis" nicht so recht gelingen.
Folgende Situation:
Zwei 1-W-Busse mit jeweils einem E-Service-Ethernet-Adapter.
Mit:
define 1WireEG OWX_ASYNC 192.168.2.221:23 bzw. define 1WireOG OWX_ASYNC 192.168.2.220:8888
in Fhem definiert - dies funktionierte auf diese Art und Weise in der Test-Version einwandfrei.
Nach einem "get devices" kommt folgende Fehlermeldung:
015.05.14 21:47:15 5: OWX_ASYNC_Schedule master: 1WireEG, task: 1WireEG
2015.05.14 21:47:16 5: SW: e3c5
2015.05.14 21:47:16 5: SW: e1f0e3b5
2015.05.14 21:47:16 5: SW: e100000000000000000000000000000000e3a5
2015.05.14 21:47:16 5: OWX_DS2480 read: After loop no. 2 received: cff0ffffffffffffffffffffffffffffffff
2015.05.14 21:47:16 1: OWX_SER::Search CRC failed : FF.FFFFFFFFFFFF.FF
2015.05.14 21:47:16 4: OWX_ASYNC_PT_Kick: Failure in search: OWX_SER::Search CRC failed : FF.FFFFFFFFFFFF.FF at /opt/fhem/FHEM/OWX_SER.pm line 390.

2015.05.14 21:47:16 5: OWX_ASYNC_RunTasks: 1WireEG task finished


Hat jemand eine Idee, wo das Problem liegt?

Gruß Scotty

[det.]

Hallo Scotty,
Beschreib doch mal die Unterschiede zwischen Testsystem und Praxis - andere (schnellere?) Hardware eventuell eingesetzt? Bei mir funktionierte die asynchrone Version auf RPI perfekt, auf Cubie2 und CubieTruck überhaupt nicht. Bin schon lange wieder bei der Version OWX und habe zeitkritische Sachen einfach auf einem zweiten Server laufen.

[Prof. Dr. Peter Henning]

Schaut bitte auch die Alpha-Versionen für das neue Backend an, sind hier zu finden: http://forum.fhem.de/index.php/topic,37122.0.html.

LG

pah

[Scotty80]

Hallo Scotty,
Beschreib doch mal die Unterschiede zwischen Testsystem und Praxis - andere (schnellere?) Hardware eventuell eingesetzt? Bei mir funktionierte die asynchrone Version auf RPI perfekt, auf Cubie2 und CubieTruck überhaupt nicht. Bin schon lange wieder bei der Version OWX und habe zeitkritische Sachen einfach auf einem zweiten Server laufen.

Der einzige Unterschied besteht darin, dass in der Praxisvariante deutlich mehr Temperatursensoren (DS18B20) vorhanden sind, ca. 10 Stück pro Bus. Perfekte Lineare Topologie. Ansonsten alles gleich zur Testvariante. Die Ethernet-Adapter funktionieren, sind ebenfalls getestet.
Das bringt mich der Vermutung nahe, dass der Elektriker die Kabel falsch zugeordnet hat.
Nun die Frage: Gibt es eine Möglichkeit, die 3 Adern des 1-Wire-Busses z.B. anhand der Widerstände zueinander zu identifizieren? Oder auch anders formuliert: Man hat 3 Drähte und weiß jedoch nicht, welcher welcher ist. Wie finde ich es heraus? (Natürlich ist gemeint, ohne die einzelnen Sensoren wieder auszugraben)

Gruß Scotty

Sooo... war ein Verdrahtungsfehler. Fehler beseitigt, nun funktioniert alles prima.
Trotzdem würde mich interessieren, welche Widerstände zwischen den einzelnen Adern eines DS18B20 existieren.