Problem mit virtuellem Fensterkontakt

RaspiCOC · 19 Juli 2016, 14:49:22

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 · 19 Juli 2016, 15:03:49

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

Matscher · 19 Juli 2016, 15:11:39

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

satprofi · 23 Juli 2016, 09:54:51

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

RaspiCOC · 25 Juli 2016, 16:43:41

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 · 27 September 2016, 22:13:29

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:

Code Auswählen

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 · 28 September 2016, 13:43:09

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.

RaspiCOC · 28 September 2016, 17:39:35

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 · 29 September 2016, 10:00:08

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.

RaspiCOC · 29 September 2016, 10:21:24

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 · 06 Oktober 2016, 13:17:00

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?

RaspiCOC · 06 Oktober 2016, 15:37:01

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 · 06 Oktober 2016, 16:18:27

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.

RaspiCOC · 06 Oktober 2016, 16:25:28

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 · 06 Oktober 2016, 16:55:56

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

Okay ich habe jetzt mal 8 Fensterkontakte eingestellt.

RaspiCOC · 06 Oktober 2016, 16:59:28

Dann werde ich die 2 COC mal ordentlich quälen! Danke!

Feedback kommt asap!

RaspiCOC · 09 Oktober 2016, 22:05:42

Bingo, funktioniert! Vielen Dank!

Habe die angepasste Version geflasht und habe dann einen der bereits eigerichteten virtuellen FKs per resync mit dem FHT80 erneut verbunden. Also kein Sync von FHT80 aus gestartet. Anschließend funktionierte der virtuelle FK wie erwartet.

Da ich den COC auf einem separaten Pi (via ser2net) habe und der COC-Pi nur alle paar Wochen mal einen Neustart bekommt, werde ich jetzt mal über ein DOIF / AT /oder so meine virtuellen FKs nach Wiederauftauchen des COC sequentiell jeweil nach einer Stunde resyncen lassen.

Matscher · 10 Oktober 2016, 09:29:27

Danke für Dein Feedback! Das freut mich das zu lesen!

Dann ist es nur noch wichtig, das die virtuellen Fensterkontakte weiterhin im Takt bleiben und reagieren. Wenn dem so ist, könnte dann die CULFW Änderung ins Repository einfließen.

Danke und Grüße.

RaspiCOC · 10 Oktober 2016, 11:32:06

Ich werde jetzt mal Stück für Stück weitere virtuelle FKs pairen und hin- und wieder einen Reboot des COC durchführen.

Über das Ergebnis / Erfahrungen werde ich berichten! Vielen Dank noch mal!

Rasprobby · 24 Oktober 2016, 22:49:43

Nach einem Stromausfall muss ich leider meine Stellantriebe FHT 8v jedes Mal neu pairen.

Ist das auf die gleiche Ursache zurückzuführen, die ihr hier diskutiert?

Und wenn ja, gibt es einen Trick, mit dem man das neu pairen vermeiden kann?

Matscher · 25 Oktober 2016, 09:11:23

Zitat von: Rasprobby am 24 Oktober 2016, 22:49:43
Nach einem Stromausfall muss ich leider meine Stellantriebe FHT 8v jedes Mal neu pairen.

Ist das auf die gleiche Ursache zurückzuführen, die ihr hier diskutiert?

Und wenn ja, gibt es einen Trick, mit dem man das neu pairen vermeiden kann?

Ähnlich. Die FHT8v synchronisieren sich jedoch nach einer gewissen Zeit auch von selbst wieder. Das passiert bei den Fensterkontakten nicht.
Schau mal hier: https://forum.fhem.de/index.php/topic,19206.0.html Da wird das alles genauestens diskutiert.

Matscher · 14 Dezember 2016, 14:48:55

Zitat von: RaspiCOC am 10 Oktober 2016, 11:32:06
Ich werde jetzt mal Stück für Stück weitere virtuelle FKs pairen und hin- und wieder einen Reboot des COC durchführen.

Über das Ergebnis / Erfahrungen werde ich berichten! Vielen Dank noch mal!

Wie sind Deine Erfahrungen? Läuft alles so wie gewünscht?

Danke
Gruß,
Matscher

RaspiCOC · 14 Dezember 2016, 22:31:56

Oh weh, mir ist die Alexa-FHEM und noch ein SD-Kartencrash dazwischengekommen. Werde das jetzt wieder aufnehmen.

