[gelöst] Versuch raw send für FHT TF-2 zu implementieren

[Matscher]

Hallo,

ich habe mich mal mit der CUL Firmware befasst. C ist jetzt nich so meins, aber ich habe einen ersten Versuch gestartet. Und zwar möchte ich RAW send auch für die Fensterkontakte einbauen (habe FS20 SI als Sensor von Reedkontakten und eine FHT80b). Das synchronisieren bzw. anmelden habe ich mit untenstehenden Code-Snippet hinbekommen. Dabei wird als erstes ein 0x0C Befehl und danach ein 0x0F als Sucsessbefehl gesendet.

Beispiel:

Code Auswählen Erweitern

set CUL raw T86310A0C
set CUL raw T86310A0F

Danach steht EA im FHT 80 und wenn ich dann noch ein Status sende, zum Beispiel "set CUL raw T86310A01" für Fensterzustand auf, steht "Auf" im Display. Wenn ich jedoch den Status wieder ändern möchte in geschlossen (set CUL raw T86310A02), funktioniert es nicht mehr, bzw. nur durch Zufall mal. Später sendet die FHT auch eine Warning vom Fensterkontakt "warnings: Fault on window sensor". Hat jemand eine Idee oder kann es jemand mal bei sich ausprobieren? Ich meine das ich es einmal während meiner Testphase hatte, das ich 5 mal nacheinander den Zustand ändern konnte.

Benutzt habe ich die "addParityAndSend(..)" Methode.

FHT.c

Code Auswählen Erweitern


...
DNL();

  } else {
fromhex(in+1, fhttf, 4);
 
// FHT TF window sensor
if(fhttf[0] >= FHT_TF_START) { // start at 0x69
 
// 1x sync 0x0c and 1x success 0x0f finish
addParityAndSend(in, FHT_CSUM_START, 2); // send FHT data
return;
}

Viele Grüße,
Steve

[Matscher]

Ich glaube ich war und bin immer in dem Intervall, wenn die Sende- und Empfangseinheit deaktiviert wird, um Strom zu sparen. (Sendeintervall = 115+0,5*4 = 117 Sekunden)

Das teste ich mal händisch und wenn es das ist muss ich die fht.c noch ein wenig erweitern

Gruß,
Steve

[Matscher]

So nach langen Tests kann ich einen virtuellen FHT TF an einer FHT80b anmelden und betreiben. Der Hauptintervall ist 240 + x Sekunden, wobei x aus dem ersten Byte des Hauscodes des FHT TF berechnet wird. Dieser Intervall dient meiner Meinung nach vorrangig der Mitteilung des Battieriestatus und als keep alive. Ein Statuswechsel, z.B. von Closed auf Open, wird innerhalb dieses Intervalls bearbeitet und jeweils in einem Zeitraster von (240 + x) /4 Sekunden bearbeitet und anschließend nochmal nach (240 + x) /4 Sekunden wiederholt. Danach wird dieser Status nach 240 + x Sekunden als von mir bezeichneter Hauptintervall wiederholt.

Code Auswählen Erweitern

(125 * (240 + ((fhttfhc0 & 0x7) * 2)));

Implementiert ist es so ähnlich wie die FHT8v Unterstützung. Nach einem Reset des CULs, muss wieder neu gesync werden. Im Moment läuft ein Dauertest, um meine Theorie zu bestätigen. Ich konnte aber reproduzierbar in verschiedenen Zeitabständen, verteilt über 1 h, den virtuellen FHT TF schalten und somit der FHT80b einen Fensterstatus mitteilen.

Es kann möglich sein, das die FHT80b nach einem Timeout des Fensterkontaktes öfter auf Empfang geht und sobald sie den Fensterkontakt wieder "hört" den neuen Interval annimmt.

Was mich noch interessieren würde, wie lang die FHT80 auf Empfang bleibt. Ich meine mal gelesen zu haben, das es sich um eine Sekunde handelt...

[Matscher]

Mit Hilfe von stromer-12 wird der Intervall aus dem Adressbyte so

Code Auswählen Erweitern

(125 * (240 + (16 - (fht_tf_addressBytes & 0x7) * 2)))

berechnet.

Diskussionsthread dazu

Und entsprechender Wiki-Eintrag ist hier zu finden.

Btw: Es können jetzt bis zu 4 FHT80TF mit einem CUL simuliert werden.