Hauptmenü

RandomTimer schaltet nicht

Begonnen von uxtuner, 28 August 2024, 15:10:46

Vorheriges Thema - Nächstes Thema

uxtuner

Hallo,

ich hab mal testweise einen Random Timer angelegt ("define random_switch5 RandomTimer 14:15:00 Deckenlicht_Treppe 14:45:00 60"), mein Licht kann ich auch problemlos mit "set Deckenlicht_Treppe on" einschalten aber leider passiert nichts bzw. wenn Licht eingeschaltet ist wird es ausgeschaltet aber nie eingeschaltet

Muss ich ein event-on-change o.ä. setzen?

defmod random_switch5 RandomTimer 15:05:00 Deckenlicht_Treppe 16:45:00 60
attr random_switch5 switchmode 800/200

setstate random_switch5 on
setstate random_switch5 2024-08-28 15:03:30 StartTime 2024-08-28 15:05:00
setstate random_switch5 2024-08-28 15:03:30 StopTime 2024-08-28 16:45:00
setstate random_switch5 2024-08-28 15:03:30 TimeToSwitch 60
setstate random_switch5 2024-08-28 15:06:00 active 1
setstate random_switch5 2024-08-28 15:07:56 state on

defmod Deckenlicht_Treppe EseraDigitalInOut ESERA 2300001B1F535429 DS2408 5 1
attr Deckenlicht_Treppe alias Treppe
attr Deckenlicht_Treppe devStateIcon 0:off:on 1:on:off
attr Deckenlicht_Treppe event-on-change-reading .*
attr Deckenlicht_Treppe genericDeviceType light
attr Deckenlicht_Treppe group Esera Aktor
attr Deckenlicht_Treppe homebridgeMapping clear\
On=state,cmdOn=on,cmdOff=off
attr Deckenlicht_Treppe icon light_downlight
attr Deckenlicht_Treppe room Hersteller->Esera,Homekit,Licht,OG->Durchgang
attr Deckenlicht_Treppe siriName Treppe
attr Deckenlicht_Treppe userReadings state {ReadingsVal($name,"out","") }

setstate Deckenlicht_Treppe 0
setstate Deckenlicht_Treppe 2024-08-28 15:09:55 in 0
setstate Deckenlicht_Treppe 2024-08-28 15:09:55 out 0
setstate Deckenlicht_Treppe 2024-08-28 15:09:55 state 0
Viele Grüße
  Uwe

Intel NUC (VDR & FHEM), QNAP TS-453, OneWire (Temp. Sensor, 8-fach Schalter, Hub, Controller), Ebus (Wolf CGW-2, ISM7i), Fibaro (Flood Sensor, Wall Plug, 4 in 1 Sensor), Qubino (Flush 1D), Shelly (Plug S, H&T, 2.5, 1 PM), Tado (Thermostat V3+)

Beta-User

Setze das Attribut "offState" passend.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

uxtuner

#2
Danke!
Nachdem ich das "offState" Attribut auf ".* 0" gesetzt habe funktioniert es :-)

Jetzt muss ich mir noch einen Dummy Switch "Urlaub" anlegen und die Bedingung mit dem RandoMTimer verknüpfen ...
Viele Grüße
  Uwe

Intel NUC (VDR & FHEM), QNAP TS-453, OneWire (Temp. Sensor, 8-fach Schalter, Hub, Controller), Ebus (Wolf CGW-2, ISM7i), Fibaro (Flood Sensor, Wall Plug, 4 in 1 Sensor), Qubino (Flush 1D), Shelly (Plug S, H&T, 2.5, 1 PM), Tado (Thermostat V3+)

Beta-User

Zitat von: uxtuner am 29 August 2024, 06:27:02Danke!
Nachdem ich das "offState" Attribut auf ".* 0" gesetzt habe funktioniert es :-)
Hmmm, eigentlich sollte "0" besser passen, sonst geht der RT wohl davon aus, dass immer "an" ist, obwohl das nicht stimmt...

Du könntest übrigens auch das "state"-Reading schlicht mit dem richtigen Wert (on/off) füllen, statt das auf diese Weise zu lösen ;) .
ZitatJetzt muss ich mir noch einen Dummy Switch "Urlaub" anlegen und die Bedingung mit dem RandoMTimer verknüpfen ...
Warum keine RESIDENTS?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

uxtuner

