FHEM bleibt stehen - FHT80b-FHT8v

[kud]

                                                 

Und es geht schon wieder los.
Nachdem FHEM brav über Wochen /Monate seinen Dienst getan hat nahm ich
wieder ein Pärchen
FHT80b-3 - FHT8v-3 in Betrieb.
Wie schon letzte Heizperiode blieb FHEM einfach nach unbestimmter Zeit
stehen.
Kein Eintrag im Log ! Nichts.
Die Position der Teile habe ich auch verändert. Von 10 Meter bis 1 Meter.
Egal. Wenn dieses Pärchen Batterie hat bleibt FHEM irgendwann stehn.
So. Nun die Frage.
Kann man irgendwie die Fehler einkreisen oder sollte man sich dieser
Hardware trennen?
Garantie ist noch. Gerätefehler?
Wie geht man am besten vor?

Danke und Gruss
Kai-Uwe

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

[Zrrronggg!]

                                                     

Ich habe starke Zweifel das "FHEM bleibt stehen" (Was immer das im
Detail genau bedeutet) mit einem defekten FHT80b zu tun hat.

Ich werde dir vermutlich nicht richtig helfen können, würde aber -
damit zumindest andere eine Chance haben - denken, das du folgende
Infos liefern solltest:

FHEM läuft worauf?
Welche Version?
Funkschnittstelle ist? Mit welcher Firmware?
Wie sieht sehen die Zeilen aus, die die Funkschnittstelle in der
config definieren?
Wie lange ist die "unbestimmte Zeit" ungefähr? Von bis?
Wenn FHEM stehen bleibt, wie sieht ein mittlaufendes Telent info timer
aus?
Wie sieht das Log in Verbose5 kurz vorher aus?
Schonmal die Kommunikation mit X61 (sofern Funkschnittstelle CUL oder
CUNO) angesehen?
Kann man vorher Kommandos an das fragliche FHT senden?
Wenn FHEM stehen bleibt, geht der Hostrechner noch ganz normal?
Speicher? TOP?





On 16 Okt., 11:44, KUD wrote:
> Und es geht schon wieder los.
> Nachdem FHEM brav über Wochen /Monate seinen Dienst getan hat nahm ich
> wieder ein Pärchen
> FHT80b-3 - FHT8v-3 in Betrieb.
> Wie schon letzte Heizperiode blieb FHEM einfach nach unbestimmter Zeit
> stehen.
> Kein Eintrag im Log ! Nichts.
> Die Position der Teile habe ich auch verändert. Von 10 Meter bis 1 Meter.
> Egal. Wenn dieses Pärchen Batterie hat bleibt FHEM irgendwann stehn.
> So. Nun die Frage.
> Kann man irgendwie die Fehler einkreisen oder sollte man sich dieser
> Hardware trennen?
> Garantie ist noch. Gerätefehler?
> Wie geht man am besten vor?
>
> Danke und Gruss
> Kai-Uwe

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

[kud]

                                                 

Danke für die Antwort.
Leider kann ich mit vielen von Dir aufgeführten Dingen nichts anfangen.

Hardware ist ein Minilinuxrechner (HP T5700) und Debian Squeeze).
Rechner läuft. FHEM läuft auch immer noch. Ich kann per Webinterface noch
alles steuern und abfragen.
Die "Datenerfassung" ist leider stehengeblieben.
Ich habe auch einen neue Kombi FHTb + 8v integriert.
Gleicher Effekt. Datenerfassung bleibt nach ca. 12 Stunden stehen.
Also hat es generell mit den FHT80b+8v zu tun.
Ich habe jetzt mal das Level auf 5 gesetzt und FHEM neu gestartet.
Was ist mit Kommunikation und X61 gemeint?

Gruss Kai-Uwe

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

[Guest]

Originally posted by: <email address deleted>

Steht nich tirgendwo im Wiki, das ein FHT80b irgendwann die Kommunikation
nach außen hin einstellt, wenn er von außen nichts hört? Sende mal mit FHEM
ein Befehl an den FHT ab und schau was passiert. Ich such mal die Stelle im
Wiki.

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

[Guest]

Originally posted by: <email address deleted>

Hier stehts: http://www.fhemwiki.de/wiki/FHT80b#Bekannte_Probleme

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

[kud]

                                                 

Danke für die Antwort.
Das Problem sind aber nicht nur die FHTs, sondern alle Messwerte bleiben
stehen.
Keine Temp. von S300TH , keine Feuchte nix.
Also die generelle Erfassung bleibt stehen.
(Wie gesagt.Nur wenn die FHTs laufen)

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

