DOIF neue Features (Sleep-Alternative)

Begonnen von Damian, 12 Juli 2015, 21:17:52

Vorheriges Thema - Nächstes Thema

Damian

Zitat von: Amenophis86 am 12 November 2015, 20:27:09
Liegt es an meiner Programmierung, oder wieso geht der Wait Timer mit Random nicht? Habe das Wait wie folgt definiert:

wait rand(600):rand(600),0:0:0:0:0

Habe es so aus der Commandref bezüglich des random, aber irgendwie wird das random komplett ignoriert.

Bei mir nicht. Um mehr dazu sagen zu können, braucht man schon mehr Infos.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Amenophis86

#316
Hier das zugehörige Doif:

([{sunset("HORIZON=-2.5",0,"20:00","22:00")}] and [WZ.Tuer.L] eq "closed" and [WZ.Tuer.R] eq "closed")
(set WR.Rollladen.Alle off)
DOELSEIF ([{sunset("HORIZON=-2.5",0,"20:00","22:00")}] and [?WZ.Tuer.L] ne "closed" and [?WZ.Tuer.R] ne "closed" and [?EZ.Rollladen] ne "off")
(set EZ.Rollladen off)
(set Pushover1 msg 'Rollladen Info' 'Wohnzimmer Rollläden nicht geschlossen, Tür noch geöffnet!')
DOELSEIF (([WZ.Tuer.L] eq "open" or [WZ.Tuer.R] eq "open") and [?WZ.Rollladen] ne "on")
(set WZ.Rollladen on)
DOELSEIF (([WZ.Tuer.L] eq "tilted" or [WZ.Tuer.R] eq "tilted") and [?WZ.Rollladen] eq "off")
(set WZ.Rollladen pct 25)
DOELSEIF ([WZ.Tuer.L] eq "closed" and [WZ.Tuer.R] eq "closed" and [?EZ.Rollladen] eq "off" and [?WZ.Rollladen] ne "off")
(set WZ.Rollladen off)
DOELSEIF ([{sunrise(0,"07:30","09:00")}] and [Gast.Uebernachtung] eq "off")
(set WR.Rollladen.Alle on)


Das Wait wird praktisch ignoriert und die Rollläden gehen trotzdem um 20uhr runter und nicht die random Zeit später.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Damian

#317
Zitat von: Amenophis86 am 12 November 2015, 21:36:08
Hier das zugehörige Doif:

([{sunset("HORIZON=-2.5",0,"20:00","22:00")}] and [WZ.Tuer.L] eq "closed" and [WZ.Tuer.R] eq "closed")
(set WR.Rollladen.Alle off)
DOELSEIF ([{sunset("HORIZON=-2.5",0,"20:00","22:00")}] and [?WZ.Tuer.L] ne "closed" and [?WZ.Tuer.R] ne "closed" and [?EZ.Rollladen] ne "off")
(set EZ.Rollladen off)
(set Pushover1 msg 'Rollladen Info' 'Wohnzimmer Rollläden nicht geschlossen, Tür noch geöffnet!')
DOELSEIF (([WZ.Tuer.L] eq "open" or [WZ.Tuer.R] eq "open") and [?WZ.Rollladen] ne "on")
(set WZ.Rollladen on)
DOELSEIF (([WZ.Tuer.L] eq "tilted" or [WZ.Tuer.R] eq "tilted") and [?WZ.Rollladen] eq "off")
(set WZ.Rollladen pct 25)
DOELSEIF ([WZ.Tuer.L] eq "closed" and [WZ.Tuer.R] eq "closed" and [?EZ.Rollladen] eq "off" and [?WZ.Rollladen] ne "off")
(set WZ.Rollladen off)
DOELSEIF ([{sunrise(0,"07:30","09:00")}] and [Gast.Uebernachtung] eq "off")
(set WR.Rollladen.Alle on)


Das Wait wird praktisch ignoriert und die Rollläden gehen trotzdem um 20uhr runter und nicht die random Zeit später.
Dann kennst du offenbar noch nicht das Attribut timerWithWait  ;)

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Amenophis86

In der Tat war mir dieses unbekannt. Das brauche ich also um bei wait ein random eizubauen. Schau an. Danke

PS. In der Commandref ist im Beispiel ein kleiner Fehler:

ZitatAnwendungsbeispiel: Lampe soll zufällig nach Sonnenuntergang verzögert werden.

define di_rand_sunset([{sunset()}])(set lamp on)
attr di_rand_sunset wait rand(1200)
attr di_rand_sunset timerWithWait
attr di_rand_sunset do always

Es fehlt das DOIF beim define. Gerade beim Nachlesen gesehen.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Damian

Zitat von: Amenophis86 am 12 November 2015, 22:40:27
In der Tat war mir dieses unbekannt. Das brauche ich also um bei wait ein random eizubauen. Schau an. Danke

PS. In der Commandref ist im Beispiel ein kleiner Fehler:

Es fehlt das DOIF beim define. Gerade beim Nachlesen gesehen.

Danke für die Info - wird beim nächsten Update korrigiert.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Skusi

