Originally posted by: <email address deleted>
Moin,
nachdem ich hier mehrfach gelesen habe, dass die FHT's gern die Unart haben,
irgendwann keine Daten mehr zu senden, habe ich auch einen allnächtlichen
AT-Job eingerichtet:
*04:32:19 set TYPE=FHT time refreshvalues
merkwürdigerweise hat der (derzeit einzige) Thermostat letzte Nach daraufhin
zwar noch die Konfiguration gesendet, aber danach nur noch die
"actuator"-Sendungen gemacht... :(
Ist das genannte Verfahren also u.U. kontraproduktiv? Wie löst man es am
besten?
Gruß,
Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
(schon wieder Selbstgespraech?)
> haben, irgendwann keine Daten mehr zu senden, habe ich auch einen
> allnächtlichen AT-Job eingerichtet:
Nachtrag dazu - waere das nicht sogar ein wunderbares Beispiel fuer
einen Watchdog? Die "measured-temp" sollte so ca. alle 15min kommen;
wenn man also nach 1h nichts mehr gesehen hat, koennte man den "set
time" abfeuern. Leider habe ich keinen Plan, wie der Regex aussehen
muesste (oder geht das doch nicht so?)
Gruss
Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> *04:32:19 set TYPE=FHT time refreshvalues
> Ich denke, das würde die Zeit setzen und zusätzlich report1 255
> report2 255 (da refreshvalues ein alias für refreshvalues ist)
> abfragen.
Genau. Hatte ich aus einem Muster so übernommen.
> Funkkommunikation zwischen CUL/CUN/FHZ und FHT aus was für Gründen
> auch immer sowieso gestört und damit unzuverlässig ist, handelt man
> sich mit refreshvalues eher mehr Probleme ein.
Gestoert scheint sie ja nicht zu sein, aber ich hatte halt den
gegenteiligen Effekt, d.h. DANACH kamen nur noch die actuator-Messages
und sonst nichts mehr.
> Rudi schlug in einem anderen Thread vor, lieber z.b.
> define fht_sync at +*3:30 set TYPE=FHT time
> zu verwenden, es ist nämlich offenbar egal WAS man genau an die FHTs
> sendet.
Ja, so weit habe ich das auch jetzt erst einmal reduziert (nur noch 1x
taeglich den TIME-Befehl). Hat zumindest seit 2 Tagen funktioniert, was
nun noch nicht wirklich repraesentativ ist).
> In jedem Fall solltest du überlegen, ob du die report1 Daten
> tatsächlich brauchst.
Nein, keinesfalls, ich hatte nur das Example dahingehend verstanden,
dass es so besser/sicherer sei.
> Zuletzt: Wenn du einen CUL/CUN hasst, kannst du auch mal versuchen die
> Frequenz minimal zu ändern, (0.5 Mhz Schritte), da manche FHTs die
> Frequenz ungenau einhalten und die CUL/CUNS wegen höherer Trennschärfe
> damit schlechter zurechtkommen als eine original FHZ1x00
Kann das denn wirklich die Ursache sein, wenn ich ueber Stunden/Tage
alle Werte bekomme, und nach so einem "refreshvalues" nur noch
actuator-Zahlen kommen? Fuer mich sieht es eher so aus, als wenn der FHT
sich "verschluckt"...?
Gruss
Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Bei einer gestörten Kommunikation kann alles Mögliche möglich sein.
Aber es stimmt natürlich, dass das beobachtete Verhalten nicht
übertrieben wahrscheinlich ist.
Waren eben nur so ein paar Gedanken die mir gekommen sind. Eine
richtige Antwort hab ich nicht.
On 4 Okt., 19:54, borsti wrote:
> > *04:32:19 set TYPE=FHT time refreshvalues
> > Ich denke, das würde die Zeit setzen und zusätzlich report1 255
> > report2 255 (da refreshvalues ein alias für refreshvalues ist)
> > abfragen.
>
> Genau. Hatte ich aus einem Muster so übernommen.
>
> > Funkkommunikation zwischen CUL/CUN/FHZ und FHT aus was für Gründen
> > auch immer sowieso gestört und damit unzuverlässig ist, handelt man
> > sich mit refreshvalues eher mehr Probleme ein.
>
> Gestoert scheint sie ja nicht zu sein, aber ich hatte halt den
> gegenteiligen Effekt, d.h. DANACH kamen nur noch die actuator-Messages
> und sonst nichts mehr.
>
> > Rudi schlug in einem anderen Thread vor, lieber z.b.
> > define fht_sync at +*3:30 set TYPE=FHT time
> > zu verwenden, es ist nämlich offenbar egal WAS man genau an die FHTs
> > sendet.
>
> Ja, so weit habe ich das auch jetzt erst einmal reduziert (nur noch 1x
> taeglich den TIME-Befehl). Hat zumindest seit 2 Tagen funktioniert, was
> nun noch nicht wirklich repraesentativ ist).
>
> > In jedem Fall solltest du überlegen, ob du die report1 Daten
> > tatsächlich brauchst.
>
> Nein, keinesfalls, ich hatte nur das Example dahingehend verstanden,
> dass es so besser/sicherer sei.
>
> > Zuletzt: Wenn du einen CUL/CUN hasst, kannst du auch mal versuchen die
> > Frequenz minimal zu ändern, (0.5 Mhz Schritte), da manche FHTs die
> > Frequenz ungenau einhalten und die CUL/CUNS wegen höherer Trennschärfe
> > damit schlechter zurechtkommen als eine original FHZ1x00
>
> Kann das denn wirklich die Ursache sein, wenn ich ueber Stunden/Tage
> alle Werte bekomme, und nach so einem "refreshvalues" nur noch
> actuator-Zahlen kommen? Fuer mich sieht es eher so aus, als wenn der FHT
> sich "verschluckt"...?
>
> Gruss
> Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Waren eben nur so ein paar Gedanken die mir gekommen sind. Eine
> richtige Antwort hab ich nicht.
ja, danke dafür!
Vielleicht kann ja ein REGEX-Spezialist noch mal was zu meiner anderen
Idee (watchdog) schreiben... Wenn das geht, würde man die FHTs wirklich
nur noch bei Bedarf "wecken". Vielleicht noch 1x im Monat zusaetzlich
die Zeit neu setzen oder so...
Gruss
Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Nachtrag dazu - waere das nicht sogar ein wunderbares Beispiel fuer
> einen Watchdog? Die "measured-temp" sollte so ca. alle 15min kommen;
> wenn man also nach 1h nichts mehr gesehen hat, koennte man den "set
> time" abfeuern.
define wd_FHT1 FHT1:measured-temp.* 01:00 SAME set FHT1 time
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
On 10/05/2011 10:51 AM, Rudolf Koenig wrote:
> define wd_FHT1 FHT1:measured-temp.* 01:00 SAME set FHT1 time
Ich glaube, Du meintest (ungetestet):
define wd_FHT1 watchdog FHT1:measured-temp.* 01:00 SAME set FHT1 time
Viele liebe Grüße,
Thomas
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> define wd_FHT1 watchdog FHT1:measured-temp.* 01:00 SAME set FHT1 time
also steht vor dem Doppelpunkt der Name des definierten Devices,
dahinter das, was im Log nach dem Devicenamen kommt, richtig verstanden?
Weil vor dem "measured.." ja keine "Joker" erforderlich zu sein scheinen.
Ich habe das mal mit einem harmlosen Befehl und einem Intervall von 1min
ausprobiert, das sieht sehr gut aus!
Das nehme ich mal zum Ausprobieren anstelle des Nachtjobs. Wenn ich mich
nicht erneut melde, funktioniert das so - vielen Dank euch beiden!
Kann man eigentlich in den REGEX auch vor dem Doppelpunkt schon
Platzhalter hernehmen (und funktioniert es dennoch)?
Beispiel: Wenn meine FHT's so heissen: "bad_FHT", "wz_FHT" und "az_FHT",
koennte ich dann "watchdog *.FHT:measured-temp.*" schreiben?
Oder wuerde das bewirken, dass eine Meldung von az_FHT auch wz_FHT
"entschaerft" (was ich mal annehme)?
Gruss,
Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Kann man eigentlich in den REGEX auch vor dem Doppelpunkt schon
> Platzhalter hernehmen (und funktioniert es dennoch)?
Das geht genauso wie beim notify, wird aber nicht das erwartete tun.
Man sollte pro FHT einen eigenen watchdog aufsetzen, sonst weckt der watchdog
den schlafenden FHT2 nie auf, nur weil FHT1 fleissig sendet...
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
>> Kann man eigentlich in den REGEX auch vor dem Doppelpunkt schon
>> Platzhalter hernehmen (und funktioniert es dennoch)?
> Das geht genauso wie beim notify, wird aber nicht das erwartete tun.
Wie befuerchtet. Schade, muss ich also gegen meine natuerliche Faulheit
doch was unternehmen (das Schoene beim "at" mit dem TYPE=FHT ist ja,
dass potentielle neue Gerate automatisch mit abgegriffen werden). ;)
Aber bei den paar Dingern ist das ja kein Drama. Danke fuer die
Bestaetigung!
Gruss,
Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Sieht aus, als würde die Sache funktionobeln:
(fhem.cfg)
define wd_bad_Thermostat watchdog bad_Thermostat:measured-temp.* 01:00 SAME
set bad_Thermostat time
(fhem.log)
2011.10.06 14:25:01 3: Watchdog wd_bad_Thermostat triggered
2011.10.06 14:25:01 2: FHT set bad_Thermostat hour 14 minute 25
2011.10.06 15:57:02 3: Watchdog wd_bad_Thermostat triggered
2011.10.06 15:57:02 2: FHT set bad_Thermostat hour 15 minute 57
(bad_Thermostat.log)
2011-10-06_13:25:00 bad_Thermostat actuator: 0%
2011-10-06_13:25:01 bad_Thermostat measured-temp: 21.3 (Celsius)
2011-10-06_13:25:02 bad_Thermostat battery: ok
2011-10-06_13:25:02 bad_Thermostat lowtemp: ok
2011-10-06_13:25:02 bad_Thermostat window: closed
2011-10-06_13:25:02 bad_Thermostat windowsensor: ok
2011-10-06_13:25:02 bad_Thermostat warnings: none
2011-10-06_13:26:55 bad_Thermostat actuator: 0%
2011-10-06_13:28:50 bad_Thermostat actuator: 0%
2011-10-06_13:30:45 bad_Thermostat actuator: 0%
2011-10-06_13:32:40 bad_Thermostat actuator: 0%
2011-10-06_14:25:01 bad_Thermostat time
2011-10-06_14:43:36 bad_Thermostat actuator: 3%
2011-10-06_14:43:38 bad_Thermostat hour: 14
2011-10-06_14:43:38 bad_Thermostat minute: 43
2011-10-06_14:45:31 bad_Thermostat actuator: 3%
2011-10-06_14:45:32 bad_Thermostat hour: 14
2011-10-06_14:45:33 bad_Thermostat minute: 45
2011-10-06_14:53:11 bad_Thermostat actuator: 2%
2011-10-06_14:55:06 bad_Thermostat actuator: 2%
2011-10-06_14:57:01 bad_Thermostat actuator: 2%
2011-10-06_14:57:02 bad_Thermostat measured-temp: 21.2 (Celsius)
2011-10-06_14:57:02 bad_Thermostat battery: ok
2011-10-06_14:57:02 bad_Thermostat lowtemp: ok
Ist zwar seltsam, dass der Kontakt gleich 2x nacheinander abgerissen ist,
aber die geplante Funktion ist offenbar gegeben.
Danke!
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ich habe keine echte Antwort, aber ein paar Anmerkungen:
*04:32:19 set TYPE=FHT time refreshvalues
soll was genau machen?
Ich denke, das würde die Zeit setzen und zusätzlich report1 255
report2 255 (da refreshvalues ein alias für refreshvalues ist)
abfragen.
Das erzeugt eine deutliche Funklast. Es würde mich nicht wundern, wenn
unter schwierigen Randbedingungen die FHT Kommunikation dann nicht
mehr sauber abläuft.
Bei nur einem FHT zwar unwahrscheinlich - zugegeben - aber wenn die
Funkkommunikation zwischen CUL/CUN/FHZ und FHT aus was für Gründen
auch immer sowieso gestört und damit unzuverlässig ist, handelt man
sich mit refreshvalues eher mehr Probleme ein.
Rudi schlug in einem anderen Thread vor, lieber z.b.
define fht_sync at +*3:30 set TYPE=FHT time
zu verwenden, es ist nämlich offenbar egal WAS man genau an die FHTs
sendet.
Ich persönlich habe 8 FHTs und daher sogar noch eine Wochentagabfrage
drin, damit ich das nur 2x die Woche mache.
In jedem Fall solltest du überlegen, ob du die report1 Daten
tatsächlich brauchst. Die ändern sich ja nun gewiss nicht täglich,
oder?
Zuletzt: Wenn du einen CUL/CUN hasst, kannst du auch mal versuchen die
Frequenz minimal zu ändern, (0.5 Mhz Schritte), da manche FHTs die
Frequenz ungenau einhalten und die CUL/CUNS wegen höherer Trennschärfe
damit schlechter zurechtkommen als eine original FHZ1x00
On 4 Okt., 19:20, borsti wrote:
> (schon wieder Selbstgespraech?)
>
> > haben, irgendwann keine Daten mehr zu senden, habe ich auch einen
> > allnächtlichen AT-Job eingerichtet:
>
> Nachtrag dazu - waere das nicht sogar ein wunderbares Beispiel fuer
> einen Watchdog? Die "measured-temp" sollte so ca. alle 15min kommen;
> wenn man also nach 1h nichts mehr gesehen hat, koennte man den "set
> time" abfeuern. Leider habe ich keinen Plan, wie der Regex aussehen
> muesste (oder geht das doch nicht so?)
>
> Gruss
> Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com