https://community.hom.ee/t/homeegramm-zur-fensterpruefung/4157/6?u=hoeffy
Damit prüfe ich beim Einschalten der Alarmanlage, ob noch ein Fenster offen ist.
Zu deinem Gruppenproblem selber kann ich allerdings nichts beitragen.
Könntest du mir morgen bitte einen Support-Zugang per PN zusenden, dann sehe ich es mir mal genauer an wenn du möchtest?
1 „Gefällt mir“
Supportzugang per PN geschickt, Danke!!!
Guten Morgen,
versuche es doch bitte mal mit dem von mir erstellten homeegramm:
hier habe ich den Wert von „Tür/Fenster“ auf „Zustand“ geändert, vielleicht ist das die Lösung?
Super das hat geholfen, also NICHT den Tür-/Fensterzustand nehmen sondern den Zustand in der Bedingung 
@Steffen
Welchen Zweck hat denn „Tür-/Fensterzustand“? Ist dieser ein Fehler resp. überflüssig? Sollte man diesen, falls überflüssig, nicht im besten Fall entfernen?
Von Grund aus denke ich, das der Status(default) bei allen Sensoren hierfür gleich sein müsste, was in dem Fall von @whoami nicht war.
Das würde ich aber trotzdem mit den Entwicklern gerne nochmal absprechen.
3 „Gefällt mir“
Das ist leider nicht die Lösung. Jetzt kommt dann keine Push-Meldung wenn ein Tür-/Fenster-Zustand nicht geschlossen ist!
Problem ist:
Unterschiedliche Definitionen von Messwerten von den Zuständen bei Tür-Fenster-Sensoren
Maco mTronic Fensterkontakt = Tür-/Fenster-Zustand (die haben keinen reinen „Zustand“)
Asus Tür-Fenster-Sensor = Zustand
In gemischten Gruppen funktioniert das dann nicht. Hier sollten alle Geräte die selbe Eigenschaften-Definition haben
Ich befürchte die Kollegen haben Recht. Bei der NeoCoolcam hat es geholfen, bei der Hoppe Eltako Fenstergriff leider nicht 
Gut wir gehen das nochmal durch, damit es natürlich auch einen einheitlichen Standard hat.
Könntet ihr mir bitte eure Screenshot’s senden?
1 „Gefällt mir“
Maco mTronic Fensterkontakt
Könntest du mir bitte hiervon noch ein Screenshot senden?
Oben sind doch Screenshots von beiden Geräten, 1. Abus, 2. Maco mTronic 
Ok, vielen dank für eure Informationen.
Wir gehen das jetzt mal mit den Entwicklern durch.
Wir sind es durchgegangen und es werden die im Homeegramm ausgewählten Attribute verglichen. Heißt wenn im Homeegramm der „Tür-/Fensterzustand“ ausgewählt wurde, dann werden nur Geräte mit dieser Eigenschaft in betracht gezogen. Das liegt am unterschiedlichen Wertebereich, da der „Tür-/Fensterzustand“ im Gegensatz zum „Zustand“ noch „gekippt“ sein kann.
@Steffen wenn sich der Status nicht sinnvoll zusammenführen lässt, kann ich nur wärmstens folgenden Feature Vorschlag empfehlen, um das Szenario dennoch ohne viel Gebastelt umsetzen zu können.
2 „Gefällt mir“
Danke für die Aufklärung aber dennoch verstehe ich die Zweiteilung nicht, warum gibt es nicht ein Attribut, welches diese Info aggregiert unabh. davon ob ein Gerät auch gekippt bestimmen kann oder nicht. 
1 „Gefällt mir“
Die unterschiedlichen Definitionen von Fenster-/Türkontakten sind einfach falsch!!!
wenn ich frage, sind irgendwelche Fenster-/Türkontakten offen, erwarte ich ich mir bei „geöffnet“ JA!
Mag sein eine Haustüre ist nie „ist gekippt“ oder „ist nicht gekippt“ (P.S.: Die Verwendung des MACO mTronic-Sensors ist aber auch hier möglich ), aber alle anderen Zustände sind gleich. Eine „Oder“-Bedingung gibt es ja nicht, wer also bei einer Bedingung fragt, „ist gekippt“, macht dies bewußt und denkt nicht an die Haustüre - sonst würde es ja heißen, sind alle geschlossen 
Sorry, aber Tür-/Fenstersensor mit unterschiedlichen Messwerten zu behandeln, was bei Gruppierungen dann nicht funktioniert, ist einfach ein grober Bug!
Ich muss da noch nachlegen:
Rollläden haben auch den Messwert „Zustand“, also „geöffnet“ und „geschlossen“!
Meiner Meinung nach, hat der Messwert vom ABUS Z-Wave Tür-/ Fensterkontakt einfach die falsche Wert-Zuordnung.
homee soll einfach sein, der Sensor ist aus eurem Shop gekauft (@Chris)… - und dann kommen irgendwelche Ausreden, weil es doch nur ein Irgendwas-Sensor ist, der doch nicht in die Gruppe Tür-/Fenstersensoren passt???