Hallo Zusammen,
ich möchte gerne einen FHT manuel in den Status "window open" setzen.
So wie ich das im commandref sehen, geht das aber nicht, oder?
Zum Hintergrund, ich habe im Flur einen FHT der einen Heizkörper steuert.
An der Haustür ist ein FS20 TFK, der mir ein paar Dinge meldet und schaltet.
Ich möchte ungern noch einen FHT80-TF zusätzlich an der Tür befestigen.
Die Idee war nun, sobald der FS20 TFK meldet, dass die Tür auf ist, der FHT
in window open schaltet.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Warum meldest Du den TFK denn nicht am FHT an? Am FHT-80b können sogar
mehrere angemeldet werden...?
> Zum Hintergrund, ich habe im Flur einen FHT der einen Heizkörper steuert.
> An der Haustür ist ein FS20 TFK, der mir ein paar Dinge meldet und schaltet.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ich wüste nicht, wie ich einen FS20TFK an den FHT-80b anmelden könnte?
Das geht doch nur mit dem FHT80-TF.
Aber kann ich denn einen FHT80-TF an zwei FHT-80b anmelden?
Am Mittwoch, 5. September 2012 20:40:18 UTC+2 schrieb Borsti67:
>
> Warum meldest Du den TFK denn nicht am FHT an? Am FHT-80b können sogar
> mehrere angemeldet werden...?
>
> > Zum Hintergrund, ich habe im Flur einen FHT der einen Heizkörper
> steuert.
> > An der Haustür ist ein FS20 TFK, der mir ein paar Dinge meldet und
> schaltet.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 5. September 2012 20:49 schrieb Mitch :
> Ich wüste nicht, wie ich einen FS20TFK an den FHT-80b anmelden könnte?
> Das geht doch nur mit dem FHT80-TF.
ja? Warum? Ich meine, die arbeiten doch beide nach dem selben Prinzip.
Probier's halt aus, wenn Du den Hauscode im FHT80b eingetragen hast,
siehst Du ja, ob er den Status erkennt. ;)
Und wenn es absolut-und-ganz-und-gar nicht gehen sollte, könntest Du
immer noch den TFK durch einen TF ersetzen (nicht zusätzlich
anbringen)...
> Aber kann ich denn einen FHT80-TF an zwei FHT-80b anmelden?
Ja sicher, das ist doch keine "gegenseitige Kopplung". Der Melder
sendet einfach nur mit seinem Hauscode ob offen oder zu ist.
Dem FHT teilst Du lediglich mit, auf welchen HC er "horchen" soll. Der
weiß nicht, ob sonst noch irgendwer zuhört.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FS20TFK hat sich nicht verbinen lassen.
Hauscode im FHT-80b eintragen? Der hat ja einen eigenen Hauscode.
Und den FHT80-TF an beide FHTs bringt mir auch nicht wirklich etwas.
Am besten wäre wie gesagt, wenn man den FHT in windows open setzten könnte.
Dann würde ich einfach, wenn der FS20TFk sendet, einen notify machen, der
den FHT auf window open schaltet.
Natürlich könnte ich den FHT auch mit dem notify auf 8 Grad runter
"setten", aber kann ich ihn denn dann auch wieder auf die programmierte
Temp stellen?
z.B. set FH_1234 day-temp
Am Mittwoch, 5. September 2012 21:15:23 UTC+2 schrieb Borsti67:
>
> Am 5. September 2012 20:49 schrieb Mitch >:
>
> > Ich wüste nicht, wie ich einen FS20TFK an den FHT-80b anmelden könnte?
> > Das geht doch nur mit dem FHT80-TF.
>
> ja? Warum? Ich meine, die arbeiten doch beide nach dem selben Prinzip.
> Probier's halt aus, wenn Du den Hauscode im FHT80b eingetragen hast,
> siehst Du ja, ob er den Status erkennt. ;)
>
> Und wenn es absolut-und-ganz-und-gar nicht gehen sollte, könntest Du
> immer noch den TFK durch einen TF ersetzen (nicht zusätzlich
> anbringen)...
>
> > Aber kann ich denn einen FHT80-TF an zwei FHT-80b anmelden?
>
> Ja sicher, das ist doch keine "gegenseitige Kopplung". Der Melder
> sendet einfach nur mit seinem Hauscode ob offen oder zu ist.
> Dem FHT teilst Du lediglich mit, auf welchen HC er "horchen" soll. Der
> weiß nicht, ob sonst noch irgendwer zuhört.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> FS20TFK hat sich nicht verbinen lassen.
schade. Ich hätte jetzt in den beiden keinen Unterschied gesehen. Dann
habe ich ja wohl Glück gehabt, dass der TF billiger ist, sonst hätte ich
dieses Problem auch schon bekommen...
> Hauscode im FHT-80b eintragen? Der hat ja einen eigenen Hauscode.
wie versuchst Du die denn zu koppeln? Wenn Du nicht völlig andere FHT's
hast als ich, muss man für jeden zu überwachenden TF dessen Hauscode
hinterlegen. Woher sonst soll der FHT wissen, welche Signale für ihn
relevant sind?
> Und den FHT80-TF an beide FHTs bringt mir auch nicht wirklich etwas.
Welchen "DEN" TF und wieso "beide FHT"?
Du schriebst, der TFK an der Tür meldet Dir irgendwas, der ist nicht an
einem FHT dran (geht ja auch nicht, sagst Du). Den baust Du ab und
ersetzt ihn durch einen neu zu beschaffenden TF, welcher dann die obigen
Meldungen sendet, die bisher der TFK gemacht hat UND den kannst Du mit
dem FHT "verheiraten".
> Am besten wäre wie gesagt, wenn man den FHT in windows open setzten könnte.
> Dann würde ich einfach, wenn der FS20TFk sendet, einen notify machen,
> der den FHT auf window open schaltet.
In dieser Form nicht möglich. Die einzige Chance wäre, wenn FHEM einen
TF "simulieren" könnte (also per Befehl die Funktelegramme senden, die
ein TF machen würde), was ich aber nicht glaube.
> Natürlich könnte ich den FHT auch mit dem notify auf 8 Grad runter
> "setten", aber kann ich ihn denn dann auch wieder auf die programmierte
> Temp stellen?
DAS würde mich übrigens auch mal interessieren. Wenn ich außer bin,
stelle meine FHT's auf "manual", so dass das hinterlegte Programm außer
Kraft gesetzt wird. Gehe ich wieder auf Automatik zurück, bleibt die
Temperatur wie derzeit eingestellt, erst beim nächsten day/night-Wechsel
läuft alles wieder nach Plan. Weiß jemand, wie man einen FHT auf die
"Standard-Einstellung" bringt?
Gruß
Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Naja, der FS20TFK ist ja ein 2-Kanal FS20 Sender, der TF einfach nur ein
Sender, der 0 oder 1 sendet.
Der Hauscode des FHT ist ja für die Verbindung zwischen FHT, Ventil und
Zentrale.
Den Code für den TF kann man nicht einstellen.
Kann es sein, dass Du die TF direkt mit einem CUL empfängst?
Ich habe eine FHZ1300, die kann das nicht, deswegen hängen die TFs an den
FHTs.
Zum notify: es fehlt mir irgendwie die Funktion, einen FHT kurzzeitig zu
verändern und ihn dann wieder in den normalen programmieren Zustand zu
versetzten.
Nicht nur für meine Türgeschicht, sondern überhaupt.
Beispiel: ich habe einen Macro, der heißt kurz Weg. Dieser soll alle FHTs
auf 16 Grad setzten (set FHT_.* ...). Wenn ich zurück komme und der Macro
umgeschalten wird, sollen die FHTs in den ursprünglichen (porgrammierten)
Zustand zurück gehen. Ich kann hier nicht mit set FHT_.* arbeiten, weil die
FHTs unterschiedliche Temperaturen programmiert haben.
Am Donnerstag, 6. September 2012 06:15:39 UTC+2 schrieb Borsti67:
>
> > FS20TFK hat sich nicht verbinen lassen.
>
> schade. Ich h�tte jetzt in den beiden keinen Unterschied gesehen. Dann
> habe ich ja wohl Gl�ck gehabt, dass der TF billiger ist, sonst h�tte
> ich
> dieses Problem auch schon bekommen...
>
> > Hauscode im FHT-80b eintragen? Der hat ja einen eigenen Hauscode.
>
> wie versuchst Du die denn zu koppeln? Wenn Du nicht v�llig andere FHT's
> hast als ich, muss man f�r jeden zu �berwachenden TF dessen Hauscode
> hinterlegen. Woher sonst soll der FHT wissen, welche Signale f�r ihn
> relevant sind?
>
> > Und den FHT80-TF an beide FHTs bringt mir auch nicht wirklich etwas.
>
> Welchen "DEN" TF und wieso "beide FHT"?
> Du schriebst, der TFK an der T�r meldet Dir irgendwas, der ist nicht an
> einem FHT dran (geht ja auch nicht, sagst Du). Den baust Du ab und
> ersetzt ihn durch einen neu zu beschaffenden TF, welcher dann die obigen
> Meldungen sendet, die bisher der TFK gemacht hat UND den kannst Du mit
> dem FHT "verheiraten".
>
> > Am besten w�re wie gesagt, wenn man den FHT in windows open setzten
> k�nnte.
> > Dann w�rde ich einfach, wenn der FS20TFk sendet, einen notify machen,
> > der den FHT auf window open schaltet.
>
> In dieser Form nicht m�glich. Die einzige Chance w�re, wenn FHEM einen
> TF "simulieren" k�nnte (also per Befehl die Funktelegramme senden, die
> ein TF machen w�rde), was ich aber nicht glaube.
>
> > Nat�rlich k�nnte ich den FHT auch mit dem notify auf 8 Grad runter
> > "setten", aber kann ich ihn denn dann auch wieder auf die programmierte
> > Temp stellen?
>
> DAS w�rde mich �brigens auch mal interessieren. Wenn ich au�er bin,
> stelle meine FHT's auf "manual", so dass das hinterlegte Programm au�er
> Kraft gesetzt wird. Gehe ich wieder auf Automatik zur�ck, bleibt die
> Temperatur wie derzeit eingestellt, erst beim n�chsten day/night-Wechsel
> l�uft alles wieder nach Plan. Wei� jemand, wie man einen FHT auf die
> "Standard-Einstellung" bringt?
>
> Gru�
> Torsten
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi Mitch!
Du sollst den (festgelegten) Code des TFK in den FHT80b eintragen damit
dieser auf den TFK reagiert. RTFM!
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Sorry dein RTFM kannst Du dir sparen!!
Hier die Links:
http://www.elv-downloads.de/Assets/Produkte/8/856/85643/Downloads/85643_FHT80B_UM.pdf
http://www.elv-downloads.de/service/manuals/FS20TFK/FS20TFK_UM_G_050727.pdf
und jetzt zeig mir, wo Du da den Code einträgst und eine TFK mit einem FHT
verbindest!!
Am Donnerstag, 6. September 2012 08:50:01 UTC+2 schrieb ilmtuelp0815:
>
> Hi Mitch!
> Du sollst den (festgelegten) Code des TFK in den FHT80b eintragen damit
> dieser auf den TFK reagiert. RTFM!
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Moin,
Am 06.09.2012 08:59, schrieb Mitch:
> Sorry dein RTFM kannst Du dir sparen!!
offensichtlich nicht:
> Hier die Links:
> http://www.elv-downloads.de/Assets/Produkte/8/856/85643/Downloads/85643_FHT80B_UM.pdf
guggst Du Kapitel 3.9.10
> und jetzt zeig mir, wo Du da den Code einträgst und eine TFK mit
> einem FHT verbindest!!
hth,
Manfred
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ja und was steht da in Kapitel 3.9.10??
Wie man einen TF (TF-2) anmeldet und NICHT einen TFK.
TF = http://www.elv.de/funk-tuer-fensterkontakt-fht80tf-2.html
TFK =
http://www.elv.de/fs20-tfk-2-kanal-tuer-fenster-kontakt-fertiggeraet.html
Einen FS20TFK kann man nicht an einen FHT80b anmelden.
Am Mittwoch, 5. September 2012 20:36:43 UTC+2 schrieb Mitch:
>
> Hallo Zusammen,
>
> ich möchte gerne einen FHT manuel in den Status "window open" setzen.
> So wie ich das im commandref sehen, geht das aber nicht, oder?
>
> Zum Hintergrund, ich habe im Flur einen FHT der einen Heizkörper steuert.
> An der Haustür ist ein FS20 TFK, der mir ein paar Dinge meldet und
> schaltet.
> Ich möchte ungern noch einen FHT80-TF zusätzlich an der Tür befestigen.
>
> Die Idee war nun, sobald der FS20 TFK meldet, dass die Tür auf ist, der
> FHT in window open schaltet.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Einen FS20TFK kann man nicht an einen FHT80b anmelden.
Um die nette Diskussion mit Details zu bereichern :)
- Ein FHT80TF sendet (wie der Name schon sagt) per FHT Protokoll, und jeweils
in bestimmten Zeitintervall so, dass das FHT80b sich schlafen legen kann,
d.h. eine Oeffnung/Schliessung wird immer Zeitversetzt gemeldet.
- das FS20TFK sendet mit dem FS20 Protokoll (das ist nicht mit FHT identisch),
wenn ich mich nicht irre sofort wenn eine Oeffnung/Schliessung entdeckt wird.
-> Ein FS20TFK sollte mit dem FHT80b aus mehreren Gruenden nicht
zusammenarbeiten.
Das ist alles aus der Theorie, ich habe keinen der beiden Geraete gesehen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> - Ein FHT80TF sendet (wie der Name schon sagt) per FHT Protokoll, und jeweils
> in bestimmten Zeitintervall so, dass das FHT80b sich schlafen legen kann,
> d.h. eine Oeffnung/Schliessung wird immer Zeitversetzt gemeldet.
...aber FHEM kann auch dieses mitlesen und somit zum Schalten
verwendet werden. Deswegen war mein alternativer Vorschlag, den TFK
durch einen TF zu ersetzen. Aber da Mitch nicht angegeben hat, was
genau der TFK schaltet (insbesondere ob es sich um eine direkte
Kopplung handelt (handeln MUSS) oder ob indirekt über FHEM (möglich
wäre)), könnte das auch daneben gehen...
> -> Ein FS20TFK sollte mit dem FHT80b aus mehreren Gruenden nicht
> zusammenarbeiten.
ich sag ja, bin froh dass ich nicht (irrtümlich) so einen erwischt habe. =8)
Einen TF hab' ich nämlich ohne FHT (also nur als Melder) in Betrieb,
das klappt bestens...
Gruß
Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Danke Rudi, dass Du meine Aussage mit Fakten hinterlegt hast.
Kannst Du mir evtl. noch sagen, ob man einen FHT aus fhem per set in
windows open setzten kann?
Wenn nicht, evtl. manuel auf 8 Grad setzten und dann zurück auf die
Ursprungstemperatur?
@Tom:
> *...aber FHEM kann auch dieses mitlesen und somit zum Schalten *
> *verwendet werden. Deswegen war mein alternativer Vorschlag, den TFK *
> *durch einen TF zu ersetzen. Aber da Mitch nicht angegeben hat, was *
> *genau der TFK schaltet (insbesondere ob es sich um eine direkte *
> *Kopplung handelt (handeln MUSS) oder ob indirekt über FHEM (möglich *
> *wäre)), könnte das auch daneben gehen... *
>
fhem kann theoretisch schon mitlesen, aber wie ich geschrieben habe, geht
das mit der FHZ1300 nicht.
Den TFK kann ich nicht ersetzten, weil ich dann eben nicht mehr meine Dinge
(Mail bei Tür auf, Klingel ausschalten, Licht im Flur an etc.) schalten
kann, weil eben der TF nicht mit der FHZ1300 direkt kommunizieren kann.
Am Donnerstag, 6. September 2012 12:03:33 UTC+2 schrieb Borsti67:
>
> > - Ein FHT80TF sendet (wie der Name schon sagt) per FHT Protokoll, und
> jeweils
> > in bestimmten Zeitintervall so, dass das FHT80b sich schlafen legen
> kann,
> > d.h. eine Oeffnung/Schliessung wird immer Zeitversetzt gemeldet.
>
> ...aber FHEM kann auch dieses mitlesen und somit zum Schalten
> verwendet werden. Deswegen war mein alternativer Vorschlag, den TFK
> durch einen TF zu ersetzen. Aber da Mitch nicht angegeben hat, was
> genau der TFK schaltet (insbesondere ob es sich um eine direkte
> Kopplung handelt (handeln MUSS) oder ob indirekt über FHEM (möglich
> wäre)), könnte das auch daneben gehen...
>
> > -> Ein FS20TFK sollte mit dem FHT80b aus mehreren Gruenden nicht
> > zusammenarbeiten.
>
> ich sag ja, bin froh dass ich nicht (irrtümlich) so einen erwischt habe.
> =8)
> Einen TF hab' ich nämlich ohne FHT (also nur als Melder) in Betrieb,
> das klappt bestens...
>
> Gruß
> Torsten
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo zusammen,
ich habe beide Geräte im Einsatz. Den FS20TFK genauso wie Markus an der
Haustür.
- Ein FHT80TF sendet (wie der Name schon sagt) per FHT Protokoll, und
> jeweils
> in bestimmten Zeitintervall so, dass das FHT80b sich schlafen legen
> kann,
> d.h. eine Oeffnung/Schliessung wird immer Zeitversetzt gemeldet.
>
Das ist nämlich der Knackpunkt. Ein FHT80TF merkt garnicht, wenn die
Haustür mal 20 Sekunden geöffnet ist. Dafür ist er zu langsam.
- das FS20TFK sendet mit dem FS20 Protokoll (das ist nicht mit FHT
> identisch),
> wenn ich mich nicht irre sofort wenn eine Oeffnung/Schliessung entdeckt
> wird.
>
Richtig, genau das macht er.
-> Ein FS20TFK sollte mit dem FHT80b aus mehreren Gruenden nicht
> zusammenarbeiten.
>
> Das ist alles aus der Theorie, ich habe keinen der beiden Geraete gesehen.
>
Deine Theorie stimmt so, Rudi.
Zur Frage von Markus:
Ich hätte erwartet, dass man mit
set >fht> window open
den Windowstatus setzen kann. Geht aber nicht bei meinem FHEM 5.0. Ich
vermute mal, mit 5.2 auch nicht.
Gruß,
Jürgen
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Kannst Du mir evtl. noch sagen, ob man einen FHT aus fhem per set in
> windows open setzten kann?
Wenn das nicht in der set-liste der FHT auftaucht, dann weiss ich es auch
nicht.
> Wenn nicht, evtl. manuel auf 8 Grad setzten und dann zurück auf die
> Ursprungstemperatur?
Das muesste gehen, ist halt etwas aufwendiger, weil man die letzte Temperatur
merken muss (am besten in einem dummy). Oder man schaltet von Auto auf manuell,
aber hier habe ich nicht alles im Kopf, also geht das evtl. auch nicht ohne
zwischenvariable.
> fhem kann theoretisch schon mitlesen, aber wie ich geschrieben habe, geht
> das mit der FHZ1300 nicht.
Das kann ich bestaetigen, das ist ein culfw feature.
> Den TFK kann ich nicht ersetzten, weil ich dann eben nicht mehr meine Dinge
> (Mail bei Tür auf, Klingel ausschalten, Licht im Flur an etc.) schalten
> kann, weil eben der TF nicht mit der FHZ1300 direkt kommunizieren kann.
Selbst wenn Du es empfangen koenntest, die verzoegerte Meldung bei der FHT-TK
waere fuer manche Szenarien ein Problem.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
>
> Ich hätte erwartet, dass man mit
>>
>> set >fht> window open
>>
>> den Windowstatus setzen kann. Geht aber nicht bei meinem FHEM 5.0. Ich
>> vermute mal, mit 5.2 auch nicht.
>>
>
Gerade mit 5.2 nochmal getestet (hatte ich gestern schon probiert), geht
aber nicht
Das muesste gehen, ist halt etwas aufwendiger, weil man die letzte
> Temperatur
> merken muss (am besten in einem dummy). Oder man schaltet von Auto auf
> manuell,
> aber hier habe ich nicht alles im Kopf, also geht das evtl. auch nicht
> ohne
> zwischenvariable.
>
Das ist auch noch eine gute Idee, werde ich heute Abend mal testen, Danke.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hab jetzt mal kurz zusammen geschrieben:
define FlurUntenChecker notify Haustuer2 {\
if ("%" eq "on") {\
fhem ("set FHT_050a mode manuel ;; set FHT_050a desired-temp 8.0");;\
}\
else {\
fhem("set FHT_050a mode auto");;\
}\
}
Aber aus dem Bauch raus würde ich sagen, die Temperatur bleibt bis zum
nächsten Schaltvorgang des FHTs bei 8 Grad.
Man muss also wirklich die Temp erstmal irgendwie rausholen und speichern,
dann zurück schreiben.
Leider ist meine Proggrammierkenntnis da nicht ausreichend :-(
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> fhem ("set FHT_050a mode manuel ;; set FHT_050a desired-temp 8.0");;\
Das erzeugt zwei FHT-Befehlsketten, und pro FHT-Wach-Zeit wird nur eine Kette
uebertragen. Dies hier:
fhem ("set FHT_050a mode manual desired-temp 8.0");;\
wird auf einmal uebertragen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hej,
ideal wäre es, einen LastState für die Soll-Temperatur einzuführen.
Aber ist eben schon wieder Entwicklungsaufwand, den jemand betreiben
muss.
Greetz,
Gerhard
Am 6. September 2012 13:06 schrieb Mitch :
> Hab jetzt mal kurz zusammen geschrieben:
> define FlurUntenChecker notify Haustuer2 {\
> if ("%" eq "on") {\
> fhem ("set FHT_050a mode manuel ;; set FHT_050a desired-temp 8.0");;\
> }\
> else {\
> fhem("set FHT_050a mode auto");;\
> }\
> }
>
> Aber aus dem Bauch raus würde ich sagen, die Temperatur bleibt bis zum
> nächsten Schaltvorgang des FHTs bei 8 Grad.
>
> Man muss also wirklich die Temp erstmal irgendwie rausholen und speichern,
> dann zurück schreiben.
> Leider ist meine Proggrammierkenntnis da nicht ausreichend :-(
>
>
> --
> 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
> Aber aus dem Bauch raus würde ich sagen, die Temperatur bleibt bis zum
> nächsten Schaltvorgang des FHTs bei 8 Grad.
So ist es, wie ich Dir aus eigener Erfahrung versichern kann. :(
> Man muss also wirklich die Temp erstmal irgendwie rausholen und speichern,
> dann zurück schreiben.
Ich hatte gehofft, dass es einen Trick gäbe, um das zu vermeiden. :-P
Wenn der FHT seine Statusberichte abgeliefert hat, stehen ja die
Soll-Temperaturen und deren Zeitfenster in den diversen Readings. Mein
Lösungsansatz wäre gewesen, die anhand dessen zu ermitteln.
Leider geht es mir da wie Dir, das ist schon recht komplex. Anhand des
aktuellen Wochentags und der Uhrzeit müsste man ermitteln, in welchem
Zeitfenster der FHT sich gerade befindet, und dementsprechend die
"desired-temp" auf "day-temp" oder "night-temp" setzen. :-/
Gruß
Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hi Mich und Rudi!
In der von Mitch selbst angegebenen ELV Quelle steht zwar im Text immer
etwas von FHT80 TF aber die Bilder zeigen eindeutig einen FHT80 TFK!
Der FHT80 TFK hat halt im Gegensatz zu TF 2 Kanäle, lässt sich aber genauso
(wie in der BA) am FHT80b anmelden.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Achso, und weil das Bild das gleiche ist, geht das dan?? sorry wenn ich
lache.
Das Bild ist so, weil der alte Fensterkontakt, der TF, das gleiche Gehäuse
wie der TFK hat.
Der neue, der TF-2, hat einfach ein neues Gehäuse.
Rudi hat es doch schon richtig erklärt, das eine ist FHT Protokoll, das
andere FS20.
Ich habe jetzt keine Lust mehr darüber zu diskutieren!
Am Donnerstag, 6. September 2012 14:23:19 UTC+2 schrieb ilmtuelp0815:
>
> Hi Mich und Rudi!
>
> In der von Mitch selbst angegebenen ELV Quelle steht zwar im Text immer
> etwas von FHT80 TF aber die Bilder zeigen eindeutig einen FHT80 TFK!
> Der FHT80 TFK hat halt im Gegensatz zu TF 2 Kanäle, lässt sich aber
> genauso (wie in der BA) am FHT80b anmelden.
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hi Torsten,
ich hab das ganze jetzt erstmal übergangsweise so gelöst:
#define FlurUntenChecker notify Haustuer2 {\
# if ("%" eq "on") {\
# fhem ("set FHT_050a mode manual desired-temp 8.0");;\
# }\
# else {\
# if (($mday=Mon || $mday=Wed || $mday=Fre && $hour < 19 || $hour > 7)
|| ($mday=thu || §mday=thu && $hour < 19 || $hour > 14)) {\
# fhem("set FHT_050a mode auto desired-temp 21.5");;\
# }\
# else {\
# fhem("set FHT_050a mode auto desired-temp 14.0");;\
# }\
# }\
#}
Allerdings weis ich nicht genau, wie man die Wochentage abfragen kann.
Am Donnerstag, 6. September 2012 13:59:31 UTC+2 schrieb Borsti67:
>
> > Aber aus dem Bauch raus würde ich sagen, die Temperatur bleibt bis zum
> > nächsten Schaltvorgang des FHTs bei 8 Grad.
>
> So ist es, wie ich Dir aus eigener Erfahrung versichern kann. :(
>
> > Man muss also wirklich die Temp erstmal irgendwie rausholen und
> speichern,
> > dann zurück schreiben.
>
> Ich hatte gehofft, dass es einen Trick gäbe, um das zu vermeiden. :-P
> Wenn der FHT seine Statusberichte abgeliefert hat, stehen ja die
> Soll-Temperaturen und deren Zeitfenster in den diversen Readings. Mein
> Lösungsansatz wäre gewesen, die anhand dessen zu ermitteln.
> Leider geht es mir da wie Dir, das ist schon recht komplex. Anhand des
> aktuellen Wochentags und der Uhrzeit müsste man ermitteln, in welchem
> Zeitfenster der FHT sich gerade befindet, und dementsprechend die
> "desired-temp" auf "day-temp" oder "night-temp" setzen. :-/
>
> Gruß
> Torsten
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> # if (($mday=Mon || $mday=Wed || $mday=Fre && $hour < 19 || $hour > 7) ||
> ($mday=thu || §mday=thu && $hour < 19 || $hour > 14)) {\
ich glaube, da würde ich noch mehr mit Klammern arbeiten, um mit den
Auswertungs-Prioritäten sicher zu sein. ;) Ausserdem ist da mind. 1
Tippfehler ("§"). Auf diese Art funktioniert das aber grundsätzlich,
ja.
Nur setzt diese Methode voraus, dass Du diese Abfrage für jeden FHT
einzeln schreiben/prüfen musst (falls Du in anderen Räumen andere
Zeiten oder Temperaturen hast) und die im FHT gespeicherten Werte mit
Deinem Ausdruck übereinstimmen. Das ist nicht sonderlich elegant.
ich formuliere mal meine Idee in "Pseudo-Code":
$jetzt=aktuelle Zeit im Format "HH:MM"
$tag=$mday in Kleinbuchstaben gewandelt
$f1=ReadingsVal("FHT_050a",$tag . "-from1","00:00")
$f2=ReadingsVal("FHT_050a",$tag . "-from2","00:00")
$t1=ReadingsVal("FHT_050a",$tag . "-to1","24:00")
$t2=ReadingsVal("FHT_050a",$tag . "-to2","24:00")
if(($jetzt ge $f1 && $jetzt le $t1) || ($jetzt ge $f2 && $jetzt ge $t2)) {
fhem("set FHT_050a mode auto desired-temp ".
ReadingsVal("FHT_050a","day-temp","21.5"))
} else {
fhem("set FHT_050a mode auto desired-temp ".
ReadingsVal("FHT_050a","night-temp","14.0"))
}
vielleicht kann das ja einer vervollständigen...?
Gruß
Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> || ($mday=thu || §mday=thu && $hour < 19 || $hour > 14)) {\
Das ist falsch. Richtig ist $mday eq "thu" || ...
= ist Zuweisung
== ist Zahlenvergleich
eq ist Stringvergleich
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Danke, Du hast natürlich Recht Rudi.
Hab das einfach mal so runter geschrieben.
Am Donnerstag, 6. September 2012 16:12:10 UTC+2 schrieb Rudolf Koenig:
>
> > || ($mday=thu || �mday=thu && $hour < 19 || $hour > 14)) {\
>
> Das ist falsch. Richtig ist $mday eq "thu" || ...
> = ist Zuweisung
> == ist Zahlenvergleich
> eq ist Stringvergleich
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
sodele, habe doch noch ein paar Stündchen Zeit gehabt...
Hier also nun eine Funktion (idealerweise in 99_MyUtils.pm packen),
die FHEM einen FHT (als Parameter zu übergeben) zurücksetzen lässt auf
die Temperatur, die gemäß Tag/Nacht-Modus eingestellt sein sollte.
Wenn man das noch eleganter machen kann, immer her damit. Falls jemand
mit WIKI-Zugriff das dort einstellen mag, bitte gern.
Die Werte 21.0 und 17.0 sind übrigens die Standard-Werte, die bei den
FHTs im Auslieferzustand gesetzt sind. Die nutze ich hier, falls die
Reports noch nicht gelaufen sind bzw. die Werte aus anderen Gründen
nicht da sind. Natürlich kann man da andere vorbelegen... Bei den
von/bis-Werten gehe ich auch sicherheitshalber davon aus, dass man es
im Zweifelsfall lieber warm hat. *grins* Aber wie gesagt, nicht
irritieren lassen, diese Zahlen greifen ja nur, wenn man vom FHT kein
Reading bekommt!
sub FHTnominal($) {
# Solltemperatur (auto) eines FHT zur aktuellen Uhrzeit ermitteln
my($fht) = @_;
my $jetzt = strftime("%R", localtime(time));
my @wdays = qw(sun mon tue wed thu fri sat);
my $tag = $wdays[strftime("%w", localtime(time))];
my $f1 = ReadingsVal($fht,$tag . "-from1","00:00");
my $f2 = ReadingsVal($fht,$tag . "-from2","00:00");
my $t1 = ReadingsVal($fht,$tag . "-to1","24:00");
my $t2 = ReadingsVal($fht,$tag . "-to2","24:00");
if(($jetzt ge $f1 && $jetzt le $t1) || ($jetzt ge $f2 && $jetzt le $t2)) {
fhem("set $fht mode auto desired-temp " .
ReadingsVal($fht,"day-temp","21.0"))
} else {
fhem("set $fht mode auto desired-temp " .
ReadingsVal($fht,"night-temp","17.0"))
}
}
@Mitch: Du müßtest die Funktion also aufrufen mit
FHTnominal("FHT_050a");
Gruß,
Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hi Torsten,
hab jetzt nochmal eine Frage dazu:
mit FHTnominal("FHT_050a");
rufe ich die Werte ab und wie schreibe ich sie zurück?
Am Freitag, 7. September 2012 11:07:52 UTC+2 schrieb Mitch:
>
> Hi Torsten,
>
> das sieht doch schonmal sehr gut aus, vielen Dank.
>
> Werde mir das mal am WE genauer anschauen und testen.
>
>
> Am Donnerstag, 6. September 2012 22:52:26 UTC+2 schrieb Borsti67:
>>
>> sodele, habe doch noch ein paar Stündchen Zeit gehabt...
>>
>> Hier also nun eine Funktion (idealerweise in 99_MyUtils.pm packen),
>> die FHEM einen FHT (als Parameter zu übergeben) zurücksetzen lässt auf
>> die Temperatur, die gemäß Tag/Nacht-Modus eingestellt sein sollte.
>> Wenn man das noch eleganter machen kann, immer her damit. Falls jemand
>> mit WIKI-Zugriff das dort einstellen mag, bitte gern.
>>
>> Die Werte 21.0 und 17.0 sind übrigens die Standard-Werte, die bei den
>> FHTs im Auslieferzustand gesetzt sind. Die nutze ich hier, falls die
>> Reports noch nicht gelaufen sind bzw. die Werte aus anderen Gründen
>> nicht da sind. Natürlich kann man da andere vorbelegen... Bei den
>> von/bis-Werten gehe ich auch sicherheitshalber davon aus, dass man es
>> im Zweifelsfall lieber warm hat. *grins* Aber wie gesagt, nicht
>> irritieren lassen, diese Zahlen greifen ja nur, wenn man vom FHT kein
>> Reading bekommt!
>>
>>
>> sub FHTnominal($) {
>> # Solltemperatur (auto) eines FHT zur aktuellen Uhrzeit ermitteln
>> my($fht) = @_;
>> my $jetzt = strftime("%R", localtime(time));
>> my @wdays = qw(sun mon tue wed thu fri sat);
>> my $tag = $wdays[strftime("%w", localtime(time))];
>> my $f1 = ReadingsVal($fht,$tag . "-from1","00:00");
>> my $f2 = ReadingsVal($fht,$tag . "-from2","00:00");
>> my $t1 = ReadingsVal($fht,$tag . "-to1","24:00");
>> my $t2 = ReadingsVal($fht,$tag . "-to2","24:00");
>>
>> if(($jetzt ge $f1 && $jetzt le $t1) || ($jetzt ge $f2 && $jetzt le
>> $t2)) {
>> fhem("set $fht mode auto desired-temp " .
>> ReadingsVal($fht,"day-temp","21.0"))
>> } else {
>> fhem("set $fht mode auto desired-temp " .
>> ReadingsVal($fht,"night-temp","17.0"))
>> }
>> }
>>
>> @Mitch: Du müßtest die Funktion also aufrufen mit
>>
>> FHTnominal("FHT_050a");
>>
>> Gruß,
>> Torsten
>>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Mitch,
> mit FHTnominal("FHT_050a");
> rufe ich die Werte ab und wie schreibe ich sie zurück?
Was meinst Du mit "abrufen"?
Mit diesem Aufruf wird Dein FHT_050a auf Betriebsart "AUTO"
eingestellt und die Temperatur auf den aktuellen Sollwert.
Die Werte holt die Funktion aus den letzten Readings, Du solltest also
mindestens ein Mal die "report"-Funktion benutzt haben, damit die
überhaupt vorhanden sind...
Eingabefenster von FHEM --> set FHT_050a report1 report2
(das dauert ziemlich lange, bis alle vom FHT gemeldet sind!)
Die Sollwerte programmierst Du entweder auf dem gleichen Weg, z.B.
"set FHT_050a night-temp 8.0" oder direkt am Gerät. Achtung: In
letzterem Fall musst Du danach auch den Report wieder abrufen, solche
Änderungen sendet der FHT m.W. nicht automatisch!
Gruß
Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ah jetzt. Danke.
Ich habs verstanden.
Am Dienstag, 11. September 2012 16:18:01 UTC+2 schrieb Borsti67:
>
> Hallo Mitch,
>
> > mit FHTnominal("FHT_050a");
> > rufe ich die Werte ab und wie schreibe ich sie zurück?
>
> Was meinst Du mit "abrufen"?
>
> Mit diesem Aufruf wird Dein FHT_050a auf Betriebsart "AUTO"
> eingestellt und die Temperatur auf den aktuellen Sollwert.
>
> Die Werte holt die Funktion aus den letzten Readings, Du solltest also
> mindestens ein Mal die "report"-Funktion benutzt haben, damit die
> überhaupt vorhanden sind...
> Eingabefenster von FHEM --> set FHT_050a report1 report2
> (das dauert ziemlich lange, bis alle vom FHT gemeldet sind!)
>
> Die Sollwerte programmierst Du entweder auf dem gleichen Weg, z.B.
> "set FHT_050a night-temp 8.0" oder direkt am Gerät. Achtung: In
> letzterem Fall musst Du danach auch den Report wieder abrufen, solche
> Änderungen sendet der FHT m.W. nicht automatisch!
>
> Gruß
> Torsten
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Das wäre jetzt mein Script dazu:
*define FlurUntenChecker notify Haustuer2 {\
if ("%" eq "on") {\
fhem ("set FHT_050a mode manual desired-temp 8.0");;\
}\
else {\
FHTnominal("FHT_050a");;\
}\
}*
Am Dienstag, 11. September 2012 16:56:14 UTC+2 schrieb Mitch:
>
> Ah jetzt. Danke.
> Ich habs verstanden.
>
>
> Am Dienstag, 11. September 2012 16:18:01 UTC+2 schrieb Borsti67:
>>
>> Hallo Mitch,
>>
>> > mit FHTnominal("FHT_050a");
>> > rufe ich die Werte ab und wie schreibe ich sie zurück?
>>
>> Was meinst Du mit "abrufen"?
>>
>> Mit diesem Aufruf wird Dein FHT_050a auf Betriebsart "AUTO"
>> eingestellt und die Temperatur auf den aktuellen Sollwert.
>>
>> Die Werte holt die Funktion aus den letzten Readings, Du solltest also
>> mindestens ein Mal die "report"-Funktion benutzt haben, damit die
>> überhaupt vorhanden sind...
>> Eingabefenster von FHEM --> set FHT_050a report1 report2
>> (das dauert ziemlich lange, bis alle vom FHT gemeldet sind!)
>>
>> Die Sollwerte programmierst Du entweder auf dem gleichen Weg, z.B.
>> "set FHT_050a night-temp 8.0" oder direkt am Gerät. Achtung: In
>> letzterem Fall musst Du danach auch den Report wieder abrufen, solche
>> Änderungen sendet der FHT m.W. nicht automatisch!
>>
>> Gruß
>> Torsten
>>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
dann bin ich ja mal gespannt, ob es wie geplant funktioniert?! :)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
so, hat etwas länger gedauert, aber ich kam endlich zum testen.
Ja, es funktioniert!!
Vielen Dank.
Am Dienstag, 11. September 2012 22:03:04 UTC+2 schrieb Borsti67:
>
> dann bin ich ja mal gespannt, ob es wie geplant funktioniert?! :)
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Schön, das freut mich. :)
Trotzdem habe ich am WE darüber gegrübelt, ob man nicht doch irgendwie
mittels FHEM einen FHTTK "emulieren" könnte?
Je länger ich darüber nachdenke, um so nützlicher kommt mir das vor:
- man könnte normale FS20-TFK nutzen und per notify (auch) die Heizung schalten
- über ein "simuliertes" offenes Fenster könnte man bei Abwesenheit
die Heizung runterregeln, ohne groß programmieren zu müssen
?
Gruß
Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Trotzdem habe ich am WE darüber gegruebelt, ob man nicht doch irgendwie
> mittels FHEM einen FHTTK "emulieren" koennte?
Doch, ein Prototyp muesste sogar ohne Modul-Schreiben klappen. Folgendes ist
aus der Theorie, und ohne je ein FHTTK gesehen zu haben :)
- culfw kann fhttk "simulieren", indem man ein THHHHHHXX Befehl absendet,
HHHHHH ist Adresse, XX ist Kommando, eine Liste der Kommandos ist in
09_CUL_FHTTK.pm
- die FHTTK's muessen direkt nach dem Actuator Meldung der FHT80b sich melden
(?), das kann man im Prototyp per notify realisieren, der ein "set CUL raw
THHHHHHXX" aussendet.
- Das Anlernen von FHEM als TFK an das FHT80b wird zunaechst mit einem in fhem
direkt ausgeloesten "set CUL raw THHHHHHXX" geloest.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Rudi,
> Doch, ein Prototyp muesste sogar ohne Modul-Schreiben klappen. Folgendes ist
> aus der Theorie, und ohne je ein FHTTK gesehen zu haben :)
habe mir diese Mail mal auf Halde gelegt. Ich glaube, das werde ich
mal ausprobieren müssen. :D
> - die FHTTK's muessen direkt nach dem Actuator Meldung der FHT80b sich melden
> (?), das kann man im Prototyp per notify realisieren, der ein "set CUL raw
> THHHHHHXX" aussendet.
das war/ist eigentlich meine Hauptsorge, das korrekte Timing. Damit
könnte man auf jeden Fall mal starten.
Möglicherweise kriege ich ja wirklich was hin, was die Ursprungsfrage
lösen würde...
Eine Frage noch, sollte man dieses Device dann zweckmäßigerweise als
"Dummy" anlegen, oder als einen FHTTK? Letzteres hätte den Vorteil,
dass man ihn quasi jederzeit durch einen echten ersetzen könnte. ;)
Gruß
Torsten
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Eine Frage noch, sollte man dieses Device dann zweckmaessigerweise als
> "Dummy" anlegen, oder als einen FHTTK?
Eigentlich ist das nur ein Notify, der koennte aber seine Parameter von
einem dummy holen, damit man sie im Frontend einfacher einstellen kann.
> Letzteres haette den Vorteil, dass man ihn quasi jederzeit durch einen echten
> ersetzen koennte. ;)
Ein Ersatz durch einen echten bedingt eine Abschaltung dieser "notify",
insofern sehe ich keine Ueberschneidung. Selbst wenn Du das "richtig" als Modul
implementierst, wuerde der Code wenig mit dem "CUL_FHTTK.pm" teilen: das alte
ist read-only, dieser waere write-only.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
nö, ein Modul hatte ich nicht vor. Ich dachte erst einmal an ein paar
Routinen für die 99_MyUtils.pm, damit man die nötigen Funktionen
global zur Verfügung hat - aber das ist alles noch unausgegoren...
Am 25. September 2012 12:11 schrieb Rudolf Koenig :
>> Eine Frage noch, sollte man dieses Device dann zweckmaessigerweise als
>> "Dummy" anlegen, oder als einen FHTTK?
>
> Eigentlich ist das nur ein Notify, der koennte aber seine Parameter von
> einem dummy holen, damit man sie im Frontend einfacher einstellen kann.
>
>> Letzteres haette den Vorteil, dass man ihn quasi jederzeit durch einen echten
>> ersetzen koennte. ;)
>
> Ein Ersatz durch einen echten bedingt eine Abschaltung dieser "notify",
> insofern sehe ich keine Ueberschneidung. Selbst wenn Du das "richtig" als Modul
> implementierst, wuerde der Code wenig mit dem "CUL_FHTTK.pm" teilen: das alte
> ist read-only, dieser waere write-only.
>
> --
> 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
Hallo,
seit einem Update gestern, habe ich leider eine für mich nicht klärbare
Fehlermeldung im Log:
2012.10.01 07:54:41 2: FS20 Haustuer1 on
2012.10.01 07:54:42 2: FS20 Haustuer2 on
2012.10.01 07:54:42 2: FHT set FHT_050a mode manual desired-temp 8.0
Use of uninitialized value $altit in uc at /usr/share/fhem/FHEM/99_SUNRISE_EL.pm line 61.
Use of uninitialized value $altit in pattern match (m//) at /usr/share/fhem/FHEM/99_SUNRISE_EL.pm line 64.
Can't ignore signal CHLD, forcing to default.
2012.10.01 07:54:43 3: Haustuer2: Haustuer on, Nachricht gesendet via eMail
2012.10.01 07:55:08 2: FS20 Haustuer1 off
2012.10.01 07:55:08 2: FS20 Haustuer2 off
2012.10.01 07:55:08 2: FHT set FHT_050a mode auto desired-temp 21.0
Can't ignore signal CHLD, forcing to default.
Eine Idee?
Am Dienstag, 25. September 2012 13:52:29 UTC+2 schrieb Borsti67:
>
> nö, ein Modul hatte ich nicht vor. Ich dachte erst einmal an ein paar
> Routinen für die 99_MyUtils.pm, damit man die nötigen Funktionen
> global zur Verfügung hat - aber das ist alles noch unausgegoren...
>
> Am 25. September 2012 12:11 schrieb Rudolf Koenig >:
>
> >> Eine Frage noch, sollte man dieses Device dann zweckmaessigerweise als
> >> "Dummy" anlegen, oder als einen FHTTK?
> >
> > Eigentlich ist das nur ein Notify, der koennte aber seine Parameter von
> > einem dummy holen, damit man sie im Frontend einfacher einstellen kann.
> >
> >> Letzteres haette den Vorteil, dass man ihn quasi jederzeit durch einen
> echten
> >> ersetzen koennte. ;)
> >
> > Ein Ersatz durch einen echten bedingt eine Abschaltung dieser "notify",
> > insofern sehe ich keine Ueberschneidung. Selbst wenn Du das "richtig"
> als Modul
> > implementierst, wuerde der Code wenig mit dem "CUL_FHTTK.pm" teilen: das
> alte
> > ist read-only, dieser waere write-only.
> >
> > --
> > To unsubscribe from this group, send email to
> > fhem-users+...@googlegroups.com
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Eine Idee?
Ja, bitte Arno Fragen, bzw. den Aufruf von der Sunrise Funktion gegen
http://fhem.de/commandref.html#SUNRISE_EL pruefen.
Die Aenderung von Arno _sollte_ Rueckwaertkompatibel sein.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hi Torsten,
das sieht doch schonmal sehr gut aus, vielen Dank.
Werde mir das mal am WE genauer anschauen und testen.
Am Donnerstag, 6. September 2012 22:52:26 UTC+2 schrieb Borsti67:
>
> sodele, habe doch noch ein paar Stündchen Zeit gehabt...
>
> Hier also nun eine Funktion (idealerweise in 99_MyUtils.pm packen),
> die FHEM einen FHT (als Parameter zu übergeben) zurücksetzen lässt auf
> die Temperatur, die gemäß Tag/Nacht-Modus eingestellt sein sollte.
> Wenn man das noch eleganter machen kann, immer her damit. Falls jemand
> mit WIKI-Zugriff das dort einstellen mag, bitte gern.
>
> Die Werte 21.0 und 17.0 sind übrigens die Standard-Werte, die bei den
> FHTs im Auslieferzustand gesetzt sind. Die nutze ich hier, falls die
> Reports noch nicht gelaufen sind bzw. die Werte aus anderen Gründen
> nicht da sind. Natürlich kann man da andere vorbelegen... Bei den
> von/bis-Werten gehe ich auch sicherheitshalber davon aus, dass man es
> im Zweifelsfall lieber warm hat. *grins* Aber wie gesagt, nicht
> irritieren lassen, diese Zahlen greifen ja nur, wenn man vom FHT kein
> Reading bekommt!
>
>
> sub FHTnominal($) {
> # Solltemperatur (auto) eines FHT zur aktuellen Uhrzeit ermitteln
> my($fht) = @_;
> my $jetzt = strftime("%R", localtime(time));
> my @wdays = qw(sun mon tue wed thu fri sat);
> my $tag = $wdays[strftime("%w", localtime(time))];
> my $f1 = ReadingsVal($fht,$tag . "-from1","00:00");
> my $f2 = ReadingsVal($fht,$tag . "-from2","00:00");
> my $t1 = ReadingsVal($fht,$tag . "-to1","24:00");
> my $t2 = ReadingsVal($fht,$tag . "-to2","24:00");
>
> if(($jetzt ge $f1 && $jetzt le $t1) || ($jetzt ge $f2 && $jetzt le $t2))
> {
> fhem("set $fht mode auto desired-temp " .
> ReadingsVal($fht,"day-temp","21.0"))
> } else {
> fhem("set $fht mode auto desired-temp " .
> ReadingsVal($fht,"night-temp","17.0"))
> }
> }
>
> @Mitch: Du müßtest die Funktion also aufrufen mit
>
> FHTnominal("FHT_050a");
>
> Gruß,
> Torsten
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Rudi,
ich versuche schon eine ganze Weile (2 Tage) meinen FHT80TF zu emulieren,
da ich einen FS20TFK einsetze.
Leider scheitert es schon beim Aussenden des Raw-Befehls "set cul raw
T2ac44902".
Dieser bleibt im FHT-Buffer hängen und wird nie gesendet.
Auch mit einer perlFn habe ich die Raw-Befehle:
set cul raw T2ac44902; # 1 Meldung
#delay 0.5 sec
set cul raw T2ac44982; # 2 Meldung
ebgesetzt. Nada :-(
Der Versuch mit zusätzlicher Quersumme
set cul raw T2ac4490245; # 1 Meldung
#delay 0.5 sec
set cul raw T2ac44982c5; # 2 Meldung
klappt auch nicht.
get cul raw T02:
CUL_0 raw => 2AC4:4902 2AC4:4982 2AC4:4902,45 2AC4:4982,C5
Da es auch direkt mit Putty nicht klappt, vermute ich, dass hier die culfw
verweigert.
Irgendwie hängt es mit der Adresse 2ac4 (mein fht80tf) zusammen.
set cul raw T12344902 geht raus!
Ich weiß nicht weiter!
Hat jemand einen Tipp?
LG, Werner
On Tuesday, September 25, 2012 8:38:44 AM UTC+2, Rudolf Koenig wrote:
>
> > Trotzdem habe ich am WE dar�ber gegruebelt, ob man nicht doch
> irgendwie
> > mittels FHEM einen FHTTK "emulieren" koennte?
>
> Doch, ein Prototyp muesste sogar ohne Modul-Schreiben klappen. Folgendes
> ist
> aus der Theorie, und ohne je ein FHTTK gesehen zu haben :)
>
> - culfw kann fhttk "simulieren", indem man ein THHHHHHXX Befehl absendet,
> HHHHHH ist Adresse, XX ist Kommando, eine Liste der Kommandos ist in
> 09_CUL_FHTTK.pm
>
> - die FHTTK's muessen direkt nach dem Actuator Meldung der FHT80b sich
> melden
> (?), das kann man im Prototyp per notify realisieren, der ein "set CUL
> raw
> THHHHHHXX" aussendet.
>
> - Das Anlernen von FHEM als TFK an das FHT80b wird zunaechst mit einem in
> fhem
> direkt ausgeloesten "set CUL raw THHHHHHXX" geloest.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Irgendwie haengt es mit der Adresse 2ac4 (mein fht80tf) zusammen.
> set cul raw T12344902 geht raus!
Ich meine mich daran zu erinnern, dass culfw alles, was nicht seinem eigenen ID
(T01) entspricht, puffert, und wartet dabei auf die Nachrichten der FHT80b.
Die anderen Pakete interpretiert er als welche fuer den FHT8V, von diesen
werden die Stellbefehle gespeichert (und zeitverzoegert regelmaessig
ausgegeben), die anderen sofort ausgesendet.
Falls Du damit kein TF "emuliert" bekommst, dann muss culfw geaendert werden.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com