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

[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?

[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

[strauch]

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.

[strauch]

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

[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)

[strauch]

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

[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

[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

[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.

[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.

[Martin Ragg]

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

[ManuelM]

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

[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.

[Tina]

Hallo Zrrronggg!

Vielen, vielen Dank für Deinen sehr ausführlichen Post.
Und auch Danke für die angebotene weitere Hilfe.
Auf Anhieb habe ich tatsächlich nicht alles verstanden.

Ich werde mich bei Gelegenheit mal damit befassen, bin allerdings die nächsten Tage erstmal unterwegs.

Also vorab nochmal ein herzliches Dankeschön.

Viele Grüße
Tina

[UliM]

@Zrrrong: wäre m.E. gut, das ins Wiki zu stellen als Erweiterung beim FHT.
Magst Du?
Gruß Uli

PS: es gibt auch nen Befehl, um im CUL nur die FHT-queue zu resetten, kam mal hoch im Kontext (actuator: unknown_69) -> set CUL raw T01<CUL_FHTCODE>

[KUD]

Oh mein Gott. (Obwohl ich nicht gläubig bin)
Das klingt nach Bastelwiese für Hobbyelektoniker und Funker.
Verstanden habe ich die Ausführungen weiter oben nicht.
Wäre schön eine Step by Step - Anleitung für die Lösung des, nicht ganz vereinzelten Problems.
Ich kann nur sagen:

FHEM als solches läuft noch. Log wird weiter geschrieben. Befehle lassen sich absetzen.

Neustart gestern gegen 15 Uhr.
Letzte Werte S300TH - 3:34 Uhr bis 3:39:39 Uhr
Letzer Wert FHT           3:39:42

get CUL_0 raw T02  => 080F:4128

Auszug-Logdatei:

2012.10.19 03:39:39 5: CUL_0: K21876163 -50
2012.10.19 03:39:39 5: CUL_0 dispatch K21876163
2012.10.19 03:39:39 4: CUL_WS S300TH CUL_WS_3: T: 18.7  H: 63.6
2012.10.19 03:39:39 5: Triggering CUL_WS_3 (3 changes)
...
2012.10.19 03:39:41 5: CUL/RAW: /T250C00A6ECF2^M

2012.10.19 03:39:41 5: CUL_0: T250C00A6EC -81
2012.10.19 03:39:41 5: CUL_0 dispatch 810c04xx0909a001250c0000a6ec
2012.10.19 03:39:41 4: FHT FHT_250c actuator: 93%
2012.10.19 03:39:41 5: Triggering FHT_250c (1 changes)
...
2012.10.19 03:39:41 5: CUL/RAW: /T250C7D6712F2^M

2012.10.19 03:39:41 5: CUL_0: T250C7D6712 -81
2012.10.19 03:39:41 5: CUL_0 dispatch 810c04xx0909a001250c7d006712
2012.10.19 03:39:41 4: FHT FHT_250c start-xmit: 18
2012.10.19 03:39:41 5: Triggering FHT_250c (1 changes)
...
2012.10.19 03:39:42 5: CUL/RAW: /T250C7D7712FA^M

2012.10.19 03:39:42 5: CUL_0: T250C7D7712 -77
2012.10.19 03:39:42 5: CUL_0 dispatch 810c04xx0909a001250c7d007712
2012.10.19 03:39:42 4: FHT FHT_250c FHZ:start-xmit: 18
2012.10.19 03:39:42 5: CUL/RAW: /T250C4269B0F2^M

2012.10.19 03:39:42 5: CUL_0: T250C4269B0 -81
2012.10.19 03:39:42 5: CUL_0 dispatch 810c04xx0909a001250c420069b0
2012.10.19 03:39:42 5: CUL/RAW: /T250C4279B0FA^M

2012.10.19 03:39:42 5: CUL_0: T250C4279B0 -77
2012.10.19 03:39:42 5: CUL_0 dispatch 810c04xx0909a001250c420079b0
2012.10.19 03:39:42 5: CUL/RAW: /T250C436900F2^M

2012.10.19 03:39:42 5: CUL_0: T250C436900 -81
2012.10.19 03:39:42 5: CUL_0 dispatch 810c04xx0909a001250c43006900
2012.10.19 03:39:42 4: FHT FHT_250c measured-temp: 17.6
2012.10.19 03:39:42 5: Triggering FHT_250c (2 changes)
...
2012.10.19 03:39:42 5: CUL/RAW: /T250C437900FA^M

2012.10.19 03:39:42 5: CUL_0: T250C437900 -77
2012.10.19 03:39:42 5: CUL_0 dispatch 810c04xx0909a001250c43007900
2012.10.19 03:39:42 4: FHT FHT_250c FHZ:measured-temp: 17.6
2012.10.19 03:39:42 5: CUL/RAW: /T250C4B6712F2^M

2012.10.19 03:39:42 5: CUL_0: T250C4B6712 -81
2012.10.19 03:39:42 5: CUL_0 dispatch 810c04xx0909a001250c4b006712
2012.10.19 03:39:42 4: FHT FHT_250c ack: 18
2012.10.19 03:39:42 5: Triggering FHT_250c (1 changes)
...
2012.10.19 03:39:42 5: CUL/RAW: /T250C4B7712FA^M

2012.10.19 03:39:42 5: CUL_0: T250C4B7712 -77
2012.10.19 03:39:42 5: CUL_0 dispatch 810c04xx0909a001250c4b007712
2012.10.19 03:39:42 4: FHT FHT_250c FHZ:ack: 18
2012.10.19 03:39:43 5: CUL/RAW: /T250C4B7712FA^M

2012.10.19 03:39:43 5: CUL_0: T250C4B7712 -77
2012.10.19 03:39:43 5: CUL_0 dispatch 810c04xx0909a001250c4b007712
2012.10.19 03:39:43 4: FHT FHT_250c FHZ:ack: 18
2012.10.19 03:44:45 4: GetFileFromURL: Got http://weather.yahooapis.com/forecastrss?w=672687&u=c, length: 2310
2012.10.19 03:44:45 4: Weather MyWeather: T: 9  H: 98  W: 2
2012.10.19 03:44:45 5: Triggering MyWeather (30 changes)
2012.10.19 03:44:45 5: MyWeather trigger: Checking AUSSERHAUS_ja for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking AUSSERHAUS_nein for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking Fenster_auf for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking FileLog_CUL_FHTTK_9b81f7 for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking FileLog_CUL_WS_1 for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking FileLog_CUL_WS_2 for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking FileLog_CUL_WS_3 for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking FileLog_CUL_WS_5 for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking FileLog_FHT_080f for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking FileLog_FHT_1436 for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking FileLog_FHT_250c for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking FileLog_FS20_0eb800 for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking FileLog_FS20_1b1b00 for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking FileLog_FS20_1b1b01 for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking FileLog_FS20_1b1b02 for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking FileLog_FS20_1b1b03 for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking Logfile for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking RADIO_ja for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking RADIO_nein for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking WD.not.01 for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking WEB for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking WEBphone for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking WEBtablet for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking autocreate for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking initialUsbCheck for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking radio_an for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking radio_aus for notify
2012.10.19 03:44:45 5: MyWeather trigger: Checking telnetPort for notify

Ab jetzt folgen nur noch die Wetteraufrufe.

Ich starte mal nicht neu.
Vielleicht hat der Eine oder Andere eine Idee, was man abrufen kann um das Problem einzugrenzen.

Danke und Gruss
Kai-Uwe

[KUD]

Das hatte ich noch nicht geliefert:

Get CUL_0 raw X     CUL_0 raw => 61900
get CUL_0 ccconf     freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB

FHT   CUL_0_RSSI  -77                  

CUL_0_MSGCNT     3384
CUL_0_TIME            2012-10-19 03:39:43
RAWMSG                 T250C4B7712FA
RSSI                          -77
VERSION                  V 1.44 CUL868

[KUD]

Noch ein Wert der vielleicht wichtig ist.

get CUL_0 fhtbuf  =>  A9             ---- > bedeutet Dez. 251

[Zrrronggg!]

@UliM: Wiki, mach ich.

@KUD:
Wenn du NICHTS von dem verstanden hast was ich gesagt habe, habe ich
mit entweder nicht gut ausgedrückt oder wir müssen erst noch ein paar
Voraussetzungen schaffen.
"Das klingt nach Bastelwiese für Hobbyelektoniker und Funker." Naja,
so schlimm ist es nicht, aber ein paar Grundfertigkeiten muss man
mitbringen. Ich selber bin auch nur der Laie im Vergleich zu anderen
hier, ihr dürft also meine Fähigkeiten nicht überschätzen.


Also gut:
- RSSI zu dem fraglichen FHT sieht gut aus, -81 und -77, das reicht.
- Get CUL_0 raw X CUL_0 raw => 61900 also 900 10 ms slots frei.
Reicht.
- Version 1.44 ist gut.
- get CUL_0 ccconf freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
Gut, bietet aber Raum, um 2-3 Sachen auszuprobieren.
- Communication mit CUL sieht auf den ersten Blick gut aus, würde das
aber lieber nicht aus dem Logfile sehen, sondern aus X61 / info timer
(siehe weiter unten)



Aber gut, versuchen wir mal ein bischen was.

Wenn ich schreibe: "Sie dir FHEM mal per Telnet an", bist du dann
schon ausgestiegen?

Wenn ja, reicht folgende Anleitung:
- Irgendein Terminalprogramm besorgen (weiss nicht, was für OS du
nutzt, ich hab einen MAc und nehme... Terminal.app)
- dort dann "telnet (IP deines FHEM Servers) 7072" eingeben und enter.
7072 ist das Port auf dem FHEM per Telnet erreichbar ist.
- wenn du nun 1x return (enter) drückst, muss das prompt "fhem>"
erscheinen.

Das wars schon.

Jetzt kann man all die oben erwähnten Kommandos eingeben.

Fangen wir mal an mit
get CUL_0 raw T02

Was kommt da raus?


Staut sich da was in der Queue?

Wenn da mehr als 3 Datenpaare drin stehen. Also mehr als
080F:4128

dann mal bitte CUL resetten:

set CUL_0 raw B00


Funktionierts danach wieder?

[KUD]

Na Super-Dank vorab.
Du gibst Dir richtig Mühe auch solche, naja ich sag mal Anfänger, zu erleuchten.
Zu den Fakts.
Das mit dem eigenen Telnetport wusste ich nicht ;-( .

fhem> get CUL_0 raw T02
CUL_0 raw => 080F:4128 250C:412E
fhem> set CUL_0 raw B00

Der 250C:412E kommt wahrscheinlich, als ich versucht habe die Temperatur des FHTs zu setzen.
Log-Auszug:

2012-10-19_15:02:13 FHT_250c actuator: 93%
2012-10-19_15:00:16 FHT_250c actuator: 93%
2012-10-19_12:49:23 FHT_250c desired-temp 23.0
2012-10-19_03:39:42 FHT_250c ack: 18

An den Zeiten siehst Du auch, dass der CUL wieder angelaufen ist.
Erstmal super. Nur das Problem war glaube ich noch nicht vom Tisch ;-((
Wie sollten Deiner Meinung nach die FHTs (nach)konfiguriert werden?

Nochmal Danke und Gruß

Kai-Uwe

[Zrrronggg!]

Also interessant ist schonmal, dass
080F:4128
immer noch drin steht. D.H. die desired Temp für ein FHT mit Adresse
080F soll schon seit Stunden auf Wert 28 gesetzt werden. (hab gerade
nicht im Kopf welche Temperatur das ist.)

Das klappt aber offenbar nicht. Du hast aber 2 FHTs in Betrieb, oder
(oder vielmehr: Mehr als eines)?

Wenn du diese FHEM Telnet Zugang offen hast, kannst du eingeben

info timer

Dann wird jedes Event wenn es passiert aufgelistet.

Wenn du vorher eingibst:

set CUL_0 raw X61 (Achtung: GROSSES X, ist wichtig)


dann wird die Kommunikation im Detail angezeigt.

Jetzt musst du dir ansehen, ob die Communication mit den FHTs so
aussieht wie im Wiki beschrieben:
http://www.fhemwiki.de/wiki/FHT80b#Log-Auszug

Mach das mal für alle deine FHTs und Vergleiche.
Lass das Telnet "info timer" im Zweifel auch ruhig mal ein paar
Stunden mitlaufen, bis es wieder stehen bleibt.

Wenn es stehen bleibt, sieh nach , was im FHT Buffer steht
get CUL_0 raw T02

Dann siehts du, ob und wenn ja welche Befehle hängen. Jetzt scrollst
du zurück und siehts nach, wie die Kommunikationsversuche mit dem FHT
aussehen, also ob die vollständig ablaufen oder in der Mitte z.b.
wegen fehlender ACKs hängen bleiben.



set CUL_0 raw X21 schaltet übrigens zurück in normalen Meldungslevel.

[KUD]

Dankeschön. Verständlich  auch für mich.
Habe den "info timer" gestartet.
Übrigens habe ich nur 1 FHT laufen.
Aber interessant ist auch, dass es bei einem anderen FHT genau die gleichen Probleme gab.
Ich habe zur Fehlereingrenzung mal den einen mal den anderen aktiviert.
Also ein generelles Problem der FHT.

Ich bleibe dran.

[Zrrronggg!]

Okay, alles nochmal im Wiki zusammengefasst:

http://www.fhemwiki.de/wiki/Kommunikationsprobleme_mit_FHT
(auch vom FHT80 Artikel verlinkt)

Noch keinen Formatierungs- und Rechtschreibprüfung, das mache ich
morgen.

Nehme auch Vorschläge für einen besseren Titel entgegen.

On 19 Okt., 15:06, KUD <kdepar...@gmail.com> wrote:

[Tom]

> http://www.fhemwiki.de/wiki/Kommunikationsprobleme_mit_FHT

Sehr schön, ich glaube, da muss ich auch noch mal einiges bei mir
nachprüfen/anpassen.

Vielen Dank!

> Noch keinen Formatierungs- und Rechtschreibprüfung, das mache ich
> morgen.

Soll ich sonst noch mal am WE drüber schauen? Bis jetzt habe ich noch
nicht viel auf dem Plan.

> Nehme auch Vorschläge für einen besseren Titel entgegen.

Den finde ich durchaus passend.

Gruß
Torsten

[Willi]

Am Freitag, 19. Oktober 2012 20:08:49 UTC+2 schrieb Zrrronggg!:

Okay, alles nochmal im Wiki zusammengefasst:

http://www.fhemwiki.de/wiki/Kommunikationsprobleme_mit_FHT
(auch vom FHT80 Artikel verlinkt)

Respekt! Da bin ich aber geplättet! 

Super Arbeit. Danke.

Da habe ich auch was zu tun......

[Zrrronggg!]

> Soll ich sonst noch mal am WE drüber schauen? Bis jetzt habe ich noch
> nicht viel auf dem Plan.

Gerne!

[puschel74]

Hallo,

na dann will ich mal hoffen das ich mit meinen 2 CUNO und meinem CUL und den 11 FHT`s nicht an den Rand der Illegalität gerate ;-)
Die FHT`s sind mit IODev auf die CUxx verteilt und ausser ab und zu mal einen Aussetzer für 2 oder 3 Stunden habe ich bisher (seit Januar 2012 ist Fhem mit im Boot) keine Probleme.
Ich will mal nicht hoffen das ich die 1%-Regel mit meiner Konstellation durchbreche :-))

Aber sonst - Hut ab - Top Wiki-Beitrag Zrrronggg!

Grüße

[Zrrronggg!]

> Ich will mal nicht hoffen das ich die 1%-Regel mit meiner Konstellation
> durchbreche :-))

Tja, das ist die Frage. Wenn ja, ich auch, da ich auch eine CUL und
RFR CUL einsetze.

> Aber sonst - Hut ab - Top Wiki-Beitrag Zrrronggg!

Danke.

[puschel74]

Hallo,

ich denke mal, da die CUxx ja keine "Weitstreckenfunker" sind und die Auflagen ja Hardware- wie auch Firmwareseitig eingehalten
werden sollten - würde eine (zwischenzeitliche) Verletzung der 1%-Regel genau wen stören?
Meinen Nachbar, der zwar FS20-Geräte im Einsatz hat aber nichtmal weiß was FHEM ist, oder die Oma, 2 Strassen weiter, die sich
am Nachmittag gerne um Ihre Herbstastern kümmert und noch weniger eine Ahnung von Funklast hat?
Wobei ich mal schwer bezweifle das die Oma 2 Strassen weiter von meiner "Funkverseuchung" auf 868 MHz was mitbekommt da
die CUxx jetzt mal keine Langstreckenfunker sind.
Wenn sie das wären hätten einige ja weniger Probleme mit ihren FHT`s ;-)
Klar. Der Staat mit seinen "Funkschnüfflern" könnte (wird) sich beschweren, oder besser abstrafen.
Aber warum genau?
Wie weit reicht so ein CUNO?
Welchen Funkverkehr stört er wenn er die Werte der FHT`s empfängt und quittiert?
Überhitzt die Mikrowelle durch einen zusätzlichen CUNO oder wird das "Essen" in der Mikrowelle nicht warm?
Könen die Einsatzkräfte bei einem Brand, Überfall oder was auch immer nichtmehr per Funk miteinander kommunizieren wenn
FHEM in der Nähe im Einsatz ist?
Ok. FHEM kann ja nix dafür aber was wenn ich ein grösseres Areal habe und die Abdeckung per LAN mit 4 oder mehr CUNO machen kann?
Ist das dann illegal??
Kanns ja wohl nicht sein, oder?

Ja, Ok. Falscher Beitrag und "knapp" am Thema vorbei aber würd mich mal interessieren.

Grüße

[KUD]

So heute Nacht war es dann wieder soweit.

Ein
get CUL_0 raw T02
brachte
CUL_0 raw => N/A

Telnet bracht soweit nicht brauchbares, da ich nur 4 Stunden zurückgehen konnte.
Log des FHTs:

2012-10-20_00:18:03 FHT_250c ack2: 18
2012-10-20_00:18:03 FHT_250c start-xmit: 18
2012-10-20_00:18:00 FHT_250c actuator: 93%
2012-10-20_00:16:03 FHT_250c actuator: 93%
2012-10-20_00:14:06 FHT_250c actuator: 93%
2012-10-20_00:12:09 FHT_250c actuator: 93%
2012-10-20_00:10:12 FHT_250c actuator: 93%
2012-10-20_00:08:16 FHT_250c ack2: 18
2012-10-20_00:08:15 FHT_250c start-xmit: 18
2012-10-20_00:08:15 FHT_250c actuator: 93%
2012-10-20_00:06:18 FHT_250c actuator: 93%
2012-10-20_00:04:21 FHT_250c actuator: 93%
2012-10-20_00:02:24 FHT_250c actuator: 93%
2012-10-20_00:00:27 FHT_250c actuator: 93%
2012-10-19_23:58:31 FHT_250c ack2: 18
2012-10-19_23:58:30 FHT_250c start-xmit: 18
2012-10-19_23:58:30 FHT_250c actuator: 93%
2012-10-19_23:57:05 FHT_250c ack: 18
2012-10-19_23:57:05 FHT_250c windowsensor: ok
2012-10-19_23:57:05 FHT_250c window: closed
2012-10-19_23:57:05 FHT_250c lowtemp: ok
2012-10-19_23:57:05 FHT_250c battery: ok
2012-10-19_23:57:04 FHT_250c warnings: none
2012-10-19_23:57:04 FHT_250c windowsensor: ok
2012-10-19_23:57:04 FHT_250c window: closed
2012-10-19_23:57:04 FHT_250c lowtemp: ok
2012-10-19_23:57:04 FHT_250c battery: ok
2012-10-19_23:57:04 FHT_250c ack: 18
2012-10-19_23:57:04 FHT_250c temperature: 17.9
2012-10-19_23:57:04 FHT_250c measured-temp: 17.9
2012-10-19_23:57:03 FHT_250c start-xmit: 18
2012-10-19_23:56:33 FHT_250c actuator: 93%
2012-10-19_23:54:36 FHT_250c actuator: 93%
2012-10-19_23:52:39 FHT_250c actuator: 93%
2012-10-19_23:50:42 FHT_250c actuator: 93%
2012-10-19_23:48:45 FHT_250c ack2: 18
2012-10-19_23:48:45 FHT_250c start-xmit: 18
2012-10-19_23:48:45 FHT_250c actuator: 93%
2012-10-19_23:46:48 FHT_250c actuator: 93%
2012-10-19_23:44:51 FHT_250c actuator: 93%
2012-10-19_23:42:54 FHT_250c actuator: 93%
2012-10-19_23:41:05 FHT_250c end-xmit: 18
2012-10-19_23:41:04 FHT_250c ack: 18

fhem-log:

2012.10.20 00:18:03 5: CUL/RAW: /T250C7D7712FA^M

2012.10.20 00:18:03 5: CUL_0: T250C7D7712 -77
2012.10.20 00:18:03 5: CUL_0 dispatch 810c04xx0909a001250c7d007712
2012.10.20 00:18:03 4: FHT FHT_250c FHZ:start-xmit: 18
2012.10.20 00:18:03 5: CUL/RAW: /T250C696712F9^M

2012.10.20 00:18:03 5: CUL_0: T250C696712 -77.5
2012.10.20 00:18:03 5: CUL_0 dispatch 810c04xx0909a001250c69006712
2012.10.20 00:18:03 4: FHT FHT_250c ack2: 18

Gruss Kai-Uwe

[KUD]

Der Titel des Themas - FHEM bleit stehen -  stimmt natürlich so nicht.
Besser wäre :
Der CUL hört auf seinen Dienst zu tun.

[Tom]

ok, ich sehe gerade, dass Du auch selbst schon allerhand wieder
überarbeitet hast. ;)
Da ich inhaltlich leider nichts beitragen kann, beschränke ich mich
mal auf Typos. Eine Zeile ist mir nicht ganz klar:

> Diese Probleme steigt mit Anzahl der FHTs potentiell an.

...sollte das "exponentiell" heißen? Ansonsten sagt mir der Satz nicht
wirklich was.

Leider weiß ich nicht, wie man im WIKI einen Absatz innerhalb einer
"*"-Liste macht - eigentlich gehört der Teil ab "Das Attribut
fhtsoftbuffer erzeugt..." zu dem davor liegenden Part, aber jetzt
steht er einzeln (und ohne Absatz liest sich das schlecht). :-/

Gruß
Torsten

[KUD]

"fhtsoftbuffer" kann ich bei den Attributen nicht finden.

Vielleicht sollte man unter den ausführlichen Erklärungen noch in Kurzform die Vorgehensweise anfügen.

Wo "softbuffer" und wie ausschalten.
dito "Lazy Mode" etc.
1.
2.
3.
...
Wer nicht so tief in der Materie ist, weiß nicht,  wo man was einstellt.
Und der Einstieg in FHEM kommt sehr häufig über die FHT-Schiene.

Aber so nebenbei. Gibt es mit den Homematicteilen weniger Probleme?

[Zrrronggg!]

>Diese Probleme steigt mit Anzahl der FHTs potentiell an.

>...sollte das "exponentiell" heißen? Ansonsten sagt mir der Satz >nicht
>wirklich was.

Nein, soll nicht exponentiell heissen. Sondern Potentiel. Ich meinte
damit: Je mehr FHTs man hat desdo eher tritt das Problem auf.

Ungeschickt formuliert irgendwie, ich merkte das schon selber.

>Wo "softbuffer" und wie ausschalten.
>dito "Lazy Mode" etc.

Okay. Das kann ich noch ergänzen. Allerdings steht das alles in FHEM
commandref:

http://fhem.de/commandref.html

>Gibt es mit den Homematicteilen weniger Probleme?

Weniger weiss ich nicht, aber wemnn dann andere. Vorteil der Homematic
Teile:
- bessere Sender / Empfänger, daruch bessere Reichweite
- wesentlich höhere Datenrate, daher weniger Funklast

Nachteile:
- Preis
- Unterstützung durch FHEM vielleicht noch nicht so gut. Ich habe aber
keine und kann dazu nicht viel sagen.
Einfach mal diese Gruppe durchsuchen.

>Leider weiß ich nicht, wie man im WIKI einen Absatz innerhalb >einer "*"-Liste macht

Ja, ich gerade auch nicht. Hab ich schon gesehen. Finde ich irgendwann
raus. Ansonsten: Danke!

Was KUDs originales Problem betrifft bin ich langsam auch mit meinem
Latein am Ende muss ich zugeben. Sorry.

[Tom]

>>Diese Probleme steigt mit Anzahl der FHTs potentiell an.
>
>>...sollte das "exponentiell" heißen? Ansonsten sagt mir der Satz >nicht
>>wirklich was.
>
> Nein, soll nicht exponentiell heissen. Sondern Potentiel. Ich meinte
> damit: Je mehr FHTs man hat desdo eher tritt das Problem auf.

Wie wäre es mit

Mit der Anzahl FHTs steigt die Wahrscheinlichkeit für das Auftreten
dieser Probleme.

?

[KUD]

Trotz der Änderungen ist der CUL wieder ausgestiegen.
Ich werde jetzt meine FHTs verkaufen und mein Glück mit Homematic versuchen.

[Zrrronggg!]

Sorry, dass ich nicht weiter helfen konnte.

@Tom:

>Mit der Anzahl FHTs steigt die Wahrscheinlichkeit für das Auftreten
>dieser Probleme.

Gut. Änderst du's?

[ManuelM]

Hallo Zrrronggg! und andere Experten,

Ich werde noch nicht aufgeben und versuche weiterhin das Thema einzugrenzen.

Bei mir bleiben weiterhin fast täglich alle FHT's zeitgleich stehen. FHEM läuft munter weiter... 

Im Anhang habe ein dies mal als Plot angehängt. An den FHT_PLOTs sieht man die letzten Temperaturwechsel (rosa) welche aber bereits 1h in der Vergangenheit liegen. 

Weiterhin habe ich mir RSSI-Plots angelegt um den Funkempfang zu optimieren, scheint aber auch mit dem Problem zusammenzuhängen da vor dem Ausfall alle FHT's über -81 liegen.

Heute wollte ich wie im Wiki empfohlen meinen CUNO auf Bandbreite 464 KHz und Sense 8dB stellen (Ausgangspunkt freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB)

und siehe da alle FHT's beginnen wieder zu senden.

Es scheint also den gleichen Effekt wie ein Reset des CUNO's zu haben.

Morgen werde ich sehen ob die neue Einstellung eine Verbesserung bringt. An den RSSI Plots ist keine Änderung zu erkennen.

Gruß Manuel

[Ralf Becker]

Hallo Manuel,

mal eine (wahrscheinlich dusselige) Frage von mir dazu:
Was heißt die FHTs bleiben "stehen"?
Das System (FHT's und Ventilantriebe) funktioniert doch autark, also auch ohne FHEM und CUNO (bei mit FHZ 1300 PC)?!
Wenn bei mir z. B. die Plots nicht mehr geschrieben / erzeugt werden, funktioniert trotzdem die Heizungssteuerung noch (ZUM GLÜCK, sonst würde mich die Frau mit allem Spielzeug in die Schranken weisen *lach). 

Ist das bei Dir anders?

Viele Grüße,
von Ralf

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

-- 
_________
Heizungssteuerung mit FHEM unter Ubuntu 10.04
Hardware:
FHZ 1300 PC (Zentrale)
10 x FHT 80B (Thermostate/Steuerungen)
10 x FHT 80FT (Fensterkontakte)
13 x FS20 Funk-Stellantriebe (Ventilantriebe)

[Ralf Becker]

Hallo Zusammen,

mal noch eine Frage, bevor ich jetzt schlafen gehe ;-)

Wer benutzt auch diese/meine Kombi zur Heizungssteuerung?
Kann ja sein, dass ich damit exotisch bin, oder meine Frage bez�glich
den aussetzenden Plots ist den Experten hier zu langweilig (oder ich bin
zu bl�de)?

Unabh�ngig davon (von einer L�sung), w�rde mich schon interessieren, wie
"gut" meine Entscheidung zur Wahl dieser Komponenten war.... ;-)

Gute Nacht,
von Ralf

_________
Heizungssteuerung mit FHEM unter Ubuntu 10.04
Hardware:
FHZ 1300 PC (Zentrale)
10 x FHT 80B (Thermostate/Steuerungen)
10 x FHT 80FT (Fensterkontakte)
13 x FS20 Funk-Stellantriebe (Ventilantriebe)

Ubuntu auf ThinClient Igel 256 MB RAM und 4 GB CF-Card

[Zrrronggg!]

Und schon wider drauf reingefallen. Ich hab nicht gemerkt, dass dies
der selbe Thread von neulich ist, weil "jemand" den Namen des Threads
geändert hat.

Ich finde das ja ungünstig mitten in der Diskussion den Tiel des
Thread zu ändern. Und hier in diesem Threads gehts eigentlich auch
nicht um die FHZ1300... könntest du da vielleicht einfach einen neuen
aufmachen?

Ich bin inzwischen ein alter seniler Sack und verliere sonst die
Übersicht.

Und ja: bei der FHZ1300 ist die Frage berechtigt, die hätte ich heut
nicht mehr eingesetzt. mit der kann man z.b. ca. die Hälfte der im
erwähnten Wikiartikel vorgeschlagenen Dinge (Debuging mit X61 z.b.)
Dinge nicht so richtig machen.
Und FHT Buffer ist wohl auch recht klein.

@ Wenn RSSI hineichend ist (sieht ja so aus), brauchst du an Bandwidth
nicht weiter rumschrauben würde ich denken, sens hingegen kann noch
was bringen nach meinem Verständniss. Das die Kommunikation mit allen
zur gleichen Zeit zusammen bricht, obwohl Funklage gut ist... hm... Da
ist Ralf Beckers Frage nicht ganz unberechtigt: Klappt die
Kommunikation zwischen FHT und Ventiltrieb noch?
Ist der Ausfall mehr oder weniger immer zur selben Uhrzeit?
Also öfters um 15 Uhr etwa?

(weil da dein Nachbar seine Funkkopfhörer einschaltet z.B.?)

[Ralf Becker]

...das mit dem ausreichenden RSSI war nicht von mir.... ;-)
Ich bleibe mal in diesem Thread, den habe ICH ja schon gerade mit "FHZ
1300" aufgemacht...

Meine URSPR�NGLICHE Frage war, ob es an Hardware oder Software (FHEM
oder Server) liegen mag, dass ich keine Plots mehr in FHEM angezeigt
bekomme...
Das wei� ich nun immer noch nicht so ganz genau...

Ich habe dann heute das Wiki "Kommunikationsprobleme mit FHT"
(http://www.fhemwiki.de/wiki/Kommunikationsprobleme_mit_FHT) gefunden
und bin "erschrocken" �ber soviel "Schw�che" im System....
Alles was ich bis dahin las (Conrad, ELV, andere) war, dass das FS20/FHT
System sehr bew�hrt, ausgereift und zuverl�ssig w�re.... :-(
Hhmm...
Naja... nun habe ich die Dinger installiert.... und hoffe, dass ich die
trotz etwaiger Schw�chen irgendwie stabil betrieben bekomme (war ja
bisher noch nicht wirklich kalt, sprich habe noch keine brauchbaren
Erfahrungswerte). Wenn die Frau (oder Kinder) am "Rad drehen" und die
Temperatur erh�hen wollen... dann muss das auch sp�testens nach 2
Minuten passieren (das kann ich denen erkl�ren, dass die Befehle eine
Weile brauchen)....

Dadurch, dass es mir nur aufgefallen ist, dass die Plots nicht mehr
erzeugt/geschrieben werden, dachte ich, dass es sich um ein FHEM- oder
sonstigen Software-Problem auf den daf�r angeschaften und installierten
Linux-ThinClient handeln k�nnte.

Wenn jetzt tats�chlich (was ich nun noch �berpr�fen muss) ALLE FHTs
(weil z. B. der Nachbar seinen Funkk�pfh�rer einschaltet) GLEICHZEITIG
ausfallen, dann w�re das schon heftig.... finde ich.
Sch�tze aber immer noch auf ein FHEM- oder FHZ-Problem..... das sich da
irgendwas verabschiedet bzw. "einschl�ft" (standby?).
Stelle ich bei einem FHT mal per FHEM einen anderen Wert ein (gew�nschte
Temp.), dann fangen wieder ALLE Plots an, Werte anzuzeigen!

Die Frage ist, ob das auch passiert, wenn ich das �ber die FHTs direkt
mache (was zu testen ist, wenn die Plots das n�chste mal ausfallen)...

Sch�n jedenfalls, dass ich damit nicht alleine dastehe, wenn es um
Verst�ndnisprobleme geht... (auch wenn die Experten vllt. gelangweilt
sind und sich wahrscheinlich auf die Schenkel klopfen, weil ich den Wald
vor lauter B�umen nicht sehe). ;-)

Viele Gr��e,
von Ralf

Am 24.10.2012 06:04, schrieb Zrrronggg!:
> Und schon wider drauf reingefallen. Ich hab nicht gemerkt, dass dies
> der selbe Thread von neulich ist, weil "jemand" den Namen des Threads

> ge�ndert hat.
>
> Ich finde das ja ung�nstig mitten in der Diskussion den Tiel des
> Thread zu �ndern. Und hier in diesem Threads gehts eigentlich auch
> nicht um die FHZ1300... k�nntest du da vielleicht einfach einen neuen

> aufmachen?
>
> Ich bin inzwischen ein alter seniler Sack und verliere sonst die

> �bersicht.
>
> Und ja: bei der FHZ1300 ist die Frage berechtigt, die h�tte ich heut
> nicht mehr eingesetzt. mit der kann man z.b. ca. die H�lfte der im
> erw�hnten Wikiartikel vorgeschlagenen Dinge (Debuging mit X61 z.b.)

> Dinge nicht so richtig machen.
> Und FHT Buffer ist wohl auch recht klein.
>
> @ Wenn RSSI hineichend ist (sieht ja so aus), brauchst du an Bandwidth

> nicht weiter rumschrauben w�rde ich denken, sens hingegen kann noch
> was bringen nach meinem Verst�ndniss. Das die Kommunikation mit allen

> zur gleichen Zeit zusammen bricht, obwohl Funklage gut ist... hm... Da
> ist Ralf Beckers Frage nicht ganz unberechtigt: Klappt die
> Kommunikation zwischen FHT und Ventiltrieb noch?
> Ist der Ausfall mehr oder weniger immer zur selben Uhrzeit?

> Also �fters um 15 Uhr etwa?
>
> (weil da dein Nachbar seine Funkkopfh�rer einschaltet z.B.?)

[Zrrronggg!]

Alles ab RSSI bezog sich auf deinen Vorredner.

Du hast keinen neuen thread aufgemacht, du hast den alten umbeannt.
Das finde ich persönlich ungünstig. Auch weil das das Thema eines
Threads unnötig aufweitet und man sich schlechter zurecht findet. Wenn
jeamdn neues mal die selben Probleme hat, dann soll er am ende einen
Thread mit 50 Posts lesen, wovon die hälfte seinen Probleme gar
nicht behandeln?

Ich weiss nicht recht.

Aber seis drum: Der FHT Artikel ist von mir, und er ist von mir als
Ergebnis diesen Threads verfasst worden. D.H du hast den Thread auch
nicht durchgelesen, sonst wüsstest du das ja. ;-)

Das FHT System ist schon stabil, und die genannten Probleme müssen
nicht auftreten und treten bei den meisten Leuten auch nicht auf.

Aber: FHT ist auch technisch "primitv". Die Datenübertragungsrate ist
langsam, die Sender/empfänger sind ungenaue billigste Pendelempfänger
und das System ist vermutlich gedacht für 3-5 Räume, wird hier von
vielen aber für 8-10 Räume und mehr verwendet. (ich selber habe 8 FHTs
im einsatz)

Zuletzt: Mit FHEM bieten sich Möglichkeiten, die man mit dem
Originalsystem nicht hat und die eben auch wegen der deutlich erhöhten
Funklast zu Problemen führen können, WENN man sie ausnutzt.

Der Artikel ist also nur so zu verstehen, Leuten die Probleme haben,
ein paar Tips und Hintergründe zu geben, woran das liegen könnte und
was man machen kann.

>
> Dadurch, dass es mir nur aufgefallen ist, dass die Plots nicht mehr
> erzeugt/geschrieben werden, dachte ich, dass es sich um ein FHEM- oder
> sonstigen Software-Problem auf den daf r angeschaften und installierten
> Linux-ThinClient handeln k nnte.
>

Das kann selbstverständlich sein, ich wollte nur anhand der mitunter
sehr vagen Fehlerbeschreibungen hier versuchen auf eine paar
Möglichkeiten hinzuweisen. Es ist nicht gesagt, dass es die FHTs sind
oder die im Artikel beschrieben Probleme. Ich bekomme, was z.b.
ManuelMs Probleme betrifft da sogar langsam Zweifel, das es an der FHT
Kommunikation liegt.

Aber irgendwie muss man sich dem Problem ja nähern.

[ManuelM]

Klappt die
Kommunikation zwischen FHT und Ventiltrieb noch?
Ist der Ausfall mehr oder weniger immer zur selben Uhrzeit?

Hallo Ralf&Zrrronggg!

bin bisher nicht recht weitergekommen. Zu den Fragen, die Kommunikation zwischen FHT udn Ventilantrieb funktioniert unabhängig von meinem Problem.
Leider habe ich eine Heizungssteuerung implementiert welche meine Heizung abhängig vom Wärmebedarf wirklich abschaltet... d.h. die Regelung läuft nach Ausfall mit dem zuletzt bekannten Zustand.
Die Regelung ist also im Eimer.

Die Uhrzeiten scheinen zufällig, zumindest habe ich noch keine Abhängigkeiten feststellen können.

Fällt noch jemandem etwas dazu ein? Es soll kalt werden!

Gruß Manuel

 

[Zrrronggg!]

> bin bisher nicht recht weitergekommen. Zu den Fragen, die Kommunikation
> zwischen FHT udn Ventilantrieb funktioniert unabhängig von meinem Problem.
> Leider habe ich eine Heizungssteuerung implementiert welche meine Heizung
> abhängig vom Wärmebedarf wirklich abschaltet... d.h. die Regelung läuft
> nach Ausfall mit dem zuletzt bekannten Zustand.
> Die Regelung ist also im Eimer.

Ich verstehe nicht, inwieweit das meine Frage beantwortet. Ich
verstehe genau genommen
überhaupt nicht, was du da machst.

Wenn ich Frage ob die Kommunikation zwischen FHT und Ventilantrieb
funktioniert, dann testet man das so:
Wenn die Kommunikation FHEM <-> FHT mal wieder unterbrochen ist, dann
dreht man am FHT die Temperatur
hoch (oder unter) und sieht dann nach ob sich nach spätestens die 2
Minuten der Öffnungswinkel des 8v Ventiltriebs
ändert. (Abzulesen am Dislay des Ventilantriebs in %). Ob die Heizung
abgeschaltet ist oder nicht, ist doch egal.

Aber wie gesagt ich habe gar nicht echt verstanden was du da machst.
Vielleicht reden wir aneinander vorbei irgendwie.

[ManuelM]

> ....zwischen FHT und Ventilantrieb funktioniert unabhängig von meinem Problem.

Mit dem Satz wollte ich aussagen dass eine Temp-Änderung vom FHT vom Ventilabtrieb sofort verarbeitet wird.

Das Problem: FHEM scheint keine FS20 Signale mehr zu erkennen.
Ein Kommando wie "rereadcfg" löst das Problem, der Empfang beginnt also wieder.

Anders ausgedrückt: Ich gehe davon aus die FHT's senden immer der CUNO verarbeitet diese Signale aber nicht.

Mein System
HomeMatic über HM-LAN geht weiterhin
1-Wire über extra USB Adapter geht weiterhin
FS20 über CUNO empfang unterbrochen

Gruß Manuel

[UliM]

Am Freitag, 26. Oktober 2012 22:22:22 UTC+2 schrieb ManuelM:

FS20 über CUNO empfang unterbrochen

Meldet sich der CUNO denn noch mit einem
get CUL version
?
(statt CUL den Namen Deines CUNO)

Nur so als Versuch: Mit
set CUL raw T01<CUL_FHTCODE> 
kannst Du in CULFW den FHT-buffer zurücksetzen. Siehe auch http://culfw.de/commandref.html#cmd_T
Vll hilft's ja...
=8-)

[ManuelM]

Hallo Uli
Ich bekomme sobald kein FS20 Empfang mehr möglich ist ein "no answer" bei der Versionsabfrage.
Das Löschen des Puffers behebt das Problem wieder (vorübergehend?)
Wie CUNO abstecken / rereadcfg ...
Bringt dich das bei der Fehlereingrenzung weiter?

Gruß Manuel

[Zrrronggg!]

kein ganz ernst gemeinter Vorschlag, aber es würde erstmal helfen:

define CUNO_reset at *05:58:09 set CUNO raw B00

Bischen Holzhammer

[Ulrich Maass]

Am 27. Oktober 2012 00:18 schrieb ManuelM <mesc...@googlemail.com>:

Bringt dich das bei der Fehlereingrenzung weiter?

Hi Manuel,
leider kenn ich CULFW auf der code-Ebene gar nicht.
Wenn Du aber sagst, dass nach einem reset nur der FHT-queue der CUL/CUN wieder tut, ist das sicher eine wichtige Eingrenzung (ein full-reset durch aus/an bringt da keinen Hinweis)
Hast Du das mal in der CULFW-Gruppe gepostet? Da das Problem ja scheinbar nicht an fhem, sondern am CUN und mithin an CULFW liegt, gehört dieses Thema m.E. dorthin - sehe gerade: Dort hat's schon jemand geposted...
https://groups.google.com/forum/?hl=de&fromgroups=#!topic/cul-fans/N5-HZdaG4dk

=8-)

 

[ManuelM]

Danke für den Tipp
MM

[Ralf Becker]

Hallo Zrrronggg,

danke f�r die zus�tzlichen Infos, auch wenn sie mich gerade nicht weiter
gebracht haben...
Ich habe mal nachgesehen, welchen Artikel �ber FHT Du meinen k�nntest
(im Wiki, oder hier in der Liste?)... habe aber nichts gefunden...
also bezogen auf die FHZ 1300 PC ...

Also wenn bei mir (also der mit der "FHZ 1300 PC" als Zentrale) mal
wieder die Plots "stehen geblieben" sind, hilft es (per FHEM) einen
neuen Wert an ein FHT (z.B. "desired-temp") zu senden und dann sind die
Plots sofort wieder da.... also auch ohne "L�cken" in der Aufzeichnung.
Blieben die Plots z. B. einfach ab 11:20h aus (und es ist z. B. 20:00h)
und ich �ndere nur einen Wert an irgendein FHT, dann sind die Plots
wieder vollst�ndig und man sieht nichts mehr von dem "H�nger"!
Also kann sich ja eigentlich nicht die Zentrale aufgeh�ngt haben, noch
kann sie "geschlafen" haben, oder?
Trotzdem zeigen die Plots ab einen bestimmten Zeitpunkt nichts mehr...

Die FHTs funktionieren ansonsten autark wie gew�nscht....

Die Probleme mit dem "Funkverkehr" im FHT-System habe ich zur Kenntnis
genommen, nur n�tzen die mir wenig, bin ich kein Elektroniker oder
Elektro-Ingenieur, Funker oder "Radiologe" ;-)

