FHT 80 reagiert nicht mehr und "CUL: unknown message LOVF"

[Guest]

Originally posted by: <email address deleted>

Hallo zusammen,

mein FHT 80 liefert immer nach einiger Zeit keine aktuellen
Temperaturwerte mehr. Bisher hat er dann trotzdem wenigstens noch
Kommandos, z.B. geänderte Temperaturvorgabe angenommen, aktuell
verweigert er allerdings auch das.

In meiner fhem.cfg habe ich so nach und nach bereits folgende Standard-
Kommandos eingefügt, da das in verschiedenen Beiträgen geraten wurde:

define t_culboot at +*3:00:00 set CUL raw B00;;set myCUL_RFR raw B00
define t_fht_report at +*03:05:00 set HeizungBad report1 0 report2 255
define t_culX21 at +*03:10:00 set CUL raw X21;;set myCUL_RFR raw X21

Im Log bekomme ich neuerdings viele LOVF-Fehler, auch direkt nach
einem fhem-Neustart:
2011.09.10 10:36:53 0: Server started (version =VERS= from =DATE=
($Id: fhem.pl,v 1.150 2011-08-16 18:06:38 rudolfkoenig Exp $), pid
16618)
2011.09.10 10:37:49 3: CUL opening CUL device /dev/ttyACM0
2011.09.10 10:37:49 3: CUL setting CUL baudrate to 9600
2011.09.10 10:37:49 3: CUL device opened
2011.09.10 10:37:49 2: FHEMWEB port 8083 opened
2011.09.10 10:37:49 2: FHEMWEB port 8084 opened
2011.09.10 10:37:49 2: FHEMWEB port 8085 opened
2011.09.10 10:38:05 2: CUL: unknown message LOVF
2011.09.10 10:38:05 2: myCUL_RFR: unknown message LOVF
2011.09.10 10:38:05 2: myCUL_RFR: unknown message LOVF
2011.09.10 10:42:04 2: CUL: unknown message LOVF
2011.09.10 10:42:05 2: CUL: unknown message LOVF
...
oder auch:
2011.09.10 12:00:10 3: fhtsoftbuffer: HeizungBad set desired-temp 30.0
is still in the culfw buffer, wont send it again
... was vermulich das nicht mehr angenommene Kommando erklärt...

das Log des FHT sieht im Wesentlichen so aus:
2011-09-10_11:19:28 HeizungBad actuator: 100%
2011-09-10_11:21:26 HeizungBad actuator: 100%
2011-09-10_11:21:27 HeizungBad report1: 0
2011-09-10_11:23:25 HeizungBad actuator: 100%
2011-09-10_11:25:23 HeizungBad actuator: 100%
...

Folgende Fragen:
1. Wie bekomme ich die FHT wieder in einen normalen Zustand? FHEM
Neustart und CUL herausziehen brachte nichts.
2. Hat jemand eine Idee wie ich das Aussteigen des FHT vermeiden kann?
3. Machen die drei Standardkommandos Sinn oder handle ich mir da evtl.
Probleme ein? Welcher zeitliche Abstand macht Sinn?
4. Die drei Standardkommandos wollte ich zeitlich etwas entzerren,
damit keine gegenseitigen Effekte entstehen. Ich habe das jetzt mal so
gemacht, dass der Abstand für den regelmäßigen Start unterschiedlich
ist. Gibt es eine elegante Lösung, die drei Kommandos jeweils alle
xStunden zu starten, aber eben versetzt (z.B. Kommando A 12:00,
15:00h, 17:00h, ..., Komando B 12:05, 15:05, 17:05, ... Kommando C
12:10, 15:10, 17:10, ...)? Irgendein "at +*3:00:00", aber beim ersten
mal mit 5 Minuten Verzögerung?

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

[Guest]

Originally posted by: <email address deleted>

Hallo zusammen,

zu den Fragen folgende ergänzende Erkenntnis (s.u.), vielleicht hat
noch jemand eine Idee für mich?

Danke, viele Grüße und guten Start in die Woche,
Carsten

> Folgende Fragen:
> 1. Wie bekomme ich die FHT wieder in einen normalen Zustand? FHEM
> Neustart und CUL herausziehen brachte nichts.
==> Nur Neustart und nur CUL herausziehen brachte nichts (die LOV-
Meldungen gingen gleich weiter). Allerdings habe ich nochmal folgende
Schritte gemacht: FHEM herunterfahren, CUL und CUL_RFR herausgezogen,
CUL reingesteckt, CUL_RFR reingesteckt, FHEM Start.
==> Dann blieben die LOVF eine Zeit lang weg, kamen aber nach wenigen
Stunden wieder.

> 2. Hat jemand eine Idee wie ich das Aussteigen des FHT vermeiden kann?
==> Ich habe einen CUL an der FritzBox und einen CUL_RFR einen Stock
tiefer. Der Empfang des FHT zum CUL ist sehr zweifelhaft, der zum RFR
müsste eigentlich ok sein. Kann es sein dass sich die beiden
Kommunikationswege beeinflussen und falls ja kann ich der FHT
irgendwie sagen, dass sie nur mit dem RFR kommunizieren soll?

