Hallo
Das waere cool. Aber … Ist es so , das bei der Batterieueberwachung auf den Wert geachtet wird
und nicht ob er aktualisiert wurde.
Der Wert auf den geachtet wird kann man angeben … also wenn Profil = True.
Den Füllstand der Batterie kann man nur auswerten wenn der z.B. in einem Wert steht - dann wird auch dieser beachtet.
Das mit dem aktualisiert verstehe ich nicht - also die Frage
Hallo
Es sollte schon eine Warnung kommen wenn die zB Batterievariable nicht
aktualisiert wird. Zum Beispiel wird die Variable alle 24 Stunden aktualisiert ( abgefragt )
und nach 2 Tagen ist das nicht passiert muss man davon ausgehen , dass der Sensor ausgefallen ist.
Also das macht das Modul aktuell nicht - z.B. bei Homematik wird m.w. nur aktualisiert wenn es was gibt und somit wäre der Wert immer alt.
Ich kann mir das aber mal ansehen - grundsätzlich ist die Idee nicht schlecht.
Eine Frage … wie würdest du das mit dem „wenn Variable“ nicht aktualisiert wurde umsetzen wollen? also Batterievariablen werden in der Tat nicht aktualisiert, wenn nichts passiert.
Ich könnte mir aber vorstellen, sowas bei Temperaturen als sinnvoll zu sehen - machbar ist es auf jeden Fall. Mir fehlt noch ein wenig das Problem welches es zu lösen gilt.
Hallo
Bei mir werden Batterievariablen schon aktualisiert auch wenn sie sich nicht veraendern.
zB FS20/Z-Wave.
Hallo
Ich hab ein Script laufen welches die letzte Aktualisierung abfragt und mit einem
Max ( No Upate Time ) vergleicht und dann Warning ( Sensor ausgefallen ).
Fur sowas würde ich einen watchdog einrichten. Bei ZigBee ist es abhängig von wem und was für ein Sensor es ist man müsste also eine separate Zeit für jeden wert haben und das geht bei watchdog ja schon.
Ralf
Also was meine Idee wäre, wäre ein „globaler“ Timeout im Modul und eine seperate Auflistung.
Also in einer Tabelle Batterien leer (oder Variablenwert gefunden) und in einer zweiten Tabelle die wo auch der Timer angeschlagen hat. Das wäre meine erste Idee.
Ein Watchdog auf eine bestimmte Variable ist aber in der Tat vermutlich besser? Das Modul hier soll ja eine „große“ Anzahl von Variablen überprüfen und wenn sich die Variablen unterschiedlich verhalten, müsste man der wieder pro Variable festsetzen.
Wenn es hier noch Ideen gibt gerne posten … ich denke noch nach was der beste Weg ist.
Ich hätte da auch noch eine Bitte, die dieses sehr gute Modul (zumindest für mich) noch besser machen würde.
Es wäre schön, eine weitere Variable hinzuzufügen, die eine Auflistung der IDs aller erkannten leeren Batterien enthalten (z.B. als String mit einem definierbaren Trennzeichen), um sie mit einem eigenen Skript auswerten und darstellen zu können.
Auch wäre es schön, das Intervall der Überprüfung in kürzeren Abständen als einem Tag einstellen zu können.
1 „Gefällt mir“
Den Timer auf der Basis von Minuten habe ich schon eingebaut … bei den Rohdaten reicht VAR1,VAR2,VAR3 oder wäre ein JSON besser oder was anderes?
Für mich wäre JSON perfekt.
Ja, JSON wäre eine Möglichkeit. Oder eine Stringvariabe, die alle IDs mit z.B. Komma getrennt enthält (das meintest du wohl mit „VAR1,VAR2,VAR3“…?). Die IDs könnte man dann bequem mit „explode“ zerlegen und verarbeiten.
Ich denke mal in Richtung JSON … dann kann man es z.B. bequem mit dem JSON Parser weiter nutzen. Mal gucken …
2 „Gefällt mir“
@APieroth @bumaas die neue Version sollte als Beta zur Verfügung stehen. Sie speichert die Variablen und den Namen in eine Variable als JSON … bin noch nicht sicher ob der Aufbau gut ist, aber das kann man schnell ändern.
Weiterhin gibt es jetzt die Option ein minütlichen Timer zu setzen.
1 „Gefällt mir“
Prima, das klingt gut.
Ich werde mich in den nächsten Tagen damit befassen.
Danke
Ich habe eine Idee wie ich das prüfen mit der Zeit machen könnte.
Grundsätzlich würde ich erst nach den Profilen suchen und wenn eines einen bestimmten Wert hat, dann noch prüfen wann die Variable das letzte mal aktualisiert wurde.
Ist es das was Dir helfen würde?
So - heute nochmal gebastelt …
Neu - Variable die den Zeitpunkt der Prüfung erfasst
Neu - Die Möglichkeit das Modul manuell auszulösen - z.B. über das Webfront … wenn man es komplett von außen auslösen will.
Vielen Dank für die Erweiterung!
Der JSON String ist aber etwas unglücklich aufgebaut. In meinem Beispiel findet er acht Variablen, die den Grenzwert unterschreiten, nach der Dekodierung sind es aber nur drei 
Mein Testskript
$json = GetValueString(21046);
echo $json . PHP_EOL;
$ids = json_decode(GetValueString(21046), true);
print_r($ids);
liefert folgende Ausgabe:
{"Battery": "26654","Batterie": "16335","Battery": "55539","Batterie": "23743","Batterie": "25078","BATTERY_STATE": "57278","Battery": "51492","Batterie": "56409"}
Array
(
[Battery] => 51492
[Batterie] => 56409
[BATTERY_STATE] => 57278
)
Im Array sind wegen der nicht eindeutigen Keys nur noch drei Einträge.
Besser wäre es, wenn du nur die Variablen Ids speicherst, mehr braucht man ja auch nicht. Also zum Beispiel so:
$IDs = [];
$VariableIDs = IPS_GetVariableList();
foreach($VariableIDs as $VariableID) {
// ...
$IDs[] = $VariableID;
// ...
}
$this->SetValue('Profile_Monitor_RAW', json_encode($IDs));
Und dann hätte ich gleich noch einen Wunsch
Das Element zur Eingabe der zu ignorierenden Variablen ist etwas zu klein. Bei mir kann ich nicht erkennen, um welche Variablen es sich wirklich handelt:
Angenehmer wäre eine ‚rowCount‘ von 15 und eine ‚width‘ von ‚auto‘. Dann hätte man einen besseren Überblick.