RaspiCOC · 27 Dezember 2016, 22:39:42

Verzeihung nochmal. Hat viel zu lang gedauert, bis ich das noch einmal ausgetestet habe. Ich habe auf Basis der neuen FW-Version jetzt mal ein Resync der bereits angelegten virtuellen FKs vorgenommen. Das hat sogleich funktioniert. Werde als nächstes schauen, was nach einem Reboot des COC passiert. Erfahrungsgemäß zeigt sich der "EA" Empfangsausfall ja auch erst nach geraumer Zeit.

RaspiCOC · 27 Dezember 2016, 23:04:25

Nach Reboot des COC und anschließendem ReSync der FKs reagiert der FHT wie gewünscht auf die Fensterkontakte! Grossartig!

Nimmst Du die erhöhte Anzahl von 8 FKs auch ins Repo auf? Sonst würde ich erst mal wieder auf die Stock-FW zurückgehen, um auf dem Standard zu bleiben.

RaspiCOC · 01 Januar 2017, 20:47:40

Ein kleineres Problem taucht auf. Immer mal wieder gehen die FHT auf "EA" Empfangsausfall. Kann es sein, dass die zeitliche Frequenz der Aussendungen des virtuellen FK etwas zu lang eingestellt ist?

Matscher · 01 Januar 2017, 21:32:57

Zitat von: RaspiCOC am 27 Dezember 2016, 23:04:25
Nach Reboot des COC und anschließendem ReSync der FKs reagiert der FHT wie gewünscht auf die Fensterkontakte! Grossartig!

Nimmst Du die erhöhte Anzahl von 8 FKs auch ins Repo auf? Sonst würde ich erst mal wieder auf die Stock-FW zurückgehen, um auf dem Standard zu bleiben.

Wenn alles funtkioniert, kann ich die 8 gern ins Repro aufnehmen.

Zitat von: RaspiCOC am 01 Januar 2017, 20:47:40
Ein kleineres Problem taucht auf. Immer mal wieder gehen die FHT auf "EA" Empfangsausfall. Kann es sein, dass die zeitliche Frequenz der Aussendungen des virtuellen FK etwas zu lang eingestellt ist?

Die Zeit wird aus dem FHT Code berechnet. Sind es immer die gleichen die ausfallen? Und tritt das ganze erst mit der Testversion auf? Wenn ja, kann ich mir vorstellen dass nach einem Rsync der Interval nicht mehr korrekt startet.

RaspiCOC · 22 Januar 2017, 20:58:51

Ja, in dieser Art tritt das nur mit der Testversion auf. Ich musste einen erneuten ReSync machen und dann war alles wieder gut.

Matscher · 23 Januar 2017, 16:31:18

Okay, ich habe noch etwas am ReSynchronisationsprozess geschraubt und hoffe das es jetzt auf Anhieb funktioniert. Weiterhin werden nur noch ~98 Credits pro Resync Prozess verbraucht.

RaspiCOC · 23 Januar 2017, 21:14:31

Geflasht, re-sync und jetzt schauen wir mal, was sich morgen so tut! Danke für die unendliche Geduld, zumal ich in letzter Zeit durch Abwesenheit geglänzt habe!

Werde gleich mal im Schlafzimmer das Fenster virtuell öffnen, denn wirklich öffnen geht gerade gar nicht (Note: für alle, die den Kontext später nicht mehr nachvollziehen können: aktuelle Aussentemperatur -14C) ....

Matscher · 24 Januar 2017, 17:06:07

Ja kein Thema.

RaspiCOC · 27 Januar 2017, 18:27:23

Also, immer wieder zwischendurch signalisiert der FHT80 einen Empfangsausfall. Das regelt sich dann allerdings nach ein paar Stunden wieder von alleine. Während des Empfangsausfalls reagiert der FHT80 auch nicht auf ein OPEN oder CLOSED. Das geschieht dann mitunter Stunden später. Der FHT80 hat einen RSSI von -72,5, also sicherlich nicht so ganz optimal. Das kann natürlich auch damit zusammenhängen.

Leider ist ein anderer FHT80 mit rein distanzmäßig optimalen Bedingungen einer, den ich nicht täglich sehe. Werde es aber auch noch dort versuchen.

RaspiCOC · 03 Februar 2017, 21:17:14

