Probleme mit FHT80b und FHEM mit CUL

[Guest]

Originally posted by: <email address deleted>

Grüß Euch!

 

Ich bin neu beim Thema FHEM und gerade dabei ein kleines FHEM System zum
Testen aufzusetzen und habe mir dazu eine CUL, ein FHT80b Set und eine Paar
FS20 Sender und Empfänger zugelegt.

 

Die FS20 Teile funktionieren spitze, auch in Kombination mit FHEM gibt es
keinerlei Probleme. Nehme ich aber die FHT80b dazu funktioniert plötzlich
gar nichts mehr:

 

Vor diesem Block kann ich über das WebInterface eine Lampe ein und
ausschalten. Danach setze ich im Web-Interface die Temperatur auf 5.5° - das
wird mit EOB und ... is unknown quitiert und ab diesem Zeitpunkt geht gar
nichts mehr. Auch die Lampe die vorher problemlos schaltbar war lässt sich
nicht mehr bedienen. Wenn kein FHT Gerät (Weder der Fensterkontakt noch das
FHT selbst) mit Batterien bestückt ist funktioniert alles ohne Probleme. Die
Daten des Fensterkontaktes alleine (ohne aktives FHT) lassen sich korrekt
auslesen, verursachen aber die gleichen Störungen  (siehe unten)

 

Kann mir irgendjemand sagen was ich hier falsch mache?

 

Ich hatte auf das im WIKI beschriebene Frequenz-Problem getippt und die
Frequenz schon etwas modifiziert. Hat das Problem aber leider nicht gelöst

 

Danke für eure Unterstützung

 

Grüße

 

Michael

 

2010.10.21 23:22:03 5: Cmd: >set FHT_0204 desired-temp 5.5<

2010.10.21 23:22:03 5: CUL sending T0204410b

2010.10.21 23:22:03 2: FHT set FHT_0204 desired-temp 5.5

2010.10.21 23:22:03 5: Triggering FHT_0204 (1 changes)

2010.10.21 23:22:03 5: FHT_0204 trigger: Checking FileLog_CUL_FHTTK_21a994
for notify

2010.10.21 23:22:03 5: FHT_0204 trigger: Checking FileLog_FHT_0204 for
notify

2010.10.21 23:22:03 5: FHT_0204 trigger: Checking FileLog_FHT_1c37 for
notify

2010.10.21 23:22:03 5: FHT_0204 trigger: Checking FileLog_FS20_2f3c01 for
notify

2010.10.21 23:22:03 5: FHT_0204 trigger: Checking FileLog_FS20_2f3c02 for
notify

2010.10.21 23:22:03 5: FHT_0204 trigger: Checking FileLog_FS20_2f3c03 for
notify

2010.10.21 23:22:03 5: FHT_0204 trigger: Checking FileLog_FS20_2f3c2f for
notify

2010.10.21 23:22:03 5: FHT_0204 trigger: Checking Logfile for notify

2010.10.21 23:22:03 5: FHT_0204 trigger: Checking autocreate for notify

2010.10.21 23:22:03 5: FHT_0204 trigger: Checking fht80refresh for notify

2010.10.21 23:22:04 5: CUL/RAW: /EOB

 

2010.10.21 23:22:04 4: CUL: EOB

2010.10.21 23:22:04 2: CUL: unknown message EOB

2010.10.21 23:22:04 5: CUL/RAW: /

 

2010.10.21 23:22:04 5: CUL/RAW: /? (EOB is unknown) Use one of B C F A G M R
T V W X e f m l t u x

 

2010.10.21 23:22:04 4: CUL: ? (EOB is unknown) Use one of B C F A G M R T V
W X e f m l t u x

2010.10.21 23:22:04 2: CUL: unknown message ? (EOB is unknown) Use one of B
C F A G M R T V W X e f m l t u x

2010.10.21 23:22:04 5: CUL/RAW: /

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[rudolfkoenig]

                                                   

> Danach setze ich im Web-Interface die Temperatur auf 5.5° - das
> wird mit EOB und ? is unknown quitiert und ab diesem Zeitpunkt geht gar
> nichts mehr.

