Alle Sensoren sprodisch auf "dead"

[Andreas74]

Hallo zusammen,

ich hab 'nen RasPi mit ner Busware COC Karte. Das Wheezy Image kommt von Busware.

So weit so gut, alles läuft super, nur einmal am Tag gehen plötzlich alle Sensoren zur gleichen Zeit auf "dead". Mache ich nix, kommen die Sensoren nach 2 - 3 Stunden zurück. Alternative ist der Restart des FHEM Servers (nur die Applikation, nicht der ganze RasPi). Ich hab mir da schon ein Script geschrieben, dass alle 10 Minuten nachschaut und bei Bedarf ein /etc/init.d/fhem stop | start macht.

Die Sensoren senden in dieser Zeit keine Daten.

Woran kann das liegen?


Viele Grüße aus Wien


Andreas

[rudolfkoenig]

Was fuer Sensoren?

[Andreas74]

Hi,

also das wäre mal alle :

drei Temparatursensoren HM_WDS40_TH, zwei Türkontakte HM_SEC_SC und zwei Bewegungsmelder HM_SEC_MDIR.

Danke

Andreas

[rudolfkoenig]

Aah. Thread verschoben.

[martinp876]

Hallo Andreas,

das dead kommt vom actionDetector - und ist auch dort zu sehen?

der actiondetector erwartet, dass sich das device zyklisch meldet - siehe Attr actCycle zur erwarteten Zeitspanne.
die Devices sollten dies automatisch tun - man kann es bei einigen steuern - siehe Register
cyclicInfoMsg

Gruss Martin

[Andreas74]

Hallo Martin,


das sieht ungefähr so aus (ActionDetector Log):

2013-12-14_09:55:01 ActionDetector status_Bewegungsmelder1: dead
2013-12-14_09:55:01 ActionDetector alive:4 dead:1 unkn:0 off:0
2013-12-14_10:05:01 ActionDetector status_Schlafzimmer: dead
2013-12-14_10:05:01 ActionDetector status_Kinderzimmer: dead
2013-12-14_10:05:01 ActionDetector status_Wohnzimmer: dead
2013-12-14_10:05:01 ActionDetector alive:1 dead:4 unkn:0 off:0


Der Status des Sensors zur selben Zeit (so sehen halt alle Sensoren zur gleichen Zeit aus):


2013-12-14_09:47:27 Kinderzimmer T: 22.5 H: 53
2013-12-14_10:05:01 Kinderzimmer Activity: dead
2013-12-14_12:05:51 Kinderzimmer temperature: 23.0
2013-12-14_12:05:51 Kinderzimmer humidity: 49
2013-12-14_12:05:51 Kinderzimmer T: 23.0 H: 49


Heute war bisher gar nix.

Ich sehe mir mal die register an.

Verstehe ich das aber richtig, dass der Action Detector selbst gar nichts auf "dead" setzt und die weitere Einlieferung von Daten damit verhindert, sondern nur den Status quasi anzeigt?


Viele Grüße aus Wien

Andreas

[martinp876]

Hallo Andreas,

am schnellsten bekommst du die Parameter mit

Code Auswählen Erweitern

define hm HMinfo
set hm param -d actStatus actCycle R-cyclicInfoMsg  autoReadReg
list ActionDetector


Gruss Martin

[tpm88]

Hallo Andreas, Martin,

ich beobachte seit kurzem bei mir das gleiche Verhalten. Exakt zum gleichen Zeitpunkt "verschwinden" meine drei RTs, vom ActionDetector werden sie als dead gemeldet. Einige Zeit später (Minuten/Stunden) erscheinen alle zum gleichen Zeitpunkt wieder.

Heute z.B.:

Code Auswählen Erweitern