[Guest]

Originally posted by: <email address deleted>

steht denn irgendwas in den Logs? Kannst du noch Befehle absenden? Oder
befehle aktiv abrufen wie bei den FHTs im Wiki beschrieben?

Am Donnerstag, 18. Oktober 2012 15:26:09 UTC+2 schrieb KUD:
>
> Danke für die Antwort.
> Das Problem sind aber nicht nur die FHTs, sondern alle Messwerte bleiben
> stehen.
> Keine Temp. von S300TH , keine Feuchte nix.
> Also die generelle Erfassung bleibt stehen.
> (Wie gesagt.Nur wenn die FHTs laufen)
>

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

[kud]

                                                 

Ich habe jetzt mal das Loglevel auf 5 gesetzt und schau mal was passiert.

Hier die letzten Logzeilen:

2012-10-18_16:03:30 FHT_250c actuator: 66%
2012-10-18_16:01:33 FHT_250c actuator: 66%
2012-10-18_15:59:36 FHT_250c actuator: 66%
2012-10-18_15:57:41 FHT_250c end-xmit: 18
2012-10-18_15:57:40 FHT_250c ack: 18
2012-10-18_15:57:40 FHT_250c windowsensor: ok
2012-10-18_15:57:40 FHT_250c window: closed
2012-10-18_15:57:40 FHT_250c lowtemp: ok
2012-10-18_15:57:40 FHT_250c battery: ok
2012-10-18_15:57:40 FHT_250c warnings: none
2012-10-18_15:57:40 FHT_250c windowsensor: ok
2012-10-18_15:57:40 FHT_250c window: closed
2012-10-18_15:57:40 FHT_250c lowtemp: ok
2012-10-18_15:57:40 FHT_250c battery: ok
2012-10-18_15:57:40 FHT_250c ack: 18
2012-10-18_15:57:40 FHT_250c temperature: 18.3
2012-10-18_15:57:40 FHT_250c measured-temp: 18.3
2012-10-18_15:57:39 FHT_250c start-xmit: 18



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

[Guest]

Originally posted by: <email address deleted>

Die Beschreibung ist immer noch vollkommen wirr.

Was soll den heißen "bleibt stehen" ? Woher stammt denn diese Information ?

Wenn jemand hier liest "FHEM bleibt stehen", schließt er daraus in der
Regel "FHEM ist abgestürzt". Das scheint aber nicht der Fall zu sein - also
was ist gemeint ?

Reagiert das Webfrontend ?

Gibt es noch Ereignisse im Log ?

Gibt es Fehlermeldungen im Systemlog (tail -f /var/log/messages) ?

pah

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

[kud]

                                                 

Ok.
Bevor ich noch mehr "dumme" Angaben mache, werde ich nach dem nächsten
"Meßdatenerfassungshänger"
mal ausprobieren was noch geht und was nicht.
Vorerst kann ich nur sagen, es werden nach einer Zeit von ca. 12 Stunden
die Meßwerte nicht mehr aktualiesiert.
Weder im Floorplan noch in den Log-Dateien.
"/var/log/fhem/fhem..." sagt bisher nichts. Gar nichts.
"/var/log/messages" Null. Linux läuft ohne Mäckern.
Nochmal die "Meßdatenerfassungshänger" haben definitiv was mit den FHTs zu
tun denn Monate ohne diese Hardware war alles ok.
Dito Anfang des Jahres. Nachdem ich die Teile Stromlos gemacht habe war
alles gut.
Also. Ich warte auf den nächsten Hänger und berichte.





Am Donnerstag, 18. Oktober 2012 17:05:45 UTC+2 schrieb Prof. Dr. Peter A.
Henning:
>
> Die Beschreibung ist immer noch vollkommen wirr.
>
> Was soll den heißen "bleibt stehen" ? Woher stammt denn diese Information ?
>
> Wenn jemand hier liest "FHEM bleibt stehen", schließt er daraus in der
> Regel "FHEM ist abgestürzt". Das scheint aber nicht der Fall zu sein - also
> was ist gemeint ?
>
> Reagiert das Webfrontend ?
>
> Gibt es noch Ereignisse im Log ?
>
> Gibt es Fehlermeldungen im Systemlog (tail -f /var/log/messages) ?
>
> pah
>

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

[Tina]

                                                           

Ich habe leider das gleiche Problem. Ich habe es bisher hier noch nicht beschrieben, da ich es überhaupt nicht verstehe.

