Problem mit virtuellem Fensterkontakt

Begonnen von RaspiCOC, 19 Juli 2016, 14:49:22

Vorheriges Thema - Nächstes Thema

RaspiCOC

Nachdem ja die FHT-Serie in den Ruhestand geht, ich sie aber noch immer einsetze und noch gern den einen oder anderen Fensterkontakt gehabt hätte, stelle ich mir nun die Frage,ob ich auch mit der OFFEN / GESCHLOSSEN-Information von anderen Sensortypen den FHT80 mitteilen kann, dass die Fenster-Offen-Temperatur genutzt werden soll, also der Fenster-Offen-Zustand ausgelöst wird.

Hat da jemand eine Idee? So wie ich das sehe, kann ich derzeit nur die "window-open-temp" per set an den FHT80 senden.

Puschel74

Zitatich sie aber noch immer einsetze und noch gern den einen oder anderen Fensterkontakt gehabt hätte
Sorry für OT aber vielleicht kann dir im Marktplatz geholfen werden  ;)
https://forum.fhem.de/index.php/topic,28385.msg212505.html#msg212505
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Matscher

Zitat von: RaspiCOC am 19 Juli 2016, 14:49:22
Hat da jemand eine Idee?

Ab CUL Firmware 1.62 kann ein virtueller FHT Fensterkontakt verwendet.

Beschrieben ist es hier:
http://www.fhemwiki.de/wiki/CUL_FHTTK

Gruß,
Matscher
Rasp 3
CUL V3 868Mhz + nanoCUL 868Mhz als RFR + nanoCUL 868Mhz für Homematic + SIGNALduino
Zigbee CC2531 - Aquara TempSensor
MySensors Ethernet Gateway, Water meter, Gas meter
Modul: 09_CUL_FHTTK.pm (assumed), culfw part HAS_FHT_TF

satprofi

Hallo. Die gibts doch bei Conrad
Und ja,ich verwende den auch um offene Fenster od. Türen dem Heizkörper mit HomeMatic mitzuteilen.

send from OP3

gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

RaspiCOC

ZitatAb CUL Firmware 1.62 kann ein virtueller FHT Fensterkontakt verwendet.

Na, dann werde ich wohl gelegentlich (der Winter braucht ja noch etwas Zeit) den zweiten COC auch noch updaten müssen.

Danke für den Hinweis!

RaspiCOC

Ich habe meine zwei COC auf RPi über ser2net an meinen FHEM-RPi angebunden. Wollte 6 virtuelle FKontakte anlegen. Wohl wegen hoher Funkauslastung scheiterte das Anlernen der letzten 2 virtuellen Kontakte. Habe dann den COC-Rpi neu gestartet und konnte die verbleibenden zwei virtuellen Kontakte anlernen.

Nun blinken an den vier zuerst angelernten FHT80 die Fenstersymbole (Empfangsausfall).

Was mache ich hier eventuell falsch? Irgendwie scheint ein Reboot des COC-RPi die Synchronisation zu killen.

Im Eventmonitor sehe ich nur noch in regelmäßigen Abständen die Statusmeldungen der nach Reboot angelernten Kontakte.

Der Buffer (get RCOC raw T12) zeigt: RCOC raw => 00:86310A02 01:86320A02, was die zwei zuletzt angelernten Kontakte sind.

Meine Definition sieht wie folgt aus:

define OG_ARB_FK_FAKE CUL_FHTTK 86310A
attr OG_ARB_FK_FAKE IODev RCOC
attr OG_ARB_FK_FAKE model dummy


Fehlt da vielleicht etwas oder muss ich nach einem Neustart erst mal einen Status "open / closed" senden?

Matscher

ZitatWollte 6 virtuelle FKontakte anlegen.

Im Moment werden nur 4 Kontakte unterstützt. Kann in der "fht.h" von der CulFirmware leicht angepasst werden. Nach einem Reset sind die Daten in der FW weg und müssen wieder neu hinzugefügt und angelernt werden. Gleiches Verhalten wie beim direkten Steuern von FHT8V.
Rasp 3
CUL V3 868Mhz + nanoCUL 868Mhz als RFR + nanoCUL 868Mhz für Homematic + SIGNALduino
Zigbee CC2531 - Aquara TempSensor
MySensors Ethernet Gateway, Water meter, Gas meter
Modul: 09_CUL_FHTTK.pm (assumed), culfw part HAS_FHT_TF

RaspiCOC

