OWTHERM blockiert FHEM

[Joachim]

Moin dan1180,
das sieht doch genial aus. Schlechteste Verzögerung 100ms. Damit kann man herorragend leben.
Wie sieht es mit der Systemlast des pi aus, Vergleich 1x FHEM gegen 2x FHEM?
Ic glaube, ich kann diese Variante dann so bedenkenlos weiterenpfehlen.

Gruß Joachim

[dan1180]

Hallo Joachim,

ja ich bin auch sehr zufrieden. Wie kann ich dir die Systemlast zeigen? Gibts da auch ne Art log?

Gruß Daniel

[dan1180]

Neues apptime. Etwas schlechter aber ich denke immer noch gut oder?

Code Auswählen Erweitern



                                name             function    max  count    total  average maxDly
                              HMLAN1           HMLAN_Read    579   2665    96593    36.25      0 HASH(0x10677a8)
                                 F2F       FHEM2FHEM_Read    259    982    50500    51.43      0 HASH(0xf0ea30)
                      tmr-PID20_Calc           PID_HKS_BD    175    356     6860    19.27     45 PID_HKS_BD
                            V_HKS_BD           CUL_HM_Set    114     27     1230    45.56      0 HASH(0x10e5d28); V_HKS_BD; valvePos; 28
                   tmr-CUL_HM_procQs        CUL_HM_procQs    110      1      110   110.00      3 CUL_HM_procQs
                              HMLAN1          HMLAN_Ready     95      3      264    88.00      0 HASH(0x10677a8)
             tmr-CUL_HM_respPendTout      respPend:100001     83     36     2315    64.31      5 respPend:100001
                      WTS_BD_Climate           CUL_HM_Set     80     13      230    17.69      0 HASH(0x10bd4e8); WTS_BD_Climate; desired-temp; 20.0
             tmr-CUL_HM_respPendTout      respPend:254AEA     78      4      106    26.50      4 respPend:254AEA
                 tmr-CUL_HM_ActCheck       ActionDetector     75     36     1042    28.94      4 ActionDetector
            tmr-HMLAN_KeepAliveCheck   keepAliveCk:HMLAN1     72    867      266     0.31     85 keepAliveCk:HMLAN1
                            N_WTS_BD          notify_Exec     54    145     5278    36.40      0 HASH(0x107abc0); HASH(0x10bd4e8)
             tmr-CUL_HM_valvePosUpdt    valvePos:10000101     53    141     3777    26.79      5 valvePos:10000101
                            C_SSP_OO    cloneDummy_Notify     47     71     2301    32.41      0 HASH(0x10dfc40); HASH(0x736088)
                            C_KOL_RL    cloneDummy_Notify     44    158     4805    30.41      0 HASH(0x1075da8); HASH(0x12ceb90)
              tmr-CUL_HM_valvePosTmr    valveTmr:10000101     43    141      930     6.60     52 valveTmr:10000101
                            C_OBK_RL    cloneDummy_Notify     40     34     1035    30.44      0 HASH(0xf016a0); HASH(0x13a5208)
                            C_OBK_VL    cloneDummy_Notify     40     48     1661    34.60      0 HASH(0x12fc560); HASH(0x12f8390)
                            C_FBH_RL    cloneDummy_Notify     38     29      800    27.59      0 HASH(0x10ef490); HASH(0x13a51f0)
                          PID_HKS_BD            PID20_Set     38    175     2925    16.71      0 HASH(0x10e62f8); PID_HKS_BD; desired; 21.5
                            C_KOL_VL    cloneDummy_Notify     36     70     1938    27.69      0 HASH(0xf27c58); HASH(0x1334c90)



[Joachim]

Systemlast anzeigen, ohne FHEM zu bremsen:
http://rpi-experiences.blogspot.de/p/rpi-monitor.html

Apptime immer noch super.

Gruß Joachim

[dan1180]

So, hab nun RPI Monitor laufen. Lass jetzt mal ne Weile aufzeichnen und poste dir dann das Ergebnis. Was möchtest du sehen? Grafik CPU Last? Brauchst du dann auch das Logfile um zu sehen ob ein peak mit fhem zu tun hat?

Danke nochmal, Dan

[dan1180]

Hallo Joachim,

im Anhang der erste Graph des RPI Monitors. Kann es sein, dass durch die Aufzeichnung mein RPI spinnt? Ich hab teilweise wieder sehr lange Wartezeiten und heute Nacht um 4 ist mein ganzes System zusammengebrochen.
Mein schlechtestes apptime aus 15 Min. wiederholender Eingabe (Womit ich ganz zufrieden bin):

