Schalten nach x minuten wenn der Wert immernoch größer als ist...

[misux]

Hi!

Ich versuche ein einfaches DOIF zu basteln was mein Rollo runterfährt wenn  ein Lichtsensor 90000 übersteigt und dieser Wert sich nach 20 Minuten nicht wieder unter 90000 ändert, DANN erst soll gefahren werden. Fällt der Lichtwert unter einen wert soll das Rollo wieder hoch.

Code Auswählen Erweitern

([Lichtsensor:Brightness] > 90000.00 and [?Außensensor:Temperature] > 19) (set Rollo off)
([Lichtsensor:Brightness] < 18000.00 and [?Außensensor:Temperature] > 19) (set Rollo on)

Attribute:
checkall: event
wait: 1200:1200

irgendwie funktioniert das mit der Änderung nicht... er fährt runter sobald der Wert sich über 90000 bewegt hat und ignoriert einen Fall unter 90000 während der 20min. Er soll erst runterfahren wenn der Wert 90000 nach 20 min IMMERNOCH über 90000 ist...

Gibt es dafür eine Lösung?

Vielen Dank!

[Per]

Mach nen DOELSE rein.

[Otto123]

Mach nen DOELSE rein.

Ich würde ein DOELESIF vorschlagen 

[misux]

ach, ja das ist natürlich schon längst.

Code Auswählen Erweitern


([Lichtsensor:Brightness] > 90000.00 and [?Außensensor:Temperature] > 19) (set Rollo off)
DOELSEIF
([Lichtsensor:Brightness] < 18000.00 and [?Außensensor:Temperature] > 19) (set Rollo on)


Funktioniert dennoch irgendwie nicht 

[pc1246]

Moin
Und wie immer haetten wir gerne ein list des DOIF! So wird es nur ein Ratespiel!
Gruss Christoph

[Otto123]

Code Auswählen Erweitern

So sieht das aus, wenn ich einfach deine Zeilenumbrüche rausnehme, das ist Gift!!!

Edit Damian (habe mich verklickt):

Würde ich so nicht sehen. Ich empfehle in der Commandref zu DOIF ausdrücklich Nutzung von Zeilenumbrüchen, um strukturiert eine DOIF-Definition darzustellen.

Beim DOIF sind keine Leerzeichen oder Zeilenumbrüche inzwischen kein Problem, wenn man nicht gerade ein Wort mittendrin umbricht.

Übrigens auch beim IF nicht, dass allerdings IF(... nicht funktioniert, ist kein IF-Problem, siehe https://forum.fhem.de/index.php/topic,90453.0.html

Ein List eines DOIFs ist natürlich Pflicht, um kompetente Aussagen treffen zu können.

[Per]

Ich würde ein DOELESIF vorschlagen 

Das das drin ist, davon bin ich ausgegangen. Ich würde weiterhin ein DOELSE vorschlagen. Dann hat das DOIF nämlich einen Anlaufpunkt, um das wait abzubrechen, der fehlt hier nämlich. Es sei denn, die Helligkeit sinkt innerhalb der 20 min von 90000 auf 18000, dann könnte es in cmd2 wechseln.

[misux]

Das das drin ist, davon bin ich ausgegangen. Ich würde weiterhin ein DOELSE vorschlagen. Dann hat das DOIF nämlich einen Anlaufpunkt, um das wait abzubrechen, der fehlt hier nämlich. Es sei denn, die Helligkeit sinkt innerhalb der 20 min von 90000 auf 18000, dann könnte es in cmd2 wechseln.

Das wird es sein... Ich kann es leider erst morgen Abend testen bzw am Wochenende. Aber ich denke das ist das Problem...

Vielleicht sollte ich das wait komplett löschen... Dann schaltet er ja einmal über 90000 auf off und dann erst unter 18000 auf on... 

[Otto123]

Code Auswählen Erweitern

So sieht das aus, wenn ich einfach deine Zeilenumbrüche rausnehme, das ist Gift!!!

Edit Damian (habe mich verklickt):

Würde ich so nicht sehen. Ich empfehle in der Commandref zu DOIF ausdrücklich Nutzung von Zeilenumbrüchen, um strukturiert eine DOIF-Definition darzustellen.

Beim DOIF sind keine Leerzeichen oder Zeilenumbrüche inzwischen kein Problem, wenn man nicht gerade ein Wort mittendrin umbricht.

Übrigens auch beim IF nicht, dass allerdings IF(... nicht funktioniert, ist kein IF-Problem, siehe https://forum.fhem.de/index.php/topic,90453.0.html

Ein List eines DOIFs ist natürlich Pflicht, um kompetente Aussagen treffen zu können.

Auch wenn mein Beitrag jetzt nicht mehr da ist. Ich stehe dazu was ich gesagt habe.
Ich habe nichts gegen Strukturen in der DEF. Aber ein Zeilenumbruch an der falschen Stelle, oder eine führende/letzte Leerzeile, oder ein Leerzeichen hinter dem Zeilenende Verbinder "\" haben schon so oft zur Funktionsstörung geführt!
Auch wenn vielleicht Schritt für Schritt solche "Schwachstellen" korrigiert werden, hängt es immer noch von der FHEM Version ab ob dies schon oder noch nicht geht.
Diese Anfälligkeit betrifft alle Module, denn manche Dinge werden im Modul und manche Dinge an zentraler Stelle behandelt.
Sehr oft werden Syntax und "das geht doch hier" von Modul zu Modul gemischt und übertragen. Deswegen mein Rat:
Wenn etwas gehen müsste, aber offenbar nicht geht - sind neben vielen Dingen und Möglichkeiten auch "Strukturelemente" eine Fehlerursache. Also im Zweifelsfall erstmal raus damit!

Ist jetzt hier vielleicht nicht der Fall, aber ich habe es jetzt hier gesagt 

Gruß Otto

[Per]

Ich habe nichts gegen Strukturen in der DEF.

Wie es in der DEF aussieht, ist mir egal, aber hier im Forum finde ich Zeilenumbrüche ein Muss. Besonders User mit Mobilen Geräten (und den "passenden" Apps) sind sonst oft außen vor, weil diese nicht richtig seitlich scrollen können.

oder ein Leerzeichen hinter dem Zeilenende Verbinder "\"

Wer selbst in der Config rumschreibt, sollte schon wissen, was er/sie macht!

[Otto123]

Naja wenn wirklich einer ein Problem hat, ist mir ein komplettes list vom Gerät viel lieber als fake Code Fragmente (wie 9 Beiträge weiter oben), die dann auf die falsche Fährte locken.
Und am Smartphone geh ich nicht ins Forum, ist mir zu anstrengend.

Gruß Otto

[Per]

ist mir ein komplettes list vom Gerät viel lieber als fake Code Fragmente

Das sowieso!