[gelöst] Xiaomi Aqara Vibrationssensor {x,y,z}-Werte auswerten

[noom0815]

Hallo zusammen,

ich möchte mit den Vibrationssensoren geöffnete Dachliegefenster erkennen.
Mit einer direkten Abfrage der orientation, also z.B. "ne orientation {x,y,z}" komme ich aber nicht wirklich weiter, da sich die Werte für x,y,z bei mir jeweils in einem Band um +/- 1° bewegen.

Kann mir jemand sagen, ob und wie man einzelne Werte der orientation abfragen kann, damit man z.B. auf "< {z-Wert}" abfragen könnte?


Danke und Grüße,
Ian

[habl]

Moin,

ich habe mir userReadings erstellt:

Code Auswählen Erweitern


attr vibSenor userReadings x { my $x=-99;; $x=ReadingsVal ("vibSenor","orientation",0);; $x=~m/(-?\d+),(-?\d+),(-?\d+)/;; return $1;;},\
y { my $x=-99;; $x=ReadingsVal ("vibSenor","orientation",0);; $x=~m/(-?\d+),(-?\d+),(-?\d+)/;; return $2;;},\
z { my $x=-99;; $x=ReadingsVal ("vibSenor","orientation",0);; $x=~m/(-?\d+),(-?\d+),(-?\d+)/;; return $3;;}



geht sicher noch einfacher, aber es geht 

[noom0815]

Hallo habl,

ich habe Deine userReadings mal ausprobiert - funktioniert bei mir nicht.
Nach meinem Verständnis müssten die einzelnen Komponenten x,y, und z unter Readings erscheinen, nachdem sie definiert wurden.
Tun sie aber nicht...
Hast Du noch einen Tip?


Danke,
Ian

[habl]

Zwei Sachen kannst Du überprüfen:
- die Readings erscheinen erst nach einem Event --> Sensorstellung ändern
- sind event-on-change-reading, event-on-update-reading richtig gesetzt?

wenn die Readings dann immer noch nicht angezeigt werden, bitte ein List vom Device hier einstellen.

VG
  habl

[noom0815]

Danke für Deine Tips...
Nach einem Event bekomme ich jetzt den x-Wert als reading ausgegeben, y und z leider nicht...irgendwas scheint noch nicht zu passen.

event-on-change-reading bzw. event-on-update-reading habe ich nicht gesetzt, da (erstmal) jede Reading-Änderung ein Event erzeugen darf/soll.


Danke und Grüße,
Ian

[habl]

dann bitte ein List oder die RAW Definition vom Device

[noom0815]

Hallo habl,

habe es gerade entdeckt: aus irgendeinem Grund werden in der Raw Definition die Semikolons und backslahes gedoppelt, sofern man die Attribute über das Pull-Down-Menü und den Button eingibt...
Im Attribut musste ich je ein Semikolon und die backslashes entfernen - läuft!

Besten Dank,
Ian

[noom0815]

Hallo nochmal,

ich habe schon wieder ein neues Problem ausgegraben:
Mit der Lösung von habl kann ich den Zustand der Dachliegefenster recht schön triggern.
Da ich mir aber in der DeviceOverview noch den state der Dachliegefenster anzeigen lassen wollte und mir mit meinen beschränkten fhem-Kenntnissen keine bessere Lösung eingefallen ist, habe ich mir ein DOIF gebastelt, welches mir den state des Dachliegefensters manipuliert (stand zuvor immer auf "initialized"):

Code Auswählen Erweitern


([Fenster_Bad:z] < -48) (setstate Fenster_Bad open) DOELSE (setstate Fenster_Bad closed)


Funktioniert soweit einwandfrei...ABER: meine Abfrage über den Öffnungszustand meiner Fenster funzt leider nicht:

Code Auswählen Erweitern


(["^Fenster:open"]) (set Pushnachricht message $DEVICE wurde geöffnet. Offen sind: [@:a"^Fenster":state:"open"]) DOELSEIF ([#"^Fenster:closed":state:"open"] == 0)(set Pushnachricht message alle Fenster geschlossen)


Bei den Dachliegefenstern existiert kein reading "state", sondern nur ein internal "STATE" - dieses wird aber von obigem DOIF nicht ausgewertet.
Also habe ich wieder gelesen und gesucht und mir ein state über die userreadings meines Dachliegefensters gebastelt:

Code Auswählen Erweitern


x { my $x=-99; $x=ReadingsVal ("Fenster_Bad","orientation",0); $x=~m/(-?\d+),(-?\d+),(-?\d+)/; return $1;},
y { my $x=-99; $x=ReadingsVal ("Fenster_Bad","orientation",0); $x=~m/(-?\d+),(-?\d+),(-?\d+)/; return $2;},
z { my $x=-99; $x=ReadingsVal ("Fenster_Bad","orientation",0); $x=~m/(-?\d+),(-?\d+),(-?\d+)/; return $3;},
state { InternalVal ("Fenster_Bad","STATE",0) }


Problem:
Das neu erzeugte reading state zeigt immer den vorherigen Zustand an, also wenn das Dachliegefenster physikalisch offen ist zeigt STATE "open" und state "closed" - und umgekehrt. Die Stati passen erst wieder, wenn der Xiaomi Sensor nach einiger Zeit zyklisch seine orientation erneut sendet...

Folgende Lösungsansätze könnte ich mir vorstellen:
Wie bringe ich state dazu, einfach eine Kopie von STATE anzuzeigen?
Kann man state evtl. verzögern, damit die Stati wieder zusammenpassen?
Kann man auch internals statt readings abfragen?

Danke und Grüße,
Ian

PS: Vllt. sollte ich dieses Thema verschieben - aber wohin genau? Für Hinweise bin ich dankbar...

[frober]

Erzeuge mit setreading state und daraus mit setstate STATE.
Dann stimmt die Reihenfolge und es sollte passen.


Nachtrag: userreadings erzeugen kein event

[noom0815]

Erzeuge mit setreading state und daraus mit setstate STATE.
Dann stimmt die Reihenfolge und es sollte passen.


Nachtrag: userreadings erzeugen kein event

...verstehe ich irgendwie nicht ganz: was genau meinst du mit Reihenfolge?
Die ersten beiden Codes sind voneinander "unabhängige DOIFs", der letzte Teil das userreading des Vibrationssensors.

[frober]

In der Regel wird in einem device das state gesetzt, daraus werden die einzelnen readings und STATE befüllt.

Du hast kein state.
userreadings und setstate erzeugen keine events!

Also änderst du dein doif und setzt mit setreading dein state.
Dann passt du, falls nötig,  im Dachfenster mit setstate dein STATE an.

Somit stimmt state mit STATE überein und deine Anfrage für den Fensterzustand wird getriggert, sofern du alles richtig angepasst hast.

[noom0815]

Danke frober - ich wusste nicht, dass man auch direkt ein setreading durchführen kann...

STATE und state sind jetzt identisch - jetzt kämpfe ich nur noch mit meiner Fenster-Check-Abfrage...