HM-SCI-3-FM, Battery Low ---> Notify

[JM2012]

Hallo zusammen,

kann mir jemand sagen, ob
bei den HomeMatic HM-SCI-3-FM Modulen ein Battery "Low"-Event generiert wird?

Bei den "HM-PBI-4-FM" Modulen wird die Information bei jedem Tastendruck mitgeneriert.
Aktuell kann ich bei den HM-SCI-3-FM so ein Event nicht sehen.

Zur Zeit fange ich diese Events ab mit:

define n_batt_chk notify .*:.*[Bb]attery.* {  \
   if("%" !~ m/ok/) {\
      Log 1, "@: Batteriewarnung %";;\
      sendEmail('test@@test.de',"FHEM Batterie-Warnung","@: Batteriewarnung %") ;;\
  } \
}

Irgendwie würde ich das ganze ja testen, habe aber keine "halbleere" Batterie.....

Gruesse
Juergen

[Martin]

Juergen,

welchen subtype hat der SCI3?
Der Batterie Alarm sollte eigentlich schon kommen - haengt von subtype ab.

Generell sollten alarme aber nur kommen wenn etwas zu verlenden ist. Also wenn die Batterie auf 'low' geht. Batterie OK sollte nur einmal nach den Start kommen und wenn sich der Zustand von low nach OK aendert.

In der neuen Version wird fuer den SCI3 eine dead/alive ueberwachung eingebaut, automatisch wenn man anlernt oder manuell, wenn man will. Sollte sich der SCI3 nicht alle 28h melden wird ein event gepostet
aktueller Zustand von Batterie und activity steht sowieso in den Variablen

Gruss
Martin

[JM2012]

Hallo Martin,

erstmal Danke für die Erläuterungen.
Die "dead/alive ueberwachung" wäre echt super!

Nun zu Deinen Fragen:
Den SubType "threeStateSensor" finde ich nur beim "Hauptchannel"....
Ich habe die Devices damals mit "autocreate" angelegt und nutze nur "Channel2" und "Channel3".

Hier die aktuelle config:
define HM_Schalter_Alarm CUL_HM 19F54E
attr HM_Schalter_Alarm channel_02 HM_Schalter_Alarm1
attr HM_Schalter_Alarm channel_03 HM_Schalter_Alarm2
attr HM_Schalter_Alarm devInfo 030000
attr HM_Schalter_Alarm firmware 1.0
attr HM_Schalter_Alarm hmClass sender
attr HM_Schalter_Alarm model HM-SCI-3-FM
attr HM_Schalter_Alarm room HomeMatic
attr HM_Schalter_Alarm serialNr JEQ0080172
attr HM_Schalter_Alarm subType threeStateSensor

define HM_Schalter_Alarm1 CUL_HM 19F54E02
attr HM_Schalter_Alarm1 chanNo 02
attr HM_Schalter_Alarm1 device HM_Schalter_Alarm
attr HM_Schalter_Alarm1 model HM-SCI-3-FM
attr HM_Schalter_Alarm1 room Alarmanlage
attr HM_Schalter_Alarm1 serialNr JEQ0080172

define HM_Schalter_Alarm2 CUL_HM 19F54E03
attr HM_Schalter_Alarm2 chanNo 03
attr HM_Schalter_Alarm2 device HM_Schalter_Alarm
attr HM_Schalter_Alarm2 model HM-SCI-3-FM
attr HM_Schalter_Alarm2 room Alarmanlage
attr HM_Schalter_Alarm2 serialNr JEQ0080172

Gruss
Juergen

[Martin]

Am Sonntag, 21. Oktober 2012 20:04:45 UTC+2 schrieb JM2012:

Hallo Martin,

erstmal Danke für die Erläuterungen.
Die "dead/alive ueberwachung" wäre echt super!

ist drin - sollte fuer SCI-3 auf 28:00 stehen (28 Stunden).
Wenn du einmal anlernen machst wird es autogeneriert. Oder manuell eintragen - commandref hat den Ablauf.