Spa� beiseite.... machen irgendwelche Befehle z. B. in einem Cron-Job Sinn?
Z. B. neu laden irgendwelcher Software?

Leider kann ich nicht stundenlang mit den Dingen "rumspielen" und
forschen... also warte ich mal ab, ob ich das mal irgendwann blicke... ;)
Bin ja froh, dass soweit alles stabil zu laufen scheint....

Herzliche Gr��e an alle,
Ralf

Am 24.10.2012 21:00, schrieb Zrrronggg!:
> Alles ab RSSI bezog sich auf deinen Vorredner.
>
> Du hast keinen neuen thread aufgemacht, du hast den alten umbeannt.

> Das finde ich pers�nlich ung�nstig. Auch weil das das Thema eines
> Threads unn�tig aufweitet und man sich schlechter zurecht findet. Wenn

> jeamdn neues mal die selben Probleme hat, dann soll er am ende einen

> Thread mit 50 Posts lesen, wovon die h�lfte seinen Probleme gar

> nicht behandeln?
>
> Ich weiss nicht recht.
>
> Aber seis drum: Der FHT Artikel ist von mir, und er ist von mir als
> Ergebnis diesen Threads verfasst worden. D.H du hast den Thread auch

> nicht durchgelesen, sonst w�sstest du das ja. ;-)
>
> Das FHT System ist schon stabil, und die genannten Probleme m�ssen