Ok, das erklärt das Verhalten, weshalb ich keine Probleme mit den ersten 4 hatte.

Was ich aber nicht verstehe ist, weshalb mir das Pairing bei einem Reset um die Ohren fliegt. Meine Annahme wäre hier gewesen, dass ich doch dem FHT80 beigebracht habe, auf den virtuellen FHT80TF zu reagieren. Das vergisst der FHT80 ja durch den Reset des COC nicht. Gut, der COC hat durch das Pairing begriffen, dass er in regelmäßigen Abständen den zuletzt angelieferten Zustand "open" / "closed" senden soll. Durch den Reset hat er diese Aufgabe sicherlich vergessen. Wenn ich also nach einem Reset ein "set virtual_FK open" absetze, dann sollte der FHT80 damit was anfangen können (konnte das auch im Event Monitor sehen) und der COC hoffentlich weiter periodisch senden, oder? Das habe ich allerdings versucht und leider keinen Erfolg gehabt - die FHT80 haben nicht weiter reagiert.

Gibt es denn noch irgendeine Möglichkeit nach einem Reset die Dinger ohne PROG - FEN - PROG - FUNC wieder zum kommunizieren zu bringen? Wenn nicht, dann werde ich das Projekt virtuelle FK wieder einstampfen, da das so in Bezug auf Ausfallsicherheit und Nutzen nichts bringt. Dass hier noch mal irgendwelche Änderungen an der CUL_FW vorgenommen werden, kann ich mir nicht vorstellen und erwarte das auch nicht, da die FHT ja nun auch ein Auslaufmodell sind  :(

Matscher

Stimmt, die Synchronisierungsphase nach "Batteriewechsel" fehlt. Das bedeutet theoretisch, das innerhalb einer Minute im Sekundentakt ein Status geschickt werden muss, damit der FHT80 in den Takt des Fensterkontaktes kommt. Das kann per FHEM im Moment nicht gesteuert werden, dazu müsste ich den Part in der CUL_FW anpassen. Aber das ist ein guter Hinweis, das Problem hatte ich bisher noch nicht wirklich. Ich betreibe zur Zeit nur einen virtuellen Kontakt. Ich schau mir das demnächst mal an.
Rasp 3
CUL V3 868Mhz + nanoCUL 868Mhz als RFR + nanoCUL 868Mhz für Homematic + SIGNALduino
Zigbee CC2531 - Aquara TempSensor
MySensors Ethernet Gateway, Water meter, Gas meter
Modul: 09_CUL_FHTTK.pm (assumed), culfw part HAS_FHT_TF

RaspiCOC

Das wäre natürlich wirklich cool!

Mir kommen dabei allerdings zwei Gedanken:

1.) Welchen Status würde der virtuelle Kontakt bei seiner Synchronisation senden? Ich nehme an, er könnte nur per Default ein "closed" senden, denn der COC/CUL/CUN... kennt ja zu diesem Zeitpunkt keinen echten Status.

2.) Habe ich mehrere virtuelle FKs, dann müsste sichergestellt werden, dass die nacheinander über einen gestreckten Zeitraum die "Batteriewechsel"-Synchronisation senden, denn sonst schlägt die 1% Regel unerbittlich zu und es würde auf Tage hinweg nichts mehr gehen. Den aus der gestreckten Synchronisation resultierenden temporären Ausfall würde man wohl hinnehmen müssen.

Nach meinem Planungsstand würde ich wenigstens 7 virtuelle Kontakte einrichten wollen. Die wären für die Räume, in denen es bislang keine FHT80TF gibt und in denen das Fenster "open" von 3rd Party Kontakten geliefert werden würde und für die Räume, in denen es zwar einen FHT80TF gibt aber zusätzliche 3rd Party Sensoren, auf die auch reagiert werden soll. Ggf. ein oder zwei (etagenbezug) "globale"-Kontakte für einen zentralen Absenkbetrieb. Die wären dann jeweils an mehr als nur einem FHT80 angelernt.

Hinweis: Durch den Einsatz zweier COC liegt mein Credit selten unter 700, so dass ich davon ausgehe, dass die zusätzliche Funklast verkraftbar wäre.

Matscher

So ich habe mal eine erste "Lösung" eingebaut.

Zitat1.) Welchen Status würde der virtuelle Kontakt bei seiner Synchronisation senden? Ich nehme an, er könnte nur per Default ein "closed" senden, denn der COC/CUL/CUN... kennt ja zu diesem Zeitpunkt keinen echten Status.
Vorerst habe ich "closed" eingetragen, wenn alles passt kann ich mir darüber auch noch Gedanken machen und den aktuellen Status vom Sensor zum Beispiel vom FHEM Modul mit übergeben zu lassen.

