Hi, ich möchte gern den o.g. Sensor in einem Flow nutzen: wenn der Bewegungsmelder auslöst UND die Tür auf ist…
Unter den AND-Cards finde ich diesen Sensor nicht. Unter den WHEN-Cards schon.
Ist das ein bekannter Bug? Danke und VG
Sie könnten eine Variable hinzufügen.
Erstellen Sie dann eine Logik variable mit der Bezeichnung “Tür offen”.
Wenn sich der Zustand der Tür ändert und die Tür offen ist, setzen Sie “Tür offen” auf ja.
Wenn sich der Zustand der Tür ändert und die Tür geschlossen ist, setzen Sie “Tür offen” auf nein.
WENN der Bewegungsmelder ausgelöst wird
AND Logik “Tür offen” ist Ja
DANN …
Der Fenstergriffsensor HmIP-SRH ist, sagen wir mal, nicht optimal integriert, aber es ist kein Bug. Dein Vorhaben ist also kein Problem, wenn man weiß was der Sensor an Daten an Homey sendet.
Wenn Du nicht weiß welche Daten ein Gerät zur Verfügung stellt, kann man dies in Developer Tools → Devices herausfinden. Einfach den Namen in das Suchfeld eingeben und dann findet man die notwendigen Informationen im Bereich Capabilities.
Beim Fenstergriffsensor HmIP-SRH sieh das ganze so aus:
Der Sensor gibt also nur einen numerischen Wert zurück. Je nach Status des Fenstergriffsensors, also geschlossen, gekippt und offen wird ein anderer Wert an Homey gesendet.
Status des Fenstergriffsensors:
– Geschlossen = 0
– Gekippt = 1
– Offen = 2
Du müsstest den Flow also mit dieser Logik-Karte
wie folgt aufbauen:
Edit
Die Nutzung von Logikkarten im Bereich Und… ist aber ganz normal. Z.B. auch wenn man Helligkeitswerte (Lux), Temperaturen, Werte etc. mit einbeziehen will. Nicht für jedes Gerät, jeden Zustand, jeden Wert gibt es eine gerätespezifische Und… Karte, das ist eher die Ausnahme.
1 Like
Super - Danke!
Ich hänge nochmal an dem Sensor. Die Kachel des Sensors zeigt mir keinen Alarm an. Habe ein virtuelles Device und folgenden Flow erstellt:
Das ist so wahrscheinlich nicht korrekt, oder? 
Leider richtig.
Und was möchtest Du genau machen? Ein virtuelles Device (Sensor) der einen Kontakt-Alarm anzeigt wenn das Fenster welchen Zustand hat?
genau! 
Und welcher Zustand?
Im Gegensatz zu normalen Tür-/Fenstersensoren gibt’s bei dem Fenstergriffsensor ja 3 Zustände:
– geschlossen
– gekippt
– offen
eine Meldung wäre gut bei allem was nicht geschlossen ist
Habe mir extra die Virtuelle Geräte App installiert. Damit funktioniert es nicht mehr. Selbst mit “richtigen” Tür-/Fenstersensoren nicht. Früher war das definitiv möglich.
Der Grund warum es aktuell nicht mehr funktioniert ist vermutlich, dass die App vor einigen Wochen von einem anderen Entwickler auf SDK3 aktualisiert wurde. Ich gehe davon aus, dass bei der Umprogrammierung etwas falsch gelaufen ist bzw. etwas vergessen wurde
Das Problem/den Fehler kann man hier melden, was ich gleich aber machen werde.
Als alternative App kann ich die Device Capabilities vorschlagen. Mit dieser App sollte mindestens alles das möglich sein, was mit der Virtuelle Geräte App auch möglich ist, und noch viel mehr. Allerdings benötigt die DC App auch deutlich mehr Arbeitsspeicher. Bei mir aktuell 33.2 MB zu 11.5 MB… 
Solltest Du die DC App anstelle der VD App einsetzen wollen, dann könnte ich Dir zeigen, wie das mit dem “Fenster offen” Alarm funktioniert.
Kurze Info zum Thema SDK3
Alle Apps die zum 01.01.2023 nicht auf SDK3 aktualisiert wurden, werden aus dem App-Store entfernt und sind auch nicht mehr installierbar, selbst aus anderen Quellen (z.B. GitHub, Community App Store) nicht. Hat man diese “alten” Apps aber bereits installiert, funktionieren diese auch weiter.
Hi, habe die App DC installiert und sehe natürlich den Wald vor lauter Bäumen nicht Wäre mehr als mega, wenn Du mir helfen könntest! Danke schonmal
Sorry, war zu langsam.
Nachdem ich mir den Thread zur VD App mal angeschaut habe, habe ich jetzt nämlich doch eine Lösung mit der VD App gefunden. Allerdings bin ich nach wie vor der festen Überzeugung, dass das früher einfacher umzusetzen war.
Als erstes eine Ja/Nein Logik-Variable erstellen, FensterBadEG (meine lautet TV_Türgriff).
Dann müssen entweder drei Advanced Flows oder vier Standard Flow erstellt werden:
Flow Fenster offen
Flow Fenster gekippt
Flow Fenster geschlossen
Flow der den Kontakt-Alarm des VDs aktiviert/deaktiviert
(Wenn Du AFs nutzt, kann dieser Flow auch mit zu einem der anderen Flows hinzugefügt werden)
Das wars…
Warum es speziell bei dem Fenstergriffsensor separate Flows sein müssen, weiß ich nicht. Ich hatte diesbezüglich bereits Kontakt zu Athom und die können es sich auch nicht erklären. Es scheint also ein Bug in der Homematic App, oder speziell im Gerätetreiber des Fenstergriffsensors zu sein. Kontaktversuche zum App Entwickler liefen ins Leere.
Device Capabilities
- Advanced Virtual Device erstellen
Dabei kann direkt der Name vergeben sowie ein Symbol ausgewählt, oder sogar ein eigenes Bild hochgeladen werden. Das AVD wird dann automatisch gespeichert. - Das AVD konfigurieren
Lange auf das erstellte AVD tippen, bis “Beginnen Sie…” erscheint. Dann
→ Wartung → Reparatur versuchen anklicken. -
Device Class → Sensor
Ja/Nein-Feld erstellen
Bezeichnung eintragen
Anzeigen als → Contact alarm
Flow-Karten erstellen anhaken
Gerät speichern anklicken → Schließen → …
Auch hier müssen wieder separate Flows erstellt werden, ansonsten funktioniert es nicht. Allerdings wird für das AVD keine zusätzliche Logik-Variable benötigt.
Flow Fenster offen
Flow Fenster gekippt
Flow Fenster geschlossen
klappt mit VD. Echt super - Vielen vielen Dank für den Support!!!
by the way:
woher weiß ich, welcher wert in “sensor” (in diesem Fall alarm_contact) zu verwenden ist?
Hier findest du die Standard-Capabilities:
Gute Frage, nächste Frage…
Auf dieser Seite des SDK-Hanbuches sollten alle standardmäßigen Capabilities (Fähigkeit) gelistet sein, die im Homey-Universum vorkommen können. Allerdings gibt es auch benutzerdefinierte Capabilities. Ich gehe übrigens davon aus, dass für den Fenstergriffsensor benutzerdefinierte Capabilities verwendet wurden bzw. verwendet werden mussten. Vermutlich deshalb wird auch nicht der Kontakt-Alarm in der Gerätekachel angezeigt. Nur so nebenbei…
Bei dem vorliegenden Fall habe ich die Seite Developer Tools → Devices aufgerufen, und nach den Capabilities eines “normalen” Tür-/Fenstersensor gesucht, mit folgendem Ergebnis:
Bei einem “normalen” Tür-/Fenstersensor heißt die Fähigkeit also alarm_contact und das ist eine boolesche Variable (Ja/Nein).
Demnach musste eine Ja/Nein Variable erstellt werden, da diese Fähigkeit nur diesen Typ von Variable verarbeiten kann. Außerdem musstedie Fähigkeit alarm_contact bei dem Sensor eingetragen werden.
PS: Das, was Du hier jetzt machst, sind schon recht komplexe Vorgänge und eigentlich nicht üblich. Und das liegt nur daran, dass der Fenstergriffsensor einfach schlecht integriert ist.
Hi @chrb,
nach dem Einfall mit dem Garagentorantrieb und der DC App, habe ich meinen Flow für den Fenstergriffsensor übrigens auch angepasst:
Ach stimmt, das hatten wir ja auch! Danke! Nur rein interessehalber: welcher unterschied besteht bei der überwachung der datenpunkte über die 2 methoden?
Was meinst Du mit 2 Methoden?
Überwachung des DP über „handle state change“ bzw. über Devise Capabilities