EOB heisst dass der FHT Puffer voll ist (siehe auch "get MyCUL raw T02"), d.h.
es wurden mehr als 13 FHT Befehle abgesetzt, die nicht weitergeschickt werden
konnten. "? is unknown" heisst, dass das CUL unbekannte Befehle bekommen hat.

Ich tippe auf eine serielle Schnittstelle mit kaputten defaults, z.Bsp. "echo"
(siehe man stty, bzw. stty -a < /dev/ttyUSB0), die Distributionen mit solchen
defaults scheinen Verbreitung zu finden.
Ich wuerde empfehlen eine beliebige Baudrate bei der CUL Definition zu
spezifizieren, dann werden etliche serielle Parameter auf "normal" gesetzt.
Beispiel: define MyCUL CUL /dev/ttyUSB0@9600 1234

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

Danke für den Tipp mit der echo-Einstellung - du hattest vollkommen
recht. Die Baudrate anzufügen hat das Problem alleine nicht behoben
aber seit ich in einem Startup-Script folgendes Kommando ausführe sind
die Fehlermeldungen verschwunden:

stty -echo -F /dev/ttyACM0

Leider bin ich schon kurz darauf an der nächsten "Ungereimtheit"
gescheitert.
Ich habe mein CUL mit dem Haus-Code 1234 initialisiert, am FHT habe
ich 047, 060 als Code eingestellt. Das hat bewirkt, dass ein FHT_2f3c
definiert wurde und auch die actuator-Meldungen ankommen und
verarbeitet werden.
Die Cent-Einstellung im FHT steht aber fest auf NA und lässt sich auch
durch mehrfache Kommandos an's FHT nicht ändern. Dadurch kann weder
die Temperatur über FHEM gesetzt werden, noch werden aktuelle
Temperaturangaben in FHEM erfasst.

zb:
2010.10.23 01:39:17 5: Cmd: >set FHT_2f3c desired-temp 10.0<
2010.10.23 01:39:17 5: CUL sending T2f3c4114
2010.10.23 01:39:17 2: FHT set FHT_2f3c desired-temp 10.0
2010.10.23 01:39:17 5: Triggering FHT_2f3c (1 changes)

Hast du zufällig auch hierzu eine Idee

Danke + Grüße

Michael

On 22 Okt., 20:24, Rudolf Koenig wrote:
> > Danach setze ich im Web-Interface die Temperatur auf 5.5 - das
> > wird mit EOB und ? is unknown quitiert und ab diesem Zeitpunkt geht gar
> > nichts mehr.
>
> EOB heisst dass der FHT Puffer voll ist (siehe auch "get MyCUL raw T02"), d.h.
> es wurden mehr als 13 FHT Befehle abgesetzt, die nicht weitergeschickt werden
> konnten. "? is unknown" heisst, dass das CUL unbekannte Befehle bekommen hat.
>
> Ich tippe auf eine serielle Schnittstelle mit kaputten defaults, z.Bsp. "echo"
> (siehe man stty, bzw. stty -a < /dev/ttyUSB0), die Distributionen mit solchen
> defaults scheinen Verbreitung zu finden.
> Ich wuerde empfehlen eine beliebige Baudrate bei der CUL Definition zu
> spezifizieren, dann werden etliche serielle Parameter auf "normal" gesetzt.
> Beispiel: define MyCUL CUL /dev/ttyUSB0@9600 1234

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Dr. Boris Neubert]

                                             

Hallo,

Am 23.10.2010 01:43, schrieb Michael Cicogna:
> Die Cent-Einstellung im FHT steht aber fest auf NA und lässt sich auch
> durch mehrfache Kommandos an's FHT nicht ändern. Dadurch kann weder
> die Temperatur über FHEM gesetzt werden, noch werden aktuelle
> Temperaturangaben in FHEM erfasst.