> nicht auftreten und treten bei den meisten Leuten auch nicht auf.
>

> Aber: FHT ist auch technisch "primitv". Die Daten�bertragungsrate ist
> langsam, die Sender/empf�nger sind ungenaue billigste Pendelempf�nger
> und das System ist vermutlich gedacht f�r 3-5 R�ume, wird hier von
> vielen aber f�r 8-10 R�ume und mehr verwendet. (ich selber habe 8 FHTs
> im einsatz)
>
> Zuletzt: Mit FHEM bieten sich M�glichkeiten, die man mit dem
> Originalsystem nicht hat und die eben auch wegen der deutlich erh�hten
> Funklast zu Problemen f�hren k�nnen, WENN man sie ausnutzt.

>
> Der Artikel ist also nur so zu verstehen, Leuten die Probleme haben,

> ein paar Tips und Hintergr�nde zu geben, woran das liegen k�nnte und

> was man machen kann.
>
>> Dadurch, dass es mir nur aufgefallen ist, dass die Plots nicht mehr
>> erzeugt/geschrieben werden, dachte ich, dass es sich um ein FHEM- oder
>> sonstigen Software-Problem auf den daf r angeschaften und installierten
>> Linux-ThinClient handeln k nnte.
>>

> Das kann selbstverst�ndlich sein, ich wollte nur anhand der mitunter