Nun muß ich auch mal nach Brain-Hilfe schreien...

Ich habe meine Rolladen auch alle über mitlerweile ziehmlich gewachsene DOIF´s laufen. Aber hin und wieder verstehe ich die denkensweise des Moduls wohl nicht richtig.
Ich hatte gerade wieder den Fall, das 2 identisch Programmierte DOIF´s das eine mal den Rolladen am Abend runter fährt, und der andre Rolladen oben bleibt. Die beiden DOIF´s sehen aber völlig gleich aus:

([([AussenLux:sr_civil]+int(rand(300)))-10:00]
and [([05:50]+int(rand(900)))-10:00|8] and [?Sonnenschutz_Buero] == 0 and [?Status] ne "Gaeste"
or [([AussenLux:sr_civil]+int(rand(300)))-10:00]
and [([08:00]+int(rand(1800)))-10:00|7] and [?Sonnenschutz_Buero] == 0 and [?Status] ne "Gaeste"
or [Sonnenschutz_Buero] == 0 and [?RolloBuero:position] < 75)
(set RolloBuero off)

DOELSEIF ([Sonnenschutz_Buero] == 1 and [?RolloBuero:position] < 75) (set RolloBuero Sonne)

DOELSEIF ([([AussenLux:ss_civil]+int(rand(180)))])
(set RolloBuero on)


Zur Erklärung: "Aussenlux" = Twilight

Etwas abgespeckt und vielleicht für Euch übersichtlicher:

([([AussenLux:sr_civil]+int(rand(300)))-10:00]
and [([05:50]+int(rand(900)))-10:00|8]
(set RolloBuero off)

DOELSEIF ([([AussenLux:ss_civil]+int(rand(180)))])
(set RolloBuero on)


Komisch ist auch das es Tagelang funktioniert, und dann setz mal wieder ein Rollo aus. Ich verstehe das nicht ! hat das was mit den (rand...) einträgen zutun.
Kann mir mal einer auf die Sprünge helfen wo das Modul anders denkt als ich ?

---Skusi
HP ThinClient 630, SIGNALduino, NanoCul868 (a-culfw), JeeLink Clone (LaCrosse), Firmata  für FB Heizung,Wasser+Gas+Klingel+Lux, Somfy Rolladen, Pollin Steckd.,TX29DTH,Tasmota+IR Lesekopf an Stromz., MAX Fensterkontakte, IButton, Fingerprint, SonOff Tasmota, ESP LED Controler, WLed,zigbee2mqtt...

mfeske

Hallo Skusi,

was sagen die Logs ? Ich hatte es ähnlich und in den Logs wurde angezeigt das alles ausgeführt wird. Ursache war der CUL der etwas in der Position verändert war.

Gruß
Micha
Hardware:
1 x Raspberry Pi Mod. B 512 MB
eq-3 2 x MAX! eTRV Heizungssteller, 1 x MAX! Fensterkontakt, 1 x MAX! Cube - LAN Gateway (ausser Betrieb)
Intertechno 1x ITZ-500, 3x ITT-1500, 9x ITR-1500, 3 x ITDL-1000, 2 x ITL-500
1 x CC1101-USB-Lite 433MHz (CUL433)  V3 1 x CC1101-USB-Lite 868MHz (CUL868)

Skusi

In den logs gibts nichts was weiter hilft.

Der Status vom bertoffenen DOIF ist auch seit morgens unverändert "AUF"
Deshalb hab ich auch nicht weiter geforscht. Das DOIF wollte laut Status ja noch gar nicht runter fahren !?

---Skusi
HP ThinClient 630, SIGNALduino, NanoCul868 (a-culfw), JeeLink Clone (LaCrosse), Firmata  für FB Heizung,Wasser+Gas+Klingel+Lux, Somfy Rolladen, Pollin Steckd.,TX29DTH,Tasmota+IR Lesekopf an Stromz., MAX Fensterkontakte, IButton, Fingerprint, SonOff Tasmota, ESP LED Controler, WLed,zigbee2mqtt...

Brockmann

Zitat von: Skusi am 15 November 2015, 19:45:46
In den logs gibts nichts was weiter hilft.
Du hast in der Bedingung zwei Intervalle jeweils mit einer Zufallskomponenten. Bist Du sicher, dass diese beiden Intervalle sich unter keinen Umständen gegenseitig ausschließen können?

Generell: Vielleicht definierst Du Dir mal ein Filelog für dieses DOIF. Da kannst Du auch im Nachhinein ganz gut nachvollziehen, warum das DOIF wann was getan hat.
Wenn Du Twilight-Events da auch noch mit reinloggst, hast Du alles an einer Stelle im zeitlichen Kontext. Vielleicht bringt Dich die Analyse dann weiter.

Ralli

Gruß,
Ralli

Proxmox 8.4 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte RaspberryMatic (3.83.6.20250705) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.4.1) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

Damian

Zitat von: Ralli am 17 November 2015, 07:24:10
Hallo Damian,

kann das: http://forum.fhem.de/index.php/topic,10033.msg359955.html#msg359955 seine Ursache im DOIF haben?
Das wird deine Problemzeile sein:

