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 !
Ist dein CUL mit der richtigen Firmware geflasht?
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 ?
Keine Ahnung wann diese aktuell wird.
Bei mir läuft http://forum.fhem.de/index.php/topic,27465.msg220237.html#msg220237 (http://forum.fhem.de/index.php/topic,27465.msg220237.html#msg220237)diese auf dem CUL.
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 !
Wenn man CULflash in FHEM verwendet, dann wird zuerst die tagesaktuelle CUL_V*.HEX von fhem.de heruntergeladen und dann verwendet.
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 ?
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.
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.
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.
Blöde Frage, geht das auch mit dem CUNO?
Ja damit funktioniert es auch. Die cuno FW hatte ich auch angepasst.
Noch ein Vorschlag:
Würde es nicht sinn machen, auf die ungültigen Hauscodes mit einem Logeintrag / einer Fehlermeldung hinzuweisen ? Wäre viel intuitiver...
Habe einen Check plus Meldungen ins Modul eingebaut. Wird morgen mit dem Update verteilt.
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
Wann hattest Du den CUNO geflasht? Vor dem 4.12.2014?
Nein, am 28.12. oder 29.12.
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
so, nochmal geflshed. Wieder ohne Fehler.
get CUL_FS20 raw T12 = no answer ???
Ausserdem wird der CUNO bei raw T12 immer diconnected?
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)
dein CUNO ist nicht erreichbar.
bei mir ergibt:
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
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
???
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. :)
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
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
#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
# 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.
# undef HAS_RF_ROUTER
Gruß,
Steve
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
# undef HAS_RF_ROUTER
verantwortlich?
Gruß
Stefan
So, habe mir mal ne neue FW compiliert.
RF Router brauche ich nicht.
Und was soll ich sagen... Es funktioniert auf Anhieb! :D
Vielen Dank