Konstantlichtregelung mit HM-HM-LC-DW-WM [Gelöst]

[fast-eddy]

Moin Damian,
sag mal machst Du auch mal Forumpause? 
Super Reaktionszeit - Danke dafür!

Aber ich stehe mal wieder suf dem Schlauch!
Ich teile doch nur die Ramptime durch zwei.
Der pct Wert wird initial auf 5 gesetzt und soll
dann über die ramptime hochgedimmt werden.
5.5 lässt vermuten, dass das einmalig um 0.5
passiert und dann stoppt,
Oder meinst Du was anderes?

[Damian]

Moin Damian,
sag mal machst Du auch mal Forumpause? 
Super Reaktionszeit - Danke dafür!

Aber ich stehe mal wieder suf dem Schlauch!
Ich teile doch nur die Ramptime durch zwei.
Der pct Wert wird initial auf 5 gesetzt und soll
dann über die ramptime hochgedimmt werden.
5.5 lässt vermuten, dass das einmalig um 0.5
passiert und dann stoppt,
Oder meinst Du was anderes?

Die genaue Bedeutung der Parameter kenne ich nicht, ich meine natürlich nur den letzten Parameter, der ja als Ramptime berechnet wurde. Zum Rest kann ich  nichts sagen.

[fast-eddy]

OK - Das pct command hat 3 Parameter:
set pct p1 p2 p3
p1 gibt den Zielwert in % an
p2 die Einschaltdauer wobei 0=unendlich
p3 die ,,ramptime" setzt die Zeit in Sekunden in der der Zielwert (pct) erreicht werden soll.

Laut Logfile werden alle Parameter sauber gesetzt.
Das was dann laut Evenlog passiert macht für mich
aber keinen Sinn.

[fast-eddy]

Hallo zusammen,

mittlerweile bin ich mir fast sicher, dass mich hier das Device HM-HM-LC-DW-WM ärgern will.
Nach den Einträgen im Logfile werden alle commands korrekt ausgeführt und auch die Berechnung
der Parameter wird sauber ausgeführt:

2018.09.19 08:30:00 3: CUL_HM set eg_garderobe_HELLIGKEIT pct 5
2018.09.19 08:30:05 3: CUL_HM set eg_garderobe_HELLIGKEIT pct 40 0 20817.5
2018.09.19 08:30:05 3: CUL_HM set eg_garderobe_FARBE pct 100 0 20817.5

Da aber zeitnah auch einige Attack Alerts im Log auftauchen bin ich auf die Idee gekommen, dass das Device durch
das viele Testen vielleicht einen Speicherüberlauf hat (lokal werkelt dort ein kleiner Atmega Controller)

2018.09.19 08:31:37 2: CUL_HM HM_59E794 attack:11F1234159E794020150CB47FFFF,11F1234159E7940202C8CB47FFFF:11E9FEE59E794010E
2018.09.19 08:32:06 2: CUL_HM HM_59E794 attack:11F1234159E794020150CB47FFFF,11F1234159E7940202C8CB47FFFF:11E9FEE59E794010E
2018.09.19 08:32:16 2: CUL_HM HM_59E794 attack:11F1234159E794020150CB47FFFF,11F1234159E7940202C8CB47FFFF:11E9FEE59E794010E

Daher habe ich mal alle Trigger, Settings usw. lokal zurückgesetzt. Und sie da - plötzlich lief das mit Eurer Hilfe gebaute DOIF und der
Regelprozess wie gewünscht. Leider nur für etwa 3 Stunden dann tauchen die attacks wieder auf und der Prozess stoppt.
Siehe List:

Code Auswählen Erweitern

Internals:
   DEF        ([{sunrise("CIVIL")}])
