Hallo,
ich vesuche das sFHTs Script von einem anderen script aus zu trigger. Das Script wird auch gestartet, nur werden leider keine Werte an die FHTs geschickt. Muß ich irgendwelche Daten übergeben? Im Timerscript wird das anscheinend noch gemacht.
Wenn ich das Script im Editor von Hand starte funktioniert alles super.
Wäre schön, wenn mir jemand helfen könnte. 
Gruß
Klaus
Hallo Klaus,
ich glaube mich zu erinnern, dass das manuelle starten nur im Debug Modus geht.
Gruss Torro
ich geh mal davon aus, Du meinst nicht den Debugmodus vom FHT Script.
Hallo,
doch, genau den meine ich. Aber wie gesagt, ist nur so eine Erinnerung…genau kann es Dir nur GGGss sagen.
Gruss Torro
Hallo,
es kann mehrere Gründe für dieses Verhalten geben.
Vom Script wird der Auslöser abgefragt.
Beispiel:
if ($IPS_SENDER == "Designer"){...}
hier „Designer“.
Daher solltest Du erstmal genau erklären, wie das Script gestartet werden soll.
Am einfachsten schreibst Du mal ein Echo an den Anfang, welches den Auslöser angibt. Etwa so:
ECHO ("Trigger: " $IPS_SENDER);
Denn je nach Sender gibt es unterschiedliche Verhaltensweisen. Außerdem gibt es noch die „Flank-Detection“ >> sende nur, wenn eine Änderung anliegt
Gruß
Fabian
Hallo Klaus,
auf welche Weise triggerst Du das Skript?
Es gibt da ja einige Möglichkeiten: Variablen, IPS_RunScript(…), include, …
Solange wir das nicht wissen, ist es sehr schwer zu helfen.
Gruß
HJH
Ich setze z.B. die Variable __iamhome und triggere dann das Script mit IPS_runscript(„sFHTs“).
Ich möchte nicht 30 Minuten warten bis die Heizung anspricht.
@ Prof:
Bin leider zur Zeit auf der Arbeit. Da kann ich leider nichts ausprobieren. (Leider 
arme (sabbel)sau 
Hallo Klaus,
ich kannte das sFHTs-Skript nicht und habe es mir gerade eben das erste mal angesehen. Ich kann also im Augenblick nicht gerade behaupten, dass ich es vollständig verstanden habe.
Aber eins kann ich bereits jetzt sagen:
Du willst die 30min-Wartezeit nicht abwarten und versuchst daher eine schnelle Reaktion dadurch herbeizuführen, dass Du es durch IPS_RunScript(…) quasi „von Hand“ aufrufst.
Der Normalfall wäre der Trigger über die Globale Variable „__imhome“. Da Du diese Variable geändert hast, wird das Skript folglich auch dadurch getriggert. Zusätzlich startest Du das Skript ein zweites Mal über IPS_RunScript(…).
Diese beiden Skriptaufrufe erzeugen verschiedene Inhalte der System-Variablen $IPS_SENDER, nämlich zuerst „Variable“ und dann „RunScript“. Wie auch schon Fabian (prof) ganz richtig angedeutet hat, macht das Skript exzessiven Gebrauch von $IPS_SENDER-Abfragen. Es ist also nicht verwunderlich, wenn das Skript auf jeden der beiden Aufrufe völlig anders reagiert.
Mit anderen Worten: Du wirst ohne zusätzliche Maßnahmen das Skript nicht so ohne weiteres austricksen können. Falls Du das vorhast, setzt das eine tiefe Kenntnis der Funktionsweise voraus.
Gruß
HJH
Hallo HJH,
bei den Variablen habe ich keinen Trigger angegeben. Die sollten das Script also nicht anstoßen.
Wenn ich es von Hand anstoße läuft es.
Wenn ich das Script richtig verstanden habe wird bei IPS_Sender „Variable“ teilweise nichts gemacht und bei IPS_Sender „Designer“ grundsätzlich nicht.
Wenn ich das Script aus einem anderen Script aufrufe dürften diese Beiden doch nicht auftreten.
Gruß
Klaus
Nachtrag: Vielleicht ist die Lösung den Trigger auf die Variablen zu legen. Werd ich heute Abend mal ausprobieren.
Hi,
ich habe gestern Abend den Trigger auf die Variablen gelegt.
Das funktioniert so weit auch, nur wenn ich wieder in den „Normalbetrieb“ wechsle werden die Temperaturen nicht zurückgesetzt.
Erst beim nächsten Temperaturwechsel in der temp.ini wird die Solltemperatur geändert. 
Gruß
Klaus
Was meinst Du mit „Normalbetrieb“? Die Umschaltung von z.B. imhome auf default…
Die Funktionsweise der Flank-Detection vermeidet unnötiges Senden zum FHT.
Wenn Du also z.B. vom imhome in default zurückschaltest, wird zur nächsten Sendezeit geprüft, ob eine Temp-Änderung vorliegt und erst dann wird gesendet.
Diese Eigenschaft habe ich etwas modifiziert. Bei mir vergleiche ich die Soll- mit der State-Temp. Bei Unterschied wird gesendet.
Dann gehören am Abend aufgedrehte Heizungen, welche über Nacht vergessen werden, der Vergangenheit an.
(mit Kindern muss man sich eben immer was einfallen lassen :D)
Grund für die verzögerte Reaktion auf die Var-Trigger:
Es ist ja ohne weiteres möglich, mehrfach zwischen den „Zuständen“ hin- und herzuschalten. bei jedem Schalten würde (bei sofortiger Übertragung) nun ein Befehl an den FHT rausgehen. Das endet im Chaos, glaube mir!
Grüße
Fabian
PS: mich wunderts, dass unser belgischer Nachbar nix sagt :rolleyes: (Urlaub?)
Ja, ich meine die Umschaltung auf default.
Die Funktion am Rad eine andere Temperatur einschalten zu können möchte ich unbedingt erhalten, die nutze ich oft.
Die Raumtemperatur ist am unteren Limit eingestellt, wenn ich es wärmer haben will drehe ich hoch. (Spart noch mal
Das ständige Umschalten hab ich verhindert in dem ich die entsprechenden Buttons nach dem Betätigen für 3 Minuten sperre.
Wenn ich verhindere, dass direkt von __iamhome auf __imaway umgeschaltet werden kann, könnte ich doch die Abfrage der Variablen rausnehmen?
Gruß
Klaus
Wenn ich verhindere, dass direkt von __iamhome auf __imaway umgeschaltet werden kann, könnte ich doch die Abfrage der Variablen rausnehmen?
nicht ganz.
Die Abfrage unterscheidet ja auch zwischen Status- und Temp-Variablen…
Hallo,
Da war ich tatsächlich 3 wochen im irlaub ohne Inet…
Das direkt vom _Imhome auf _Imaway schalten ist nicht so ganz vorsehen im script. Bei dem standard-mässigen install sollten diese beide (und _party) das script triggeren. Das script merkt sich diese änderung und holt sich direkt die neue soll-werte aus das .ini.
Gibt es bei dir 30 minuten verzögerung dann wird das script nicht durch diese variablen getriggert. (Alle achtung das du das beobachachted hasst :eek: = 30 miuten warten: „was macht er jetzt?“)
Grundsetzlich sind die variablen gedacht um aus-sonderliche situationen klären zu können. (du nimmst dir ein schnupper-tag aber solltest normal-gesehen in die Arbeit = Iamhome); ergo am sonntag zu die Eltern = IamAway
Alle andere situationen sollten durch das default verhalten geklärt werden können.
Dein switchen von iamhome zu iamaway hies in die logik des programms: „Ich sollte auf die arbeit - nimm mir aber ein snuppertag - der boss ruft dann an und ich muss 2 Tage ins ausland“ -> gegnugend verständlich??
das extern triggeren uber call() oder exec… hat kein sinn, weil beim setzen die variablen iamhome, iamaway und party sollte das script getriggerd werden laut wiki-installation. Was du machen möchtest uberflutet nur den FHZ-buffer mit möglicherweise den gefolg das die laetzte soll-temp nie mals ankommt.
Wenn die speciale variable zuruck gesetz werden sollte das script die default werte senden.
Hoffe alles ist geklärt… bei ruckfragen einfach antworten
Grusse aus Belgien,
Fredje
Hallo Fredje,
ich hoffe Du hattest einen schönen Urlaub
Ich benutze die Variablen weil wir sehr unregelmässige Arbeitszeiten haben.
Mal einen halben Tag arbeiten, mal einen ganzen und auch mal frei.
Wenn ich von __imhome auf „normal“ (keine Variable gesetzt) zurück geschaltet habe wurden nur die Werte zurück gesetzt, die sich in der Zwischenzeit geändert haben.
Ich habe die Buttons im Script so verriegelt, dass die FHTs nicht überflutet werden. Es kann immer nur einer betätigt sein und nach jedem Schalten wird für drei Minuten alles geblockt.
Gruß
Klaus