Hallo zusammen,
nach ein paar Stunden voller erfolgreicher Freude beim peeren diverser HM-SCI-3-FM als Fensterkontakt für den jeweils zugehörigen Heizkörperthermostat, komme ich mit der Logik der Erkennung des Zustand im Thermostat nicht mehr klar.
Dank der Anleitung unter https://forum.fhem.de/index.php/topic,41541.15.html (https://forum.fhem.de/index.php/topic,41541.15.html) ging das Peeren auch für die HM-SCI-3-FM gut von der Hand.
Wir haben ein Fenster mit 3 Flügeln, weshalb jeder einen Eingebauten Magnetkontakt hat. Damit ergibt sich ein HM-SCI-3-FM pro Fenster.
Jetzt zu zum springen Punkt:
Öffne ich einen Flügel in beliebiger Reihenfolge wird auch die Temperatur am Thermostat abgesenkt. Soweit wie erwartet.
Schließe ich einen Flügel wieder, so springt bereits jetzt die Temperatur zurück auf den normal gesetzten Wert am Thermostat. Siehe Screenshot des Zustands der Readings im Anhang.
Mein Ziel ist es die Temperatur jedoch erst wieder hoch zu setzen, wenn ALLE Flügel geschlossen sind.
Im aktuellen Zustand ist die Erkennung des offenen Fenster von der Logik etwas unlogisch ;D
Meine Forschungsreisen mit Hans Google haben ergeben, dass das Reading State nur mit dem Fenstergriffkontakt bedient wird oder bin ich noch auf dem Holzweg?
Für alle Tipps bin ich sehr dankbar, da ich mich mit den Eingeweiden der Register nicht auskenne. Notlösung wäre eine Dummy, welcher den Gesamtzustand des Fensters hält. Ich würde den Zustand des Fensters jedoch gern ohne Umweg über einen Dummy pflegen.
Viele Grüße
Jörg
Ich würde die Fensterkontakte in einer Struktur zusammenfassen (offen- mindestens ein Fenster offen; geschlossen- alle Fenster zu).
Das Thermostat würde ich mit einem virtuellen Kanal der VCCU, welcher die Fensterinfo enthält, peeren.
Genauer kann ich aktuell nicht nachsehen, ich weiß das es so bei Winmatic ging.
Meine seit kurzem ausgerollte Lösung kommt ohne structure aus, dafür gibt es ein paar (mögliche) userAttr am virtuellen Fensterkontakt:
https://github.com/rejoe2/FHEM/blob/master/99_myUtils_Homematic.pm
Da ist u.a. auch eine kleine commandref drin mit dem notify und der exemplarischen Definition eines virtuellen FK's. Das ganze funktioniert nur während der Heizperiode und mit einer (auf verschiedenen Ebenen einstellbaren) Verzögerung, so dass nicht jede Türöffnung usw. sofort mit einem Funkbefehl belohnt wird...
Hallo zusammen,
vielen Dank für die Vorschläge bzw. Tipps. So wie ich eure Antworten deute, hat beim WindowRec Kanal keiner mehrere Kontakte vorgesehen. Selbst wenn ich den State setzen würde, würde als State oder TriggerLast immer ein closed empfangen, sobald das erste Fenster geschlossen wird.
Einen Dummy zur Erfassung des Gesamtzustandes der Fensterflügel habe ich, werde ich als Plan B beihalten. Den Lösungweg von Beta-User finde ich ganz schick und wird in Kürze getestet.
Sofern es wetere clevere regSets gibt, bin ich für Vorschläge offen :)
Grüße
Bei mir war das früher schon so gewesen, dass mehrere Kontakte eingetragen waren. An sich sollte das also auch mit direktem peering funktionieren (habe die Drehgriff- und Magnet-Variante im Einsatz).
Schon mal geprüft, ob die firmware jeweils aktuell ist und ggf. was im changelog steht?
(Abgeändert habe ich das, weil eine Lösung her sollte, die weniger Bursts funkt und ggf. auch mit ganz anderen FK's "klarkommt"; HM finde ich immer weniger prickelnd, und wenn was ausfällt, wird das was anderes...)
ZitatHM finde ich immer weniger prickelnd, und wenn was ausfällt, wird das was anderes...
Das Gefühl habe ich bisher nicht so. Interessehalber hätte ich gern gewußt in welche Richtung Du da denkst?
Klassische Aktoren (an/aus) gehen zu ZWave (das ist leider etwas weniger "gesprächig"), alles, was (nicht schlichte an/aus-) Beleuchtung ist, wird tendenziell ZigBee; letzteres wäre vermutlich auch die Lösung, wenn HM-FK's schlapp machen (günstiger und hübscher).