> sehr vagen Fehlerbeschreibungen hier versuchen auf eine paar

> M�glichkeiten hinzuweisen. Es ist nicht gesagt, dass es die FHTs sind

> oder die im Artikel beschrieben Probleme. Ich bekomme, was z.b.
> ManuelMs Probleme betrifft da sogar langsam Zweifel, das es an der FHT
> Kommunikation liegt.
>

> Aber irgendwie muss man sich dem Problem ja n�hern.

[Zrrronggg!]

Das klingt jetzt wieder so wie das normale "FHTs senden nach ein paar
Tagen nicht mehr, wenn sie keinen Befehl erhalten" Problem.

Lässt sich mit einem Watchdog fixen.

Wenn du so oder so das Thema hast, das das senden eines BBefehls die
wieder zum Leben erwecken, dann mach einfach folgendes:

define fht_reportZimmer1 at *04:00:00 {if ($wday == 1) { fhem("set
hzg_Zimmer1 report2 255") } }


Das machst du für jeden FHT, aus Funklastgründen für jeden an einem
anderen Tag ($wday == 2), ($wday == 3) und so weiter.


Wenn du nur 3-5 FHTs hast, kannst du das auch jede Nacht machen, z.B.
so:

define fht_report at *04:00:00 set hzg.* report2 255

(setzt natürlich voraus, das alle dein FHTs mit "hzg...." anfangen)

Das fordert von allen FHTs den "Report 2" ab (das sind temp, desired
temp, day und night temp und noch so paar Daten)

[Ralf Becker]

Vielen Dank f�r den Tipp!

Jetzt noch die dumme Frage, wo ich das reinschreibe....
"global configuration" (/etc/fhem.cfg)?

Ok.... wird wohl die sein...?!

Teste ich bald..

DANKE!

Am 30.10.2012 18:55, schrieb Zrrronggg!:
> Das klingt jetzt wieder so wie das normale "FHTs senden nach ein paar
> Tagen nicht mehr, wenn sie keinen Befehl erhalten" Problem.
>

> L�sst sich mit einem Watchdog fixen.

>
> Wenn du so oder so das Thema hast, das das senden eines BBefehls die
> wieder zum Leben erwecken, dann mach einfach folgendes:
>
> define fht_reportZimmer1 at *04:00:00 {if ($wday == 1) { fhem("set
> hzg_Zimmer1 report2 255") } }
>
>

> Das machst du f�r jeden FHT, aus Funklastgr�nden f�r jeden an einem

> anderen Tag ($wday == 2), ($wday == 3) und so weiter.
>
>
> Wenn du nur 3-5 FHTs hast, kannst du das auch jede Nacht machen, z.B.
> so:
>
> define fht_report at *04:00:00 set hzg.* report2 255
>

> (setzt nat�rlich voraus, das alle dein FHTs mit "hzg...." anfangen)

[strauch]

ja das muss in die fhem.cfg du kannst es aber auch über das Webinterface eintippen.

Am Dienstag, 30. Oktober 2012 21:05:55 UTC+1 schrieb Ralf Becker:

Vielen Dank f�r den Tipp!

Jetzt noch die dumme Frage, wo ich das reinschreibe....
"global configuration" (/etc/fhem.cfg)?

Ok.... wird wohl die sein...?!

Teste ich bald..

DANKE!


Am 30.10.2012 18:55, schrieb Zrrronggg!:
> Das klingt jetzt wieder so wie das normale "FHTs senden nach ein paar
> Tagen nicht mehr, wenn sie keinen Befehl erhalten" Problem.
>

> L�sst sich mit einem Watchdog fixen.

>
> Wenn du so oder so das Thema hast, das das senden eines BBefehls die
> wieder zum Leben erwecken, dann mach einfach folgendes:
>
> define fht_reportZimmer1 at *04:00:00 {if ($wday == 1)  { fhem("set
> hzg_Zimmer1 report2 255") } }
>
>

> Das machst du f�r jeden FHT, aus Funklastgr�nden f�r jeden an einem

> anderen Tag ($wday == 2), ($wday == 3) und so weiter.
>
>
> Wenn du nur 3-5 FHTs hast, kannst du das auch jede Nacht machen, z.B.
> so:
>
> define fht_report at *04:00:00 set hzg.* report2 255
>

> (setzt nat�rlich voraus, das alle dein FHTs mit "hzg...." anfangen)

[Ralf Becker]

Danke!
Habe es mal über das Interface eingegeben....

--

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

-- 

Mit freundlichen Grüßen,
Ralf Becker

_____
Ralf Becker
St.-Martin-Straße 6
66780 Rehlingen-Siersburg


Mobil: 0151-211 65 216
Festnetz: 06835-60 11 93
email: ralf....@rb-typo3.de

[Ralf Becker]

Wenn ich das in die Zeile oben eingebe... passiert nix... :-(
Kommt der Sicherheitshinweis... (kein PW usw..), schaue ich jedoch in die fhem.cfg dann ist das nicht drin, was ich über die Eingabezeile oben im Browser eingegeben habe...

Hhmm.... also direkt eintippen?

Ich habe übrigens 10 FHTs....
Was passiert denn, wenn ich die alle mit dem Einzeiler (und dem Wildcard) täglich verarbeite?
Klar, das ist nicht so toll wegen der Funklast... aber was genau passiert?

Ach was... ich tippere sie jetzt einzeln in die fhem.cfg  und fertig... mal schauen ob das was bringt...

Grüße,
Ralf

_________
Heizungssteuerung mit FHEM unter Ubuntu 10.04
Hardware:
FHZ 1300 PC (Zentrale)
10 x FHT 80B (Thermostate/Steuerungen)
10 x FHT 80FT (Fensterkontakte)
13 x FS20 Funk-Stellantriebe (Ventilantriebe)
Ubuntu auf ThinClient "Igel" 256MB RAM und 4 GB CF-Card

Am 30.10.2012 21:31, schrieb strauch:

--

[Ralf Becker]

Muss ich eigentlich FHEM neu starten, nachdem ich was in die fhem.cfg
geschrieben habe?

Am 30.10.2012 18:55, schrieb Zrrronggg!:

> Das klingt jetzt wieder so wie das normale "FHTs senden nach ein paar
> Tagen nicht mehr, wenn sie keinen Befehl erhalten" Problem.
>

> L锟絪st sich mit einem Watchdog fixen.

>
> Wenn du so oder so das Thema hast, das das senden eines BBefehls die
> wieder zum Leben erwecken, dann mach einfach folgendes:
>
> define fht_reportZimmer1 at *04:00:00 {if ($wday == 1) { fhem("set
> hzg_Zimmer1 report2 255") } }
>
>

> Das machst du f锟絩 jeden FHT, aus Funklastgr锟絥den f锟絩 jeden an einem

> anderen Tag ($wday == 2), ($wday == 3) und so weiter.
>
>
> Wenn du nur 3-5 FHTs hast, kannst du das auch jede Nacht machen, z.B.
> so:
>
> define fht_report at *04:00:00 set hzg.* report2 255
>

> (setzt nat锟絩lich voraus, das alle dein FHTs mit "hzg...." anfangen)

--

Mit freundlichen Gr锟斤拷en,

Ralf Becker

_____
Ralf Becker

St.-Martin-Stra锟絜 6

[Dr. Boris Neubert]

Hallo, es genügt, wenn Du die Konfiguration neu lädtst - siehe commandref. Viele Grüße, Boris

---

Von: Ralf Becker <r...@rb-software.de>
Gesendet: Wed Oct 31 02:09:02 MEZ 2012
An: fhem-...@googlegroups.com
Betreff: Re: [FHEM] Re: FHEM und FHT80b-FHT8v und FHZ 1300

Muss ich eigentlich FHEM neu starten, nachdem ich was in die fhem.cfg 
geschrieben habe?


Am 30.10.2012 18:55, schrieb Zrrronggg!:

Das klingt jetzt wieder so wie das normale "FHTs senden nach ein paar
Tagen nicht mehr, wenn sie keinen Befehl erhalten" Problem.

Lässt sich mit einem Watchdog fixen.

Wenn du so oder so das Thema hast, das das senden eines BBefehls die
wieder zum Leben erwecken, dann mach einfach folgendes:

define fht_reportZimmer1 at *04:00:00 {if ($wday == 1)  { fhem("set
hzg_Zimmer1 report2 255") } }

Das machst du für jeden FHT, aus Funklastgründen für jeden an einem

anderen Tag ($wday == 2), ($wday == 3) und so weiter.


Wenn du nur 3-5 FHTs hast, kannst du das auch jede Nacht machen, z.B.
so:

define fht_report at *04:00:00 set hzg.* report2 255

(setzt natürlich voraus, das alle dein FHTs mit "hzg...." anfangen)

-- 

Mit freundlichen Grüßen,

Ralf Becker

_____
Ralf Becker

St.-Martin-Straße 6

66780 Rehlingen-Siersburg


Mobil: 0151-211 65 216
Festnetz: 06835-60 11 93
email: ralf....@rb-typo3.de

--
sent from my WePad - apologies for brevity

[Zrrronggg!]

ich würde das irgendwo in die config reinschrieben.

On 31 Okt., 06:10, "Dr. Boris Neubert" <om...@online.de> wrote:
> Hallo, es genügt, wenn Du die Konfiguration neu lädtst - siehe commandref. Viele Grüße, Boris
>

> -------- Original-Nachricht --------

> ...
>
> Erfahren Sie mehr »