Das Phänomen beschreibt sich wie folgt:
Nach ganz unterschiedlichen Zeiten (Tage oder auch nur wenige Stunden) besteht keine Kommunikation mehr zwischen den FHTs und FHEM.
D.h. In den Logfiles erscheinen keine Werte von den FHTs ( wie Temperatur oder Batteriestatus) und ich kann von FHEM auch keine Befehle mehr senden bzw. sie kommen nicht bei den FHTs an.
In sämtlichen Logfiles von FHEM finden sich keine Fehlermeldungen.
Das gleiche Phänomen betrifft auch  meine ESA 2000.
Ich habe insgesamt 5 FHT80b.
Alle anderen FS20-Geräte, wie z.B. Steckdosen und auch die FHEM Weboberfläche funktionieren weiterhin einwandfrei.
Ein Neustart von FHEM löst das Problem kurzzeitig.

FHEM läuft bei mir auf einer FritzBox 7170 mit Freetz und einem CUL (ich glaube V2).

Es wäre toll, wenn wir eine Lösung finden würden.

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

[Guest]

Originally posted by: <email address deleted>

Halli,

ich hatte zuletzt ein ähnliches Problem - ich hatte meine FHTs meist der
Reihe nach nach dem rereadcfg um 00:05 verloren. Das reread war bei mir
nicht wirklich "schuld" - Lösung, die seit gut anderthalb Wochen jetzt
funktioniert ist ein zweiter Cul als RFR.
Habt ihr einmal mit "*set* CUL1 raw *X67" *die FHT-Protokollierung
eingeschaltet und dann mit einem inform timer im Telnet geschaut was da
passiert - bei mir sah das so katastrophal aus, dass ich dann endlich den
zweiten CUL aus der Schublade gekramt habe (mit 10 FHTs war ich aber eh an
der Grenze des machbaren). In den normalen fhem-Logs war auch erstmal nicht
drin, ich war erstmal durch den zeitlichen Zusammenhang auf der falschen
Fährte.

Vielleicht hilft's beim Suchen,
viele Grüße,
Martin

Am Donnerstag, 18. Oktober 2012 20:06:24 UTC+2 schrieb Tina:
>
> Ich habe leider das gleiche Problem. Ich habe es bisher hier noch nicht
> beschrieben, da ich es überhaupt nicht verstehe.
>
> Das Phänomen beschreibt sich wie folgt:
> Nach ganz unterschiedlichen Zeiten (Tage oder auch nur wenige Stunden)
> besteht keine Kommunikation mehr zwischen den FHTs und FHEM.
> D.h. In den Logfiles erscheinen keine Werte von den FHTs ( wie Temperatur
> oder Batteriestatus) und ich kann von FHEM auch keine Befehle mehr senden
> bzw. sie kommen nicht bei den FHTs an.
> In sämtlichen Logfiles von FHEM finden sich keine Fehlermeldungen.
> Das gleiche Phänomen betrifft auch  meine ESA 2000.
> Ich habe insgesamt 5 FHT80b.
> Alle anderen FS20-Geräte, wie z.B. Steckdosen und auch die FHEM
> Weboberfläche funktionieren weiterhin einwandfrei.
> Ein Neustart von FHEM löst das Problem kurzzeitig.
>
> FHEM läuft bei mir auf einer FritzBox 7170 mit Freetz und einem CUL (ich
> glaube V2).
>
> Es wäre toll, wenn wir eine Lösung finden würden.

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

[Guest]

Originally posted by: <email address deleted>

Mein CULv3 hat auch ab und zu Hänger, liefert also keine Daten mehr. Ich
hatte dazu auch schon verschiedene Postings in den letzten Jahren hier in
der Liste dazu.

Ich hatte schon vieles in Verdacht: RFR (hatte ich früher mal eingesetzt),
Hardware CUL, Firmware CUL, etc.
Lösungsversuche gab es viele. Angefangen von Abstecken/Anstecken CUL,
Init-Commands, Firmware-Updates, etc.

Mit meinem CULv2, der nicht mit FHTs gepairt ist, gibt es keine Probleme.
Das kann aber theoretisch an etwas anderem liegen. Derzeit hat sich mal
wieder das Pairing der FHTs aufgelöst.

Ich habe das Gefühl (kann ich aber nicht beweisen), dass das
Kommunikationsprotokoll des FTH80b sehr sensibel ist und Funkstörungen zu
solchen Problemen führen können.

Bisher hatte ich dabei aber noch keinen Fall, dass FHEM selbst Probleme
hatte.