ich habe aehnliche Erfahrungen gemacht, als ich gestern versucht habe,
eine FHT80b mit einem CUN zu paaren. Es sieht mir danach aus, dass Dein
Problem und das Problem von Hugo Habicht mit dem softbuffer
zusammenhaengen. Soweit ich das gestern debuggen konnte, werden die
Kommandos in den Buffer von CUN/CUL geschrieben und auch weitergesendet.
Die Rueckmeldung wird aber nicht immer von fhem verarbeitet, so dass der
softbuffer verstopft und erst nach maxretrycount geleert wird. Die
Ursache ist m.E., dass das Warten auf eine Antwort auf ein "get myCUN
..." die von CUN/CUL nebenlaeufig empfangenen und spontan an fhem
geleiteten Datagramme auffrisst. Das passiert regelmaessig beim
softbuffer wegen des periodischen Aufrufs von getFHTBuffer, aber auch
beim manuellen Absenden von "get myCUN ..." (beides beobachtet).

Ich werde dieses Wochenende am Code arbeiten.

Gruesse,
Boris

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Mr. P]

                                                       

Hej hej,

klingt nach dem gleichen Problem, dass ich auch erst vor ein paar
Tagen gemeldet habe:
http://groups.google.de/group/fhem-users/t/7a3c94d8bd7b3d1a

Greetz,
   Gerhard

On 23 Okt., 09:02, "Dr. Boris Neubert" wrote:
> Hallo,
>
> Am 23.10.2010 01:43, schrieb Michael Cicogna:
>
> > Die Cent-Einstellung im FHT steht aber fest auf NA und lässt sich auch
> > durch mehrfache Kommandos an's FHT nicht ändern. Dadurch kann weder
> > die Temperatur über FHEM gesetzt werden, noch werden aktuelle
> > Temperaturangaben in FHEM erfasst.
>
> ich habe aehnliche Erfahrungen gemacht, als ich gestern versucht habe,
> eine FHT80b mit einem CUN zu paaren. Es sieht mir danach aus, dass Dein
> Problem und das Problem von Hugo Habicht mit dem softbuffer
> zusammenhaengen. Soweit ich das gestern debuggen konnte, werden die
> Kommandos in den Buffer von CUN/CUL geschrieben und auch weitergesendet.
> Die Rueckmeldung wird aber nicht immer von fhem verarbeitet, so dass der
> softbuffer verstopft und erst nach maxretrycount geleert wird. Die
> Ursache ist m.E., dass das Warten auf eine Antwort auf ein "get myCUN
> ..." die von CUN/CUL nebenlaeufig empfangenen und spontan an fhem
> geleiteten Datagramme auffrisst. Das passiert regelmaessig beim
> softbuffer wegen des periodischen Aufrufs von getFHTBuffer, aber auch
> beim manuellen Absenden von "get myCUN ..." (beides beobachtet).
>
> Ich werde dieses Wochenende am Code arbeiten.
>
> Gruesse,
> Boris

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

Servus!

Ich bin noch recht neu bei dem ganzen FHEM-Thema deswegen kann ich
mein Problem nicht wirklich nachvollziehen oder näher untersuchen.

Bei dir ist der Fehler doch erst mit der Aktivierung des Soft-Buffers
aufgetreten oder? Den hatte ich bis gerade eben noch ausgeschaltet
(wusste nicht mal dass ich den bewusst einschalten kann/muss). Auch
das Einschalten hat das Problem leider nicht behoben.

Ich hoffe die Code-Änderung von Boris bringt mein FHT zum reden.

Grüße

Michael

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

Hallo Leute!

Ich habe jetzt ein bisschen weitergespielt und rausgefunden, dass
neben den "actuator: xx"-Meldungen, die im 2-Minuten-Takt eintrudeln,
auch etwas "anderes" vorgehen muss. Folgende Meldungen kommen alle ~6
Minuten:

2010.10.24 22:02:42 4: CUL: T323200A6FB -75
2010.10.24 22:02:42 5: CUL dispatch 810c04xx0909a00132320000a6fb
2010.10.24 22:02:42 4: FHT wz actuator: 98%
2010.10.24 22:02:42 5: Triggering wz (1 changes)
2010.10.24 22:02:42 4: CUL: p 3  352  400  560  592 12  6 6 FE
32994014CFB888
2010.10.24 22:02:42 2: CUL: unknown message p 3  352  400  560  592
12  6 6 FE 32994014CFB888
2010.10.24 22:02:42 5: CUL/RAW: /p 3  384  368  544  576 12  6 6 FD
32995F4CF64DC0