Code Auswählen Erweitern

                                name             function    max  count    total  average maxDly
         FHEMWEB:192.168.2.103:49386              FW_Read    365     12      433    36.08      0 HASH(0x1c54410)
                              HMLAN1           HMLAN_Read    103     11      445    40.45      0 HASH(0x1388978)
                                 F2F       FHEM2FHEM_Read     79      5      312    62.40      0 HASH(0x1929268)
             tmr-CUL_HM_respPendTout      respPend:100001     58      1       58    58.00      2 respPend:100001
             tmr-CUL_HM_valvePosUpdt    valvePos:10000101     55      1       55    55.00      3 valvePos:10000101
                      tmr-PID20_Calc           PID_HKS_BD     50      1       50    50.00      3 PID_HKS_BD
                            N_WTS_BD          notify_Exec     34      1       34    34.00      0 HASH(0x1962cc8); HASH(0x1826978)
                            C_KOL_RL    cloneDummy_Notify     33      1       33    33.00      0 HASH(0x1939a40); HASH(0x1c0a7b0)
                            C_KOL_VL    cloneDummy_Notify     32      1       32    32.00      0 HASH(0x1939968); HASH(0x1c6d908)
                            C_SSP_MM    cloneDummy_Notify     29      1       29    29.00      0 HASH(0x1938f70); HASH(0x1c473a0)
                            C_OBK_RL    cloneDummy_Notify     27      1       27    27.00      0 HASH(0x193a130); HASH(0x1a17150)
                            C_FBH_RL    cloneDummy_Notify     26      1       26    26.00      0 HASH(0x1937f60); HASH(0x1c29698)
                          PID_HKS_BD            PID20_Set     19      1       19    19.00      0 HASH(0x194f848); PID_HKS_BD; desired; 20.0
                          eventTypes    eventTypes_Notify     12     24      104     4.33      0 HASH(0x1383e98); HASH(0x18264e0)
         FHEMWEB:192.168.2.103:49384              FW_Read     10     17       89     5.24      0 HASH(0x1c297b8)
         FHEMWEB:192.168.2.103:49388              FW_Read     10      4       27     6.75      0 HASH(0x1c295f0)
         FHEMWEB:192.168.2.103:49387              FW_Read      8      5       29     5.80      0 HASH(0x1c09ec8)
                             SSP_LOG          FileLog_Log      7     24       62     2.58      0 HASH(0x184af08); HASH(0x1c0a7b0)
                 tmr-HMLAN_KeepAlive     keepAlive:HMLAN1      7      3       18     6.00      3 keepAlive:HMLAN1
         FHEMWEB:192.168.2.103:49389              FW_Read      5      2       10     5.00      0 HASH(0x1c11ef0)
                                 WEB              FW_Read      5      9       33     3.67      0 HASH(0x11926c8)

Laut Logfile wurde fhem um 4:30 neu gestartet und die Systemzeit wurde um 13 Min zurückgestellt. Das hatte ich (anscheinend) schon öfter, da ich ständig um eben diese 13 Min. meine Systemuhr neu stellen muss. Hab mir deshalb auch schon einen Abgleich mit der Atomuhr in Braunschweig in mein rc.local geschriedeb. Der wird allerdings nur bei einem Reboot gemacht.

Log vom Neustart bis sich das System aufgehängt hat im Anhang (Log/graph).

Das Selbe heute Nacht (05.05., ca. 1:30Uhr) wieder (Log2/graph2). Allerdings über 20Min Zeitverschiebung.

Beide Male finden sich vor dem crash sehr Ähnliche Einträge

Code Auswählen Erweitern

2014.05.04 04:30:05.642 5: HMLAN_Parse: HMLAN1 R:E261CBA   stat:0000 t:02255705 d:FF r:FFB2     m:21 8470 261CBA 000000 009235
2014.05.04 04:30:05.644 5: HMLAN1 dispatch A0C218470261CBA000000009235::-78:HMLAN1

2014.05.05 01:38:15.693 5: HMLAN_Parse: HMLAN1 R:E262430   stat:0000 t:036A680A d:FF r:FFA3     m:23 865A 262430 000000 7CAB2F
2014.05.05 01:38:15.695 5: HMLAN1 dispatch A0C23865A2624300000007CAB2F::-93:HMLAN1

Der Unterschied ist, dass am 04.05. der WTS_KU, am 05.05. der WTS_FL abgefragt wurde?!

[Joachim]

Moin dan1180,

Bei mir rennt der RPI Monitor seit Monaten ohne Probleme, und deutlich Performance schonender wie z.B. Sysmon. Ich kann das Problem also so nicht nachvollziehen.
Zum Thema Systemzeit schau Dir mal Diesen Tread an:
http://www.forum-raspberrypi.de/Thread-tutorial-aktuelle-uhrzeit-mit-braunschweig-abgleichen
Die Lösung von meigrafd gefällt mir recht gut.
Dafür, dass Dein Pi in der Wüste landet, kann es 1001 Gründe geben, und da Du noch an diversen anderen Stellen am basteln bist, kommen noch einmal 1001 Gründe dazu. Allerdings hat Dein Pi wenn er abgestürztist immer sehr lange gestanden. 4.5 von ca 4:30 - 9:45, 5.5 von ca. 1:45 - 8:45.
Ich würde ersteinmal versuchen das System stabil zu bekommen, und dann Stück für Stück zu erweitern. Damit kann man den Fehler am besten einkreisen.