2013-12-16_13:45:27 ActionDetector alive:3 dead:0 unkn:0 off:0
2013-12-17_23:15:32 ActionDetector status_dg_Thermostat: dead
2013-12-17_23:15:32 ActionDetector status_az_Thermostat: dead
2013-12-17_23:15:32 ActionDetector status_wz_Thermostat: dead
2013-12-17_23:15:32 ActionDetector alive:0 dead:3 unkn:0 off:0
2013-12-17_23:45:33 ActionDetector status_dg_Thermostat: alive
2013-12-17_23:45:33 ActionDetector status_az_Thermostat: alive
2013-12-17_23:45:33 ActionDetector status_wz_Thermostat: alive
2013-12-17_23:45:33 ActionDetector alive:3 dead:0 unkn:0 off:0
2013-12-18_06:55:34 ActionDetector status_dg_Thermostat: dead
2013-12-18_06:55:34 ActionDetector status_az_Thermostat: dead
2013-12-18_06:55:34 ActionDetector status_wz_Thermostat: dead
2013-12-18_06:55:34 ActionDetector alive:0 dead:3 unkn:0 off:0
2013-12-18_12:05:35 ActionDetector status_dg_Thermostat: alive
2013-12-18_12:05:35 ActionDetector status_az_Thermostat: alive
2013-12-18_12:05:35 ActionDetector status_wz_Thermostat: alive
2013-12-18_12:05:35 ActionDetector alive:3 dead:0 unkn:0 off:0


Bei mir läuft FHEM auf der FB7390 - die HM Devices werden alle von einem CUL angesteuert.

Hier die Parameter:

Code Auswählen Erweitern


set hm param -d actStatus actCycle R-cyclicInfoMsg  autoReadReg
param done:
param list
    entity              : actStatus            |actCycle              |R-cyclicInfoMsg      |autoReadReg          |
    az_Thermostat        : alive          |000:10          |on              |4_reqStatus   
    az_podFS1010        :  -              | -              | -              |4_reqStatus   
    dg_Thermostat        : alive          |000:10          |on              |4_reqStatus   
    ke_Pumpe            :  -              | -              | -              |4_reqStatus   
    ke_Switch4          :  -              | -              | -              |4_reqStatus   
    ku_Switch1          :  -              | -              | -              |4_reqStatus   
    wz_Markise          :  -              | -              | -              |4_reqStatus   
    wz_Thermostat        : alive          |000:10          |on              |4_reqStatus   

list ActionDetector



Internals:
   CHANGED   
   DEF        000000
   IODev      CUL_HM
   NAME       ActionDetector
   NR         89
   STATE      alive:3 dead:0 unkn:0 off:0
   TYPE       CUL_HM
   Readings:
     2013-12-18 23:45:36   state           alive:3 dead:0 unkn:0 off:0
     2013-12-18 23:45:36   status_az_Thermostat alive
     2013-12-18 23:45:36   status_dg_Thermostat alive
     2013-12-18 23:45:36   status_wz_Thermostat alive
   Helper:
     actCycle   600
     peers      21DC30,21DE95,21F220
     rxType     1
     21dc30:
       recent     2013-12-18 23:45:13
       start      2013-12-16 13:35:27
     21de95:
       recent     2013-12-18 23:44:49
       start      2013-12-16 13:35:26
     21f220:
       recent     2013-12-18 23:45:20
       start      2013-12-16 13:35:27
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf   
       qReqStat   
     Role:
       vrt        1
     Shadowreg:
Attributes:
   actCycle   600
   event-on-change-reading .*
   room       Unsorted


In den übrigen Logs finde ich keinerlei Anhaltspunkte oder Einträge, die zu den Zeitpunkten "Verschwinden" bzw. "Wiederauftauchen" passen würden.

Ratlos,
Tobias

[martinp876]

Hi Thomas,

der ActionDetector selbst prüft regelmäßig den Zustand der angemeldeten Devices. Die Periode ist attribut
ActionDetector -> actCycle
festgelegt - default ist 600 = 10 min.

Daher kommen alle Meldungen gleichzeitig.

Die eigentliche Prüfung ist, dass der Delinquent sich in der vereinbarten Periode gemeldet haben muss - irgend etwas sollte FHEM von ihm empfangen haben.
Die erlaubte Periode steht in Device
attr <dev> actCycle ...
bei deinen Devices ist es 10 min