ein disableCond (ReadingsVal("Urlaub","state","on") eq "off") tuts gerade, das mit den RESIDENTS schau ich mir an ...
Viele Grüße
  Uwe

Intel NUC (VDR & FHEM), QNAP TS-453, OneWire (Temp. Sensor, 8-fach Schalter, Hub, Controller), Ebus (Wolf CGW-2, ISM7i), Fibaro (Flood Sensor, Wall Plug, 4 in 1 Sensor), Qubino (Flush 1D), Shelly (Plug S, H&T, 2.5, 1 PM), Tado (Thermostat V3+)

uxtuner

anscheinend bekommt der RandomTimer nicht mit, wenn Urlaub on/off geschaltet wird
Wenn ich "set randomTimer active" schalte berücksichtigt er den Urlaubs Status - was fehlt noch?
Viele Grüße
  Uwe

Intel NUC (VDR & FHEM), QNAP TS-453, OneWire (Temp. Sensor, 8-fach Schalter, Hub, Controller), Ebus (Wolf CGW-2, ISM7i), Fibaro (Flood Sensor, Wall Plug, 4 in 1 Sensor), Qubino (Flush 1D), Shelly (Plug S, H&T, 2.5, 1 PM), Tado (Thermostat V3+)

uxtuner

auch ohne "Urlaub" Kondition arbeitet das Modul nicht zuverlässig, hier mein letzter Stand:
Internals:
   COMMAND    off
   DEF        20:15 Deckenlicht_Treppe    23:00 900
   DEVICE     Deckenlicht_Treppe
   FUUID      66d02848-f33f-55bb-4598-6b03feb0f29151bd
   NAME       Simu_Treppe
   NR         398
   STATE      off
   TYPE       RandomTimer
   eventCount 23
   READINGS:
     2024-09-22 23:13:35   LastCommand     set Deckenlicht_Treppe off
     2024-09-22 03:58:06   StartTime       2024-09-22 20:15:00
     2024-09-22 03:58:06   StopTime        2024-09-22 23:00:00
     2024-09-22 03:58:06   TimeToSwitch    900
     2024-09-22 23:13:35   active          0
     2024-09-22 23:13:35   state           off
   helper:
     NEXT_CHECK 22.09.2024  23:13:35
     REL       
     REP       
     SIGMAWHENOFF 800
     SIGMAWHENON 200
     STARTTIME  22.09.2024  20:15:00
     STOPTIME   22.09.2024  23:00:00
     SWITCHMODE 800/200
     S_REL     
     TIMESPEC_START 20:15
     TIMESPEC_STOP 23:00
     TIMETOSWITCH 900
     VAR_DURATION 0
     VAR_START  0
     active     0
     offReading state
     offRegex   0
     startTime  1727028900
     stopTime   1727038800
Attributes:
   offState   0
   room       Abwesenheit
   switchmode 800/200

Gestern (23.09) hätte das Modul schalten müssen, da ist aber nichts passiert ...
Viele Grüße
  Uwe

Intel NUC (VDR & FHEM), QNAP TS-453, OneWire (Temp. Sensor, 8-fach Schalter, Hub, Controller), Ebus (Wolf CGW-2, ISM7i), Fibaro (Flood Sensor, Wall Plug, 4 in 1 Sensor), Qubino (Flush 1D), Shelly (Plug S, H&T, 2.5, 1 PM), Tado (Thermostat V3+)

Beta-User

Zitat von: uxtuner am 24 September 2024, 06:58:32Gestern (23.09) hätte das Modul schalten müssen, da ist aber nichts passiert ...
Sorry für die späte Antwort:
a) RandomTimer arbeitet Random, von daher ist "müssen" relativ. Es kann durchaus vorkommen, dass eben zufällig gar nicht geschaltet wird...
b) Ggf. müßte man mal schauen, ob eben zufällig alle Schaltungen auf "mache nichts" gefallen sind, ich bin aber nicht sicher, ob da bei verbose 4/5 viel zu sehen wäre. Notfalls müßte man mal den Code aufbohren, um mehr rauszufinden. Im Moment ist das hier seit langem der einzige Bericht über unerwartetes Verhalten bei RT, was eher für ein Verständnisproblem spräche.

War denn der "Urlaub" schon aktiv, als der RT seine "Tagesaktualisierung" gemacht hat? Das passiert (soweit ich mich entsinne) nur am Tagesanfang. Ändert man über den laufende Tag was, müßte man den RT nochmal initialisieren.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files