Nun zu Deinen Fragen:
Den SubType "threeStateSensor" finde ich nur beim "Hauptchannel"....
Ich habe die Devices damals mit "autocreate" angelegt und nutze nur "Channel2" und "Channel3". 

ich muss immer nachfragen da der Subtype sich aus den device meldungen selbst erzeugt und ich keine referenzliste habe. 
Batteriestate sollte einen event erzeugen wenn
- nach dem restart einmal
- wenn low dann mit jeder message(eigentlich unschoen... wollen aber manche)
- wenn von low nach ok aendert einmal

ausserdem sollte ein Readign bestehen mit Batterie.

Gruss
Martin

[JM2012]

Hallo Martin, 

vielen Dank für Deine Erklärungen und den tollen Support!!!!!!!!!

Ich habe noch ein wenig mit dem "ActionDetector" rumgespielt und habe schliesslich die Lösung gefunden. 
(Der Detector spart mir ca. 50 cfg-Zeilen, super!)

Toll wäre, wenn Du irgendwann einen "ReTrigger" von alive- bzw. dead-Events in x Sekunden programmieren könntest.....

Da ich nirgends ein komplettes Beispiel gefunden habe, hier noch einmal die komplette Konfiguration für weitere fhem-User: 

define FHEM_rereadcfg notify global:REREADCFG {\
   Log 1, "****** FHEM-REREADCFG ******" ;;\
   fhem ("set HM_Taster_Klingel actiondetect 030:00") ;; \
   fhem ("set HM_Schalter_Garage actiondetect 030:00") ;; \
}

define HM_Taster_Klingel CUL_HM 1839D7
attr HM_Taster_Klingel devInfo 040303
attr HM_Taster_Klingel firmware 1.3
attr HM_Taster_Klingel hmClass sender
attr HM_Taster_Klingel model HM-PBI-4-FM
attr HM_Taster_Klingel room Klingel
attr HM_Taster_Klingel serialNr IEQ0535421
attr HM_Taster_Klingel subType pushButton

define HM_Schalter_Garage CUL_HM 19F54E
attr HM_Schalter_Garage channel_02 HM_Schalter_Garage_1
attr HM_Schalter_Garage channel_03 HM_Schalter_Garage_2
attr HM_Schalter_Garage devInfo 030000
attr HM_Schalter_Garage firmware 1.0
attr HM_Schalter_Garage hmClass sender
attr HM_Schalter_Garage model HM-SCI-3-FM
attr HM_Schalter_Garage room HomeMatic
attr HM_Schalter_Garage serialNr JEQ0080172
attr HM_Schalter_Garage subType threeStateSensor

define HM_Schalter_Garage_1 CUL_HM 19F54E02
attr HM_Schalter_Garage_1 chanNo 02
attr HM_Schalter_Garage_1 devInfo 030000
attr HM_Schalter_Garage_1 device HM_Schalter_Garage
attr HM_Schalter_Garage_1 model HM-SCI-3-FM
attr HM_Schalter_Garage_1 room test
attr HM_Schalter_Garage_1 serialNr JEQ0080172
attr HM_Schalter_Garage_1 subType threeStateSensor

define HM_Schalter_Garage_2 CUL_HM 19F54E03
attr HM_Schalter_Garage_2 chanNo 03
attr HM_Schalter_Garage_2 devInfo 030000
attr HM_Schalter_Garage_2 device HM_Schalter_Garage
attr HM_Schalter_Garage_2 model HM-SCI-3-FM
attr HM_Schalter_Garage_2 room test
attr HM_Schalter_Garage_2 serialNr JEQ0080172
attr HM_Schalter_Garage_2 subType threeStateSensor

define dead notify .*:.*dead.* {  \
   Log 1, "DEAD: @: %";;\
}

define alive notify .*:.*alive.* {  \
   Log 1, "ALIVE: @: %";;\
}

define ActionDetector CUL_HM 000000
attr ActionDetector room CUL_HM