Ich habe aus den Diskussionen gelernt, dass es auch viele User gibt, die
keinerlei Probleme mit FHTs haben und deren Systeme ohne neues Pairing
Jahrelang stabil läuft.

Meine Konsequenz ist langfristig da wo Funk notwendig ist von FHT80b auf
die HM-Geräte zu wechseln.

Einen HM-CC-VD sowie HM-CC-TC habe ich im Einsatz. Das Setzen der
Temperatur über FHEM funktioniert noch nicht ganz stabil, aber ich habe da
große Hoffnungen, da Martin das HM-Modul derzeit kräftig weiterentwickelt.

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

[Guest]

Originally posted by: <email address deleted>

Hallo zusammen,
ich beobachte diesen Effekt ebenfalls seitdem die Heizperiode wieder begonnen hat.
Zur gleichen Zeit kommen von den FHT's keine Nachrichten mehr.
Bei FHEM konnte ich keine weiteren Probleme feststellen, an den Logfiles liegt es nicht, da werden neue desired-temps protokolliert. Meine Homematic Geräte und 1-wire Komponenten laufen ebenfalls weiter.

Nach shutdown restart, aber auch nach abstecken des CUNO vom USB Anschluss geht alles wie gewohnt, bis dann nach 4-8 Stunden gleiches Problem erneut auftaucht.

Ich habe einen Teil in meiner cfg in welcher ich Solltemperaturen in Abhängigkeit vom Homestatus sende. Ergibt ziemlich viel Traffic, deswegen habe ich hier mal Programmteile ausgelöscht und siehe da... Dann lief es gestern einen Tag durch.
Heute trat der Fehler aber erneut auf.
Habt ihr ähnliches programmiert? Eine Gemeinsamkeit scheint eine relativ Höhe Anzahl von FHT's zu sein...
Lazy-Mode habe ich noch versucht.... Ohne Erfolg.

Fehlermeldungen habe ich übrigens nicht bemerkt.

Gruß Manuel

FHEM läuft auf FB7390, CUNO mit FW 1.46, 7 FHT's

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

[Zrrronggg!]

                                                     

DAs ist jetzt ein Haufen difuser Meldungen, die sich insgesammt für
mich in etwa so lesen:

Die FHT kommunikation geht nach einiger Zeit nicht mehr, resett von
(diversem) entspannt die Situation.

Das ist natürlich alles recht vage, aber ich möchte versuchen trotzdem
mal eine paar Gedanken in den Raum zu werfen:

Die FHT kommunikation ist recht fragil. Es müssen einen Menge
Kommandos in einem bestimmten Timing ausgetauscht werden, damit Erfolg
eintritt... und das auch wenn man nix ändert alle 15 Minuten.
Wenn da nur eine Kleinigkeit schief geht, scheitert die Kommunikation
und es wird noch mal probiert.

Zusätzlich sind die FHTs nicht mit den genausten Sendern ausgestattet
und können in Bandbreite, Frequenz was weiss ich auch daneben liegen.

Insbesondere wer CUL /CUNO einsetzt, hat damit womöglich ein Problem,
weil die eher trennscharf sind.


Wenn es also aufgrund von solchen Abweichungen oder Aufgrund sowieso
schlechter Funklage zu vielen Sendeversuchen kommt, kann schon ein FHT
zu EOB , LOVf und ganz allgemein 1% Problemen kommen, besonders wenn
man zum testen auch noch rumspielt.
Dazu *sollte* es Hinweise im Log geben, wer sich aber z.b. info timer
per Telent ansieht, merkt unter Umständen nix, denn dort werden keine
Warnungen abgegeben.


Diese Problem steigt mit Anzahl der FHTs potentiell an.
Leider bestehen viele von euch darauf, die FHTs regelmaessig mit
Wochenprogrammen oder
Statusabfragen a la report1=255,report2=255 zu quälen.

UND die FHTs hören unter Umständen auch auf zu senden, wie oben schon
erwähnt.

Das pervide ist, das dann in der Tat *EIN* FHT auch alle anderen
Stören kann, wenn es erstmal Prpbleme mit 1% gibt.

Dann haben wir das Thema, das irgendwelche Störungen des Kanals (der
berühmte Funkkopfhörer aus China) die FHT Kommunikation eigentlich
immer platt machen. Es reicht von den 1 Dutzend Kommandos die hin und
er gehen ja aus, wenn EINES davon nicht korrekt ankommt und schon ist
alles unterbrochen, muss wiederholte werdn klaut noch mehr Sendezeit
etc..

