HmIP Fenstergriffsensor SRH: keine UND-Card verfügbar?

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? :wink:

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! :slight_smile:

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 :slight_smile:

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… :man_shrugging:t3:
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 :slight_smile: 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… :wink:

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

  1. 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.
  2. Das AVD konfigurieren
    Lange auf das erstellte AVD tippen, bis “Beginnen Sie…” erscheint. Dann :gear: → Wartung → Reparatur versuchen anklicken.
  3. 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… :wink:

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:

image

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

?

Sorry, verstehe grade nur Bahnhof…

DP = Datenpunkt. Die Frage ist aber auch eher interessehalber als aus einem wirklichen Problem heraus:

Hier sind es 2 Ansäte, den Zustand eines bspw. Fenstergriffs zu überwachen, wenn ich das richtig verstehe…

Sorry für den verursachten Bahnhof.

Ok, mit “Datenpunkt” meinst Du also die numerische Variable homematic_rhs_state des Fenstergriffsensors, welche die drei Zustände offen, gekippt und geschlossen widerspiegelt!?

Das Ergebnis ist bei allen Varianten identisch. Durch eine Positionsänderung des Fenstergriffsensors wird entweder eine selbsterstellte Variable oder das extra erstellte AVD (siehe Post #12) entsprechend geändert.

Der Vorteil des Flows mit der DC Triggerkarte Überwachen von… ist, dass man:

  1. weniger Flow-Karten benötigt
  2. nur einen einzigen Flow benötigt um den Status der selbsterstellten Variable bzw. das AVD zu ändern

Perfekt - Danke! Verstanden :grinning: