Hallo Ich hab da mal ne Grundsatzfrage?
Hab einen Script über den Event Change Variable am aktivieren.
Im Script selber ist Sleepevent. Was passiert den wenn während dieser
Wartezeit die Variable erneut ändert???
Startet dieses Script als separate Routine und ist dei erste noch fleissig am abarbeiten, oder wird das erste Script damit gestoppt, weil es von forne startet??
Ach ja noch mit den Flanken:
Kann man evtl. auch beeinflussen, dass die Triggerung bei einer Aufsteigende bzw. Abfallende Flanke stattfindet??
Würd mich über einen Tipp sehr freuen. Lese natürlich gerade die Handbücher
und Forumbeiträge fleissig weiter hoch und runter.
Da wird das script neu gefeuert in multitasking und lauft auch bis zu die sleep() und wartet seine zeit. Dies kann maximal bis 10x geschiehen.
Wan das nicht der erwartete antwort war : IPS_SEMAPHORE
Flanken detektieren tut eine onchange nicht -> da brauchst du selber die vorherige situtiation bei zu behalten und selber vorheriger und aktueller wert ab zu gleichen. Obwohl… false -> false ist keine flanke, false zu true = / flanke. Hey WIeso brauchst du diese? bei / flanke ist der end wert true, ergo „ich habe eine / flanke bekommen“.
Umgekehrt : true -> true keine flanke, true -> false = \ flanke, wert ist false und dabei „ich habe eine \ flanke bekommen“.
Macht kein sinn flanken zu detektieren ODER dein puls ist zu kurz, aber da lauft IPS schon mal 2x das script ab vonwegen multitasking. Lösung : semaphore
Script wird durch onUpdate oder Onchange getriggert,
im Script selber wird Variable aber geändert (z.B. leer gemacht)
Beispiele für Variable --> „“:
Passworteingaben und deren Verarbeitung
RegisterVariable: reg2var-binär-Input-Variable nach Verarbeitung leer machen, damit der binäre Inhalt dieser Roh-Variable nicht in settings.xml gespeichert wird, sonst gibt es Fehler beim nächsten IPS-Start: settings wird nicht komplett eingelesen wegen Xml-Interpreter-Fehler.
Nur die Variable leer machen im Shutdown-Event-Handler allein reicht da nicht, da das nur wirkt bei sauberem IPS-Shutdown. Aber settings.xml ist trotzdem jedes mal korrupt, wenn IPS zum Beispiel nach Programmierfehler mal gekillt werden muß oder ähnliches.
…das nur mal so als zwei Ideen, wo ich schon selber mir „Flanken“-Erkennung (hier auch: Stringlänge > 0?) gewünscht habe.
Das ist aber auch bei Boolean oft so, z.B. Alarmverarbeitung: Flag für neuer Status --> Status ist verarbeitet worden --> zurücksetzen (Aber: Onchange triggert die Verarbeitungs-Scripts?)
Aber bei Boolean hilft da OnValue (=true), das IST Flankenerkennung
Hi Toni,
ich stimme Dir voll zu bis auf eine Ausnahme:
OnValue bei Strings:
Wenn ein eingetragener (aber inhaltlich eben vorab nicht bekannter Wert) das Script triggern soll, aber das „leermachen“ (String="") eben nicht…
Dann ist ja gerade der für „OnValue“ notwendige „Value“ nicht bekannt.
…da fehlt irgendwie was wie „String nicht leer“. Im Moment helfe ich mir innerhalb der Scripts und überprüfe das dort. Aber dafür muß das Script trotzdem starten, was bei Semaphoren-Verriegelungen wiederrum etwas diffiziel ist, zumindest wenn das Script selber seine Triggervariable wieder leerräumt (Ursachenprinzip: Das Script selber „weiß am Besten“, wann es das nicht mehr braucht)… usw
Da kommt es in Folge schnell mal zu Dauerblockaden oder Endlosschleifen, wenn man nicht genau aufpasst. Gar nicht erst triggern wenn der Value leer ist, wäre da viel besser. Natürlich darf das nun aber nicht generell bei „onValue“ umgestellt werden, denn auch ein Leerstring kann ja mal Triggerkriterium sein. „OnIsValue“ oder sowas schwebt mir da vor, quasi als „String-Flankenerkennung“.
Hmmm… vielleicht immer erst die String-Variable durch ein entsprechendes Script jagen, das diese per „if (strlen($a) > 0)“ checkt und eine Boolean-Variable setzt, und erst diese als Trigger nehmen? Aber dann kann man wieder nicht mehr gleichzeitig unterschiedliche String-Inhalte aus mehreren triggernden Quellen übernehmen, was z.B. beim Alarm- und Messaging-Handling recht wichtig wäre… brächte also auch nichts.
@bastelwasti: Sorry, ist etwas von ursprünglicher Frage abgewichen, aber du fragtest ja wg. „generellem Verhalten“
setLostSensor (extra Script, da zyklisch; denn wenn Sensor verloren ist, ist ja gerade nichts mehr zum Triggern da)
–> setAlert (getriggert, auch für viele andere Alarme, z.B. per onValues usw)
–> setMessage (getriggert, nicht nur aber auch die Alarme verarbeitend)
davon wieder je nach Nachrichtenklasse abgespalten
–> TTS-Auskopplung
–> eMail/SMS-Auskopplung
–> Logging / Datenbank
–> Message je nach Info-Panel auskoppeln und aufbereiten
In den ganzen Infoketten ist es schon recht günstig, wenn die jeweils beteiligten Scripts gleich immer hinter sich aufräumen. Und das dann am besten noch im gleichen Script, bevor das Semaphor wieder freigegeben wird und ein anderes Event da reinfunkt.
Hallo GGGsss,
also. Mein Urproblem ist das ich wohl noch in Basic denke und mit goto
Start ne Endlosschlaufe habe :rolleyes:.
Nun werden in meinem ersten Testscript für meine Jalosien mittels runter und Hochtaster die Jalosien entsprechend angesteuert und nach einer Einstellbaren Zeit alles wieder abgeschaltet.
Das funzzt auch.
Nur ich denke da jetzt an weitere Funktionen wie das während der Fahrt in eine Richtung durch betätigen der Taster (gleicher Richtung) ein Stop
eingelegt wird. Sprich mittels einen Impuls während des Hoch- oder Runterfahren gestoppt wird.
Oooooooder Richtungswechsel!
Ich dachte daran Wenn Taster gedrückt das Richtungsrelais entsprechend in die richtige Richtung und das Netzrelais geschaltet ist. Alle Relais abgeschaltet werden.
Nur wenn der Script getriggert ist und dieser gerade in der Sleep wartet und durch die nächste Tastenbetätigung ein zweitesmal dieser Script gestartet wird… fehlt mir inzwischen die Vorstellungskraft was passiert.
In meinem alten C-Control Basic funzzen vier Rolladen allerdings in einer Endlosschlaufe und bis auf geringe Geschwindigkeit was letzendlich die Abtastrate für die Eingänge (Zykluszeit) bedeuten.
Naja vieleicht könnt Ihr mir mal mein Horizonzt erweitern.
ähmmm… du weißt, dass es da fertige Instanzen und Befehle im IPS gibt, die sogar die Laufzeitprofile der Rolläden unterschiedlichen Durchmessers und Länge durch Anlernen berücksichtigen können?
Stichwort: fs20ms (das IPS-Device), direkt z.B. hinter ein Device „fs20tx“ geschaltet, da kannst Du das alles konfigurieren, und anschließend denkt das Teil dann für Dich.
Als Befehl gibst du ihm dann nur noch an, auf wieviel „Prozent Schließung“ die Rollade gefahren werden soll. Ob und in welche Richtung die sich dann bewegt, verwaltet das Device dann intern anhand seiner „Ist“-Daten.
Nachteil: Wenn Du mit anderen Steuerquellen wie direkte Fernbedien-Befehle oder hartverdrahtete Jalousientaster „dazwischenfunkst“, weiß IPS nix davon. Deshalb mache ich z.B. vor automatisch gesteuertem Jalousienfahren ein „Reset“ indem ich erstmal „in Ruheposition“ fahre, bevor dann die Zielposition ansteuere.
Beispiele für derartige Automatismen:
nautische Dämmerung (x Min. vor Sonnenauf- / nach -untergang) alles auf / zu
Sturm (lokale Wetterstation: Windgeschwindigkeit > x km/h)
Heizung (FHT)/Fenstersensor: Fenster länger x Min offen [bei Aussentemp < y °C]
Sonnenstand (Azimut/Sonnenwinkel) + Helligkeitssensor (Sonne scheint) + Profil je Fenster + Raumtemperatur (FHT): Jalousien als Sonnenschutz bedarfsweise „nachfahren“
Das „Reset“ muß lediglich „zeitlich entkoppelt“ werden, da es sonst schnell zum Überlauf der Funkbefehls-Queue kommen kann. Ich mache das durch einen 2 Minuten-Offset zwischen „Fahre in Endlage“ und eigentlichem Fahrbefehl. Bis auf den Alarmfall „Sturm“ (wo ohnehin alles nur zufährt = „Reset“), ist das aber zeitlich unkritisch.
Wie gesagt: Alles per „Fahre auf x %“-Befehl" = „FS20_SetPosition($id, $targetPos)“, damit ich mich nicht auch noch um „die unteren Schichten des Handlings“ kümmern muß. Das macht IPS selber.
ich glaube, das hilft Bastelwasti nicht. Er hat 1-Wire im Einsatz und ich meine, dafuer will er sich entsprechende Scripte schreiben. Da hilft der FS20MS ueberhaupt nicht, das ist ja nur die Instanz fuer die ELV Geraete.
Fuer seine selbst gebastelten Rolladenmodule muss er sich etwas eigenes einfallen lassen.
ok… Die Frage wär natürlich, ob man das IPS-Device „FS20MS“, was ja auch erst hinter dem „hardwarenäheren“ FS20TX-Device liegt, nicht einfach hinter einem entsprechenden anderen Device connecten kann, das das „1wire-TX“ macht. Sozusagen Anwendung eines Schichtenmodells und Austausch der unteren hardwarenahen Schicht…
Ich meine da die so heißenden IPS-Instanz-Devices, nicht die wirkliche Hardware!
aufgrund der auf die jeweilige Technik abgestimmten I/O Prozesse in den jeweiligen Modulen duerfte dies nicht gehen. Letzendlich kann das aber nur paresy sagen. Ich glaube, es geht nicht.
…was schade wäre, denn das hardware-unabhängige Handling der Jalousie dürfte ja eigentlich eben genau das sein: eben von der (Übertragungs-)Hardware unabhängig.
