local i = 1
repeat
i = i+1
fibaro.sleep(1000)
print("",i)
until i >= 80
Dann wird B nicht getartet so lange A noch läuft.
So weit so Gut.
Bei beiden Scenen steht „Allow to restart a running scene: ?“ auf No
Wenn ich mir jetzt aber die CPU Auslastung ansehe, so ist diese gegen 0 das verstehe ich allerdings nicht mehr.
Wenn wir ein Multitasking System hätten und die Scenen einzeln getriggert werden können und getrennt von ein ander ablaufen so kann das nicht sein.
Wenn wir kein Multitasking System haben, so ist eine CPU Auslastung von nahezu 0 nicht möglich da diese eine Scene eigendlich alle CPU Zeit schluckt.
Wenn der fibaro.sleep die Scene in den Schlafmodus versetzt und gleichzeitig alles andere auch, so könnte ich mir das erklähren aber dann würde Rechenzeit vergäuden.
Kann mir das Bitte mal einer erklären ?
Hallo @Berges01, Du hast Dir die Antwort schon selbst gegeben. Fibaro.sleep versetzt alles in den Schlafmodus. Deshalb wird schon seit der HC2- Ära von dem Befehl gewarnt. Mehr als ein paar Sekunden soll man das sleep nicht nutzen, aber manchmal geht es nicht anders und es ist ja so einfach.
Im Fibaro Forum habe ich das gleiche gefragt und da meinte einer er hätte es versucht und das währe kein Problem.
Ich denke du hast da recht, da war wie auch beim fibaro.setTimeout ein etwas liederlicher Assembler oder C-Programmierer am Werke, denn beide Befehle haben Probleme.
Der eine ist ein Schätzeisen und der andere blockiert alles.
Wie bekommt man den nun einen einiger maßen genauen Timer hin ?
Trigger kann ausgebremst werden, Sleep Blockert das „Multitasking“, Timeout wird von den Anderen Tasks ausgebremst prima Vorraussetzung.
Von Echtzeit will ich ja gar nicht reden.
Eigentlich ist das im Assembler kein Problem, Einsprungadresse auf den Steck, Timer auf wert x und auf Interrupt mit den Steckwert und raus aus der Routine und warten bis der Timer den IRQ ausgelöst hat. Na ja im Prinzip, ist schon etwas mehr aufwand.
Ist schon Mist wenn man ein System hat das völlig asynchrones Verhalten zeigt.
Das muss ich erst noch lernen das nichts so ist wie man es erwartet.
Ich habe darum schon Globale Zähler eingebaut um Timer nachzubilden und vorhersagbare Zeiten zu bekommen aber ich glaube das muss ich Extensivieren um die Beiden Befehle zu ersetzen.
Mal sehen ob sich nicht ein QA aufbauen lässt mit der Systemzeit als Timegeber.
Damit könnte man das Problem umgehen zumindest einigermaßen.
Mal etwas länger drüber nachdenken und die Befehle Sleep und Timeout noch mal analysieren und deren Verhalten besser verstehen. Jetzt weis ich wenigstens warum da bei Sleep der Hase im Pfeffer steckt.
Gruss Frank
Hi @Berges01, hab die Antwort von jgab gelesen. Eigentlich sollte es schon so tun wie er das beschreibt. Steht bei Dir in B das gleiche wie in A?. Das wäre dann ja die Situation das beide Szenen lahmgelegt sind. Er hat ein anderes Szenario zum testen benutzt.
Der Typ ist der beste Programmierer aus dem Forum. Hat mir schon oft geholfen.
Frage warum brauchst Du so einen Sekunden genauen Timer?
Ich weiß das der Trigger/Declaration Abschnitt auch nicht fehlerfrei ist und Fibaro weiß das auch.
Ich hab in meinen HC2 mittlerweile fast 50 Szenen und wenn ich alles portiert habe, werden es vermutlich nur halb so viele sein Dank ER4.
Der EventRunner4 von jgab ist echt der Hammer. So eine QA habe ich noch nie dort gesehen.
Er fängt jedes aber auch jedes Event ab und darauf kann man mit einer Regel triggern. Es geht von einfach bis kompliziert. Aber er kann so gut wie alles abdecken.
Habe das jetzt schon seit über 3 Monaten im Einsatz.
Vielleicht löst das Deine Timer Probleme.
@jeep
Guten Morgen
Nein ich brauche keinen Timer der genau ist, auch nicht auf eine Sekunde.
Aber er muss vorhersagbar sein und das ist eigentlich das was ich erreichen wollte.
Wahrscheinlich ist das aber nur dem Geschuldet das ich ein Voraussagbares System bis Dato gewöhnt bin.
Genau zu wissen was, wann, wo und warum passiert kannte ich bis Dato nur.
Ich wollte eine Scenen-Ablaufkontrolle erstellen mit der ich feststellen kann ob eine Scene abgelaufen ist oder ob die hängt, da ich durch Speicherprobleme einige Scenen hatte die nicht abgelaufen sind und einfach stehen blieben. Da ich eine Alarmanlage und Brandmeldeanlage am laufen habe oder haben werde ist das in meinen Augen unerlässlich.
So weit habe ich das schon erstellt jetzt benötige ich nur noch ein Watchdog Timer Hardwareseitig und das ding ist am laufen. (Retriggerbare Monostabiele Kippstufe)
Die Asynkronität der Scenen und Abläufe habe ich schon bis auf den Timer gut im Griff und kann genau vorhersagen was passiert. Nur bei dem Timer (wenn ich Ihn den benutze) kommt mein System ins straucheln. Darum benutze ich auch Counter anstelle von Timern, die sind Vorhersagbar und genau, weiterhin belasten diese die CPU´s nicht, haben aber den Nachteil das nichts unter einer Minute vorhersagbar ist. (Das alles ist wahrscheinlich ein Kopfproblem bei mir, darüber bin ich mir in klaren, nur muss ich den Knoten erst noch lösen und das System verstehen und es auch so benutzen)
Ein System das man nicht versteht und das vorraussagen kann, das ist nur schwer bis gar nicht nutzbar.
Den ER4 schaue ich mir mal an.
Eigentlich habe ich was den Trigger betrifft keine Probleme, der funktioniert so lange ich CPU-Power habe. Das muss ja nicht besonders schnell sein im SmartHome Bereich gibt es keinen Grund über ms zu reden, der muss nur funktionieren. Wenn der aber durch einen Sleep ausgenockt wird so ist das schon ein Problem. Damit steht und Fällt das gesamte Kartenhaus. Darum verstehe ich jetzt auch die Warnung von Fibaro vor diesem Befehl.
Vielleicht eine blöde Idee, aber was wäre wenn man diese Systemzeitzahl, jede Sekunde in eine globale Variable schreibt und dann von dort aus durch Zahlenvergleiche, die vergangene Zeitspanne extrahiert und damit dann einfach errechnete Zeitwerte für die Auslösung verschiedener Events verwendet ?
Beispiel: wenn die Zahl nach dem 2. Auslösen um 10 größer ist, dann sind 10 Sekunden vergangen und eine SZene löst deshalb aus…
Hab ich das verständlich formuliert !?
Ja das hatte ich mir auch schon überlegt.
Es ist so das ein Sleep den kompletten HC3 blockert, der Timeout von
jeglicher CPU-Last unterbrochen wird.
Somit ist es egal was man macht das wird alles nichts senkrechtes.
Ein Programmblock oder ein QA mit Globaler Variabel ist genau so anfällig für die CPU-Last wie auch alles andere.
Ich bin glaube ich zu verwöhnt und ein zu Pedantisch und muss mich umstellen und die Software so aufbauen das es egal ist ob mir etwas dazwischen funkt.
Jetzt baue ich mir erst mal einen Hardware WatschDog deamit ich wenigstens merke wenn was klemmt.
Gruss Frank
Hallo @jeep,
Heisst das, dass ich auf der HC2 und der HC3 während EINE Szene 20 Sekunden Sleep abarbeitet KEINE ANDERE Szene laufen kann, oder hab ich das falsch verstanden??
@pblacky
Das mit dem Sleep und dem Timeout scheint eine heikle Sache zu sein.
In anderen Foren habe ich da auch schon Fragen gestellt und selbst du Gurus haben sich da bedeckt gehalten und haben versucht mich ruhig zu stellen (Bildlich gesprochen).
Dann habe ich aufgehöhrt zu fragen. Entweder fand man meine Fragen zu Blöd oder man wollte keine schlafenden Hunde wecken.
Fibaro warnt vor der Benutzung des Sleep man solle besser Timeout benutzen.
Wenn man das wie Sleep benutzen möchte muss man sein Programm umstellen.
Timeout arbeitet völlig anders wenn auch als Zeitverzögerung.
Somit habe ich beschlossen mit Globalen Variabeln zu arbeiten und einem 1min Ticker der die Variabel inkrementieren oder dekrementieren. Damit umgehe ich das Problem und das ist einigermaßen genau. Dann achte ich darauf ja keine CPU-Zeit zu benutzen also alles schön geschmeidig halten und nur sehr wenig schleifen zu benutzen.
Da durch sieht das alles sehr komisch und stümperhaft aus rennt aber wie die wilde Wutz !
Ich überwache die Laufzeit der einzelnen Scenen und die Überwachungsscene wird mit dem Watch Dog überwacht.
Somit kann ich getrost meine Alarmanlage aktivieren und die Brandmeldeanlage, die Scenen laufen oder der Watch Dog schlägt an.
Den Watch Dog habe ich mit einem Qubino Flush 2 Relais und 2 Timern sowie einer Monostabilen Kippstufe aufgebaut.
Wechselt der Qubino angesteuert von der Überwachungsrutine nicht in weniger als 1,5 Minuten seinen Zustand so sprechen die Timer an und verriegeln, das wiederum führt dazu das die Kippstufe einen Radaumacher anwirft.
Die Probleme das ich mit dem Speicherüberlauf hatte, hat mich zu dem Schritt gezwungen, denn was nützt es eine Alarmanlage zu haben oder eine Brandmeldeanlage die nicht funktioniert.
Wenn das Licht oder die Rolladen hängen bleiben ist das unschön aber bei Rauch oder Alarm hört der Spaas auf.
Der HC3 ist keine Sicher ablaufende Kiste wie auch alle Anderen nicht. Bei einigen Brandmeldeanlagen und Alarmanlagen ist das sicher genau so nur hat das noch keiner gemerkt oder kontrolliert. So lange die keinen TÜV haben und nach DIN aufgebaut sind denke ich kann man davon ausgehen.
Für mich reicht das was ich gemacht habe und ich kann mich wieder anderen Sachen widmen.
Jetzt suche ich nach einer Möglichkeit einen Analogwert in den HC3 zu bekommen mit 12bit den ich meine Festgestellt zu haben das alles Andere nur 8 oder 7 Bit ist.
Nach der Info habe ich in allen Foren gefragt und keiner hat geantwortet, auch die Handbücher halten sich was Auflösung, Impedanz und Genauigkeit sehr bedeckt.
Einen „AZDelivery ESP32“ um den Wert einzulesen und einen QA um den mit dem HC3 abzufragen.
Das wird eine schwierige Sache für mich, da ich alles noch nicht gemacht habe und viel lesen muss.
Die Hardware ist für mich einfach.
Da weis ich genau was ich habe, welche Impedanz und welche Genauigkeit ich habe, zur Not könnte man das sogar kalibrieren (wem es Spaas macht).
Gruss Frank
@pblacky,
Ja ist schon ein Befehl den man mit Vorsicht genießen soll. Sleep lässt die ganze Szene für die Anzahl an Sekunden einschlafen. Wenn man das noch mit der random() Funktion kombiniert und noch andere
setTimeout in der Szene hat ist die zeitliche Ausführung nicht absehbar.
print("Start")
local function TestFunktion()
print('Sleep 5 Sek.')
fibaro.sleep(5000)
fibaro.setTimeout(20000, function()
print("setTimeout 20 Sek.")
end)
print('Funktion TestFunktion startet nach jeder Minute')
fibaro.setTimeout(60*1000, TestFunktion)
end
TestFunktion()
print("Ende")
Wie verwirrend es ist kannst Du mit der kleinen Testfunktion probieren. Da wird sleep und 2 verschiedene setTimeout benutzt. Und dann kannst Du noch fibaro,sleep(random(5,10)) einbauen. CPU ist hier immer idle.
Bin gerade etwas überrascht!!
Hab daher gerade meine Szenen durchforstet und einige Sleep bis zu 300 Sek gefunden!!
Wie würde ich eine Wartezeit von 60 Sekunden bis 5 Minuten programmieren OHNE alles lahmzulegen?
Gibt es da ANDRER Lösungen?
Ich habe alles was über 1 minute liegt mit einem Counter und einer Globalen Variabel gelöst.
Die Globale Variabel wird von einem 1 min Trigger um einen Verringert und dann im Programm abgetragt.
Im Prinzip so !
local variabel = 10 – für 10 min.
fibaro.setGlobalVariable(„G_Variabel“,variabel)
variabel = fibaro.getGlobalVariable(„G_Variabel“)
if variabel = 0 then – Zeit abgelaufen.
Anderes Programm das Zyklisch 1 x in der Minute durchlaufen wird das hier gemacht.
local variabel = fibaro.getGlobalVariable(„G_Variabel“)
if variabel >= 0 then
variabel = variabel -1
fibaro.setGlobalVariable(„G_Variabel“,variabel)
end
Damit umgehe ich das Problem mit dem Nachteil das alles nur im 1 Minuten Ablauf möglich ist.
Der Vorteil ist das man sogar auf den Ablauf Triggern kann.
{
conditions = { {
isTrigger = true,
operator = „==“,
property = „G_Variabel“,
type = „global-variable“,
value = „0“
} },
operator = „all“
}
Ich habe aber einen Array benutzt und mehrere Timer damit gebaut so das ich diese überalle einsetzen kann.
Das geht natürlich auch mit einer QA wahr mir aber zu Aufwändig.
Damit währen dann auch geringere Zeiten (ist mir grade eingefallen) mit möglich darüber müsste ich mal nachdenken.
Danke @Berges01 für diesen Input!
Ich bin ja derzeit noch auf der HC2 und werde dort glaube ich nix mehr umstellen!
Aber deine Idee wird mal zum Test in meine HC3 eingebaut, sobald ich dort einen Timer brauche, um das mal zu testen…
Also ein Trigger der alle Minute einen Startimpuls an Aktion gibt.
Hier die Aktion die dazu gehört :
print("Start Sek_Timer = ",os.date("%d/%m/%Y %H:%M:%S"))
local i=0
repeat
fibaro.sleep(1000)
print("Time = ",os.date("%H:%M:%S"))
until i >= 150
Ja ich weis genau was da abläuft und das ist Absicht.
Dann musste ich meinen Test unterbrechen und habe das weiter laufen lassen.
Als ich nach einigen Stunden wieder nach Hause kam wahr der Ärger groß,
Rollos sind nicht gefahren, Heizungen standen auf volle Pulle obwohl Fenster oder Türen auf waren, Aussenbeleuchtung ohne Funktion und und und.
Bis ich darauf gekommen bin das diese Blöde Routine die Ursache wahr.
Diese hat verhindert das die 1 min Trigger und einige Device Trigger wahren auch betroffen, auslösten und die Routinen für einige Funktionen nicht mehr angeworfen wurden.
An der CPU und auch an der Speicherauslastung konnte man nichts erkennen.
Was mich stutzig gemacht hat wahr das die CPU-Last nahe 0 lag und keine Peaks aufgewiesen hat.
Dann habe ich die Oben aufgezeigte Routine deaktiviert und nach einer kurzen Pause liefen alle Routinen wieder los.
Oh ha so schlimm hatte ich mir die Auswirkungen von Sleep nicht vorgestellt.
Was angeschlagen hat bei alle dem war meine Scenenüberwachung denn alle Laufzeiten lagen im Stundenbereich weil die Scenen nicht neu gestartet wurden.
Wenn ich jetzt noch eine Push absetze würde ich es auch gemeldet bekommen so weit wahr ich noch nicht.
Also muss dringend ein Ersatz für Sleep her wer weis was da noch so im Argen liegt.
