Fehler in fht.c?

[Rocktagon]

in der fht.c Zeile 371

Code Auswählen Erweitern

   if(fi4 != fht_hc0 &&                // Foreign (not our) FHT/FHZ, forget it
       fi4 != 100 &&    

müßte das nicht (fi0 != fht_hc0) heißen?
Ansonsten versteh ich den sinn der anweisung nicht so ganz.

[rudolfkoenig]

Ich meine nein: ein FHT sendet ein Telegramm, was nicht an uns (fht_hc0) oder an unbekannt (100) gerichtet ist, also ignorieren. fi0+fi1 ist Absenderaddresse der FHT.

[Rocktagon]

Ah ok. Also ist bei ACK das 4 Byte das paring Byte.

Versuche gerade der Reihenfolge der Handshakes auf den Grund zu kommen um einem FHT80b was zu senden.
Dazu lese ich den gesammten Verkehr zwischen der FHZ und der FHT Byteweise mit.
Das Problem ist halt das ich nicht sehe welche Daten aus welcher Richtung kommen.
Daher hatte ich mal geschaut ob ich in dem CUL Code was brauchbares finde.

Kurzer Sinneserklärung:
Ich habe einen Arduino mit RX/TX868 aus FS20 Komponenten, Lan, SD Karte und RS485.
Dieser dient als "Hausserver", liest die RFID Chips an den Türen sowie die Heizung (Viessmann) aus und soll dementsprechend schalten (FS20 und FHT80b).
Bis auf das senden an ein FHT80b Raumregler klappt schon alles.

[rudolfkoenig]

> Das Problem ist halt das ich nicht sehe welche Daten aus welcher Richtung kommen.

Ein FHZ setzt im vorletzten Byte das 5. bit, das FHT nicht.

[Rocktagon]

Stimmt das hatte ich mal irgendwo gelesen (aber wieder vergessen^^).
Danke, macht die Sache einfacher.

Bei 119 (Bit: 01110111) wäre das also die FHT80b
Und 121 (Bit: 01111001) wäre das die FHZ

Dann wäre das ganze ja so zu verstehen (alle Zahlen dezimal):

RAW  17 28   0 166  0 223 // Ventielstellung - Empfang von FHT80b
RAW  17 28 125 119  4  49 // FHT80B Sendet Empfangsbereit, Byte 4 ist das paring Byte
RAW  17 28  65 121 30  17 // FHZ sendet Solltemp (15 Grad)
RAW  17 28  75 119 30  25 // FHT80B bestätigt
RAW  17 28 126 119 30  76 // FHT80b sendet übertragungs Ende

Aber wie passt dann das:

RAW  17 54 125 119   4  75 //FHT sendet Empfangsbereit
RAW  17 54  66 121 193 207 //FHZ (121) sendet 66=0x42 = Ist Temp Low Byte ???
RAW  17 54  67 121   0  15 //FHZ (121) sendet 67=0x42 = Ist Temp High Byte ???
RAW  17 54  75 119   0  21 //FHT bestätigt
RAW  17 54  68 121   0  16 //Batteriestatus
RAW  17 54  75 119   0  21 //FHT beendet Übertragung

Müßten dann bei den 3 Befehlen (66,67,68) nicht eigentlich 121 sein?
Irgendwo habe ich da noch ein Fehler im System.

[rudolfkoenig]

Ich meinte es von unten, oder auch (1<<4).
Da ich fuer solche Aufgaben hex mehr mag:
Dec 17 54 125 119 4 75 == Hex 1136 7d 77 04 (4b)

1136: FHT-Id
7d = start-xmit (siehe fhem/FHEM/11_FHT.pm)
77 = s.u.
04 = FHZ-Id
4b = RSSI

77: kenne die Bedeutung der Bits nicht wirklich, aber wenn es vom FHZ kommt, dann ist es 7x, wenn vom FHT dann 6x, wobei x ueblicherweise 7 oder 9 ist.

[Rocktagon]

Ok, Danke vielmals. Werd morgen mal weiter basteln. Aber langsam kommt mal Licht ins Dunkel :)

[Rocktagon]

Für den Fall das noch mal wer nach der direkten Kommunikation mit einem FHT80b sucht:
Das 4 Byte teilt sich wie folgt auf:
unteren 4 Bit -> Befehl
Bit 5 -> Batterie Warnsignal Erlaubniss
Bit 6 -> Erweiterungsbit, 1 wenn mit Erweiterungsbyte
Bit 7 -> BiDi Befehl (bei Kommunikation mit Ventilen immer aus, bei FHZ immer an - ausnhame Fensterkontakte)
Bit 8 -> 1 Wenn der vorherige Befehl nur wiederholt wird

Heißt zb bei 0x67 (103)
01100111:
0 Keine Wiederholung
1 BiDi Befehl
1 mit Erweiterungs Byte
0 Momentan würde keine Batteriewarnung ausgegeben
0 0111 -> Befehl 7
1
1
1

Bei den Bedeutung der Befehle kann man hier gucken: http://fhz4linux.info/tiki-index.php?page=FHT%20protocol

Wobei noch ein zu eränzen wäre:
7 -> Nachricht kommt vom Empfänger
9 -> Nachricht kommt vom Sender

Die restlichen "unbekannt" dürften auch der Kommunikation mit einer FHZ dienen, die Bedeutung ist Mir (noch) unbekannt.
Ablauf zb bei einem Temperatur setzen:
FHZ wartet bis die entsprechende FHT 0x7d (125) sendet (empfangsbereit) mit Befehl 7.
FHZ sendet 0x41 (65) mit Befehl 9 und der neuen Temperatur
FHT quittiert 0x4b (75) mit Befehl 7 und der neuen Solltemp
FHT beendet 0x7e (126) mit Befehl 7

Innerhalb einer kompletten Sendung müßen empfänge quittiert werden da die FHT sonst in eine wiederholungsschleife fällt.
Dazu reicht ein senden von der FHZ mit 4b (75) und Befehl 7(Empfänger) im 4 Byte nach einem Empfangenen Sendebefehl der FHT.