> 3. Machen die drei Standardkommandos Sinn oder handle ich mir da evtl.
> Probleme ein? Welcher zeitliche Abstand macht Sinn?
> 4. Die drei Standardkommandos wollte ich zeitlich etwas entzerren,
> damit keine gegenseitigen Effekte entstehen. Ich habe das jetzt mal so
> gemacht, dass der Abstand für den regelmäßigen Start unterschiedlich
> ist. Gibt es eine elegante Lösung, die drei Kommandos jeweils alle
> xStunden zu starten, aber eben versetzt (z.B. Kommando A 12:00,
> 15:00h, 17:00h, ..., Komando B 12:05, 15:05, 17:05, ... Kommando C
> 12:10, 15:10, 17:10, ...)? Irgendein "at +*3:00:00", aber beim ersten
> mal mit 5 Minuten Verzögerung?

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

[rudolfkoenig]

                                                   

> define t_culboot at +*3:00:00 set CUL raw B00;;set myCUL_RFR raw B00

Ich glaube nicht, dass ein Neustart des CUL's irgendwelche Probleme
loest, hoechstens als ein mir unbekanntes Seiteneffekt. Meine CUL's
laufen ohne Neustart seit einem Jahr.


> define t_fht_report at +*03:05:00 set HeizungBad report1 0 report2 255

Ich wuerde das auch nicht regelmaessig absetzen wollen: die gemeldeten
Werte werden ja nicht so haeufig geaendert. Abgesehen davon belastet
es auch das Sendebudget, was ja laut LOVF offensichtlich ein Problem
ist. Ich sende an meine FHT's einmal am Tag um 3:00 die aktuelle Zeit
(set TYPE=FHT time), damit ist auch die Sommerzeitumstellung erledigt.


> define t_culX21 at +*03:10:00 set CUL raw X21;;set myCUL_RFR raw X21

X21 initialisiert das Funkchip (CC1101) neu, und kalibriert es damit
auch gleichzeitig. Andererseits erfolgt die gleiche Initialisierung
beim jeden RFR<->CUL Nachrichtenwechsel, und auch vor jedem
Sendevorgang wird die Kalibrierung durchgefuehrt, insofern ist es mAn
dieses Kommando ueberfluessig.


> Im Log bekomme ich neuerdings viele LOVF-Fehler, auch direkt nach
> einem fhem-Neustart:

Das ist ein echtes Problem, und man sollte die Ursache beseitigen.
LOVF kann passieren, falls zu viele FHT angeschlossen sind (max. 17,
praktisch eher so 10, und fhem Kommandos an die FHT's sind dabei gar
nicht gezaehlt), oder man anderweitig zu viele FS20 Befehle aussendet
(max 160 die Stunde). FHT und FS20 sind zusammen zu zaehlen, und nicht
jeder fuer sich.

Meine FHT's laufen seit etwa 5 Jahren relativ gut. Einer hatte ca 1
Monat lang einen Aussetzer, da hat er zwar die Befehle ausgefuehrt
aber nix gesendet. Hat sich aber wieder "selbst geheilt". Wuesste ich
auch gerne woran das lag.

Evtl. hilft es die Kommunikation der FHT's naeher anzuschauen, in der
Wiki ist es irgendwo beschrieben wo man das macht.

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

[Zrrronggg!]

                                                     

Ist sichergestellt, das das RFR CUL eine andere FHT ID hat als das
CUL?

Wenn die, z.b. weil du die mal testweise getauscht hast, die selbe FHT
ID haben, treten alle die genannten Effekte auf, denn dan fühlen sich
in der Kommunikation beide CULs angesprochen, acken beide, dann kommen
Telegramme nicht durch und werden wiederholt und nochmal und nochmal
und so weiter.  Da hast du schneller LOVF als du gucken kannst. Sehr
sehr schön zu beobachten mit inform und X61.

Ich habe das mal aus versehen gemacht und hatte danach die Pest am
Bein. Dazu habe ich hier auch eine Post gemacht... such mal nach
"kleiner Erfahrungsbericht mit RFR CUL" oder so ähnlich.


>define t_fht_report at +*03:05:00 set HeizungBad report1 0 report2 255

Das mache ich auch, aber nur 1x die Woche und ausserdem für FHTs
tageweise versetzt um die Funklast zu verteilen (siehe auch Rudis
anmerkung)

"report1 0" kann sich auch sparen denke ich (also report 2 255 reicht)



