Wenn Wert länger als 30 Minuten kleiner als *gelöst*

[haselchen]

@homoran

Vermutlich solange bis die Batterie des GTag leer ist .
Und nur solange er in Reichweite der Nodemcu ist . Das ist aber selbsterklärend.

[Homoran]

@haselchen sagte in Wenn Wert länger als 30 Minuten kleiner als *gelöst*:

Vermutlich solange bis die Batterie des GTag leer ist .

was verstehe ich denn nicht?

Wenn der Tag in Honolulu idt hat er keine Verbindung mehr zu nodemcu!
dann ist doch vollkommen wurscht ob, wie oft und was er am anderen Ende der Welt sendet!

Sendet die nodemcu dann weiter alle x sekunden den letzten Status an den iobroker?

[paul53]

@haselchen sagte: Mit stop Timeout und Timeout darunter .

Wenn jetzt jede Minute bei Abwesenheit gesendet wird, dann ändere die Timeout-Zeit mal auf 2 Minuten.

[haselchen]

@homoran

Diese Thematik ist völlig unerheblich, weil sonst alles funktioniert.
Ich möchte nur 1mal diese Meldung bekommen, wenn 1min nicht aktualisert wurde.
Nicht mehr nicht weniger.

Der Rest funktioniert alles tadellos.

[haselchen]

@paul53

Dann bekomme ich die Nachricht alle 2min.
Da muss noch irgendeine Logik oder ein Baustein rein, der es auf eine Nachricht senden begrenzt.

[paul53]

@haselchen sagte: jede Minute eine Nachricht.

Wie wird die Nachricht erzeugt? Im geposteten Blockly wird nur ein Datenpunkt geschrieben!

[Homoran]

@haselchen sagte in Wenn Wert länger als 30 Minuten kleiner als *gelöst*:

Diese Thematik ist völlig unerheblich,

eben nicht, weil du ggf. falsch denkst

@haselchen sagte in Wenn Wert länger als 30 Minuten kleiner als *gelöst*:

Ich möchte nur 1mal diese Meldung bekommen, wenn 1min nicht aktualisert wurde.

und genau dieses wenn ist der Knackpunkt und deshalb bin ich so penetrant!

aktualisiert die node mcu dann wirklich nicht mehr?

[mrjeschke]

Moin,
Ich habe mal bei mir nachgeschaut.
Bei Abwesenheit wird bei mir der RSSI-Wert alle 5 Minuten mit nan aktuallisiert.

[haselchen]

@homoran

Nein, der letzte Wert bleibt stehen, wenn außer Reichweite.
Sonst aktualisiert er in grüner Farbe die RSSI Zahl.

[haselchen]

@paul53

Das ist das Blockly , wenn nach 1min der Nicht-Aktualisierung der DP auf falsch geht.

Und das bekomme ich dann je nachdem welcher Timeout eingestellt ist, jede Minute, alle 2 Minuten.....

[DJMarc75]

@haselchen sagte in Wenn Wert länger als 30 Minuten kleiner als *gelöst*:

Sonst aktualisiert er in grüner Farbe die RSSI Zahl.

also dann ist der DP als Trigger in Deinem Blockly nicht gut !

[paul53]

@haselchen sagte: der letzte Wert bleibt stehen, wenn außer Reichweite.

Dann ändere mal den RSSI-Trigger auf "wurde geändert" in der Hoffnung, dass sich der RSSI-Wert bei Anwesenheit mind. einmal in der Minute ändert.

[Homoran]

@haselchen sagte in Wenn Wert länger als 30 Minuten kleiner als *gelöst*:

Und das bekomme ich dann je nachdem welcher Timeout eingestellt ist, jede Minute, alle 2 Minuten....

du schaltest auf jeden Fall den DP erst einmal auf WAHR, egal welchen Wert die nodemcu sendet, da der Trigger auf aktualisieren steht.
1 (oder 2) Minuten später geht dann der DP auf FALSCH

und das Telegram Skript reagiert auf Änderung des Anwesenheits DPs.
und die findet alle 1 (2) Minuten statt

[paul53]

@homoran
Ohne das wirkliche Verhalten des RSSI-DP zu kennen (Log oder History), ist alles nur Spekulation.
Wenn der DP öfter als einmal pro Minute aktualisiert wird, dürfte der Anwesenheits-DP nie FALSCH werden. Wenn seltener, weshalb dann nach einer Minute wieder WAHR --> FALSCH?
@haselchen verheimlicht uns was! Vielleicht noch ein weiteres Skript?

Ursachenforschung mit einem Trigger auf den Anwesenheits-DP:

[Homoran]

@paul53
ich tippte ja darauf, dass der RSSI-DP öfter aktualisiert wird.
Die Aussage mit dem kurz grün werdenden Wert, was später ausbleibt, hat mich allerdings ins Grübeln gebracht

Allerdings haben wir nie etwas zu den Timestamps des DP erfahren.

[haselchen]

@paul53

Ist doch eigentlich ganz einfach. Während das Auto im Carport steht sendet der GTag an die Nodemcu den RSSI Wert.
Das ist fast alle 2sek, als Beispiel 77 dann 80, dann 75 dann 70....und das permanent.
Und solange immer aktualisiert wird , bleibt der DP Anwesenheit auf true.
Wenn das Auto da jetzt 100 Tage steht, wird vermutlich die Batterie irgendwann leer sein, aber solange wird der DP mit den RSSI Wert beschrieben.
Fahre ich nun weg, dann ist der GTag nach ca. 100m ausser Reichweite der Nodemcu und der Wert aktualisiert sich nicht mehr und bleibt auf dem letzten Wert stehen.
Der DP geht nach der besagten Minuten (durch das Blockly Skript) auf falsch.
Soweit so gut.
Wenn das passiert , soll mir Telegram schreiben, dass der GTag "offline" ist. Aber eben nur 1 MAL.

Komme ich wieder nach Hause und bin in Reichweite der Nodemcu, dann wird der RSSI DP wieder aktualisiert mit den gesendeten Werten und der Anwesenheits DP geht auf true.

Alles soweit verstanden?

[Homoran]

@haselchen sagte in Wenn Wert länger als 30 Minuten kleiner als *gelöst*:

Alles soweit verstanden?

klar! schon lange!

Das ist das was du willst!
aber da passiert irgendetwas anderes.

[haselchen]

@homoran

So, Anwesenheit ist okay. Die Abwesenheit macht Probleme.
Ich hab jetzt den Timestamp vom Radar2 Adapter auserkoren.

Wenn der GTag weg ist, dann aktualisiert er die Zeit nicht mehr.
Ich krieg es nicht zusammengeschustert, dass ich das ins Blockly kriege.
Wenn eine bestimmte Zeit dieser Datenpunkt nicht aktualisiert wurde, dann mein Anwesenheits DP auf falsch.

[paul53]

@haselchen sagte: Wenn der GTag weg ist, dann aktualisiert er die Zeit nicht mehr.

Du meinst den Wert, der in "_lastHere" steht?
Dann triggere auf "wurde geändert". Rest wie gehabt.

[haselchen]

@paul53

Ich muss nen Knoten im Hirn haben, anders geht es nicht.
Wenn ich auf wurde geändert triggere, aber sich nichts ändert, dann wird das Skript doch nicht abgearbeitet?