FHEM Forum

                                                 

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

                                                     

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

                                                 

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

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

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

                                                 

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

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

                                                 

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

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

                                                 

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

                                                           

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

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

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

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

                                                     

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

                                                           

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

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

                                                 

@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

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

                                                 

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





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

                                                 

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

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

                                                 

Noch ein Wert der vielleicht wichtig ist.

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

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

                                                     

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




On 19 Okt., 12:46, KUD wrote:
> Noch ein Wert der vielleicht wichtig ist.
>
> get CUL_0 fhtbuf  =>  A9             ---- > bedeutet Dez. 251

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

                                                 

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











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

                                                     

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.






On 19 Okt., 15:06, KUD wrote:
> 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

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

                                                 

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.

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

                                                     

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 wrote:
> 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

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

                                                 

> 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

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

Originally posted by: <email address deleted>

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

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

                                                     

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

Gerne!

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

                                               

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

Am Freitag, 19. Oktober 2012 22:11:14 UTC+2 schrieb Zrrronggg!:
>
>
> > Soll ich sonst noch mal am WE drüber schauen? Bis jetzt habe ich noch
> > nicht viel auf dem Plan.
>
> Gerne!
>

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

                                                     

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

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

                                               

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



Am Freitag, 19. Oktober 2012 22:47:47 UTC+2 schrieb 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.
>

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

                                                 

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

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

                                                 

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


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

                                                 

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

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

                                                 

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



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

                                                     

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




On 20 Okt., 14:28, KUD wrote:
> "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?

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

                                                 

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

?

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

                                                 

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

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

                                                     

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?

On 21 Okt., 09:19, KUD wrote:
> Trotz der Änderungen ist der CUL wieder ausgestiegen.
> Ich werde jetzt meine FHTs verkaufen und mein Glück mit Homematic versuchen.

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

Originally posted by: <email address deleted>

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

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

Originally posted by: <email address deleted>

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


Am 23.10.2012 20:48, schrieb 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
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@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)
>
>
>

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

Originally posted by: <email address deleted>

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


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

                                                     

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.?)



On 24 Okt., 02:15, Ralf Becker wrote:
> 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

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

Originally posted by: <email address deleted>

...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.?)
>
>
>
> On 24 Okt., 02:15, Ralf Becker wrote:
>> 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
>

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

                                                     

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.


On 24 Okt., 11:54, Ralf Becker wrote:
> ...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.?)
>
> > On 24 Okt., 02:15, Ralf Becker wrote:
> >> 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

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

Originally posted by: <email address deleted>

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

 

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

                                                     

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

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

Originally posted by: <email address deleted>

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

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

                                                 

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  
kannst Du in CULFW den FHT-buffer zurücksetzen. Siehe auch
http://culfw.de/commandref.html#cmd_T
Vll hilft's ja...
=8-)

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

Originally posted by: <email address deleted>

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

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

                                                     

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

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

Bischen Holzhammer

On 27 Okt., 00:18, ManuelM wrote:
> 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

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

                                                 

Am 27. Oktober 2012 00:18 schrieb ManuelM :

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

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

Originally posted by: <email address deleted>

Danke für den Tipp
MM

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

Originally posted by: <email address deleted>

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.
>
>
> On 24 Okt., 11:54, Ralf Becker wrote:
>> ...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.?)
>>> On 24 Okt., 02:15, Ralf Becker wrote:
>>>> 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
>

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

                                                     

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)






On 30 Okt., 02:31, Ralf Becker wrote:
> 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.
>
> > On 24 Okt., 11:54, Ralf Becker wrote:
> >> ...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.?)
> >>> On 24 Okt., 02:15, Ralf Becker wrote:
> >>>> 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

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

Originally posted by: <email address deleted>

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)
>
> Das fordert von allen FHTs den "Report 2" ab (das sind temp, desired
> temp, day und night temp und noch so paar Daten)
>
>
>
>
>
>
> On 30 Okt., 02:31, Ralf Becker wrote:
>> 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.
>>> On 24 Okt., 11:54, Ralf Becker wrote:
>>>> ...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.?)
>>>>> On 24 Okt., 02:15, Ralf Becker wrote:
>>>>>> 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
>

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