On 12 Sep., 17:24, Rudolf Koenig wrote:
> > define t_culboot at +*3:00:00 set CUL raw B00;;set myCUL_RFR raw B00
>
> Ich glaube nicht, dass ein Neustart des CUL's irgendwelche Probleme
> loest, hoechstens als ein mir unbekanntes Seiteneffekt. Meine CUL's
> laufen ohne Neustart seit einem Jahr.
>
> > define t_fht_report at +*03:05:00 set HeizungBad report1 0 report2 255
>
> Ich wuerde das auch nicht regelmaessig absetzen wollen: die gemeldeten
> Werte werden ja nicht so haeufig geaendert. Abgesehen davon belastet
> es auch das Sendebudget, was ja laut LOVF offensichtlich ein Problem
> ist. Ich sende an meine FHT's einmal am Tag um 3:00 die aktuelle Zeit
> (set TYPE=FHT time), damit ist auch die Sommerzeitumstellung erledigt.
>
> > define t_culX21 at +*03:10:00 set CUL raw X21;;set myCUL_RFR raw X21
>
> X21 initialisiert das Funkchip (CC1101) neu, und kalibriert es damit
> auch gleichzeitig. Andererseits erfolgt die gleiche Initialisierung
> beim jeden RFR<->CUL Nachrichtenwechsel, und auch vor jedem
> Sendevorgang wird die Kalibrierung durchgefuehrt, insofern ist es mAn
> dieses Kommando ueberfluessig.
>
> > Im Log bekomme ich neuerdings viele LOVF-Fehler, auch direkt nach
> > einem fhem-Neustart:
>
> Das ist ein echtes Problem, und man sollte die Ursache beseitigen.
> LOVF kann passieren, falls zu viele FHT angeschlossen sind (max. 17,
> praktisch eher so 10, und fhem Kommandos an die FHT's sind dabei gar
> nicht gezaehlt), oder man anderweitig zu viele FS20 Befehle aussendet
> (max 160 die Stunde). FHT und FS20 sind zusammen zu zaehlen, und nicht
> jeder fuer sich.
>
> Meine FHT's laufen seit etwa 5 Jahren relativ gut. Einer hatte ca 1
> Monat lang einen Aussetzer, da hat er zwar die Befehle ausgefuehrt
> aber nix gesendet. Hat sich aber wieder "selbst geheilt". Wuesste ich
> auch gerne woran das lag.
>
> Evtl. hilft es die Kommunikation der FHT's naeher anzuschauen, in der
> Wiki ist es irgendwo beschrieben wo man das macht.

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

[Guest]

Originally posted by: <email address deleted>

Danke für die konkreten und hilfreichen Hinweise!!

Tatsächlich hat sich bei mir im CUL und im RFR CUL dieselbe ID
eingeschlichen. Also gleich mal beim RFR CUL eine neue vergeben (ich
hoffe die kann frei vergeben werden und hat nichts mit der ID bei
"define HeizungBad FHT 0647" zu tun?). Dann habe ich noch "attr
HeizungBad IODev myCUL_RFR" gesetzt und neu gepaired. Den
fhtsoftbuffer habe ich auch mal wieder auf 0 gesetzt.

Jetzt nimmt die FHT wieder Kommandos an und so wie es aussieht bisher
auch noch keine LOVF's ) (allerdings kamen sie früher auch nicht
immer sofort wieder...).

Weiterhin bekomme ich aber keine aktuellen Temperatur-Werte, lediglich
die actuator-Meldungen (obwohl Pairing scheinbar geklappt hat).

Ich habe mal X61 am CUL eingeschaltet (am RFR CUL geht das nicht,
oder?) und bekomme nun folgende Informationen, die ich leider nicht
interpretieren kann. Geben die evtl. noch Hinweise?
In der fhem.log kommt regelmäßig alle paar Sekunden:
2011.09.13 22:24:00 2: CUL: unknown message p 3  384  352  576  512
12  5 5 F8 DE6926902D70, wobei die Werte nach dem p 3 unterschiedlich
sind.

In der FHT-log wiederholen sich folgende Einträge regelmäßig (immer
mit Wert 18):
2011-09-13_22:11:31 HeizungBad FHZ:can-xmit: 18
2011-09-13_22:11:31 HeizungBad can-rcv: 18
2011-09-13_22:11:32 HeizungBad FHZ:start-xmit: 18

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

[Guest]

Originally posted by: <email address deleted>

Ergänzung:
Welche Bedeutung hat eigentlich das interne Feld LASTIODev? Bei meiner
FHT steht das aktuell auf CUL, obwohl das Attribut IODev auf myCUL_RFR
steht. Könnte das eine Erklärung sein, warum bestimmte aktuelle Werte
nicht bei FHEM ankommen (da CUL ja eigentlich nicht gepaired sein
sollte)

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

[rudolfkoenig]

                                                   

> Welche Bedeutung hat eigentlich das interne Feld LASTIODev?

Zeigt das physikalische Geraet (CUL/FHZ/etc) an, was zuletzt Daten fuer dieses
fhem-Geraet (FS20/CUL_WS/etc) empfangen hat.  Auch wenn ein CUL mit einem FHT
nicht gepaired ist, meldet es die Nachrichten von und zu dieses FHT weiter.

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