CUL_FHTTK Device wird nicht erkannt

[Guest]

Originally posted by: <email address deleted>

Hi!

Ich hab nun seit einigen Tagen FHEM erfolgreich ans laufen gebracht.
Bis auf einen einzigen Fensterkontakt. Der wird mir Partout nicht
angezeigt.

Zum Setup: Ich hab Fhem auf einem Linux PC mit einem CUL V3.2 laufen.

Daran angeschlossen sind 4 FHT Sets mit Fensterkontakten und Stellern,
2 S300TH Sensoren und ein zusätzlicher Fensterkontakt.

Es funktionieren alle Geräte, jedoch ein Fensterkontakt aus einem Set
wird nicht angezeigt. Der dazugehörige Steller erkennt aber den
Fensterkontakt (auch aus verschiedenen Reichweiten getestet) Ich habe
den in verschiedenen Reichweiten zum CUL schalten lassen und der hat
nichts bemerkt.
Ich hab den Steller und den Kontakt neu gepaart, mehrfach in den
Synchonisationsmodus geschaltet. Nur jetzt bin ich am Ende mit den
Ideen. Was könnte ich noch machen, damit ich diesen FHT80-TF2
erkennbar bekomme in FHEM.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Dann mach ich mal die Ingrid:

Ich hab den Sensor nun entdeckt:
Sobald ich ein
set CUL raw X61 abschicke wird das Ding erkannt:

2011-10-22 12:24:48 Global global UNDEFINED CUL_FHTTK_4a5653 CUL_FHTTK
4a5653
2011-10-22 12:24:48 Global global DEFINED CUL_FHTTK_4a5653
2011-10-22 12:24:48 Global global DEFINED FileLog_CUL_FHTTK_4a5653
2011-10-22 12:24:48 Global global DEFINED weblink_CUL_FHTTK_4a5653
2011-10-22 12:24:49 CUL_FHTTK CUL_FHTTK_4a5653 Window: Closed

Dann hab ich fhem neugestartet und nichts mehr...
Dann wieder das Kommando gesendet und schon gehts. Ich hab den hier
schon unbenannt in Badezimmer_Fenster

CUL CUL raw X61
CUL_FHTTK Badezimmer_Fenster Window: Closed

 Was ist denn der normale reporting Modus vom CUL?
Ist das was beim Device unter initString steht?

Hab ich das dann so richtig verstanden?
Dann wäre das ja X21 als 0010 0001 sein
    Bit 0: Report known messages (parity & checksum ok), with type
prefix.
    Bit 5: RSSI: report RSSI value as an additional HEX byte after
digested data or as a separate byte if Bit 3 is set too.

und mit X61 (0110 0001)
    Bit 0: Report known messages (parity & checksum ok), with type
prefix.
    Bit 5: RSSI: report RSSI value as an additional HEX byte after
digested data or as a separate byte if Bit 3 is set too.
    Bit 6: Report FHT protocol messages (ack, etc)

Wenn ich mir die Nachrichten mit Inform raw anschaue, dann seht das
imho ganz normal aus:
CUL CUL T4A565301
CUL CUL T4A565381

Wie bekomme ich das denn hin, das das auch ohne Anpassung bzw. Auch
wenigstens direkt nach einem Neustart so läuft?

mfg,
DF

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> CUL CUL T4A565301
> CUL CUL T4A565381

Ist wohl ein Bug in culfw.

Es ignoriert ohne gesetzten Bit 6 alle FHT Pakete, deren Kommando-Byte (das
vorletzte) eins von 4B 53 54 69 7D 7E ist. Dass die Adresse einer FHTTK 3 Byte
ist, und damit diese Bytes auch beinhaltet, war mir unbekannt. Fuer ein BugFix
muesste mir jemand mitteilen, wie culfw ein FHTTK und ein FT80b
auseinanderhalten soll.

Workaround:

define culSetX61 notify (global:INITIALIZED|MyCUL:CONNECTED) set MyCUL raw X61

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

On 10/22/2011 01:21 PM, Rudolf Koenig wrote:
>> CUL CUL T4A565301
>> CUL CUL T4A565381
>
> Ist wohl ein Bug in culfw.

Vielleicht erklärt das auch folgendes:

http://groups.google.com/group/fhem-users/browse_thread/thread/dac9b3e3716ce14f

Ich werde das heute abend mal genauer untersuchen.

Grüße,
Thomas

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com