Okay, einige von euch, also auch Threadownder, scheint das Problem
nicht zu haben.
Andere vielleicht wohl, insbesondere wenn ein Resett des CUL Erfolg
bringt (= Buffer leer) riecht's verdächtig.

Es ist im übrigen NICHT zwingend, das EOB oder sonstigen Meldungen
erscheinen: Der FHT Buffer kann so gut wie voll sein, sich wegen
kommunikatoonsproblemen sehr langsam oder gar nicht abarbeiten und
dann hat man unter umständen über grosse Zeiträume keine Verbindung zu
einem oder mehren CULs und sieht trotzdem über grosse Zeiträume kein
EOB oder LOVF.


Was kann man tun?
Hier in loser Folge mal ein paar Sachen, die in der Vergangenheit bei
mir weitergeholfen haben (ich habe 9 FHTs im Einsatz)

- Sparsam funken. Lazy mode nutzen. FHTs nicht über update der FHT-
localen Daten (Wochenprogramm, im FHT gespeicherte Temperaturen)
steuern.  Kein regelmässiges report, insbesondere NICHT report1=255.
Zum Wiedererwecken,der FHTs Watchdog verwenden. Oder Report2=255 1-2x
pro Woche nachts für die FHTS versetze. Ich weiss das einige von euch
eine andere Philosphie verfolgen, I'm just telling you.

- RSSI der FHTs beobachten. Unter -85 ist die Dangerzone. Unbedingt
versuchen ein besseres RSSI als -85 hinzubekommen, zu ALLEN FHTs (mein
schlechterster läuft -86 noch gerade zuverlässig). Antennnenlage
korrigieren, mit Freq, bandwidth und sens spielen. Ich habe viel
Erfolg gehabt mit bandwithd auf 464 khz und andere haben gerade eben
berichtet, das sens auf 8 db hilfreich sein kann . Wenn das nicht
geht, zweiten CUL /CUNO einsetzen auch als RFR CUL. Nicht zu viele
FHTs ans RFR CUL anbinden, nur so viele wie gerade nötig. Selbst die
Lage des FHTs kann viel bringen. Ein Meter nach Rechts.. bingo.

- alles richtig einstellen. Retrycount auf 1 (ich glaube mich zu
erinnern Retrycunt hat bei CUL eh keine Wirkung, bin mir aber nicht
sicher. So oder so: mehr Retrys heisst nur: Buffer schneller voll und
so weiter, wenn was richtig im argen liegt.) Softbuffer aus, verdeckt
nur die Probleme. Bei mehreren  CUxx IOdef kontrollieren. Pairen mit
CUL1, IOdef auf CUL2->Spass.

- wenn der Fall eintritt, unbedingt mit telnet auf FHEM und sich ein
bisschen mit den CUL/CUNO befassen. Erstmal: Ist der CUxx so
konfiguriert wie wir glauben?
get CUL1 ccconf : Werte ansehen.

Ist der FHT Buffer leer oder was steht da drin?
get CUL1 raw T02
Da sollte möglichst nix drin stehen ("CUL1 raw => N/A") oder nicht
viel. Mit der Zeit erkent man die Codes gleich, da steht drin welches
FHT Probleme macht (Adresse) und welche Kommandos noch auf Aussendung
warten.
Sowas hier:
CUL1 raw => 060D:4118 060D:65FF 060D:66FF 060D:4120
Sieht verdächtig aus. FHT 060D hat noch 4 Kommandos in der mache, die
Abarbeitung hier dauert schon im besten Fall mindests 8 Minuten. Sieht
bereits nach "Rückstau" aus.
(4118  = desired temp auf 18 Grad, 65ff= report1=255  66ff=
report2=255)
Und natürlich mit set CUL1 raw X61 ansehen, wie die Kommunikation
abläuft.

Freie Sendezeit checken:
get CUL1 raw X = Freie CUL Sendezeit, 2. Wert ist Sendezeit in 10ms
slots

Zuletzt: set CUL1 raw B00 resttet das CUL, das löscht alles Buffer und
so.

(CUL1 natürlich immer durch den Namen eures CULs ersetzen)

Rult nix davon vorschnell aus, nur wiel nichs im Log steht!

Das sind alles recht allgemeine Dinge, ich weiss.


Aber mehr kann ich angesichts der Ungenauigkeit der Posts oben nicht
bieten.

Wenn einer nicht weiss, wovon ich rede, fragt nach, dann geh ich ins
Detail so gut ich kann.

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