(set Sonos Groups [Sonos_Bad], [Sonos_Esszimmer], [Sonos_Kind1], [Sonos_Schlafzimmer], [Sonos_Kind2])

Komma ist ein Trenner in DOIF, daher musst du den Ausdruck in zusätzliche Klammern packen.

((set Sonos Groups [Sonos_Bad], [Sonos_Esszimmer], [Sonos_Kind1], [Sonos_Schlafzimmer], [Sonos_Kind2]))

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ralli

Danke  8) - da habe ich nicht dran gedacht.
Gruß,
Ralli

Proxmox 8.4 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte RaspberryMatic (3.83.6.20250705) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.4.1) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

Skusi

Hallo Brockmann,

ich habe nun einen FileLog für alle Rolladen DOIF´s mitlaufen lassen. Heute fuhr wieder ein anderer nicht zu bei Twilight:ss_civil. Das DOIF tauchte im gegensatz zu den anderen in dem Log gar nicht erst auf. Die cmd 3 Zeile ist aber bei allen DOIF´s gleich. 3 Rolladen reagieren darauf und einer (immer mal eine anderer) bleiben auf Status "off" von dem Morgen Timer auf cmd 1 stehen.

Ich versteh das nicht.

Alle DOIF´s haben

DOELSEIF ([([AussenLux:ss_civil]+int(rand(180)))])
(set RolloBuero on)


als letzte Bedingung. Warum geht das an einem Tag und an einem anderen wieder nicht ?

Die beiden Bedingungen am Anfang:

([([AussenLux:sr_civil]+int(rand(300)))-10:00]
and [([05:50]+int(rand(900)))-10:00|8]


sollen bewirken das die Rolladen erst aufgehen wenn

a. die Sonne "ungefähr" aufgegangen ist
und
b. nicht vor "ungefähr" 05:50 Uhr

Das "ungefähr" soll verhindern das alle Rolladen im Winter bei Sonnenaufgang exakt gleichzeitig auffahren. Und das "ungefähr" bei der 2. Bedingung das sie im Sommer nicht alle gleichzeitig öffnen, sonder immer leicht unterschiedlich in zufälliger Reihenfolge.

Aber mein Problem ist ja eigentlich die 3. Bedingung fürs Abendliche zufahren.

Hab ich da was mit dem Triggern falsch verstanden ? Muß AussenLux:ss_civil auch in der ersten Bedingung stehen damit das DOIF überhaupt triggert ?
Aber ich will ja bei morgendlichen Auffahren nicht den Sonnenuntergang abfragen.

Ich bin verwirrt....

---Skusi
HP ThinClient 630, SIGNALduino, NanoCul868 (a-culfw), JeeLink Clone (LaCrosse), Firmata  für FB Heizung,Wasser+Gas+Klingel+Lux, Somfy Rolladen, Pollin Steckd.,TX29DTH,Tasmota+IR Lesekopf an Stromz., MAX Fensterkontakte, IButton, Fingerprint, SonOff Tasmota, ESP LED Controler, WLed,zigbee2mqtt...

Damian

Zitat von: Skusi am 18 November 2015, 18:27:04
als letzte Bedingung. Warum geht das an einem Tag und an einem anderen wieder nicht ?

Die beiden Bedingungen am Anfang:

([([AussenLux:sr_civil]+int(rand(300)))-10:00]
and [([05:50]+int(rand(900)))-10:00|8]


Zwei Intervalle, die mit AND verknüpft sind, machen eigentlich wenig Sinn. Die Bedingung ist nur dann wahr, wenn sie sich überschneiden. Normalerweise werden Intervalle mit OR verknüpft, um unterschiedliche Zeitintervalle, die sich normalerweise nicht überschneiden, anzugeben.


Gruß

Damian


Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Brockmann

Zitat von: Skusi am 18 November 2015, 18:27:04
Hab ich da was mit dem Triggern falsch verstanden ? Muß AussenLux:ss_civil auch in der ersten Bedingung stehen damit das DOIF überhaupt triggert ?
Nein. Wann immer das Device AussenLux ein Event generiert, wird jedes DOIF getriggert, wo [AussenLux...] als Bedingung aufgeführt wird. Es werden alle Bedingungen (und nur die), die dieses Device enthalten überprüft und die erste Bedingung gewählt, die zutrifft. Wenn eines der DOIF darauf nicht reagiert, obwohl eine Bedingungen erfüllt sein müsste, liegt es nahe, dass es sich bereits in diesem Zustand befand und deshalb nicht reagiert. Denn eine Aktion erfolgt nur bei einem Zustandswechsel des Moduls (es sei denn, Du hast do always gesetzt, was bei Deinem Szenario aber eher unwahrscheinlich ist).

Du solltest mal in dem Moment (bzw. unmittelbar nachdem) ein solches vermeintliches "Fehlverhalten" eines DOIF aufgetreten ist, ein list <Name des DOIFs> machen und das Ergebnis hier posten (bzw. Dir erstmal selbst anschauen). Das erklärt in den meisten Fällen, warum das Modul sich so verhält wie es das tut.