Batteriestatus FS20 BF (Bodenfeuchtesensor

[Motivierte linke Hände]

Hi,

ich würde gerne den Batteriestatus meines Bodenfeuchtesensors FS20 BF überwachen. Das Wiki suggeriert zwar, dass es bei FS20-Geräten einen Batteriestatus gibt (http://www.fhemwiki.de/wiki/Batterie%C3%BCberwachung), aber das scheint nicht bei allen der Fall zu sein, oder?

Mein FS20BF sieht jedenfalls so aus:

Code Auswählen Erweitern

Internals:
   BTN        10
   CUL1_MSGCNT 102
   CUL1_RAWMSG 810c04xx0101a001744710003a4f
   CUL1_RSSI  -54
   CUL1_TIME  2015-03-31 17:52:37
   DEF        7447 10
   IODev      CUL1
   LASTInputDev CUL1
   MSGCNT     102
   NAME       FS20_744710
   NR         688
   STATE      on-old-for-timer 60
   TYPE       FS20
   XMIT       7447
   Code:
     1          7447 10
   Readings:
     2015-03-31 17:52:37   state           on-old-for-timer 60
Attributes:
   IODev      CUL1
   room       FS20

Wenn da nix fehlt, fehlt der Batteriestatus.

Also habe ich mir gedacht, ich überwache mal, wie oft Meldungen zum state eingehen. Herausgefunden habe ich, dass ich die Uhrzeit der letzten State-Übermittlung mit ReadingsTimestamp auslesen kann. Das müsste ich dann parsen und in einer at-Routine regelmäßig testen. Geht es auch einfacher, z.B. über einen Watchdog?

Danke, Christian

[rudolfkoenig]

MWn ist im FS20-Protokoll ist das Melden der Batterie-Status nicht vorgesehen. Woher fhemwiki die Info hat, ist mir ein Raetsel. Mit Watchdog kann man das Geraet ueberwachen. Watchdog hat ein Problem mit einem FHEM-Neustart, dabei vergisst er die aktivierende Nachricht.

[Motivierte linke Hände]

Danke, dann würde ich, wenn Du hier keine Probleme siehst, den entsprechenden Eintrag im Wiki um folgende Funktion ergänzen, die dann hoffentlich auch über einen Neustart hinweg funktioniert (es sei denn, zwischen Ende und Neustart liegen so viele Stunden, dass allein dieser Zeitraum schon ausreicht, das Gerät als "tot" anzusehen):

Code Auswählen Erweitern

sub check_if_alive($$) {
  # Expects:
  # 1. Devicename to be checked
  # 2. Age in hours, after the expiry of which with no new state the device will be considered as dead.
  # Returns:
  # 0 -> Device dead
  # 1 -> Device alive
  # 2 -> Error
  my ($Device,$hours_threshold) = @_;
  my ($Device) = @_;
  my $now = time;
  my $Timestamp = ReadingsTimestamp($Device,"state","0");
  if ($Timestamp eq "0") {
    return 2;
  }

  my @splitdatetime = split(/ /,$Timestamp);
  my @splitdate = split(/-/, $splitdatetime[0]);
  my @splittime = split(/:/, $splitdatetime[1]);
  my $last_state_time =  timelocal($splittime[2], $splittime[1], $splittime[0], $splitdate[2], $splitdate[1]-1, $splitdate[0]);
  my $age_in_hours = ($now - $last_state_time) / 3600;

  if ($age_in_hours > $hours_threshold) {
    Log 1, ("check_if_alive: $Device dead, last state was $age_in_hours hours ago");
    return 0;
  } else {
    return 1;
  }
   
}

[Dime]

Da die FS10/FS20-Transceiver und Spezialsensoren ja z.T. schon knapp werden:
http://web.archive.org/web/20131022182640/http://knowhow.amazers.net/space/dev/projects/hardware/GardenaBodenfeuchteSensorFS20Modul
Hat eigentlich mal jemand Quellen zu dieser Lösung mit CC1101 gesehen?
(Dessen http://busware.de/tiki-index.php?page=CPM auch schon EOL ist, aber Nachfolger hat...)
Gerade die Bidirektionalität inkl. Herausfischen des Hauscodes ist ein seltener, nützlicher Ansatz.

[Motivierte linke Hände]

Hm, bevor ich in der Richting was bastele, würde ich eher auf 1-Wire und den Vegetronix VH400 gehen. Das ist ohne Batterien und damit wartungsfreier, und man kann die Bodenfeuchte als Wert auslesen, was flexibler ist.

[Dime]

Hm, bevor ich in der Richting was bastele, würde ich eher auf 1-Wire und den Vegetronix VH400 gehen. Das ist ohne Batterien und damit wartungsfreier, und man kann die Bodenfeuchte als Wert auslesen, was flexibler ist.

Im 1-Wire-Thread wird der CC1101 ja auch diskutiert: http://forum.fhem.de/index.php/topic,18996.msg287095.html#msg287095
Aber die mit dem Bodensensor umgesetzte Idee, es auch als selbstlernenden Transceiver für die alten ELV-Protokolle zu verwenden, ist gut und günstig auf einer Linie mit CUL etc. - richtig nützlich wird Domotik ja v.a. im Bestand, wenn sie herstellerübergreifend funktioniert.