Virtueller FHT80TF in fhem an FHT80b anmelden klappt einfach nicht

jksd · 28 Dezember 2014, 20:29:54

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).

Code Auswählen


# 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

Code Auswählen


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 · 28 Dezember 2014, 21:18:36

Ist dein CUL mit der richtigen Firmware geflasht?

jksd · 28 Dezember 2014, 22:11:14

Code Auswählen

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 · 28 Dezember 2014, 22:21:41

Keine Ahnung wann diese aktuell wird.
Bei mir läuft http://forum.fhem.de/index.php/topic,27465.msg220237.html#msg220237diese auf dem CUL.

jksd · 28 Dezember 2014, 22:24:51

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 · 29 Dezember 2014, 10:07:18

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

jksd · 29 Dezember 2014, 11:40:25

Moin moin,

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

Code Auswählen


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).

Code Auswählen


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 · 29 Dezember 2014, 12:21:08

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 · 29 Dezember 2014, 15:41:34

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.

jksd · 29 Dezember 2014, 22:18:28

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:

Code Auswählen

get CUL_FS20 raw T12 liefert: CUL_FS20 raw => 00:83C0D702 => OK

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

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

Mitch · 29 Dezember 2014, 22:31:23

Blöde Frage, geht das auch mit dem CUNO?

Matscher · 30 Dezember 2014, 08:01:42

Ja damit funktioniert es auch. Die cuno FW hatte ich auch angepasst.

jksd · 30 Dezember 2014, 19:04:46

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 · 08 Januar 2015, 20:52:42

Habe einen Check plus Meldungen ins Modul eingebaut. Wird morgen mit dem Update verteilt.

Mitch · 12 Januar 2015, 20:08:13

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

Code Auswählen

get DUNO raw T12 liefert

Code Auswählen

CUNO raw => No answer

Meine CUNO Version: V 1.62 CUNO868

Matscher · 12 Januar 2015, 20:33:49

Wann hattest Du den CUNO geflasht? Vor dem 4.12.2014?

Mitch · 12 Januar 2015, 20:47:50

Nein, am 28.12. oder 29.12.

Matscher · 12 Januar 2015, 21:17:15

Okay, scheint das flashen nicht geklappt zu haben. Die Änderung ist seit 4.12. eingecheckt. Was anderes sehe ich im Moment nicht, warum es nicht funktionieren sollte. Die Board.h des CUNO2 hat das Define für den TF definiert. Kannst Du es nochmal probieren?

Latest FW:
http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/CUNO2/CUNO2.hex

Mitch · 12 Januar 2015, 21:38:33

so, nochmal geflshed. Wieder ohne Fehler.

get CUL_FS20 raw T12 = no answer

Ausserdem wird der CUNO bei raw T12 immer diconnected?

Code Auswählen

2015.01.12 21:36:26 3: CUNO: Possible commands: mBbCFZiAGMRTVWXOefltuHxEcq
2015.01.12 21:36:26 1: 192.168.0.48:2323 reappeared (CUNO)
2015.01.12 21:36:26 1: 192.168.0.48:2323 disconnected, waiting to reappear (CUNO)

stromer-12 · 12 Januar 2015, 21:49:54

dein CUNO ist nicht erreichbar.

bei mir ergibt:

Code Auswählen

fhem> get CUL_. raw T12
CUL_0 raw => 00:86310A02 01:8674C202
CUL_1 raw =>

CUL_0 ist ein CUL mit Firmware V 1.61 CUL868 hier aus dem Thread
CUL_1 ist ein CUNO mit alter Firmware V 1.52 CUNO868

Mitch · 12 Januar 2015, 22:06:11

Nein, der CUNO war schon verfügbar, wurde aber durch T12 disconnected.

Hab ihn jetzt noch mal rebootet und jetzt kommt bei T12: CUNO raw => TC7309F82F8
Nochmal getestet: no answer und er wird kurz disconnected

Gebe ich in der Befehlzeile direkt get CUNO raw T12 ein, kommt CUNO raw => N/A aber er wird nichts disconnected

Matscher · 13 Januar 2015, 09:34:08

ZitatGebe ich in der Befehlzeile direkt get CUNO raw T12 ein, kommt CUNO raw => N/A aber er wird nichts disconnected

Das ist das erwartete Ergebnis von T12. Dein CUNO hat die passende FW. Warum das andere Problem auftaucht, kann ich nicht sagen. Was ist denn der alternative Weg zu get CUNO raw T12? Kenne mich mit CUNOs nicht aus. Bei stromer-12 wird, unabhängig von der FW, der CUNO schonmal nicht disconnected.

StefanW · 05 November 2015, 08:57:37

Hallo,

ich grabe das Thema noch mal aus, da ich ums verrecken keinen virtuellen FT80TF an mein FHT80b angelernt bekomme.

Definiert ist der Dummy so:

define FHT80TF_Fenster_virtuell CUL_FHTTK 83C00A
attr FHT80TF_Fenster_virtuell model dummy

Sync wird auch gestartet, aber beim FHT kommt einfach nix an.
2015.11.05 08:46:01 3: CUL_FHTTK (FHT80TF_Fenster_virtuell) syncing with FHT80b.

Mit "get CUL_0 raw T12" bekomme ich allerdings keine Ausgabe. (CUL_0 raw => )
Firmware ist die neuste aus dem SVN geflasht. (V 1.65 CUL868)
Allerdings ist mein CUL noch ein V2.
Ist diese Funktion vllt noch nicht in die V2-Firmware implementiert?

Ich hoffe, ihr könnt mir da weiterhelfen.

Gruß
Stefan

Matscher · 05 November 2015, 13:40:55

Hallo Stefan,

Zitat von: StefanW am 05 November 2015, 08:57:37
Mit "get CUL_0 raw T12" bekomme ich allerdings keine Ausgabe. (CUL_0 raw => )
Firmware ist die neuste aus dem SVN geflasht. (V 1.65 CUL868)
Allerdings ist mein CUL noch ein V2.
Ist diese Funktion vllt noch nicht in die V2-Firmware implementiert?

richtig, für den CUL V2 ist diese Funktionalität nicht enthalten. Ist dem geringeren Speicher geschuldet.

In der board.h kannst Du im Block vom V2

Code Auswählen


#ifdef CUL_V2
#  define TTY_BUFSIZE           48
#  define FHTBUF_SIZE           74
#  define RCV_BUCKETS            2 
#  define RFR_SHADOW                    // PROGMEM: 10b    RAM: -(TTY_BUFSIZE+3)
#  define HAS_TX3
#  define HAS_HOERMANN
#  undef  HAS_CC1101_RX_PLL_LOCK_CHECK_TASK_WAIT
#endif

es mit

Code Auswählen


#  define HAS_FHT_TF

hinfügen und neu compilieren.

Um etwas Platz zu schaffen würde ich RF Router dafür entfernen, sofern es nicht gebraucht wird.

Code Auswählen


#  undef HAS_RF_ROUTER

Gruß,
Steve

StefanW · 05 November 2015, 14:55:12

Danke für die Info, da kann ich ja lange probieren.

Vllt sollte das in der commandref noch erwähnt werden.

Ich werde es mal testen.
Wofür ist denn

Code Auswählen

# undef HAS_RF_ROUTER
verantwortlich?

Gruß
Stefan

StefanW · 05 November 2015, 18:28:45

So, habe mir mal ne neue FW compiliert.
RF Router brauche ich nicht.
Und was soll ich sagen... Es funktioniert auf Anhieb!

Vielen Dank