Originally posted by: <email address deleted>

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)
> >
> > Das fordert von allen FHTs den "Report 2" ab (das sind temp, desired
> > temp, day und night temp und noch so paar Daten)
> >
> >
> >
> >
> >
> >
> > On 30 Okt., 02:31, Ralf Becker wrote:
> >> 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.
> >>> On 24 Okt., 11:54, Ralf Becker wrote:
> >>>> ...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.?)
> >>>>> On 24 Okt., 02:15, Ralf Becker wrote:
> >>>>>> 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
> >
>

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

Originally posted by: <email address deleted>

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

Am 30.10.2012 21:31, schrieb 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)
>     >
>     > Das fordert von allen FHTs den "Report 2" ab (das sind temp,
>     desired
>     > temp, day und night temp und noch so paar Daten)
>     >
>     >
>     >
>     >
>     >
>     >
>     > On 30 Okt., 02:31, Ralf Becker wrote:
>     >> 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.
>     >>> On 24 Okt., 11:54, Ralf Becker wrote:
>     >>>> ...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.?)
>     >>>>> On 24 Okt., 02:15, Ralf Becker wrote:
>     >>>>>> 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
>     >
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@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.becker@rb-typo3.de


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

Originally posted by: <email address deleted>

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:
> 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)
>     >
>     > Das fordert von allen FHTs den "Report 2" ab (das sind temp,
>     desired
>     > temp, day und night temp und noch so paar Daten)
>     >
>     >
>     >
>     >
>     >
>     >
>     > On 30 Okt., 02:31, Ralf Becker wrote:
>     >> 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.
>     >>> On 24 Okt., 11:54, Ralf Becker wrote:
>     >>>> ...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.?)
>     >>>>> On 24 Okt., 02:15, Ralf Becker wrote:
>     >>>>>> 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
>     >
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com
>
> --
>
>

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

Originally posted by: <email address deleted>

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)
>
> Das fordert von allen FHTs den "Report 2" ab (das sind temp, desired
> temp, day und night temp und noch so paar Daten)
>
>
>
>
>
>
> On 30 Okt., 02:31, Ralf Becker wrote:
>> 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.
>>> On 24 Okt., 11:54, Ralf Becker wrote:
>>>> ...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.?)
>>>>> On 24 Okt., 02:15, Ralf Becker wrote:
>>>>>> 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

--

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.becker@rb-typo3.de


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

                                             

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


-------- Original-Nachricht --------
Von: Ralf Becker
Gesendet: Wed Oct 31 02:09:02 MEZ 2012
An: fhem-users@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)
>
> Das fordert von allen FHTs den "Report 2" ab (das sind temp, desired
> temp, day und night temp und noch so paar Daten)
>
>
>
>
>
>
> On 30 Okt., 02:31, Ralf Becker wrote:
>> 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.
>>> On 24 Okt., 11:54, Ralf Becker wrote:
>>>> ...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.?)
>>>>> On 24 Okt., 02:15, Ralf Becker wrote:
>>>>>> 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

--

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.becker@rb-typo3.de


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

--
sent from my WePad - apologies for brevity

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

                                                     

ich würde das irgendwo in die config reinschrieben.

On 31 Okt., 06:10, "Dr. Boris Neubert" wrote:
> Hallo, es genügt, wenn Du die Konfiguration neu lädtst - siehe commandref. Viele Grüße, Boris
>
> -------- Original-Nachricht --------
> Von: Ralf Becker
> Gesendet: Wed Oct 31 02:09:02 MEZ 2012
> An: fhem-users@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)
>
> > Das fordert von allen FHTs den "Report 2" ab (das sind temp, desired
> > temp, day und night temp und noch so paar Daten)
>
> > On 30 Okt., 02:31, Ralf Becker wrote:
> >> 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.
> >>> On 24 Okt., 11:54, Ralf Becker wrote:
> >>>> ...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.?)
> >>>>> On 24 Okt., 02:15, Ralf Becker wrote:
> >>>>>> 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
> >>>>>> _________
>
> ...
>
> Erfahren Sie mehr »

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