Nach ein paar weiteren Tagen taucht das "EA" Problem auch weiterhin bei den anderen FHTs auf. es löst sich zwar irgendwann von selbst,scheint aber auch zu erheblichen Verzögerungen von OPEN / CLOSED zu führen.

Matscher · 03 Februar 2017, 21:56:39

Danke für Deine Rückmeldung.

Dann ist der Synprozess immer noch nicht sauber. Ich setz mich die Tage nochmal dran und suche den Fehler.

Gruß,
Steve

RaspiCOC · 03 Februar 2017, 21:59:15

Kann ich das irgendwie unterstützen? Klingt etwas nach der Suche der Nadel im Heuhaufen...

Matscher · 06 Februar 2017, 09:05:55

Danke für Deine Hilfe und vor allem das Testen!

Der Abschluss der SyncPhase ist noch nicht korrekt. Ich werde nochmal paar Messreihen anlegen müssen. Ich melde mich wenn ich was habe.

RaspiCOC · 06 Februar 2017, 10:09:16

Ich habe zu danken!!! Werde geduldig und freudig warten!

Matscher · 20 Februar 2017, 21:26:36

So ich habe eine neue Version zum testen. Im Test sieht soweit alles gut aus. Der Interval wird nachdem resync wieder aufgenommen.

RaspiCOC · 20 Februar 2017, 22:18:42

:)Ist geflasht, resynce gerade die Fensterkontakte. Werde mal ein paar Tage beobachten, was passiert und melde mich dann zurück.

Danke für die Mühe!

RaspiCOC · 25 Februar 2017, 21:56:30

Traue es mich fast schon nicht, es zu schreiben. Nach so etwa 24 Stunden, fingen die FHTs wieder an Empfangsausfall zu signalisieren. Ich denke, ich kann Empfangsprobleme ausschließen, denn zumindest 3 der betroffenen FHTs sind nur bis zu 3m Luftlinie vom COC entfernt.

Kurz nochmal, was ich gemacht habe:

- geflasht
- reboot
- resync pro virtuellem Sensor

Was mir aufgefallen ist, ist das der COC seit dem resync der insgesamt 6 virtuellen FK kaum noch über 100 Credits kommt. Vorher lag der immer so um die 800. Irgendwie kann ich mir kaum vorstellen, dass die 6 virtuellen FK die Ursache sind.

Gibt es noch etwas, was ich mal ausprobieren soll?

Matscher · 01 März 2017, 09:21:15

Hmm mist aber nun gut. Der Weg wie Du es gemacht hast, ist so wie es sein soll.

Du könntest nachdem Du einen Sensor resynct hast, dessen Status mal ändern, ob der FHT diesen dann zeitnah mitbekommt. Ich denke da wird er schon aus dem Zeitfenster raus sein.

Du könntest mir noch die Addresscodes der verwendeten Kontakte geben.

Wegen den Credits: Ich erhöhe beim Resync die Credits um 510, da pro Resync 68 Pakete á 75ms kosten. Es würde ohne funktionieren, aber nur solang der COC/CUL nicht viel anderes nebenbei macht. Nachdem ReSync müßte jedoch wieder nach einer Stunde voll sein.

RaspiCOC · 01 März 2017, 18:08:14

Bin gerade bis Sonntag unterwegs und poste dann die Codes.

Matscher · 02 März 2017, 09:26:47

Okay alles klar. Danke

RaspiCOC · 02 März 2017, 09:39:45

Dank VPN kommeich zumindest an die Codes...

OG_ARB_FK_FAKE	86310A
OG_BAD_FK_FAKE	86320A
OG_ISE_FK_FAKE	86330A
OG_MAE_FK_FAKE	86350A
OG_SCH_FK_FAKE	86360A
OG_KLO_FK_FAKE	86340A

Ich hoffe nun inständig, dass die Codes nicht die Ursache des Problems sind....

Matscher · 02 März 2017, 10:21:17

Danke!

Nein, da diese ohne ReSync ja normal funktionieren.

Zumindest habe alle den gleichen Intervall von 4:12 min.

Matscher · 31 März 2017, 11:55:57

Hi,

ich habe leider noch keine vernünftige Lösung gefunden. Es läuft noch nicht zuverlässig, aber arbeite aber noch daran.

RaspiCOC · 12 April 2017, 16:44:27

Wie schön, dass die Heizperiode sich dem Ende zuneigt...