Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[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?

[paul53]

@haselchen sagte: Wenn ich auf wurde geändert triggere, aber sich nichts ändert,

Ändert sich der Wert nicht laufend, wenn der GTag detektiert wird?

[haselchen]

@paul53

Deswegen will ich einen Mix aus beiden DP, einmal Radar2 und ESPHome.
Es kommt leider vor, dass der Radar2 für ne Sekunde aus Anwesend -> Abwesend-> wieder Anwesend (eventuell kurz mal für ne Millisekunde die Verbindung verloren) macht und dann wird das Licht im Carport ausgelöst.
Das möchte ich abfangen, in dem ich dem Blockly sage > wenn DP für 2min nicht aktualisiert, dann False.

[paul53]

@haselchen
Du hast meine Frage nicht beantwort:

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

Ändert sich der Wert nicht laufend, wenn der GTag detektiert wird?

[haselchen]

@paul53

Die Abfrage ist im Adapter mit 31sek eingetragen.

[paul53]

@haselchen sagte: Die Abfrage ist im Adapter mit 31sek eingetragen.

Dass heißt, der Wert in "_lastHere" wird alle 31 s geändert?
Ich muss so ausführlich fragen, da ich das Verhalten des Adapters und dessen Einstellungen nicht kenne.

[mrjeschke]

@haselchen
Hast du schon mal esp_presence unter ESPhome probiert?
Der liefert einen ON/OFF Wert und läuft bei mir problemlos.

[haselchen]

@paul53

Der wird nur aktuell , wenn der GTag in Reichweite ist.
Hab den Adapter eben mal gestartet, der GTag ist unterwegs.
Wie du siehst ist das Datum noch von gestern.