Zitat2.) Habe ich mehrere virtuelle FKs, dann müsste sichergestellt werden, dass die nacheinander über einen gestreckten Zeitraum die "Batteriewechsel"-Synchronisation senden, denn sonst schlägt die 1% Regel une...
Das ist schon etwas komplizierter und wenn das auch die CUL_FW übernehmen müsste, würde das mehr Speicherverbrauch bedeuten. Im Moment könnte man jeden sofort synchronisieren, was natürlich den LOVF zu Folge hat. Wenn alles klappt, würde ich das versuchen im Modul zu verriegeln.

Das 09_CUL_FHTTK.pm habe ich schon für das "ReSynchronisieren" angepasst und ist per update verfügbar.

Hast Du die Möglichkeit dies zu testen?

Rasp 3
CUL V3 868Mhz + nanoCUL 868Mhz als RFR + nanoCUL 868Mhz für Homematic + SIGNALduino
Zigbee CC2531 - Aquara TempSensor
MySensors Ethernet Gateway, Water meter, Gas meter
Modul: 09_CUL_FHTTK.pm (assumed), culfw part HAS_FHT_TF

RaspiCOC

Ja, denke, das werde ich am Wochenende schaffen. Ich nehme an, dass ich beim COC mit One-Wire die COC.hex nehmen muss, oder? Ansonsten doch sicherlich alles in Analogie zu den bekannten Anleitungen, oder?

Ich werde jetzt erst mal nur einen FK verwenden und die übrigen löschen. Sollte ja für einen Test erst mal reichen. Die Annahme wäre: FK anlernen, COC Reboot, Synchronisation des FK-Sensors ist weiter vorhanden.

Ist da jetzt noch eine Limitierung der Anzahl drin?

Vielen Dank, finde ich super, dass Du Dich der Sache angenommen hast!

Matscher

Gern :)

Bei beiden Versionen wäre OneWire dabei. Ich wusste nur nicht welches COC Du hast, deswegen habe ich gleich beide an gehangen. Wie bei den Anleitungen beschrieben vorgehen. Da hat sich nichts geändert.

ZitatDie Annahme wäre: FK anlernen, COC Reboot, Synchronisation des FK-Sensors ist weiter vorhanden.
Nicht ganz, die Synchronisation muss via dem FHEM Modul angestoßen werden, weil die FW das nicht permanent speichert. Mit "set FK ReSync" aus FHEM heraus wird der  Fensterkontakt wieder eingetragen und die ca. 1 minütige Synchronisation durchgeführt. Fertig. Somit entfällt das erneute "pairen" mit den FHT80B.

"FK anlernen, COC Reboot, FHEM set FK ReSync, Synchronisation des FK-Sensors ist wieder vorhanden" -> das wäre ideal :)

Ja im Moment ist die Limitierung auf 4 Fensterkontakte weiterhin enthalten. Kann ich aber dann für Dich gern hoch drehen, würde dies aber ungern für alle culfw Versionen machen.
Rasp 3
CUL V3 868Mhz + nanoCUL 868Mhz als RFR + nanoCUL 868Mhz für Homematic + SIGNALduino
Zigbee CC2531 - Aquara TempSensor
MySensors Ethernet Gateway, Water meter, Gas meter
Modul: 09_CUL_FHTTK.pm (assumed), culfw part HAS_FHT_TF

RaspiCOC

Sorry, muss nochmal nachfragen. Ich nutze den COC ausschließlich für die FHT80 Kommunikation. Aktuell habe ich die FW für COC mit RTC und One-Wire drauf. Welche Version ist dann die richtige?

Das mit dem ReSync ist hilfreich. Dann kann ich ja auch mit Bordmitteln den ReSync zeitlich verteilen.

Matscher

Die COC.hex wäre die richtige, die COC.radio_only.hex ist ohne OneWire.

Okay ich habe jetzt mal 8 Fensterkontakte eingestellt.
Rasp 3
CUL V3 868Mhz + nanoCUL 868Mhz als RFR + nanoCUL 868Mhz für Homematic + SIGNALduino
Zigbee CC2531 - Aquara TempSensor
MySensors Ethernet Gateway, Water meter, Gas meter
Modul: 09_CUL_FHTTK.pm (assumed), culfw part HAS_FHT_TF