Da es sich im Thermostate handelt sollten sich diese alle 2,5 min melden - also 3-4 mal in 10 min.

ActionDetector behauptet nun, dass
17ter 23:15:32 dg_Thermostat: dead
17ter 23:45:33 dg_Thermostat: alive
==> von 17ter 23:05 bis mindestens 23:35 keine Meldung des Thermostat

18ter 06:55:34 dg_Thermostat: dead
18ter 12:05:35 dg_Thermostat: alive
==> von 18ter 06:45 bis mindestens 11:55 keine Meldung des Thermostat

loggst du die temperaturen? Dann kannst du dies im Logfile prüfen.
Kannst du es nachvollsiehen? Oder stimmt etwas nicht?
Gruss Martin

[tpm88]

Hallo Martin,

danke für die Erklärungen - soweit alles verstanden. Ich logge die Temperaturen meiner drei RT Thermostate ganz normal jeweils in einem eigenen Logfile. Die Logfiles weisen für den "dead"-Zeitraum keine Einträge auf.

Am Beispiel des dg_Thermostat - bei den beiden anderen Thermostate sehen die Logs analog aus:

Code Auswählen Erweitern


2013-12-18_06:36:51 dg_Thermostat desired-temp: 17
2013-12-18_06:36:51 dg_Thermostat actuator: 0 %
2013-12-18_06:39:10 dg_Thermostat measured-temp: 18.4
2013-12-18_06:39:10 dg_Thermostat desired-temp: 17
2013-12-18_06:39:10 dg_Thermostat actuator: 0 %
2013-12-18_06:41:14 dg_Thermostat measured-temp: 18.3
2013-12-18_06:41:14 dg_Thermostat desired-temp: 17
2013-12-18_06:41:14 dg_Thermostat actuator: 0 %
2013-12-18_06:44:07 dg_Thermostat measured-temp: 18.2
2013-12-18_06:44:07 dg_Thermostat desired-temp: 17
2013-12-18_06:44:07 dg_Thermostat actuator: 0 %
2013-12-18_06:55:33 dg_Thermostat Activity: dead
2013-12-18_12:02:59 dg_Thermostat measured-temp: 22.8
2013-12-18_12:02:59 dg_Thermostat desired-temp: 21
2013-12-18_12:02:59 dg_Thermostat actuator: 12 %
2013-12-18_12:05:35 dg_Thermostat Activity: alive
2013-12-18_12:05:58 dg_Thermostat measured-temp: 22.8
2013-12-18_12:05:58 dg_Thermostat desired-temp: 21
2013-12-18_12:05:58 dg_Thermostat actuator: 12 %

Was ich nicht verstehe - drei unabhängige (insbesondere keine Peers) Thermostate können ja nicht gleichzeitig das Senden aufhören und wieder beginnen. Batterie- und Empfangsprobleme schliesse ich somit aus. Die RSSI-Werte für die Thermostate sind gut (avg besser -55).

Insofern müsste das Problem somit eher auf der Empfangsseite (beim FHEM-Server) liegen. Da Andreas das gleiche Verhalten auf einem RPi mit CoC sieht, ist es unwahrscheinlich, dass es bei mir an der Kombination FB7390 und CUL liegt. Die CPU-Auslastung der FB7390 ist ganz normal. Der FHEM-Server friert aber auch nicht komplett ein - die Erfassung der 1wire Temperaturwerte der Heizung (via ECMD - ok, das ist "pull") z.B. ist lückenlos.
Und ist http://forum.fhem.de/index.php/topic,17622.0.html evtl. "related" ?


Lässt sich das durch Erhöhen von LogLevels eingrenzen? Wenn ja wie und für welche Komponenten? Dummerweise tritt das Problem ja nur sporadisch auf.

Danke (wie immer) für deine Mühe
Gruss
Tobias

[martinp876]

Hallo Tobias,

das gute ist also , dass der ActionDetector korrekt arbeitet - und auch Probleme aufdeckt.

