Virtueller FHT80TF in fhem an FHT80b anmelden klappt einfach nicht

Begonnen von jksd, 28 Dezember 2014, 20:29:54

Vorheriges Thema - Nächstes Thema

jksd

Hallo,
habe schon einige FS20 und HomeMatik-Komponenten im Einsatz. Aus alten Tagen habe ich im Wohnzimmer einen FHT80b Heizungsregler im Einsatz, den ich jetzt mit einem HomeMatik-Türkontakt koppeln möchte.

Als Hilfsmittel bediene ich mich des virtuellen FHT80TF. Die 09_CUL_FHTTK.pm habe ich auf den neusten Stand gebracht (21.12.14, r7294).


# ID habe ich wie folgt definiert:
# Definition der ID 0xabcdef:
#
# Byte 1: HC1 (ab)
# Byte 2: HC2 (cd)
# Byte 3: Adress-Byte (ef)
#
define FHT80TF_Fenster_virtuell CUL_FHTTK 0C220A
attr FHT80TF_Fenster_virtuell model dummy


Die HC1/HC2 = 0c22 habe ich aus der Definition des FHT80b in fhem entnommen. Die Adresse 0A habe ich frei gewählt.

Ich habe dann den FHT80b in den Anmelde-Modus gebracht (PROG -> FEn -> PROG -> Function). Das Display zeigt "Code".

Dann habe ich in fhem "set FHT80TF_Fenster_virtuell Syncing" gestartet.

Mit Loglevel 5 sehe ich die Meldung

2014.12.28 19:49:04 5: CUL_FS20 sending T0c220a0c
2014.12.28 19:49:04 5: SW: T0c220a0c


Sieht zunächst gut aus.

ABER:
Was fehlt ist die Quittung dazu (T0c220a0f). Am FHT80b wird ebenfalls nichts angemeldet.
Auch längeres Warten/mehrere Versuche bringen keine Veränderung.

Was habe ich falsch gemacht ?

Danke im Voraus für Eure Hilfe !

stromer-12

FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

jksd

get CUL_HM1 raw V

liefert:

CUL_HM1 raw => V 1.61 CUL868

Bin mit dem Hinweis mal auf dem culfw trunk schauen gegangen: In der dort entstehenden V1.62 steht "- HAS_FHT80_TF by Matcher (Forum #29677)".

=> Ist das schon des Rätsels Lösung ? Wann wird die V1.62 offiziell freigegeben ?

stromer-12

FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

jksd

Habe die 1.62 gerade von sourceforge geladen.
Werde sie voraussichtlich aber erst morgen Abend ausprobieren können.

Vielen Dank für die schnellen Antworten !

rudolfkoenig

Wenn man CULflash in FHEM verwendet, dann wird zuerst die tagesaktuelle CUL_V*.HEX von fhem.de heruntergeladen und dann verwendet.

jksd

Moin moin,

habe den CUL gerade auf die V1.62 von gestern Abend aktualisiert.

get CUL_FS20 raw V

liefert jetzt:
CUL_FS20 raw => V 1.62 CUL868

Nach dem erneuten Anmelde-Versuch bekomme ich trotzdem keinen Erfolg.

Habe die Loglevel für CUL_FS20, FHT80b und den virt. FHT80TF_Fenster_virtuell auf 5 gesetzt (Rest auf 1).

attr CUL_FS20 verbose 5
attr Heizung_Wohnz verbose 5    # FHT80b
attr FHT80TF_Fenster_virtuell verbose 5


Logmeldungen, die durch Absetzen von "set FHT80TF_Fenster_virtuell Syncing" generiert werden:

2014.12.29 11:33:16 5: FHT80TF_Fenster_virtuell option: Syncing and value:
2014.12.29 11:33:16 3: CUL_FHTTK (FHT80TF_Fenster_virtuell) syncing with FHT80b.
2014.12.29 11:33:16 5: CUL_FS20 sending T0c220a0c
2014.12.29 11:33:16 5: SW: T0c220a0c
2014.12.29 11:33:16 5: FHT80TF_Fenster_virtuell option: ? and value:
2014.12.29 11:33:16 5: FHT80TF_Fenster_virtuell option: ? and value:
2014.12.29 11:33:16 5: FHT80TF_Fenster_virtuell option: ? and value:
2014.12.29 11:33:16 5: FHT80TF_Fenster_virtuell option: ? and value:

Was bedeutet "FHT80TF_Fenster_virtuell option: ? and value: " ?

Habt Ihr noch Ideen für mich ?

rudolfkoenig

Es ist eine Debug-Meldung in FHEM/09_CUL_FHTTK.pm/CUL_FHTTK_Set, um mitzukriegen, welche set Befehle/Parameter das Modul bearbeiten soll. "set Name ?" wird typischerweise vom FHEMWEB aufgerufen, um das Dropdown mit den moeglichen Parametern anbieten zu koennen.
-> Nichts auffaelliges.

stromer-12

Wenn du wie im ersten Post mit dem Anmelden peeren vorgegangen bist, sollte es passen.

mit "get CUL_FS20 raw T12" kannst du sehen ob der CUL deinen virtuellen FK im Buffer hat.
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

jksd

GELÖST:

Am Ende war es eigentlich einfach, wenn man zuvor nicht von falschen Voraussetzungen ausgeht.

1.) Haus-Code HC1/HC2 von FHT80b und FHT80TFs muss NICHT übereinstimmen.
2.) Der Haus-Code der FHT80TFs darf jedoch NICHT unter 0x69 liegen (steht in dem Posting-Link von stromer-12).

Ich habe jetzt den Haus-Code 83C0 für meinen virtuellen FHT80TF frei gewählt (bzw. aus dem Posting übernommen).

Anlernen funktionierte dann wie erwartet.
> FHT80b zeigt nach dem Anlernen "EA" => OK
> fhem: get CUL_FS20 raw T12 liefert: CUL_FS20 raw => 00:83C0D702 => OK

Nach ca. 1 min erkennt der FHT80b jetzt Fenster auf/zu  :D :D :D

Vielen Dank für Eure Unterstützung !
Hoffe, meine Erfahrungen helfen Nachahmern weiter. Viel Glück.


Mitch

FHEM im Proxmox Container

Matscher

Ja damit funktioniert es auch. Die cuno FW hatte ich auch angepasst.
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

jksd

Noch ein Vorschlag:

Würde es nicht sinn machen, auf die ungültigen Hauscodes mit einem Logeintrag / einer Fehlermeldung hinzuweisen ? Wäre viel intuitiver...

Matscher

Habe einen Check plus Meldungen ins Modul eingebaut. Wird morgen mit dem Update verteilt.
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

Mitch

Zitat von: Matscher am 30 Dezember 2014, 08:01:42
Ja damit funktioniert es auch. Die cuno FW hatte ich auch angepasst.

Also irgendwie funzt das nicht.

Ein get DUNO raw T12 liefert CUNO raw => No answer

Meine CUNO Version: V 1.62 CUNO868
FHEM im Proxmox Container