FHT mit CUL und CUL_RFR macht Probleme
cge
ich habe eine FHEM-Konfiguration mit diversen FS20 Devices, die gut
funktionieren (bis auf zeitweise Aussetzer bei den CUL_WS (S300) von
Conrad). Leider macht meine FHT-Heizungssteuerung nur Probleme.
Nachdem ich das Problem mit der falschen ID beim RFR gelöst habe
taucht das LOVF-Problem nicht mehr auf.
Allerdings: Wenn ich alle CUL's herausziehe, FHEM neu starte und FHT
neu paire (mit dem RFR), dann funktioniert zunächst (meistens) mal
alles. D.h. ich bekomme aktuelle Temperaturwerte in FHEM, die actuator-
Meldungen, desired-temp-Meldungen und auch Kommandos (z.B. neues
desired-temp) werden angenommen.
Nach 1-2 Tagen fällt dann die Temperatur-Meldung aus und irgendwann
werden auch keine Kommandos mehr angenommen bzw. so wie es aussieht
mit > 5h Verspätung ausgeführt.
Ein "define t_fht_report at *03:00:00 set HeizungBad report2 255"
scheint das auch nicht zu lösen.
Bisher hat dann zumindest noch die lokale Temperatur/Zeitregelung der
FHT funktioniert. Aktuell ist es allerdings so, dass ein set desired-
temp vom Vormittag irgendwann nachmittags zuschlägt und alles
durcheinander bringt. So wie es aussieht wird das penetrant von
irgendjemanden regelmäßig gesendet, mein Log-File zeigt in
unregelmäßgem Abstand (einige Minuten bis einige Stunden) den Eintrag
2011-09-28_22:10:21 HeizungBad desired-temp: 18.0
Die 18° wurden vor vielen Stunden einmal in der FHEM-Oberfläche
eingestellt.
Ein get CUL raw T02 liefert für den CUL
CUL raw => N/A
Für den gepaired'ten CUL-RFR liefert get myCUL_RFR raw T02
myCUL_RFR raw => ? (;102U0647:4124 0647:66FF 0647:4124 0647:4124
0647u0201T02 is unknown) Use one of B C F i A G M R T V W X e f m l t
u x
Kann es sein, dass eine FHT nicht mit CUL und CUL_RFR zurecht kommt?
Eben fällt mir noch auf, dass der CUL definiert ist mit
define CUL CUL /dev/ttyACM0@9600 1234
und 1234 auch der Housecode einiger FS20 Devices ist. Macht das
Schwierigkeiten?
Wäre für jeden Hinweis dankbar!
Grüße,
Carsten
Rudolf Koenig
kann mir aber vorstellen dass es zu Problemen fuehren kann. Ich habe es
allerdings noch nie untersucht.
Die CUL/FHZ <-> FHT Kommunikation ist sehr fragil, und braucht fuer die
Uebermittlung von N Werten etwa 5+N ungestoerte Nachrichtenuebermittlungen
abwechselnd von beiden Teilnehmer mit dem langsamen 1kHz Technik. Falls
waehrend dieser langen "Diskussion" eine Nachricht nicht klar empfangen wird,
dann geht alles in 2 Minuten von vorne los. Nur falls ein Austausch komplett
abgearbeitet ist, kommt der naechste aus dem CUL Puffer (T02) dran.
Dieses Verfahren an sich ist schon ein Garant fuer Probleme.
Das FHZ macht es auch nicht anders, und hat die Situation meiner Erfahrung nach
nicht besser im Griff als das CUL.
Auf der anderen Seite ist die RFR Uebertragung, die erst auf eine Sendepause
wartet, dann den Empfaenger mit wenigen Bits auf 1kHz anpingt, daraufhin beide
auf 250kHz umschalten und die Daten uebertragen. Dem RFR Code ist nicht
bekannt, dass eine FHT-Uebertragung unterwegs ist. Solange keine Sendepause
vorliegt, werden alle empfangenen Daten in einem 64 Byte grossen lokalen Puffer
geschrieben, diese sind durch ; getrennt im Raw RFR Daten sichtbar.
> Ein "define t_fht_report at *03:00:00 set HeizungBad report2 255"
> scheint das auch nicht zu l�sen.
Dieses Befehl uebertraegt (wenn ich die Doku richtig lese) N=8 Nachrichten,
und stellt damit das RFR vor eine Herausvorderung.
> F�r den gepaired'ten CUL-RFR liefert get myCUL_RFR raw T02
> myCUL_RFR raw => ? (;102U0647:4124 0647:66FF 0647:4124 0647:4124
> 0647u0201T02 is unknown) Use one of B C F i A G M R T V W X e f m l t
> u x
Das ist ueblicherweise ein Zeichen fuer eine nicht korrekt eingestellte USB
Schnittstelle. stty -a < /dev/ttyACM0 muesste werte mit echo anzeigen, korrekt
ist wenn alle echo Felder mit vorangestellten - angezeigt werden, also -echoe
-echok usw.
> Eben f�llt mir noch auf, dass der CUL definiert ist mit
> define CUL CUL /dev/ttyACM0@9600 1234
> und 1234 auch der Housecode einiger FS20 Devices ist. Macht das
> Schwierigkeiten?
Das CUL Hausecode ist FHT spezifisch und hat mit FS20 nichts zu tun.
Thomas Herrmann
On 09/28/2011 10:38 PM, cge wrote:
> Nach 1-2 Tagen f�llt dann die Temperatur-Meldung aus und irgendwann
> werden auch keine Kommandos mehr angenommen bzw. so wie es aussieht
> mit > 5h Versp�tung ausgef�hrt.
> Ein "define t_fht_report at *03:00:00 set HeizungBad report2 255"
> scheint das auch nicht zu l�sen.
Auch ich hatte lange Zeit Probleme mit CUL_RFR und FHT (wir hatten ja
neulich schon per E-Mail dar�ber geschrieben). Ich habe nochmal
nachgeschaut, bei mir laufen 2 FHT �ber RFR und 4 direkt �ber den CUL.
Seit ich alle n�chtlichen "set ... time" weggelassen und alle "set ...
report 255" auf "set ... report2 7" ge�ndert habe, l�uft es (solange die
Batterien voll genug sind) relativ stabil.
Viele liebe Gr��e,
Thomas
cge
Ich hatte vor einiger Zeit das Problem mit echo, welches dank Euerer
Hilfe eingegrenzt werden konnte.
http://groups.google.com/group/fhem-users/browse_thread/thread/7f0c6b22fb5bcb24/431ad439e1779494?lnk=gst&q=cge#431ad439e1779494
Die Neuinstallation sorgte dafür, dass nun -echo statt echo kam,
allerdings weiterhin echoe, echok, echoctl und echoke. Die unknown
messages waren damit weg. Soeben habe ich das nochmal geprüft und nun
haben alle echo ein - bis auf echoke. Ich glaube dass ich in der
Zwischenzeit ein Update von der FritzBox Labor auf die reguläre
Firmware gemacht habe.
==> Kann das echoke (ohne -) ein Problem sein und wie kann ich das
ggf. umstellen?
@Ralf und Thomas bzgl. set ... report 2 255:
Das hatte ich einige Zeit komplett raus, hatte dann aber mal den
Eindruck, dass nach so einem Befehl die FHT hinsichtlich der Sendung
von Temperaturwerten wieder "aufwacht" und ihn testweise mal wieder
reingenommen. Hat aber auf Dauer nicht geholfen.
Ich habe nun noch den Housecode meines CUL auf 0000 gesetzt
(Kommunikation soll ja über den RFR laufen, IODev ist entsprechend
gesetzt), vielleicht hilft das auch den Traffic auf meinem Funkkanal
etwas zu reduzieren. Ich werde die Lage beobachten.
==> Grundsätzlich habe ich allerdings noch ein Problem und Fragen zur
Pufferung der Befehle und dem Log-Eintrag:
So weit ich das erkennen kann deuten Einträge der Form
2011-09-29_14:30:19 HeizungBad desired-temp 18.0 (ohne : vor der
Temperatur) auf ein von FHEM gesendetes Kommando hin, während
2011-09-29_14:45:45 HeizungBad desired-temp: 18.0 (mit : vor der
Temperatur) auf einen von der FHT gesendeten Wert hindeuten.
==> Ist das so?
Falls das stimmt habe ich den Eindruck dass bei mir oft die FHT-
Meldungen hin und hergesendet werden, denn wenn ich eine Temperatur
einmalig über FHEM oder FHT einstelle kommt sofort die Meldung ohne :
(bei Einstellung in FHEM) und irgendwann eine Meldung mit dem :.
Allerdings wird die dann regelmäßig in unregelmäßigen Intervallen (mal
3 Minuten, mal 30 Minuten) wiederholt. Die Meldungen können eigentlich
nicht vom FHT kommen, da der in der Zwischenzeit oftmals schon eine
andere gewünschte Temperatur am Gerät anzeigt. Wäre nicht ganz so
tragisch wenn nicht offensichtlich diese Meldungen zu späteren
Zeitpunkten dazu führen, dass damit irgendwann auch andere neue
Wunschtemperaturen am FHT wieder überschrieben werden, die über die
lokale FHT-Zeiteinstellung automatisch eingestellt wurden.
Kann es also sein dass die Status-Meldung zur desired-temp vom FHT
über CUL oder CUL_RFR an FHEM weitergeleitet werden und dann in
irgendeiner Dauerschleife gesendet wird?
Viele Grüße,
Carsten
Rudolf Koenig
> ggf. umstellen?
Unwahrscheinlich. Da CUL normalerweise nur ASCII weiterschickt, sollte kein
"Kill character" dabei sein.
> So weit ich das erkennen kann deuten Eintr�ge der Form
> 2011-09-29_14:30:19 HeizungBad desired-temp 18.0 (ohne : vor der
> Temperatur) auf ein von FHEM gesendetes Kommando hin, w�hrend
> 2011-09-29_14:45:45 HeizungBad desired-temp: 18.0 (mit : vor der
> Temperatur) auf einen von der FHT gesendeten Wert hindeuten.
> ==> Ist das so?
Ja, obwohl das keine direkte Absicht ist.
Wenn ein set ausgeloest wird (egal fuer welches Geraet), dann wird ein Event
mit allen Set-Parameter generiert. Das FHT Modul wiederum generiert ein Event
mit dem Inhalt "cmd: value" falls irgendetwas empfangen wurde, die Meldungen
stammen vom FHT, der gerade ein Befehl vom FHZ/CUL bestaetigt. Allerdings
sendet das CUL das gleiche Befehl nochmal raus, wenn kein "ack" bestaetigt
wurde, siehe auch http://fhemwiki.de/index.php/Maximal_nutzbare_Ger%C3%A4te
Wie in den anderen Postings geschrieben: die Uebertragung der Daten an das FHT
kann lange dauern, falls es zu Stoerungen kommt. Eine Quelle des Problems kann
auch das "fhtsoftbuffer" sein, der bei dem FHZ1x00 Geraeten nuetzlich war und
auch fuer das CUL implementiert wurde, obwohl meiner aktuellen Ansicht nach in
dieem Fall ueberluessig ist.
Was ein CUL an das FHT senden will kann man mit dem Befehl "get CUL raw T02"
und Studium der Tabelle am Anfang von 11_FHT.pm rauskriegen.
Gruss,
Rudi
Zrrronggg!
In dem Zusammenhang:
Es vielleicht eine Idee, in commandref die Empfehlung täglich "report1
255 und report2 255" an alle FHTs zu senden etwas einzuschränken.
Das erzeugt selbst in Installationen ohne RFR meiner Meinung nach
nicht unerhebliche Funklast.
Speziell report1 255 fragt das eingestellte Wochenprogramm ab, das in
vielen Installationen nicht mehr gebraucht wird, und selbst wenn sich
kaum täglich ändert.
On 30 Sep., 08:31, Rudolf Koenig <inf...@koeniglich.de> wrote:
> > ==> Kann das echoke (ohne -) ein Problem sein und wie kann ich das
> > ggf. umstellen?
>
> Unwahrscheinlich. Da CUL normalerweise nur ASCII weiterschickt, sollte kein
> "Kill character" dabei sein.
>
> > So weit ich das erkennen kann deuten Eintr ge der Form
> > 2011-09-29_14:30:19 HeizungBad desired-temp 18.0 (ohne : vor der
> > Temperatur) auf ein von FHEM gesendetes Kommando hin, w hrend
> > 2011-09-29_14:45:45 HeizungBad desired-temp: 18.0 (mit : vor der
> > Temperatur) auf einen von der FHT gesendeten Wert hindeuten.
> > ==> Ist das so?
>
> Ja, obwohl das keine direkte Absicht ist.
> Wenn ein set ausgeloest wird (egal fuer welches Geraet), dann wird ein Event
> mit allen Set-Parameter generiert. Das FHT Modul wiederum generiert ein Event
> mit dem Inhalt "cmd: value" falls irgendetwas empfangen wurde, die Meldungen
> stammen vom FHT, der gerade ein Befehl vom FHZ/CUL bestaetigt. Allerdings
> sendet das CUL das gleiche Befehl nochmal raus, wenn kein "ack" bestaetigt
Rudolf Koenig
> 255 und report2 255" an alle FHTs zu senden etwas einzuschr�nken.
Danke fuer den Hinweis. Habs gegen
define fht_sync at +*3:30 set TYPE=FHT time
getauscht, und report1 mit einer Warnung versehen.
cge
mit CUL und CUL_RFR kommt und sich die beiden evtl. nicht über die
Zuständigkeiten einig sein?
Ich habe über FHEM nacheinander die desired-temp gesetzt (zunächst auf
17, dann auf 17,5°). Beide Befehle konnte ich beim RFR mit get
myCUL_RFR raw T02 sehen.
Das Log zeigt:
2011-10-04_13:27:35 HeizungBad desired-temp 17.0
2011-10-04_13:28:15 HeizungBad actuator: 0%
2011-10-04_13:28:49 HeizungBad desired-temp 17.5
2011-10-04_13:30:14 HeizungBad actuator: 0%
2011-10-04_13:30:15 HeizungBad desired-temp: 17.0
2011-10-04_13:32:12 HeizungBad actuator: 0%
2011-10-04_13:32:13 HeizungBad desired-temp: 17.5
2011-10-04_13:34:11 HeizungBad actuator: 0%
2011-10-04_13:34:12 HeizungBad desired-temp: 17.5
2011-10-04_13:34:12 HeizungBad desired-temp: 17.5
und folgende Dinge kommen mir seltsam vor:
- Nachdem die erste 17.5 Rückmeldung (mit Doppelpunkt) erschien, war
im myCUL_RFR T02 Puffer immernoch eine desired-temp Meldung.
Eigentlich müsste die 17.5-Kommunikation dann doch abgeschlossen sein?
Zum Zeitpunkt als ich das Log-File kopiert habe war der Puffer dann
leer.
- in den FHT-Parametern steht:
CODE 0647
CUL_MSGCNT 130
CUL_RAWMSG T064700A600EE
CUL_RSSI -83
CUL_TIME 2011-10-04 13:42:05
DEF 0647
MSGCNT 138
NAME HeizungBad
NR 48
STATE ???
TYPE FHT
myCUL_RFR_MSGCNT 117
myCUL_RFR_RAWMSG T064700A6000A
myCUL_RFR_RSSI -69
myCUL_RFR_TIME 2011-10-04 13:42:05
Wobei mich hier insbesondere weiterhin "LASTIODev CUL" stutzig macht
(die ID beim CUL ist auf 0000).
Kann es sein, dass sich CUL und CUL_RFR bei der FHT-Kommunikation
nicht ganz einig über die Zuständigkeiten sind?
(Ich hatte eben sicherheitshalbe einen kompletten Neustart meiner FHT-
relevanten Komponenten durchgeführt (fhem neu gestartet, CUL und
CUL_RFR neu eingesteckt sowie FHt neu gepaired). CUL ist inzwischen
definiert mit
define CUL CUL /dev/ttyACM0@9600 0000.
Durch das 0000 dürfte er eigentlich an der FHT-Kommunikation nicht
mehr direkt beteiligt sein?)
Viele Grüße
Carsten
Rudolf Koenig
Nicht wenn das Finale ack danach vom FHT nicht beim RFR angekommen ist (siehe
nochmal den erwaehnten fhemwiki Eintrag). Es kann auch sein, dass diese FHT
Nachricht nicht vom RFR sondern vom CUL empfangen wurde.
Die FHT Protokollmeldungen kann man in fhem mit "set CUL raw X61" aktivieren,
ich wuerde aber sowas bei einem RFR nie tun.
CUL ID 0000 schaltet das culfw Modul fht.c ab, was fuer das (rechtzeitige)
Senden der FHT Nachrichten samt Header zustaendig ist. Empfang der FHT Daten
ist unabhaengig, deswegen ist ein "LASTIODev CUL" nichts schlimmes.
Zrrronggg!
> define fht_sync at +*3:30 set TYPE=FHT time
>getauscht, und report1 mit einer Warnung versehen.
As the FHT stops sending the values every 5-10 days, it is adviseable
to schedule following command regularly:
define fht_report at +*06:00:00 set <name> report1 255 report2 255
Rudolf Koenig
> >Habs gegen
> > define fht_sync at +*3:30 set TYPE=FHT time
> >getauscht, und report1 mit einer Warnung versehen.
>
> Hm. Wenn ich http://fhem.de/commandref.html#FHT aufrufe, lese ich noch
Stimmt, ich habs ja auch nur im CVS eingecheckt. Jetzt habe ich es aber
hochgeladen.
Zrrronggg!
Okay, sorry, wusste nicht, wie lange das so dauert.
On 5 Okt., 10:50, Rudolf Koenig <inf...@koeniglich.de> wrote:
> On Tue, Oct 04, 2011 at 10:24:50AM -0700, Zrrronggg! wrote:
> > >Habs gegen
> > > define fht_sync at +*3:30 set TYPE=FHT time
> > >getauscht, und report1 mit einer Warnung versehen.
>