Es stellt sich die Frage, warum nichts mehr ankommt. SW-Problem ist bei SW immer möglich
Könnte auch am IO-device liegen.

Kommt zur Gegebenen Zeit irgend-etwas an? Es sind  ja immer hin 5 Stunden. Ich betreibe neben den Logs für Graphen nur ein generelles Logfile - falls du so etwas hast kannt du nachsehen, ob irgend etwas passiert ist.

Code Auswählen Erweitern

define log_all FileLog log/all_%Y.log .*
attr log_all logtype text


besser in diesem Fall ist das loggen der messages - kannst du hier selektiv machen:
Da du eine CUL hast geht es nicht selektiv - also:
attr global verbose 1
attr global mseclog 1
attr <CUL> verbose 5

Gruss Martin

[Andreas74]

Bei lief es jetzt mal drei Tage einwandfrei durch.

Gestern wieder alles zum gleichen Zeitpunkt auf "dead". Meine RSSI Werte liegen eigentlich immer < 80 auf allen Sensoren.

Es sind aber auch Sensoren betroffen, die direkt neben dem FHEM server liegen (Temparatur + Bewegungsmelder). Da ich bei mir auch das CCD von Busware einsetze, bin ich über diesen beitrag gestolpert:

http://forum.fhem.de/index.php/topic,15128.msg97877.html#msg97877

Hab irgendwie das Gefühl, dass es bei mir auch bei erhöhter Aktivität aussetzt.

Werde mal das Flashen der Firmware probieren, wobei mein CCD erst 2 Wochen alt ist..

[tpm88]

Hallo Andreas, Martin,

Kommt zur Gegebenen Zeit irgend-etwas an? ...

Zumindest während einer "dead"-Zeitspanne des Thermostats hat FHEM einmal erfolgreich via Homematic die Heizungspumpe eingeschaltet:

Code Auswählen Erweitern


2013-12-06_04:36:12 ActionDetector status_wz_Thermostat: dead
2013-12-06_04:36:12 ActionDetector alive:0 dead:1 unkn:0 off:0
2013-12-06_05:36:12 ActionDetector status_wz_Thermostat: alive

2013-12-06_05:30:00 ke_Pumpe set_on
2013-12-06_05:30:01 ke_Pumpe level: 100 %
2013-12-06_05:30:01 ke_Pumpe pct: 100
2013-12-06_05:30:01 ke_Pumpe deviceMsg: on (to CUL_HM)
2013-12-06_05:30:01 ke_Pumpe on
2013-12-06_05:30:01 ke_Pumpe timedOn: off


Vielleicht hat aber in diesem Fall gerade der Sende-Befehl von FHEM an die Pumpe und deren Antwort auch den Empfang von den Thermostaten wieder in Gang gebracht??

In meiner Umgebung sehe ich aber auch nicht wirklich erhöhte Aktivität als Fehlerquelle. Es sind derzeit gerade einmal 3 RTs, die kontinuierlich senden. Die sporadischen "dead"-Zeiträume sehe ich im Log des Action Detectors aber auch schon, als ich gerade mal nur ein einziges Thermostat aktiv hatte.

Falls das weiterhin öfter passiert (seit drei Tagen läuft es gerade ohne Probleme - toi toi toi), werde ich es mal mit dem von Martin vorgeschlagenen erweiterten Logging versuchen.

Gruß
Tobias

[Andreas74]

Bei mir war es gerade wieder weg.

hab aber auch dran rumgebastelt, und zwar wollte ich mir mal mit "screen" das Device anzeigen lassen. Ab dem Moment war schluss und die Devices sind der Reihe nach auf dead gegangen.

War das in dem Falle mein Fehler?? Oder war's Zufall?

[martinp876]

@thomas
interessante Theorie, dass der receiver des HMLAN einschläft und durch ein Senden aufgeweckt wird.

@andreas
welches screen?
kann es sein, dass dann das HMLAN ein problem hatte? Überlast? Bitte details,was screen macht/machen solll

Gruss Martin