Gruß Joachim

[dan1180]

Hallo Joachim,

diesesmal bist du es der schlampig gelesen hat 

Den Abgleich mit der Atomuhr mach ich schon. Allerdings greift der ja nur bei einem Reboot des RPi. Wenn sich meine Systemzeit aber auf einmal verändert bringt mir das auch nichts.

...und da Du noch an diversen anderen Stellen am basteln bist, kommen noch einmal 1001 Gründe dazu.

Das ist es ja was mich wundert...ich war fertig mit basteln.Soll heißen ich hab bis zur Installation von RPI Monitor fast ne Woche nichts mehr verändert und hatte die Probleme nicht?

Allerdings hat Dein Pi wenn er abgestürztist immer sehr lange gestanden

Na logisch.Wenn der um 1:30Uhr in die Knie geht bekomm ich das leider erst mit wenn ich nach dem Frühstück nachschau wie es in meinem Kessel ausschaut...

Aber wenn du denkst, dass das nicht am Monitoring liegt und in meinen Logfiles auch nichts verdächtiges steht dann gehört das wohl in ein anderes Forum...

Eine Frage noch: Was sagst du zur Systemauslastung?

[Joachim]

Moin dan1180,

diesesmal bist du es der schlampig gelesen hat

nicht wirklich, da die von mir vorgeschlagene Variante alle 2 Stunden einen Zeitabgleich macht, und nicht nur beim Systemstart.

Sinnvoller wäre das über crontab des root Benutzers zu regeln:

Falls ihr als " pi " angemeldet seid, führt ihr bitte den Befehl sudo crontab -e aus
Wenn ihr direkt als " root " angemeldet seid, führt ihr bitte den Befehl crontab -e aus

Und tragt dort folgende Zeilen ein:
Code: Alles markieren
@reboot        ntpdate -s 0.pool.ntp.org
0 */2 * * *    ntpdate -s 0.pool.ntp.org
(-s steht für silent, wenn ihr also den Befehl über die Konsole testen wollt dann lasst -s weg)

Damit würde ein mal bei System Start und alle 2 Stunden ein Zeitabgleich gemacht werden

Wenn die Abstürze erst mit der Installation des RPI-Monitors aufgetreten sind, dann entferne ihn und beobachte, ob das System wieder stabil ist!
Bei mir rennt der RPI-Monitor seit Monaten sauber und fehlerfrei, es kann natürlich sein, dass das bei Dir nicht so ist, deshalb ausprobieren.
Die Systemlast sieht für 2 FHEM-Installationen gut aus, Vereinfacht gesagt hast Du ca. 25% Systemlast, da ist also noch viel Luft nach oben.

Gruß Joachim

[dan1180]

Hallo Joachim,

mein System läuft nun seit dieser Woche stabil durch. Seit dem zweiten crash passt alles (vielleicht Startschwierigkeiten?).

nicht wirklich, da die von mir vorgeschlagene Variante alle 2 Stunden einen Zeitabgleich macht, und nicht nur beim Systemstart.

Dann will ich mich hier in aller Form entschuldigen  Trotzdem würde mich die Ursache dafür interessieren, da die verstellte Uhr auch ohne Systemcrash schon ab und an vorkam...

Also wenn meine apptimes und meine Systemlast gut sind dann kann ich diesen Beitrag, denke ich , als geslöst markieren und schließen?! 

[Joachim]

Moin dan1180,
ich glaube auch, dass Du dieses Thema: OWTHERM blockiert FHEM
auf gelöst setzen kannst.

Gruß Joachim

[dan1180]

Und wieder ist ein Problem gelöst. Um mein fhem wieder salonfähig zu machen und vor allem um die HM Komponenten nicht auszubremsen habe ich meine OWX Komponenten, genauer gesagt meine 1wire Sensoren, wie von Joachim empfohlen in eine zweite fhem-Instanz ausgelagert. Seit dem rennt mein fhem wie ein junger Hund und aussteigende HM Komponenten gehören der Vergangenheit an.
Eine kleine Beschreibung wie das funktioniert findet ihr ab Antwort #66.

Vielen Dank an alle, die mir mit prouktioven Antworten versucht haben zu helfen und vor allem (mal wieder) an Joachim für die Lösung.

Bis bald (soll keine Drohung sein  )

Daniel