define FileLog_ActionDetector FileLog /var/log/fhem/ActionDetector-%Y.log .*Activity:|ActionDetector.*
attr FileLog_ActionDetector logtype text
attr FileLog_ActionDetector room CUL_HM


Gruss
Juergen

[Martin]

Hallo Juergen,

tip: Wenn du
define HM_Taster_Klingel CUL_HM 1839D7
attr HM_Taster_Klingel room Klingel
eingibts und dann anlernen setzt werden alle anderen attribute automatisch gesetzt

define HM_Schalter_Garage CUL_HM 19F54E
=> anlernen
es werden  die beiden Kanaele automatisch generiert
Setzen von Deviceparatetern in den Kanaelen ist nicht notwendig und wird nicht benutzt. Ausnahme ist model - das wird in machen webdarstellung genutzt, nicht aber in CUL_HM.

Zum Retrigger - verstehe nicht wozu. Generell wird ein Status (fast)immer nur einmal gemeldet. Den Wert kann man auch nachsehen. Sollte man etwas 'verpasst' haben, weil FHEM aus war... nach einem Restart kommt immer der Aktuelle Status.

Kannst du noch einmal erklären welchen Status man wie oft wiederholen sollte?
Ich schlage vor - und plane so etwas fuer mich - eine Webseite mit alarmen zu erstellen, in der ich alle Alarme,die ich fuer kritsch halte sehen kann. Das halte ich fuer sinnvoller als Alarme einfach zu wiederholen.

Gruss
Martin

[JM2012]

Hallo Martin,

die Idee von "Retrigger" war, dass ich eine Lösung suche, falls ich einen "dead" oder "alive" verpasse.
In meinem Fall verschicke ich eine eMail, die auch mal untergehen kann.

Ich habe mir erstmal geholfen, indem ich per "at"-command meinen eigenen regelmässigen job starte und mit
$attr{HM_Taster_Klingel}{actStatus} den Status der detectoren abfrage...und entsprechend reagiere....

Deine Idee mit der Webseite für Alarme ist gut....für mich reicht die oben beschriebene Variante.....

Was mir noch aufgefallen ist, wenn ich fhem neu starte, ist der Status erstmal auf timeout und danach auf dead(incl. Event-Generierung).(also eher pessimistisch). Ist auch erstmal logisch, da ja noch kein Event erfolgte.....Gibt es einen einfachen trick, den status auf "alive" (quasi als default) zu setzen?
Alternative wäre, die "actiondetect"-Zeit zu warten und erst dann auf dead zu gehen, falls nicht zwischendurch ein alive erkannt wurde....

Aber nochmal: Ich bin erstmal glücklich und will Dir nicht unnötig Arbeiten machen!!

Danke an das gesamte FHEM-Core-Team für die unermüdliche Arbeit!!!!!!!

Gruss
Juergen

[Martin]

Hallo Juergen,

der Status sollte nach erstellen unknown sein und - da hast du recht beim ersten Trigger wird er, wenn kein Trigger kam - auf 'dead' gesetzt.
 Eine schnelle, nicht ganz saubere Loesung fuer dich ist, die Abtastzeit groesser als die groesste Triggerzeit zu machen. Dann sollte - nach restart - ein Trigger dagewesen sein bevor abgetastet wird.
Bisher merke ich mir die startzeit nicht - und kann daher nicht pruefen, wie lange das Device schon ueberwacht wird. das meusste ich ggf nachbauen. Wird wohl noetig sein.

Das mit dem mehrmals schicken wuerde ich dem User ueberlassen - sprich sich einen Job zu basteln der alarme nach Wunsch noch einmal verarbeitet. Denn das sollte ich sicher nicht auf dead-or-alive beschraenken. Und die anderen Alarme kommen (hoffentlich) auch nur einmal. Klingt das vernuenftig?

Gruss
Martin

[JM2012]

Hallo Martin,

das kling vernuenftig. Dann bin ich mit meiner Lösung gar nicht mal so weit weg.

Gruss
Juergen