(set eg_garderobe_HELLIGKEIT pct 5)
(set eg_garderobe_HELLIGKEIT pct 40 0 {(hms2secs(sunset_rel("CIVIL"))/2)})
(set eg_garderobe_FARBE pct 100 0 {(hms2secs(sunset_rel("CIVIL"))/2)})
(set eg_garderobe_HELLIGKEIT pct 5 {(hms2secs(sunset_rel("NAUTIC")))})
DOELSEIF ([23:00])
(set eg_garderobe_HELLIGKEIT off)
   MODEL      FHEM
   NAME       timer_LED_GARDEROBE
   NR         503
   NTFY_ORDER 50-timer_LED_GARDEROBE
   STATE      cmd_1_3
   TYPE       DOIF
   READINGS:
     2018-09-19 11:34:09   cmd             1.3
     2018-09-19 11:34:09   cmd_event       set_cmd_1
     2018-09-19 11:34:09   cmd_nr          1
     2018-09-19 11:34:09   cmd_seqnr       3
     2018-09-19 11:33:32   mode            enabled
     2018-09-19 11:34:09   state           cmd_1_3
     2018-09-19 11:33:32   timer_01_c01    20.09.2018 06:37:26
     2018-09-19 11:33:32   timer_02_c02    19.09.2018 23:00:00
     2018-09-19 11:34:09   wait_timer      19.09.2018 15:49:05 cmd_1_4 set_cmd_1
   Regex:
   attr:
     cmdState:
     wait:
       0:
         0
         5
         5
         {hms2secs(sunset_rel("CIVIL"))/2}
       1:
         0
     waitdel:
   condition:
     0          DOIF_time_once($hash,0,$wday)
     1          DOIF_time_once($hash,1,$wday)
   days:
   devices:
   do:
     0:
       0          set eg_garderobe_HELLIGKEIT pct 5
       1          set eg_garderobe_HELLIGKEIT pct 40 0 {(hms2secs(sunset_rel("CIVIL"))/2)}
       2          set eg_garderobe_FARBE pct 100 0 {(hms2secs(sunset_rel("CIVIL"))/2)}
       3          set eg_garderobe_HELLIGKEIT pct 5 {(hms2secs(sunset_rel("NAUTIC")))}
     1:
       0          set eg_garderobe_HELLIGKEIT off
     2:
   helper:
     event     
     globalinit 1
     last_timer 2
     sleepdevice set_cmd_1
     sleepsubtimer 3
     sleeptimer 0
     triggerDev
     triggerEvents
     triggerEventsState
     DOIF_eventas:
       cmd_nr: 1
       cmd_seqnr: 3
       cmd_event: set_cmd_1
       state: cmd_1_3
   intervalfunc:
   itimer:
   localtime:
     0          1537418246
     1          1537390800
   realtime:
     0          06:37:26
     1          23:00:00
   time:
     0          {sunrise("CIVIL")}
     1          23:00:00
   timeCond:
     0          0
     1          1
   timer:
     0          0
     1          0
   timers:
     0           0
     1           1
   triggertime:
     1537390800:
       localtime  1537390800
       hash:
     1537418246:
       localtime  1537418246
       hash:
   uiState:
   uiTable:
Attributes:
   group      Haussteuerung
   room       STEUERUNG
   timerWithWait 1
   wait       0,5,5,{hms2secs(sunset_rel("CIVIL"))/2}:0

Ich vermute, dass der lokale Prozessor auf dem LED Controller mit zu langen ramptimes d.h. zu vielen Schaltzyklen Probleme mit dem raren Speicher bekommt. Vielleicht ist da im entsprechenden HM-Modul aber ein Limit eingebaut oder große Werte (noch) nicht implementiert. Vielleicht kann uns da martinp876 weiterhelfen.

[fast-eddy]

So ich noch mal - Es rennt....!

Das DOIF hatte ich ja mit Eurer Unterstützung recht schnell am Laufen - nur der Controller wollte nicht so recht mitspielen
und hat ganz komische Dinge gemacht. Zunächst dachte ich die Ramptimes wären limitiert oder der LED Controller sogar defekt.
Zumindest liesen die Blink Codes des Geräts darauf schließen.

Letztlich war es doch die im Controller verbaute CPU bzw. deren geringer Speicher. Durch das ganze Testen und ausprobieren habe
ich wohl den Speicher vollgeschrieben und das arme Ding zum Absturz gebracht. Mit Factory Reset und stromlos machen konnte ich
es überreden wieder seinen Job zu machen

Jetzt habe ich hier eine schöne Lichtvoute im Flur, die analog zum Sonnenstand Lichttemperatur und Helligkeit nachführt - coole Sache!
Danke nochmals für alle die mitgedacht und debugged haben!

Und so sieht das ganze aus - für diejenigen die mal en Code Snipped für sowas suchen:

Code Auswählen Erweitern

define timer_LED_GARDEROBE DOIF ([{sunrise("CIVIL")}])
(set eg_garderobe_HELLIGKEIT pct 5 0 2, set eg_garderobe_FARBE pct 5 0 0)
(set eg_garderobe_HELLIGKEIT pct 50 0 {(hms2secs(sunset_rel("CIVIL"))/2)})
(set eg_garderobe_FARBE pct 80 0 {(hms2secs(sunset_rel("CIVIL"))/2)})
(set eg_garderobe_HELLIGKEIT pct 10 0 {(hms2secs(sunset_rel("CIVIL")))})
(set eg_garderobe_FARBE pct 0 0 {(hms2secs(sunset_rel("CIVIL"))/2)})
DOELSEIF ([23:00])
(set eg_garderobe_HELLIGKEIT off)

attr timer_LED_GARDEROBE timerWithWait 1
attr timer_LED_GARDEROBE wait 0,5,5,{hms2secs(sunset_rel("NAUTIC"))/2},5:0

P.S. Ich weiss, dass ich die dedizierten set commands mehr FHEM Last erzeugen als kommaseparierte
aber das war mir fürs erste zu unübersichtlich. Wenn ich mal wieder Zeit übrig habe räum´ ich auf... 

[Per]

So ich noch mal - Es rennt....!die dedizierten set commands mehr FHEM Last erzeugen als kommaseparierte

Da du mit wait arbeitest, wirst du noch ohne auskommen.