Re: Post im FHEM users zum Thema "Keine aktuelle Tenperatur von FHT's"
Michael Röhrig
jetzt nochmal eine e-Mail zum Thema die etwas ausführlicher ist als die letzte.
Ich verwende für die Anbindung der FHTs an das FHEM ein CUN, aktuelle Firmware ist drauf, war aber auch mit der alten schon so...
Ich sehe im Logfile aller FHTs, dass die Solltemperatur und der Aktorwert alle 2 Minuten empfangen werden.
IST-Temperaturen aber nur von 2 der 4 FHTs.
Zur möglichen Ursache: Ich habe den Hauscode einmal verändert, weiß aber nicht mehr wie er war, danach habe ich aber (meine ich) noch Temperaturwerte empfangen.
Ist beim "neu Paaren" der FHTs mit dem CUL etwas besonderes zu beachten?
Ich habe bei mir FHT80B-3 die geht, FHT80B-2 davon gehen welche und welche nicht...
Viele Grüße
Michael
Am 29.10.2010 14:00, schrieb Carsten Busch:
Hallo,
ich habe leider kein Google-Account und möchte mir vom Büro aus auch keines Anlegen, daher auf diesem Weg. Ich bin ganz neu im Thema (seid gestern) und habe das unten stehende Problem auch. Wobei es bei mir so ist, das die FHT80b-V2 einwandfreie Werte liefern, bei den FHT80b-V3 aber keine aktuelle Temeratur geliefert
Vielleicht hilft das ja weiter, das Problem einzugrenzen. Ich were am Wochenende noch ein wenig experimentieren.
Momentan habe ich allerding noch keine FHEM installiert, sondern Arbeite mit dem CUL via Terminal. Ich habe auch noch eine FHT8-SA, die zeigt bei den FHT809b-V3 ebenfalls keine Temperaturen.
Viele Grüße,
Carsten
> ich habe im Haus 4 FHT's h ngen wobei ich von zwei St ck regelm ig eine
> aktuelle Temperatur bekomme, von zwei FHT's bekomme ich aber nur die
> Soll-Temperatur und den Aktorwert...
Merkwuerdig. Zum Verstaendnis braeuchte ich noch die Angben, ob an dem Computer
ein FHZ oder ein CUL angeschlossen ist, und ob es noch weitere "FHT-Hosts", wie
z.Bsp ein FHZ1000 (nicht PC) oder andere Rechner mit einem FHZ*PC noch in der
Naehe sind.
Ventilwerte kriegt man mit einem CUL auch beim fehlenden FHT<->CUL Paarung mit,
aber Soll-Temperaturen nur dann, falls eine Paarung existiert und aktiv bedient
wird. Und dann sendet der FHT die Ist-Temperatur freiwillig alle 15 Minuten.
Falls keine weiteren FHZ's existieren, dann tippe ich auf einem FHT Fehler.
Michael Röhrig
nochmal ein Update:
der eine FHT von den zweien die keine IST-Temperatur senden sendet seit heute Nach 4 Uhr wieder die Temperatur.
Um die Uhrzeit habe ich in der Konfig die Abfrage der Reports konfiguriert. Scheint also doch etwas mit dem Paaren zutun zu haben...
Ich hab die Paarung im zweiten FHT auch nochmal angestoßen...
...ich melde mich wenns wieder geht...
Noch zu Deinen Fragen: Es gibt nur ein CUN sonst nichts. Hab auch im Logfile noch keine Geräte der Nachbarn gefunden...
Viele 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-...@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+...@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
Dr. Boris Neubert
Am 29.10.2010 17:39, schrieb Michael Röhrig:
> der eine FHT von den zweien die keine IST-Temperatur senden sendet seit
> heute Nach 4 Uhr wieder die Temperatur.
wenn die FHT mit der Zentrale richtig gepaart ist, beisst Dich
vermutlich ein Standardproblem.
Ups, es ist nicht in der FAQ beschrieben... Ich hole es demnaechst nach.
define foo at *00:40:00 set TYPE=FHT time
scheint zu genuegen, die FHTs daran zu erinnern, dass sie noch einen
Meister haben, dem sie zu melden haben. Alternativ zu time geht auch
report1 255 report2 255 oder refreshvalues (deprecated?).
Gruesse,
Boris
Michael Röhrig
ich habe die FHT im Bad (das ist die die nicht wollte) nochmal auf na
gesetzt und die Temperatur gesetzt...
...stand danach auf on, sollte also jetzt gepaart sein.
Hab mir dann nochmal das Logfile von dem einen FHT angesehen, dass sich
heute fr�h erholt hat...
...um 4:00Uhr habe ich mit Set xxx report1 255 report2 255 die Werte
angefordert...
...die erste gemessene Temperatur kam aber erst um 5:26Uhr...
...und ab dann auch nicht wirklich regelm��ig...
Mal sehen ob sich die FHT im Bad noch erholt...
Hat noch einer einenTipp f�r mich???
Viele Gr��e
Michael
Am 29.10.2010 18:36, schrieb Dr. Boris Neubert:
> Hallo,
>
dossidr
hat sich der FHT wieder erholt?
Habe seit Tagen das gleiche Problem.
hier der Log Auszug:
2010.11.09 11:27:10 5: Cmd: >setstate FHT_2337 ???<
2010.11.09 11:27:10 5: Cmd: >setstate FHT_2337 2010-11-09 11:25:31
actuator 0%<
Ich bekomme definitiv keine Temp. geliefert sondern nur TV%.
Werde heut Abend den gleichen Weg, Pairing wiederholen.
Gruß
Denny
dossidr
habe heut mal getestet was da los ist und komme zu folgendem Ergebnis:
Wenn ich den FHT im Menü auf "na" stelle und eine Temp. im "Manual
Modus" sende, sollte ja das "paaren" zwischen CUL <-->FHT hergestellt
sein.
Dies scheint aber definitiv nicht der Fall zu sein, denn mein "LOG"
des FHEM sieht so aus:
###############################################################################################################################################################
2010.11.09 20:00:17 5: Cmd: >set FHT_2337 desired-temp 22.0<
2010.11.09 20:00:17 5: CUL/RAW (ReadAnswer): 20
2010.11.09 20:00:17 5: getFhtBuffer: 0 fhtbuf => 20
2010.11.09 20:00:17 5: CUL sending T2337412c
2010.11.09 20:00:17 2: FHT set FHT_2337 desired-temp 22.0
2010.11.09 20:04:18 5: getFhtBuffer: 0 fhtbuf => 1B
2010.11.09 20:04:18 5: CUL sending T2337412c
2010.11.09 20:04:18 2: FHT set FHT_2337 desired-temp 22.0
2010.11.09 20:08:18 5: getFhtBuffer: 0 fhtbuf => 16
2010.11.09 20:08:18 5: CUL sending T2337412c
2010.11.09 20:08:18 2: FHT set FHT_2337 desired-temp 22.0
2010.11.09 20:12:18 5: getFhtBuffer: 0 fhtbuf => 11
2010.11.09 20:12:18 5: CUL sending T2337412c
2010.11.09 20:12:18 2: FHT set FHT_2337 desired-temp 22.0
2010.11.09 20:16:18 2: FHT_2337 set desired-temp 22.0: no confirmation
after 4 tries, giving up
############################################################################################################################################
Dabei ist mir aufgefallen, das FHEM versucht über den CUL die Daten
zusenden, was wohl auch geschiet aber es kommt nix zurück.
Es ist auch im Display des FHT auch keine Änderung zu erkennen. Der
FHT steht dabei auf (NAcht bzw. Absenk Temp. 6 Grad Celcius).
Ich denke doch es sollte nun, wenn erfolgreich eine Verbindung stehen
würde, diese dann geändert sein auf die 22 Grad Celcius.
Was ich auch noch getestet habe, war die Einstellung im FHT "CENT" auf
"ON".
Aber da passiert auch nix.
Weis echt keinen Rat mehr.
Gruß
Denny
Der ganze Mist hat erst angefangen, nachdem ich die FH8v direkt
ansprechen wollte und dies nun wieder rückgängig gemacht habe.
Dabei hatte die FHT vorher die Kennung "054d" diese wurde dann
angepasst für die neue Paarung des Stellantriebes auf "2337" also
3555.
Wie Rudi ja schon geschrieben hat in einem weiteren Thread, empfängt
man ja trotz allem das TV in % des Stellantriebes.
Gibt es eine Möglichkeit den FHT auf die Werkseinstellung
zurückzusetzen????
Rudolf Koenig
> des FHEM sieht so aus:
Da ist offensichtlich fhtsoftbuffer aktiv, was in der Version 5.0 im
Zusammenhang mit einem CUL eher kontraproduktiv ist. Bei der CVS Version
(fuer cvs-phobiker http://www.dhs-computertechnik.de/downloads/fhem-cvs.tgz)
ist es eher egal.
Falls Du es naeher debuggen willst, dann hilft ein "set CUL raw X61", d.h. das
CUL sollte auch die FHT Protokollnachrichten ans fhem melden, und ein "inform
timer" im telnet, siehe auch
http://fhemwiki.de/index.php/Hauskode_der_FHZ1300_herausfinden
> Der ganze Mist hat erst angefangen, nachdem ich die FH8v direkt
> ansprechen wollte und dies nun wieder r�ckg�ngig gemacht habe.
Was steht denn in den jeweiligen Puffer der CUL?
T02 (FHT80b Puffer) sollten die Hex-Codes der Befehle stehen.
T10 (FHT8v Puffer) sollte leer sein.
dossidr
Danke für die Info.
Leider habe ich das Gefühl hier den Gau aller Dinge zu produzieren.
Nachdem isch wie beschrieben den Eintrag:
<Falls Du es naeher debuggen willst, dann hilft ein "set CUL raw X61"
hat sich Fhem aufgehängt.
Was mich dabei völlig überrascht hat, die "fhem.cfg" war völlig leer
nach dem "save" über die Weboberfläche.
Erst nach dem füllen der Standart Einstellungen, welche ja bei der
Installation auch durchgefühert werden, konnte ich wieder mit der
Weboberfläche arbeiten.
Gruß
Denny
On 10 Nov., 08:35, Rudolf Koenig <inf...@koeniglich.de> wrote:
> > Dies scheint aber definitiv nicht der Fall zu sein, denn mein "LOG"
> > des FHEM sieht so aus:
>
> Da ist offensichtlich fhtsoftbuffer aktiv, was in der Version 5.0 im
> Zusammenhang mit einem CUL eher kontraproduktiv ist. Bei der CVS Version
dossidr
nachdem ich nun an meiner VM das Thema nochmals geprüft habe, sendet
und empfängt der FHT wohl wieder Befehle und Temp. Werte.
Wie es genau zur Kommunikation kam ist mir nicht ganz klar, da ich bis
auf Gestern nur im "fhem.cfg" eine weitere Adresse für den FHT
vergeben habe und dann Fhem neu gestartet habe.
FHT SoftBuffer habe ich weider rausgenommen, da ich nicht die .cvs.
verwende.
Kurz darauf hatte ich im Fhem Web 2x den FHT mit folgenden
Bezeichnungen:
FHT_2337--> der war schon seit einigen Tagen vorhanden --> Adresse
(2337) wurde am FHT eingestellt über die "Code" Funktion
FHT_045d --> kam Testweise hinzu, danach sendet der FHT Temp. Werte --
> dies war die original Adresse bei der 1. Inbetriebnahme welche über
"autocreate" erkannt wurde.
Was komisch ist, nach einfügen des Parameters "set CUL raw X61" in die
fhem.cfg kann ich auf die fhem.log im Web nicht mehr zugreifen.
Es sind aber Daten enthalten, wenn ich im System direkt nachschaue.
Woran kann das liegen?
Gruß
Denny
dossidr
nachdem ich nun einige Tage das System am laufen hatte, muss ich
leider zu meiner Unzufriedenheit feststellen, dass es immer zu
sporadischen Problemen mit den FHTś und CUL kommt.
Hier mal ein paar Logdaten vom CUL<-FHT.
2010-11-16_00:39:52 FHT_2337 FHZ:measured-temp: 19.9 (Celsius)
2010-11-16_00:40:00 FHT_2337 time
2010-11-16_00:41:49 FHT_2337 actuator: 0%
2010-11-16_00:41:49 FHT_2337 FHZ:can-xmit: 33
2010-11-16_00:41:50 FHT_2337 can-rcv: 33
2010-11-16_00:41:50 FHT_2337 FHZ:start-xmit: 33
2010-11-16_00:41:50 FHT_2337 start-xmit: 33
2010-11-16_00:41:50 FHT_2337 FHZ:hour: 0
2010-11-16_00:41:50 FHT_2337 hour: 0
2010-11-16_00:41:50 FHT_2337 FHZ:minute: 42
2010-11-16_00:41:50 FHT_2337 minute: 42
2010-11-16_00:41:50 FHT_2337 FHZ:ack: 33
#################################################################
2010-11-16_21:49:47 FHT_2337 FHZ:actuator: unknown_79: 65%
2010-11-16_21:49:47 FHT_2337 actuator: unknown_69: 65%
2010-11-16_21:51:45 FHT_2337 actuator: 0%
2010-11-16_21:51:45 FHT_2337 FHZ:can-xmit: 33
2010-11-16_21:51:45 FHT_2337 FHZ:can-xmit: 33
2010-11-16_21:53:43 FHT_2337 actuator: 0%
2010-11-16_21:53:43 FHT_2337 FHZ:can-xmit: 33
2010-11-16_21:53:44 FHT_2337 can-rcv: 33
2010-11-16_21:53:44 FHT_2337 FHZ:start-xmit: 33
2010-11-16_21:53:44 FHT_2337 FHZ:start-xmit: 33
2010-11-16_21:56:30 FHT_2337 desired-temp 30.5
2010-11-16_21:59:39 FHT_2337 actuator: 0%
2010-11-16_21:59:39 FHT_2337 can-rcv: 100
2010-11-16_22:01:37 FHT_2337 actuator: 0%
2010-11-16_22:01:37 FHT_2337 can-rcv: 100
2010-11-16_22:05:34 FHT_2337 actuator:
0%---------------------------------------------------------> letzte
Empfangszeit
2010-11-17_00:40:00 FHT_2337
time----------------------------------------------------------------->
Reminder aus fhem.cfg
2010-11-17_05:30:00 FHT_2337 desired-temp
30.0----------------------------------------------------> hier ein
"set" obwohl dieser erst um 5:30 Uhr kommen soll laut fhem.cfg
2010-11-17_07:20:33 FHT_2337 actuator: 0%
2010-11-17_07:22:31 FHT_2337 actuator: 0%
2010-11-17_07:24:30 FHT_2337 actuator: 0%
2010-11-17_07:24:30 FHT_2337 can-rcv: 100
2010-11-17_07:26:28 FHT_2337 actuator: 0%
2010-11-17_07:28:27 FHT_2337 actuator: 0%
2010-11-17_07:30:00 FHT_2337 desired-temp 6.0
###################################################################---------------------------------------
> laut Grafik hing danach Fhem oder FHT im Nirvana und es kam nichts
mehr an. Erst nach einem Reset der FHT gings weiter.
Nach dem Reset lief es wieder 2 Tage ohne Probleme!!!!!!
###################################################################
2010-11-18_00:36:11 FHT_2337 start-xmit: 33
2010-11-18_00:36:12 FHT_2337 FHZ:start-xmit: 33
2010-11-18_00:36:12 FHT_2337 ack2: 33
2010-11-18_00:36:12 FHT_2337 FHZ:ack2: 33
2010-11-18_00:37:25 FHT_2337 actuator: 0%
2010-11-18_00:39:23 FHT_2337 actuator: 0%
2010-11-18_00:40:00 FHT_2337 time
2010-11-18_00:40:11 FHT_2337 start-xmit: 33
2010-11-18_00:40:12 FHT_2337 FHZ:start-xmit: 33
2010-11-18_00:40:12 FHT_2337 measured-temp: 19.5 (Celsius)
2010-11-18_00:40:12 FHT_2337 FHZ:measured-temp: 19.5 (Celsius)
2010-11-18_00:40:12 FHT_2337 ack: 33
2010-11-18_00:40:12 FHT_2337 FHZ:ack: 33
2010-11-18_00:40:13 FHT_2337 battery: ok
2010-11-18_00:40:13 FHT_2337 lowtemp: ok
2010-11-18_00:40:13 FHT_2337 window: closed
2010-11-18_00:40:13 FHT_2337 windowsensor: ok
2010-11-18_00:40:13 FHT_2337 warnings: none
2010-11-18_00:40:13 FHT_2337 battery: ok
2010-11-18_00:40:13 FHT_2337 lowtemp: ok
2010-11-18_00:40:13 FHT_2337 window: closed
2010-11-18_00:40:13 FHT_2337 windowsensor: ok
2010-11-18_00:40:13 FHT_2337 FHZ:warnings: none
#####################################################################
ab dem 20 auf den 21 gab es wieder Probleme und Bad blieb kalt:-
(!!!!!!!!!
2010-11-20_19:16:46 FHT_2337 start-xmit: 33
2010-11-20_19:16:47 FHT_2337 FHZ:start-xmit: 33
2010-11-20_19:30:36 FHT_2337 actuator: 0%
2010-11-20_19:32:34 FHT_2337 actuator: 0%
2010-11-20_19:34:33 FHT_2337 actuator: 0%
2010-11-20_19:36:31 FHT_2337 actuator:
0%---------------------------------------------> letzter Empfang!
2010-11-21_00:40:00 FHT_2337
time-----------------------------------------------------> Reminder
aus fhem.cfg
2010-11-21_05:30:00 FHT_2337 desired-temp
30.0----------------------------------------> Wurde nicht umgesetzt
und Bad blieb kalt! :-(
2010-11-21_05:38:54 FHT_2337 actuator: 0%
2010-11-21_05:38:54 FHT_2337 FHZ:can-xmit: 33
2010-11-21_05:38:54 FHT_2337 FHZ:can-xmit: 33
2010-11-21_06:34:12 FHT_2337 actuator: 0%
2010-11-21_06:34:12 FHT_2337 FHZ:can-xmit: 33
2010-11-21_06:34:12 FHT_2337 can-rcv: 33
########################################################################
Da ich den Verdacht nicht loswerde, das die FW des FHT zerschossen
ist, werde ich den FHT tauschen lassen.
Ich habe jetzt fast alle Threads bezüglich "Paarung" durch, auch das
WIKI in alle Richtungen studiert, aber ich denke fats es hat dem FHT8v
nicht gut getan, diesen "direkt" zu integrieren.
Kann evtl. die FHT8b auf die Werkseinstellung zurückgesetzt werden?
Abschließend noch die Frage, wieso hängt sich die Verbindung oder wie
auch immer, genau im 00:40:00 Uhr auf?? Liegt das evtl. an dem
"Reminder" welcher in der fhem.cfg drin hängt?
Kann es sein das bei der Erinnerung durch den "Meister", die FHT einen
Würfelhusten bekommt und dadurch regelmäßig aussteigt?
Werde diesen jetzt mal rausnehmen und neu testen.
> > des FHEM sieht so aus:
>
> Da ist offensichtlich fhtsoftbuffer aktiv, was in der Version 5.0 im
> Zusammenhang mit einem CUL eher kontraproduktiv ist. Bei der CVS Version
Dr. Boris Neubert
> Abschlie�end noch die Frage, wieso hÀngt sich die Verbindung oder wie
> auch immer, genau im 00:40:00 Uhr auf?? Liegt das evtl. an dem
> Kann es sein das bei der Erinnerung durch den "Meister", die FHT einen
> Werde diesen jetzt mal rausnehmen und neu testen.
Nur zur Sicherheit:
- fhtsoftbuffer ist nicht gesetzt, und
- die aktuelle fhem- und culfw-Versionen aus dem CVS sind im Einsatz?
Gruesse,
Boris
Rudolf Koenig
Das passiert mWn wenn man das Geraet neu paart oder die Batterie entfernt.
> Abschlie�end noch die Frage, wieso h�ngt sich die Verbindung oder wie
> auch immer, genau im 00:40:00 Uhr auf??
Die Verbindung war laut Log schon vorher (20:19) gestoert.
> Liegt das evtl. an dem "Reminder" welcher in der fhem.cfg drin h�ngt?
Was macht denn dieser Reminder? Vor irgendwelchen resets bitte volgendes pruefen:
- was ist in den FHT80b Puffer des CUL (get CUL raw T02)
- was ist in den FHT8v Puffer des CUL (get CUL raw T10)
- empfaengt das CUL andere Signale (S300, etc)
- kann man via CUL Daten aussenden (FS20, andere FHTs)
- reagiert das Ventil nach manuelles verstellen der FHT80b-Teperatur?
dossidr
fhtsoftbuffer --> off
FHEM Version 5.0 Release
CUL-FW --> 1.38
Gruß
Denny
dossidr
was ist in den FHT80b Puffer des CUL (get CUL raw T02)
Problme
umstelle reagiert der Stellantrieb aber keine Temp. im WEBIF.
Habe den HC auf 1234 von 2147 geändert. Weiterhin habe ich den FHT
Code auf 054d von 2337 zurück geändert.
Danach die Neustart. Immer noch keine Temp. und auch Kein "on" im CENT
obwohl ich eine "desired" Temp gesendet habe.
Danach habe ich T02 und T10 im WEBIF ausgeführt. Kam aber leider nur N/
A.
Allerdings war danach sofort die Temp. da.
Gruß
Denny
dossidr
Update wegen CUL FW
habe den auf ----> 1.39 V3 geflasht.
:-)
Gruß
Denny
Michael Röhrig
ich habe mich nochmal auf die Suche gegeben um heraus zu finden wo jetzt
genau das Problem liegt, dass einige von meinen FHT's keine aktuelle
Temperatur liefern und auch ein Anfordern der Reports um die
"vergesslichen" FHT's daran zu erinnern hilft nicht immer und wenn nur
zeitweise...
Auf dem Weg zur Fehlereingrenzung half "Aldi Nord", dort habe ich zwei
S�tze ergattern k�nnen.
Danach ging's auf die Suche:
1.) Schritt: einen der neuen FHT's einbauen und am FHEM anmelden...
...Trommelwirbel...
...l�uft seit dem ohne Ausf�lle.
2.) Schritt: eine der "Problem FHT's" gegen eins vom Aldi austauschen
(alles gleich gelassen, Code �bernommen), angemeldet...
...Trommelwirbel...
...l�uft seit dem ohne Ausf�lle.
Jetzt packt mich der Ehrgeiz... Leider gab's bei Aldi Nord in meiner
N�he nicht mehr FHT's...
...nochmal DANKE an Klaus, da gabs noch welche...
...heute noch zwei auf dem gleichen Weg ausgetauscht...
...werde die Tage mal Bericht erstatten.
Ich habe aber mal nachgeschaut welche Version die FHT's haben die laufen
und welche Version die haben die nicht laufen.
Als Version bezeichne ich mal die Zahlen die beim Einschalten (Einlegen
der Batterien) angezeigt werden.
Die drei FHT's die nicht gehen haben alle die Version "2.2"
Die die gehen, haben die Version "3.1" bzw "3.2"...
Das spricht f�r mich daf�r, dass es wohl (Software-) Versionen gibt die
ne Macke haben...
Evtl. kann das ja mal der eine oder andere der Probleme hat/keine
Probleme hat mal vergleichen...
Viele Gr��e aus K�ln
Michael
Thomas Boehne
On 02/10/2011 09:05 PM, Michael R�hrig wrote:
> ich habe mich nochmal auf die Suche gegeben um heraus zu finden wo jetzt
> genau das Problem liegt, dass einige von meinen FHT's keine aktuelle
> Temperatur liefern und auch ein Anfordern der Reports um die
> "vergesslichen" FHT's daran zu erinnern hilft nicht immer und wenn nur
> zeitweise...
Gut zu wissen, dass auch andere wegen des Problems schlaflose N�chte
haben... Ich habe mir jetzt extra einen CUL als RFR gekauft, um das
Problem zu beheben, hat aber leider auch nicht geholfen. Also an der
Empfangsqualit�t kann es bei mir jetzt eigentlich nicht mehr liegen, da
der RFR im gleichen Raum ist wieder der problematische FHT.
> Ich habe aber mal nachgeschaut welche Version die FHT's haben die laufen
> und welche Version die haben die nicht laufen.
> Als Version bezeichne ich mal die Zahlen die beim Einschalten (Einlegen
> der Batterien) angezeigt werden.
> Die drei FHT's die nicht gehen haben alle die Version "2.2"
> Die die gehen, haben die Version "3.1" bzw "3.2"...
Man lernt nie aus... Ich wusste gar nicht, dass es verschiedene
Versionen gibt.
Leider muss ich Dir mitteilen, dass meine alle die Version 3.1 haben,
und auch da bei zweien �fters das Problem auftritt. Ich habe die FHTs
alle als Set-3 im Sommer 2010 gekauft.
Gr��e aus Bensheim
Thomas
Zrrronggg!
auf 464 khz erhöht habe.
Es scheint also so, als ob aus was für grünen auch immer, die Frequenz
des FHT irgendwie ein bischen daneben lag.
Rudolf Koenig
> des FHT irgendwie ein bischen daneben lag.
Wenn ich es richtig verstanden habe, ist das ein grundsaetzliches Problem:
FHT & Konsorten verwenden einfachere Empfaenger (Pendelempfaenger?), die auf
breiteren Frequenzband empfindlich sind als CUL&co. Fuer diese Geraete ist die
Ungenauigkeit also egal.
Edwin Top
> Ein FHT machte bei mir auch Probleme, bis ich die Bandbreite des CUL
da ich genau das Problem auch habe, wusste ich gerne wie man die
Bandbreidte �ndert.
Gru�,
Edwin Top
Thomas Boehne
> On 02/11/2011 02:09 AM, Zrrronggg! wrote:
>> Ein FHT machte bei mir auch Probleme, bis ich die Bandbreite des CUL
>
> da ich genau das Problem auch habe, wusste ich gerne wie man die
get MyCUL ccconf
MyCUL ccconf => freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
set MyCUL bWidth 464
get MyCUL ccconf
MyCUL ccconf => freq:868.300MHz bWidth:464KHz rAmpl:42dB sens:4dB
Grüße
Thomas
Juergen Lennefer
> MyCUL ccconf => freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
> set MyCUL bWidth 464
> get MyCUL ccconf
> MyCUL ccconf => freq:868.300MHz bWidth:464KHz rAmpl:42dB sens:4dB
fhem.cfg packen?
Wenn ich das CUL-Readme richtig interpretiere, muss man noch ein X21
hinterher schicken, wenn geflasht werden soll:
- after changing the value (in the EEPROM) an X command (X21) will be
necessary to write the EEPROM changes to the CC1101.
Rudolf Koenig
> fhem.cfg packen?
Das fhem Befehl macht alles "richtig" :), und verweigt es ins eeprom.
Thomas Böhne
> Ein FHT machte bei mir auch Probleme, bis ich die Bandbreite des CUL
> auf 464 khz erhöht habe.
es
eigentlich die meiste Zeit mit normaler Bandbreite ziemlich stabil.
Jetzt
habe ich die Bandbreite auf 464 kHz hochgesetzt, und trotzdem ist
heute
früh der Empfang von 2 FHTs fast komplett abgerissen.
Externe Störungen sind natürlich möglich, aber da diese Probleme oft
mitten in der Nacht anfangen und meistens nach FHT-Neustart oder
CUL-Neustart behoben sind halte ich ein prinzipielles Problem für
wahrscheinlicher.
Hier mal ein Logfile von einem FHT, den ich jetzt ohne Änderung
wieder
korrekt und regelmäßig empfangen kann:
2011-02-15_04:26:59 GZ_Thermostat measured-temp: 18.1 (Celsius)
2011-02-15_04:27:00 GZ_Thermostat battery: ok
2011-02-15_04:27:00 GZ_Thermostat lowtemp: ok
2011-02-15_04:27:00 GZ_Thermostat window: closed
2011-02-15_04:27:00 GZ_Thermostat windowsensor: ok
2011-02-15_04:27:00 GZ_Thermostat warnings: none
2011-02-15_04:28:55 GZ_Thermostat actuator: 0%
2011-02-15_04:30:00 GZ_Thermostat time
2011-02-15_04:30:51 GZ_Thermostat actuator: 0%
2011-02-15_04:30:52 GZ_Thermostat hour: 4
2011-02-15_04:30:53 GZ_Thermostat minute: 31
2011-02-15_04:32:48 GZ_Thermostat actuator: 0%
2011-02-15_04:36:41 GZ_Thermostat actuator: 0%
2011-02-15_04:36:42 GZ_Thermostat hour: 4
2011-02-15_04:36:43 GZ_Thermostat minute: 37
2011-02-15_04:38:37 GZ_Thermostat actuator: 0%
2011-02-15_04:40:34 GZ_Thermostat actuator: 0%
2011-02-15_04:42:30 GZ_Thermostat actuator: 0%
2011-02-15_04:42:31 GZ_Thermostat measured-temp: 18.1 (Celsius)
2011-02-15_04:42:32 GZ_Thermostat battery: ok
2011-02-15_04:42:32 GZ_Thermostat lowtemp: ok
2011-02-15_04:42:32 GZ_Thermostat window: closed
2011-02-15_04:42:32 GZ_Thermostat windowsensor: ok
2011-02-15_04:42:32 GZ_Thermostat warnings: none
2011-02-15_04:44:27 GZ_Thermostat actuator: 0%
2011-02-15_04:45:00 GZ_Thermostat report1 255 report2 255
2011-02-15_04:46:24 GZ_Thermostat actuator: 0%
2011-02-15_04:46:25 GZ_Thermostat report1: 255
2011-02-15_04:46:25 GZ_Thermostat report2: 255
2011-02-15_04:48:20 GZ_Thermostat actuator: 0%
2011-02-15_04:48:21 GZ_Thermostat mon-from1: 08:00
2011-02-15_04:48:21 GZ_Thermostat mon-to1: 17:00
2011-02-15_04:50:16 GZ_Thermostat actuator: 0%
2011-02-15_04:50:17 GZ_Thermostat mon-from1: 08:00
2011-02-15_04:50:18 GZ_Thermostat mon-from2: 24:00
2011-02-15_04:52:13 GZ_Thermostat actuator: 0%
2011-02-15_04:52:14 GZ_Thermostat mon-from1: 08:00
2011-02-15_04:54:09 GZ_Thermostat actuator: 0%
2011-02-15_04:56:06 GZ_Thermostat actuator: 0%
2011-02-15_04:58:02 GZ_Thermostat actuator: 0%
2011-02-15_04:58:03 GZ_Thermostat mon-from1: 08:00
2011-02-15_04:58:04 GZ_Thermostat mon-from1: 08:00
2011-02-15_04:59:59 GZ_Thermostat actuator: 0%
2011-02-15_05:01:55 GZ_Thermostat actuator: 0%
2011-02-15_05:03:52 GZ_Thermostat actuator: 0%
2011-02-15_05:03:53 GZ_Thermostat mon-from1: 08:00
2011-02-15_05:05:48 GZ_Thermostat actuator: 0%
2011-02-15_05:07:45 GZ_Thermostat actuator: 0%
2011-02-15_05:09:41 GZ_Thermostat actuator: 0%
2011-02-15_05:11:38 GZ_Thermostat actuator: 0%
2011-02-15_05:13:34 GZ_Thermostat actuator: 0%
2011-02-15_05:13:35 GZ_Thermostat mon-from1: 08:00
2011-02-15_05:13:35 GZ_Thermostat mon-to1: 17:00
2011-02-15_05:13:36 GZ_Thermostat mon-from2: 24:00
2011-02-15_05:13:36 GZ_Thermostat mon-to2: 24:00
2011-02-15_05:13:36 GZ_Thermostat tue-from1: 08:00
2011-02-15_05:13:37 GZ_Thermostat tue-to1: 17:00
2011-02-15_05:15:31 GZ_Thermostat actuator: 0%
2011-02-15_05:19:24 GZ_Thermostat actuator: 0%
2011-02-15_05:21:20 GZ_Thermostat actuator: 0%
2011-02-15_05:23:17 GZ_Thermostat actuator: 0%
2011-02-15_05:23:18 GZ_Thermostat tue-from1: 08:00
2011-02-15_05:23:18 GZ_Thermostat tue-to1: 17:00
2011-02-15_05:23:18 GZ_Thermostat tue-from2: 24:00
2011-02-15_05:23:18 GZ_Thermostat tue-to2: 24:00
2011-02-15_05:23:19 GZ_Thermostat tue-to2: 24:00
2011-02-15_05:25:13 GZ_Thermostat actuator: 0%
2011-02-15_05:27:10 GZ_Thermostat actuator: 0%
2011-02-15_05:29:06 GZ_Thermostat actuator: 0%
Die report-Daten kommen noch, das bedeutet doch, dass Empfang in beide
Richtungen korrekt funktionieren muss, richtig? Die actuator-Daten
werden ja nur vom CUL empfangen, aber für report wird doch bereits
ein
bidirektionales Protokoll gefahren.
Vielleicht hat ja jemand eine Idee dazu. Ich habe übrigens das
Gefühl,
dass vermehrt Probleme auftreten, wenn ich täglich reports von FHTs
abhole.
Die betroffenen FHTs sind Luftlinie 4m vom CUL entfernt, mit einer
Rigipswand und einer dünnen gemauerten dazwischen.
Thomas
Zrrronggg!
Versuchskette, basieren auf Rudolfs vorversuchen.
Andere Leute (auch hier in der Group) hatten schon abweicheungen von
mehr bei einzelnen FHTs. wEnn in den Dingern tatsächlich nur
Pendelempfänger drin sind (weiss ich nicht genau) dann reicht schon
Temperatur, Luftfeuchte, Mondprotuberanzen oder anfassen um die
Freuquenz zu ändern.
report 1 und report 2 erzeugt nett Funklast. du hast nicht im Log
irgendwo LOFV Messages? (in inform sieht man die glaube ich nicht)
Bei nur 4 FHTs wäre das eher ungewöhnlich aber zur Sicherheit sieh
doch mal nach.
report1 liefert eigentlich nur das Wochenprogramm, muss man sich
überlegen, ob man die Daten wirklich braucht. Ich fordere nur report 2
an und das 2x die Woche und zwar für die FHTs versetzt. Täglich bringt
eigentlich nix, weil report x immer für 3-5 Tage hält (wie lange weiss
ich eigentlich gar nicht, aber 1x die Woche report anfordern reicht
nicht.)
lass doch testweise mal report1 weg. Erfolg würdest du aber erst in
2-3 Tagen sehen, nämlich wenn die FHTs aufhören report1 Daten zu
senden.
Zrrronggg!
Kurz nochmal:
- täglich report senden bringt nix, da report immer 3-5 Tage aussenden
von reportdaten zur Folge hat. Ich mach's 2x pro Woche, reicht
- report 1 und report 2 erzeugt durchaus Funklast. Sollte bei 4 FHTs
zwar kein Problem sein, aber check doch mal bitte das log auf LOFV
meldungen.
- report 1 fragt die Schaltpunkte des FHT ab. Brauchst du die täglich
neu? Vielleicht lässt du mal probeweise report 1 auslaufen
- wenn die FHTs Pendelempfänger haben, kann von genauigkeit bei der
Frequenz keine Rede sein. Schon anfassen würde reichen um die Frequenz
zuändern. die 464 Khz haben bei mir geholfen, einzelne FHTs könnten
auch mehr daneben liegen.
Dr. Boris Neubert
bei mir ist das beschriebene Problem mit den verstummenden FHTs weg,
seit ich für jeden FHT eine Zeile der Form
define watchdog.3.dz.hzg watchdog 3.dz.hzg 00:15:00 SAME set 3.dz.hzg
report2 255
in der fhem.conf habe.
Grüße,
Boris
Rudolf Koenig
Und bei mir hat das nicht geholfen, dafuer aber hat es nach 2 Wochen Pause von
sich aus angefangen zu senden. :) Meine "EEPROM" Theorie ist damit leider auch
hinfaellig.
Juergen Lennefer
aber immer measured-temp, selten bis nie actuator und desired-temp.
report2=255 hilft ihnen meistens auf die SPrünge, aber nur für kurze
Zeit.
Seit dem EInsatz des 2. CUL ist das nicht wirklich besser geworden
(nur wesentlich weniger LOVF).
Die bWidth-Anhebung auf 464kHz vom Samstag hat nix gebracht, auch
nicht die Erhöhung von sens auf 12dB.
Ich versuche jetzt mal Boris' watchdog-Empfehlung. Das aber die
measured-temp immer kommt, wird das wohl auch nicht helfen.
Juergen Lennefer
> Von meinen 8 FHTs sind meistens 3-5 (aktuell 5) recht still, senden
> aber immer measured-temp, selten bis nie actuator und desired-temp.
> report2=255 hilft ihnen meistens auf die SPrünge, aber nur für kurze
> Zeit.
auch regelmäßig, aber desired-temp bei vielen der FHTs nur auf
Aufforderung.
Ein manuell verschickter report2=255 gestern Abend hat die
schweigenden 5 FHTs dazu bewegt, auch ein desired-temp zu melden. Das
wars dann.
Heute morgen verweigern 6 von 8 FHTs die Aussagen der eingestellten
Temperatur:
2011-01-30_16:28:57 fht.dg.bad desired-temp: 9.0
2011-02-11_13:48:02 fht.dg.bad desired-temp: 9.0
2011-02-11_14:01:41 fht.dg.bad desired-temp: 9.0
2011-02-15_19:33:29 fht.dg.bad desired-temp: 9.0
2011-02-15_19:37:22 fht.dg.bad desired-temp: 9.0
===============================
2011-01-30_16:31:53 fht.dg.sz desired-temp: 8.0
2011-01-30_16:37:40 fht.dg.sz desired-temp: 8.0
2011-01-30_16:37:40 fht.dg.sz FHZ:desired-temp: 8.0
2011-02-11_14:00:37 fht.dg.sz desired-temp: 8.0
2011-02-15_19:27:29 fht.dg.sz desired-temp: 8.0
===============================
2011-01-30_16:53:21 fht.dg.wz desired-temp: 9.0
2011-01-30_16:53:21 fht.dg.wz FHZ:desired-temp: 9.0
2011-02-11_13:58:42 fht.dg.wz desired-temp: 9.0
2011-02-15_19:43:39 fht.dg.wz desired-temp: 9.0
===============================
2011-02-15_04:59:55 fht.eg.bad desired-temp: 22.0
2011-02-15_09:00:33 fht.eg.bad desired-temp: 16.0
2011-02-15_15:29:53 fht.eg.bad desired-temp: 22.0
2011-02-15_21:29:53 fht.eg.bad desired-temp: 16.0
2011-02-16_04:59:53 fht.eg.bad desired-temp: 22.0
===============================
2011-02-15_19:23:53 fht.eg.sz desired-temp: 19.5
2011-02-15_19:37:30 fht.eg.sz desired-temp: 19.5
2011-02-15_19:37:31 fht.eg.sz desired-temp: 19.5
2011-02-15_19:39:25 fht.eg.sz desired-temp: 19.5
2011-02-15_20:01:11 fht.eg.sz desired-temp: 13.0
===============================
2011-02-14_18:31:03 fht.eg.wz desired-temp: 21.0
2011-02-14_21:30:46 fht.eg.wz desired-temp: 15.5
2011-02-15_05:01:04 fht.eg.wz desired-temp: 21.0
2011-02-15_21:30:33 fht.eg.wz desired-temp: 15.5
2011-02-16_05:00:51 fht.eg.wz desired-temp: 21.0
===============================
2011-02-09_08:40:34 fht.kg.az desired-temp: 15.0
2011-02-09_18:50:42 fht.kg.az desired-temp: 12.5
2011-02-11_13:54:37 fht.kg.az desired-temp: 12.5
2011-02-15_19:31:26 fht.kg.az desired-temp: 12.5
2011-02-15_19:31:26 fht.kg.az desired-temp: 12.5
===============================
2011-02-15_18:00:57 fht.kg.wnz desired-temp 25 holiday1 126 holiday2
15 mode holiday_short
2011-02-15_18:01:32 fht.kg.wnz desired-temp: 25.0
2011-02-15_18:04:00 fht.kg.wnz desired-temp: 16.0
2011-02-15_18:04:01 fht.kg.wnz desired-temp: 16.0
2011-02-15_18:59:10 fht.kg.wnz desired-temp: 16.0
Zur Erklärung: die 3 FHTs im Dachgeschoss stehen auf manuell und 9°,
weil da gerade keiner mehr wohnt, aber egal.
Wie würde eine watchdog-Definition aussehen, die auf fehlende desired-
temp reagiert?
Juergen Lennefer
> Wie würde eine watchdog-Definition aussehen, die auf fehlende desired-
> temp reagiert?
define watchdog.fht.dg.sz watchdog fht.dg.sz 02:00:00
fht.dg.sz.*desired-temp set fht.dg.sz report2 255
Michael Röhrig
so, nach fast einer Woche wollte ich mich dann doch nochmal melden...
Seit dem Austausch habe ich von allen FHT's regelm��ig die
Raumtemperatur erhalten.
Demnach m�chte ich mal einen Fehler im fhem oder CUN ausschlie�en...
...ob jetzt die Revision der FHTs eine Rolle spielt oder ab das Zufall
ist bzw. ob die Revision Software oder Hardware oder beides beeinflu�t
wei� ich nicht.
Mir ist auf jeden Fall aufgefallen, dass die "neueren" FHTs im
Batteriefach eine Art "Programmieranschlu�" haben (7 Kontaktfl�chen in
einer Reihe).
Ob da auch ein anderes Funkmodul drin ist wei� ich aber noch nicht...
Ich werde jetzt im n�chsten Schritt mal eins von den "kaputten" FHTs in
einem anderen Raum einbauen und die Bandbreite in CUN hochsetzen...
Ob das hilft schreibe ich dann in ca. 1 Woche...
Viele Gr��e aus K�ln
Michael