Hallo
besteht die Möglichkeit das open bzw close eines FHT80TF mit dem CUL zu simulieren, dass der FHT80B meint das Fenster ist auf.
Hintergrund mein FHT Fensterkontakt funktioniert nicht mehr richtig, und ich hätte noch ein paar Homematic Fenster Schalter.
Hatte versucht die RAW message T5214A101 für open und T5214A102 für close zu senden, aber so leicht funktioniert es nicht.
Schöne grüße Hannes
Hallo Hannes,
Ja die Möglichkeit besteht. Ich habe das seit kurzen bei mir lokal am laufen (http://forum.fhem.de/index.php/topic,27032.msg202021.html#msg202021 (http://forum.fhem.de/index.php/topic,27032.msg202021.html#msg202021)). Es funktioniert bis jetzt ohne Ausfälle. Ich wandel einen FS20 SI3 als reedkontakt Sensor für meine Fenster auf die fht80b um. Die Firmware basiert auf 1.61 und momentan nicht im SVN. Wenn du es ausprobieren möchtest kann ich dir gern das hexfile geben. Dazu nur noch das neueste 09_Culfhttk.pm updaten und schon kannst Du einen Fht80 tk simulieren. :)
Gruß,
Steve
Hallo Steve
das ist ja cool :-).
Das ist genau das was ich gesucht habe.
Ja bitte sende mir das hexfile zu, dann werde ich mich versuchen es zu flashen.
Ich hatte nicht mal den sync hin bekommen :-(.
Vielen Dank schon mal im voraus.
Gibt es dann eine eigene Funktion im CUL für den sync und das senden von Fenster Kontakten?
Gruß habe
Da hätte ich auch Interesse dran, Danke!
Hallo Hannes,
Fensterkontakte fangen bei 0x69 (1. Byte Hauscode) an und die Pakete die Du schicken wolltest, sind für eine FHT80b mit dem Hauscode 5214. So hatte ich auch angefangen :)
ZitatGibt es dann eine eigene Funktion im CUL für den sync und das senden von Fenster Kontakten?
Ja aber das ist nicht so trivial wie es scheint. Also wenn Du eine "RAW" message mit z.B. T
86310A0C absetzt, kannst Du einen Sync damit anstoßen. Aber vorher muss der FHT80B schon auf sync für die Fensterkontakte gestellt sein. Dann sollte der Kontakt angemeldet sein/werden und im geräte-spezifischen Intervall funktionieren. Den Status ändern, wäre mit T86310A01 oder T86310A02 wie Du schon geschrieben hattest. Dann funktioniert es bis der CUL resetet wird. Danach muss man wie bei den FHT8v neu syncen.
Aber wichtig ist im Moment, das das 1. Byte vom Hauscode des Kontakts
86 ist. Das ist für die Intervallberechnung wichtig. Das kommt daher, das ich eigentlich mehr als einen unterstützen wollte...:)
Aber um den Komfort zu erhöhen, habe ich das Module 09_CUL_FHTTK.pm angepasst. Beinhaltet nun Set-Funktionen inklusive Sync. :) Dafür muss nur das attr model hinzugefügt und auf dummy gesetzt werden. Beim Sync wird der Fensterstatus automatisch auf Closed gesetzt. Alles andere wird dann innerhalb von 1 Minute abgehandelt.
define Fenster CUL_FHTTK 86310A
attr Fenster model dummyset Fenster ClosedMit get <CUL_name> raw T12 kann man sich den Buffer für den Fensterkontakt ausgeben und mit set <CUL_name> raw T01FHZID wieder zurücksetzen.
Viele Grüße,
Steve
Habt Ihr beiden das schon ausprobieren können? :) Würde mich über Euer Feedback freuen.
Hallo Steve
ich habe es auf die schnelle noch nicht geschafft, den CUL zu flashen.
Hatte aber noch keine zeit mich damit auseinander zu setzen.
Da aber die Heizzeit ansteht muss ich es jedoch demnächst machen.
Schöne grüße
Hannes
Zitat von: Matscher am 06 Oktober 2014, 09:28:09
Habt Ihr beiden das schon ausprobieren können? :) Würde mich über Euer Feedback freuen.
Hallo Steve,
jetzt habe ich es hin bekommen, den CUL mit Deiner Firmware zu flashen :-)
Erst hat es nicht funktioniert, nach RTFM bin ich dann drauf gekommen, dass ich natürlich das neue Fenster erst bekannt machen muss.
Und siehe da es funktioniert ;D.
Vielen Dank nochmals :)
Jetzt kann der Winter kommen und das automatische Lüften meiner Velux Fenster bringt meine Heizung nicht aus den Tritt.
Noch eine Frage: Kommt diese Funktion auch in die Standard Firmware des CUL?
Gruß und Danke nochmals
Hannes
Hallo Hannes,
das ist eine sehr gute Nachricht :) Freut mich.
Zu Deiner Frage: Das wäre wünschenswert. Ich werde mal im CUL - Dev Forum nachfragen und einen Patch bereitstellen. Ich denke das könnten noch mehr User gebrauchen.
Gruß,
Steve
Einfach so einen Dummy FHTTK anlegen geht nicht, er nimmt nicht jeden Code an. Es muss eine Prüfsumme drin sein.
Habe mit 987654 probiert -> funktioniert nicht.
Mit oben genannten -> funktioniert.
Die Prüfsumme wird in der CUL Firmware berechnet und angehangen. Der angelegte 987654 wird aber am FHT angemeldet?
ZitatAber wichtig ist im Moment, das das 1. Byte vom Hauscode des Kontakts 86 ist. Das ist für die Intervallberechnung wichtig. Das kommt daher, das ich eigentlich mehr als einen unterstützen wollte...:)
Deswegen wird dein 987654 im Moment nicht auf dauer funtkionieren. Im Moment ist 86 fix in CUL FW eingetragen. Du könntest 867654 probieren.
Zitat von: Matscher am 07 November 2014, 19:44:12
Die Prüfsumme wird in der CUL Firmware berechnet und angehangen. Der angelegte 987654 wird aber am FHT angemeldet?
Nein, er kann sich nicht anmelden.
Zitat von: Matscher am 07 November 2014, 19:44:12
Deswegen wird dein 987654 im Moment nicht auf dauer funtkionieren. Im Moment ist 86 fix in CUL FW eingetragen. Du könntest 867654 probieren.
Die 867654 kann sich anmelden.
Ich sehe gerade im Log
2014.11.07 20:03:38 3: CUL_FHTTK (dummy_fhttk_2) syncing with FHT80b.
2014.11.07 20:03:38 1: PERL WARNING: Argument "0f" isn't numeric in numeric ne (!=) at ./FHEM/09_CUL_FHTTK.pm line 277.
2014.11.07 20:03:38 1: PERL WARNING: Argument "0c" isn't numeric in numeric ne (!=) at ./FHEM/09_CUL_FHTTK.pm line 277.
Zitat von: stromer-12 am 07 November 2014, 20:04:09
Die 867654 kann sich anmelden.
Ahh stimmt ich hatte in der FW Version die Beschränkung auf 86 eingebaut (if(fhttf[0] == 0x86)).
Wegen der PERL Warning schau ich mal :)
Mehr als 1 Dummy FHTTK ist im Moment nicht möglich. Sobald ein 2. angelegt ist geht keiner mehr.
Mehr als einer wird im moment nicht unterstützt. Das kam nicht deutlich genug im Post http://forum.fhem.de/index.php/topic,27465.msg203561.html#msg203561 (http://forum.fhem.de/index.php/topic,27465.msg203561.html#msg203561) rüber. Mehr als einer ist nicht ganz trivial zu lösen, da sich es doch ein wenig von den fht8v unterscheidet. Wichtig ist vllt. hier den Bedarf zu ermitteln. Vorrangig ist natürlich auch die Stabilität und Funktion. Danke auf jeden Fall für Dein Feedback dazu.
Zitat...momentan nicht im SVN. Wenn du es ausprobieren möchtest kann ich dir gern das hexfile geben. Dazu nur noch das neueste 09_Culfhttk.pm updaten und schon kannst Du einen Fht80 tk simulieren
@stromer-12: Brauchst Du mehr als einen virtuellen FHT80TF?
Ich werde meine FHTs auf HM umstellen.
Meine 3 FHT8b sind ja auch schon über 10Jahre alt.
Die 3 FHT80b wollte ich mit HM Kontakten ansteuern.
So habe jetzt eine neue Firmware Version genereiert, die maximal 4 TFs unterstützt. Weiterhin habe ich die Housecodebeschränkung (1. Byte 0x86) entfernt und nun sollten alle Housecodes größer 0x69 akzeptiert werden. Zur Unterscheidung der 4 TFs ist darauf zu achten, das mindestens eins der ersten 3 Bytes unterschiedlich ist.
define Fenster CUL_FHTTK 86310A
attr Fenster model dummy
Ich hoffe auf ein positives Feedback :)
Ich habe nur den CUL neu geflasht.
TK mit FHT gesynct, TK wird vom FHT erkannt, und das war es auch schon.
Ich bekomme über meinen CUNO keine weiteren TK Meldungen rein und auch der FHT sagt Fault TK
Okay schau ich mir an.
Bei einem Statuswechsel kommt auch nichts?
Noch mal die neue Version drauf geschoben. Der Sync geht raus und danach nichts mehr. Zumindest der CUNO sieht nichts mehr.
Sync ist das einzige was geht.
So ich denke ich habe das Problem gefunden. Damit müßte es funktionieren. Problem beim Timerdurchlauf... .
Mit einem TK funktioniert es erstmal im Kurztest
Das ist schon mal sehr gut. :)
Mit einem 2.TK bekomme ich sync und einmal closed oder open übertragen. der 1.TK funktioniert weiterhin.
00:86310A02 funktioniert
01:7874C202 kein neuer Status
kann es sein der 2. noch nicht im richtigen Abstand sendet.
Meine Vermutung mit der Zeit könnte hinhauen, ich habe jetzt mal den 2.TK auch mit 86xxxx angelernt.
Der erste Konntakt nach dem Anlernen klappt noch sofort, eine weitere Reaktion des FHTs kommt erst nach ca. 45 Minuten.
Es scheint mehr als nur das erste Byte in der Berechnung der Zeit zu liegen, bzw. ein anderes.
ich habe hier 3 reale TFs
f7fd57 -> 4:02min
ca5401 -> 4:14min
64c870 -> 4:16min
Edit: Meiner Vermutung nach liegt der Sendeabstand in den niederwertigsten 3bit.
Deine ID 86310A sendet mit 4:12
Da könntest du recht haben. Dann wäre der 86310a gerade zufällig genau im zeitraster von 4:12.
Okay danke, damit lässt sich auf jeden Fall was anfangen. Ich rechne das nochmal durch,da muss noch was sein, was ich über sehen habe.
Bin noch nicht weiter gekommen. :-\
Meine zwei realen sind
83 C0 D7 -> 4:02 min -> identischer Intervall von Deinem F7 FD 57 -> 4:02
86 30 0A -> 4:12 min -> identischer Intervall mit dem virtuellen 86 31 0A -> 4:12 min
Hab mal eben eine Tabelle angelegt:
Code HC1 HC2 Addressbyte Zeit
F7 FD 57 1111 0111 1111 1101 0101 0111 4:02 (242)
83 C0 D7 1000 0011 1100 0000 1101 0111 4:02 (242)
86 30 0A 1000 0110 0011 0000 0000 1010 4:12 (252)
86 31 0A 1000 0110 0011 0001 0000 1010 4:12 (252)
CA 54 01 1100 1010 0101 0100 0000 0001 4:14 (254)
64 C8 70 0110 0100 1100 1000 0111 0000 4:16 (256)
Code HC1 HC2 Addressbyte Zeit Zeit kurzes Interval
F7 FD 57 1111 0111 1111 1101 0101 0111 4:02 (7) 1:00 bzw 1:01
83 C0 D7 1000 0011 1100 0000 1101 0111 4:02 (7)
86 30 0A 1000 0110 0011 0000 0000 1010 4:12 (2)
86 31 0A 1000 0110 0011 0001 0000 1010 4:12 (2)
CA 54 01 1100 1010 0101 0100 0000 0001 4:14 (1) 1:03 bzw 1:04
64 C8 70 0110 0100 1100 1000 0111 0000 4:16 (0) 1:04
60 + ( 16 - x * 2 ) / 4 Zeit in Sekunden für kurzes Intervall
Ja das sieht sehr gut aus. Danke! :)
Ich habe es gleich angepasst.
So, nach einer Stunde klappt das senden zum FHT immer noch, mit der gleichen ID wie gestern.
Der 2. läuft jetzt synchron.
Das ist eine gute Nachricht. :) Dann haben wir offensichtlich die richtige Formel gefunden.
Danke.
Gerade eben den 2. geschaltet und reagierte sofort innerhalb von einer Minute
Passt und ich nehme an, heute läuft es immer noch :)
Wenn es weiterhin stabil ist, werde ich nochmal im CUL Corner nachfragen, ob es dann offiziell in die FW kommen kann.
Ja, es wird innerhalb der nächsten Minute reagiert vom FHT.
Zitat von: Matscher am 19 November 2014, 08:25:46
Passt und ich nehme an, heute läuft es immer noch :)
Wenn es weiterhin stabil ist, werde ich nochmal im CUL Corner nachfragen, ob es dann offiziell in die FW kommen kann.
Hallo Steve,
hast Du schon eine Rückmeldung ob es in die offizielle Version mit aufgenommen werden kann?
Müsste es eigentlich funktionieren den Fensterkontakt automatisch zu synchronisieren wenn FHEM neu gestartet wird?
defint ntf_INIT notify global:INITIALIZED {;fhem("set az_fk_Virtuell syncing")} Denn letztes mal hatte ich das Problem, das der CUL nicht mehr funktionierte und ich diesen kurz aus und ansteckte und neu initialisiert und anschließend waren die Fenster nicht mehr i.O.,
weil ich nicht an den sync dachte :'(.
Oder könnte ich auch automatisch einmal in der NAcht per
at um z.B. 03:30 ein syncing ausführen?
defint at_Syncing at +*3:30 set az_fk_Virtuell syncing Gruß Hannes
Hallo Hannes,
Zitathast Du schon eine Rückmeldung ob es in die offizielle Version mit aufgenommen werden kann?
Ja, die Erweiterung wurde eingecheckt. Wird wohl dann im nächsten offiziellen 1.62 Build auf der Seite zum Download stehen. Aber in SVN liegt schon eine Version, die das beinhaltet.
ZitatMüsste es eigentlich funktionieren den Fensterkontakt automatisch zu synchronisieren wenn FHEM neu gestartet wird?
Nein, da das FHT80B auch im Sync Modus für den Fensterkontakt sein muss. Automatisch geht da leider nichts. Verhält sich wie mit den Stellantrieben. Sobald der CUL stromlos oder ein reset durchgeführt wurde, muss alles wieder angelernt werden. Der CUL weiß in dem Moment den Sendeintervall nicht mehr und würde danach immer asyncron laufen. Ein einfaches FHEM neustarten, stellt hingegen kein Problem dar, da der CUL den FHT80TF simuliert.
Gruß,
Steve
Zitat von: Matscher am 14 Dezember 2014, 20:13:42
Hallo Hannes,
Ja, die Erweiterung wurde eingecheckt. Wird wohl dann im nächsten offiziellen 1.62 Build auf der Seite zum Download stehen. Aber in SVN liegt schon eine Version, die das beinhaltet.
Nein, da das FHT80B auch im Sync Modus für den Fensterkontakt sein muss. Automatisch geht da leider nichts. Verhält sich wie mit den Stellantrieben. Sobald der CUL stromlos oder ein reset durchgeführt wurde, muss alles wieder angelernt werden. Der CUL weiß in dem Moment den Sendeintervall nicht mehr und würde danach immer asyncron laufen. Ein einfaches FHEM neustarten, stellt hingegen kein Problem dar, da der CUL den FHT80TF simuliert.
Gruß,
Steve
Hallo Steve,
danke für die Rückmeldung.
Nun muss ich mir überlegen, wie sich sicherstellen kann, dass der Sync zwischen den Fensterkontakten und dem FHT80B immer in Ordnung ist :-\.
Hast Du hierfür eine Idee, wie ich dass am besten überwachen könnte.
Schöne Grüße
Hannes
Hallo Hannes,
Du könntest das Reading "warnings" vom FHT80B nehmen. Wenn der Sensor nicht mehr empfangen wird, kommt dann:
2014-09-13_14:27:43 FHT_0300 warnings: Fault on window sensor
Grüße,
Steve
Mir sind noch 2 Sachen in der 09_CUL_FHTTK.pm aufgefallen:
Zum einen eine Fehlermeldung im Log:
2014.12.21 11:39:12 1: PERL WARNING: Argument "0c" isn't numeric in numeric ne (!=) at ./FHEM/09_CUL_FHTTK.pm line 278.
2014.12.21 11:39:12 1: PERL WARNING: Argument "0f" isn't numeric in numeric ne (!=) at ./FHEM/09_CUL_FHTTK.pm line 278.
Zum anderen eine Falschmeldung im Log:
2014.12.21 11:54:02 3: CUL_FHTTK (vt_fk_ku) changed window state to open.
Sollte eigentlich "to closed" sein
Ersteres "!=" durch "ne" in Zeile 278 ersetzen.
Zweiteres in Zeile 176 "open" durch "closed" ersetzen.
einen schönen 4. Advent
Gerd
Hallo Gerd,
danke für die Hinweise.
Habe beides korregiert und eingecheckt.
Viele Grüße und schönen abend.
Steve
Zitat von: Matscher am 17 Dezember 2014, 11:50:15
Hallo Hannes,
Du könntest das Reading "warnings" vom FHT80B nehmen. Wenn der Sensor nicht mehr empfangen wird, kommt dann:
2014-09-13_14:27:43 FHT_0300 warnings: Fault on window sensor
Grüße,
Steve
Hallo Steve,
danke für den Tipp.
Schöne Weihnachten
Gruß Hannes
Gesendet von Tapatalk