2010.10.24 22:02:42 4: CUL: p 3  384  368  544  576 12  6 6 FD
32995F4CF64DC0
2010.10.24 22:02:42 2: CUL: unknown message p 3  384  368  544  576
12  6 6 FD 32995F4CF64DC0
2010.10.24 22:02:43 5: CUL/RAW: /p 3  336  400  560  592 11  6 6 FD
32995F4CF64DC0

2010.10.24 22:02:43 4: CUL: p 3  336  400  560  592 11  6 6 FD
32995F4CF64DC0
2010.10.24 22:02:43 2: CUL: unknown message p 3  336  400  560  592
11  6 6 FD 32995F4CF64DC0
2010.10.24 22:02:43 5: CUL/RAW: /p 3  400  320  640  512 12  6 6 FD
32995F4CF64DC0

2010.10.24 22:02:43 4: CUL: p 3  400  320  640  512 12  6 6 FD
32995F4CF64DC0
2010.10.24 22:02:43 2: CUL: unknown message p 3  400  320  640  512
12  6 6 FD 32995F4CF64DC0

Hat jemand eine Idee was es damit auf sich hat? Wie kann ich diese
Nachrichten interpretieren? Sind das eventuell meine Temperaturdaten
die da im digitalen Nirvana verschwinden?

Für mich sieht das so aus als würden die nachrichten schon in meinem
CUL untergehen.

Danke + Grüße

Michael

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[rudolfkoenig]

                                                   

> Hat jemand eine Idee was es damit auf sich hat?

Ja

> Wie kann ich diese Nachrichten interpretieren?

Am besten vor dem verstellen des culfw X Parameters das culfw README komplett
durchlesen.  Fhem funktioniert nur mit X21 korrekt, deswegen habe ich auch das
alte verbose Kommando aus 00_CUL.pm ausgebaut.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

Soooooo.....

Mein Problem hat sich nun endlich gelöst. Ich möchte euch nochmal kurz
um eure Unterstützung bitten damit ich das System durchblicke.

Folgendes habe ich bemerkt:

HausCode CUL = HausCode FHT (zb: CUL 3232 FHT 3232)
Temperatur kann gelesen werden, keine Reaktion auf das Setzen von
Werten

HausCode CUL in den ersten zwei Stellen <> HausCode FHT (zb CUL 3132
FHT 3232)
Keinerlei Interaktion möglich

HausCode CUL in den ersten zwei Stellen = Hauscode FHT, in den
hinteren zwei Stellen <> Hauscode FHT (zb CUL 3211 FHT 3232)
Alles funktioniert wunderbar

Ist das bei mir "Zufall" oder gibt es einen Grund für dieses
Verhalten? Ich habe dazu jedenfalls nichts in der Doku gefunden -
Ronni hat ein ähnliches (das selbe) Verhalten allerdings hier in der
Mailinglist schon Mal erwähnt

Danke für Eure Unterstützung bisher

Grüße

Michael

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[rudolfkoenig]

                                                   

> Ist das bei mir "Zufall" oder gibt es einen Grund für dieses
> Verhalten?

Wenn das CUL ein FHT Befehl mit seinem eigenen ID (bzw. aehnlichen siehe unten)
bekommt, dann nimmt es an dass es selber als FHT80b fungiert und FHT8v's direkt
steuern soll. Dann landen diese Befehle nicht mehr im FHT80b Puffer (T02)
sondern im FHT8v Puffer (T10), und werden alle 115+x Sekunden an die Ventile
gesendet. Damit das wiederum funktioniert muessen die Ventile mit dem CUL
synchronisiert sein, sonst verschlafen die 8v's die Nachrichten,

Falls das CUL ID AABB ist, dann werden alle FHT-Ids CCBB als FHT8v Befehl
identifiziert, fuer die gilt AA >= CC && CC <= AA+7
Am besten also fuer die letzten beiden Stellen der CUL-Id was anderes waehlen.

Ich werde solche ID's demnaechst bei der Definition der FHT's pruefen, und es
nicht zulassen. Im FHT8v Modul is es bereits drin, mit anderen Vorzeichen.

Danke fuer den Hinweis.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.