Timer ranges

[sciurius]

Timers can be used to switch a device on or off on preset times.

A common use for a timed device is to be active between two times. E.g., water the garden from 05:00 till 07:00.

For (mostly) lights, sunrise and sunset are relevant times. E.g., lights on from sunset to 23:00 and from 07:00 to sunrise.

You feel it coming: What if the sun rises before 07:00...? IIUC, this currently requires complex configuration using rules. I think this should be trivial since it is such a common case.

This could be done with configuring ranges instead of endpoints. If the end point precedes the starting point, the range is ignored.

From UI perspective this could be very simple: just add a 'Range' checkbox to a timer and this will then consider this timer the starting poing, and the next timer the end point.

Does this make sense?

[rapi3]

It is very simple already to configure timers based on Sunset/Sunrise and required interval -/+ ( before or after ) from interface... check the documentation;
Sunrise/Sunset are calculated all the time automatically based of location and timezone configured by user.

[sfromis]

Where the complication comes is combining sunset/sunrise timing with fixed times taking control when the sunset/sunrise veers outside of this interval. This is manageable with a few rules, not very complex, but is more than merely having a sunset/sunrise timer.

[sciurius]

Exactly.

Moreover I think that the concept of ranges is more natural than isolated (independent!) on/off switching. You switch things on and later off again. Also, after a reboot, you can easily check if the current time is within some of the ranges, and act accordingly. You cannot do that with independent on/off switching.

[LucidEye]

Yes, this is a BIG fail-safe issue. This is why durations, or time-spans are a more robust way of programming a timer... a "looping-timer" can check itself after a power failure or reboot and pick up where it left off on an action... a single-point timer can not do that.

[rapi3]

In my automatization I think I am using range at this moment with PulseTime.

[gemu2015]

i made a special script for timer ranges. only drawback is an overnight switch has to be split into 2 entries.
another more complex script supports visualization and any number of outputs
advantage of ranges in case of restart the appropriate state is immediately set

compressed_script.txt
color_script.pdf

[ascillato2]

Nice !!!!

[sciurius]

Where can I get this?

[ascillato]

in the links above. between the 2 images.

[gemu2015]

the script is appended, you have to compile your own Tasmota version with scripting enabled.
you need the following additional defines.

#define USE_SCRIPT
#define USE_TIMERS
#define USE_SCRIPT_WEB_DISPLAY
#define SCRIPT_POWER_SECTION

[sciurius]

Ah, it's a custom version...

[Jason2866]

@sciurius We provide special builds. There is a scripting variant for esp8266 / ESP32 which includes the above defines.
https://github.com/tasmota/install/tree/main/firmware/unofficial

[sciurius]

Interesting, thanks!

[sciurius]

@gemu2015 I understand that I need to define the ranges in the script itself?
Is it possible to define e.g. 15 minutes before sunrise?
What does (end)time 0r730 mean?

[gemu2015]

Currently no offset from sunset sunrise implemented, should be easy however will think about it soon
0r730 is a typo should read 0730

[sciurius]

Excuse me for asking... What is {s}, {m}, and {e} ?

[barbudor]

These are "macros" that are replaced at run time by HTML code:

{s} = <tr><th>
{m} = </th><td>
{e} = </td></tr>

It saves flash bytes

[sfromis]

They are used for column-formatting the sensors on the Tasmota front page, each line having tags for start,mid,end

[gemu2015]

ok i checked for adding offsets to sunrise, sunset.
it can be added easily but it increases script size that will no longer fit in the standard precompiled build.

with a custom build you can use option
#define USE_EEPROM
#define EEP_SCRIPT_SIZE 6200

this activates a special mode where you get 6200 bytes script size.
(standard script size is about 2560)

with a 4m Flash size you may also use the Filesystem
there you can set script size with e.g.
#define UFSYS_SIZE 4096

[gemu2015]

what i did is doing some math in the descriptor line, so you can add offsets to sunrise or sunset
example:
=#ts("-1-5:-2+3:3:0")

so every single entry may be individually adjusted

i agree, mostly not necessary

[sciurius]

Are there real benefits of having a single parameter with colon-separated values over 4 values. E.g. =#ts("1500:2100:2:5") over =#ts(1500,2100,2,5) ?

[gemu2015]

both would be possible, however the separator is space not comma so
=#ts(1500 2100 2 5)
would take 4 separate parameters
may be this version could use less code space but would not allow this math =#ts("-1-5:-2+3:3:0")

in theory also web gui functions are available in scripter so input times etc are possible
eg this inputs a time
>D
t1f="15:30"
tmin="0000"
tmax="2359"

>W
tx(t1f "Timer 1 Start " "time" tmin tmax)

[gemu2015]

via a POST request.

[sciurius]

That must be one of the best kept secrets of Tasmota... No word in the docs.

[rapi3]

If you want to use rules it is not complicated:

Set your timer start time as you want and use to trigger rule with defined range.

Set your rule that will define pulsetime - interval for range and power on; something like this:
ON clock#Timer=1 DO backlog Pulsetime XX, Power1 ENDON
ON clock#Timer=2 DO backlog Pulsetime YY, Power1 ENDON
ON clock#Timer=3 DO backlog Pulsetime ZZ, Power1 ENDON
...
or if you have a device with UFS filesistem you can define/edit (Timer01....) and run from there the commands you want
ON clock#Timer=1 DO UfsRun Timer01 ENDON

if you also turn on/off manually or from another device then add:
ON Power1#state=0 DO Pulsetime 0 ENDON

[sciurius]

I notice that the scripts-enabled firmware does not send a STATE message when the state is changed by the script or manually. Observers will therefore have to wait until the periodic STATE message (once every 5 minutes) is sent.
The regulat firmware sends a STATE message immedeately.

Is this a feature or did I miss a magic setting?

FWIW: The Domoticz message is immedeately sent after a state change.

08:22:22.920 CMD: power 1
08:22:22.931 MQT: domoticz/in = {"idx":368,"nvalue":1,"svalue":"19","Battery":100,"RSSI":7}
08:22:22.934 MQT: stat/bulb02/RESULT = {"POWER":"ON"}
08:22:22.938 MQT: stat/bulb02/POWER = ON
08:26:38.373 MQT: tele/bulb02/STATE = {"Time":"2022-01-24T08:26:38","Uptime":"0T00:05:09","UptimeSec":309,"Heap":20,"SleepMode":"Dynamic","Sleep":10,"LoadAvg":42,"MqttCount":1,"POWER":"ON","Dimmer":19,"Color":"0631000000","HSBColor":"113,100,19","White":0,"CT":153,"Channel":[2,19,0,0,0],"Scheme":0,"Fade":"OFF","Speed":1,"LedTable":"ON","Wifi":{"AP":1,"SSId":"Oh Denneboom","BSSId":"xx:xx:xx:xx:xx:xx","Channel":11,"Mode":"11n","RSSI":84,"Signal":-58,"LinkCount":1,"Downtime":"0T00:00:03"}}

[barbudor]

The 3rd and 4th line of your logs are sent immediatly. It shows the state change as per the "stat" prefix included in the topic.
The 5th line is the periodic telemetry message ("tele" prefix) which is a recap sent only at periodic time
This is the standard behavior of Tasmota

I known nothing about the Domoticz integration but to be consistent with Tasmota behavior, the immediate message to Domoticz would be more logical that it includes only the changed states. So may be it is a requirement of Domoticz ?

[sciurius]

In this case it is HomeAssistant that doesn't pick up the state change until the STATE message is received.

I merely noticed the difference between the regular 10.1.0 firmware (that sends the STATE message immedeately) and the scripting enabled build 2022.01.3.

[sfromis]

You should also be able to use SetOption59 to get .../STATE published after commands like Power.

[i-perfectus]

can You share bin file?

[sciurius]

I try to understand the GUI...
The ±value doesn't make sense with fixed times, does it?
Would it be possible to combine the time and hh:mm fields into a single field that can contain either sunrise, sunset, or a hh:mm value? Or maybe something like sr+0:15 (15 minutes after sunrise)?

[sfromis]

No, combining would lose a feature of the timers. As the docs about Timers explain, the +/- window of up to 15 minutes allows for a random number to be added/subtracted. When you use Sunrise/Sunset, the hh/mm values below gets another +/- sign and becomes a fixed offset from the varying sun-dependent time, which you then can tweak with a bit of randomness too.

[gemu2015]

currently the offsets are valid for sunrise, sunset. if you select sunrise, sunset the appropriate times are filled into the time field. since the page is dynamic html under script control you could easily hide the offsets in case of fixed times.
the complete script is 3.6k which leaves about 2,5 k left for modifications.
since this implementation does not rely in any way to the Tasmota timers and also uses its own permanent storage you are completely free to design it as you like.

[gemu2015]

here is 1M max script size binary (in english) i included energy sensor for e.g. gosund
later i will provide some example scripts like this gosund one.

tasmota-1M_maxscript.bin.gz

[gemu2015]

current state of range timers:

[Jonsonmon]

current state of range timers:

It looks fantastic and exactly what I need, could you please post the script you made with all the changes for sunrise offsets etc... ?

[gemu2015]

in this link you find a collection of special scripts like the above
https://www.dropbox.com/scl/fo/9ltbureyz71se5i7t4yvw/AJLcMsK98Cx_rhLQ3xA05eY?rlkey=uuxsn04d17lng6djkmtgie5kv&e=1&dl=0

[Swyter]

In case anyone else searches for this.

I made a tiny Berry script that reuses the Tasmota timer functionality, to turn a pair timers into a start-end range, shutting it down e.g. when a reboot happens and NTP time is still not configured (no Internet, wrong time/date on startup) and other fail-safe features that Tasmota lacks, like not shutting down something when there's a brownout and the end range timer never fires due to the device being inoperable at that second, even it it's just a small blip.

So it otherwise would stay on for the rest of the day, unlike even the most basic mechanical timer that would take care of this (which I find very silly and a regression of functionality for such a "smart" device).

So yeah, this adds that back:

https://github.com/Swyter/tasmota32-berry-timer-interval

Doesn't currently support sunrise/sunset or random offsets, though, but it does what I need it to do.

---

To use it you just upload autoexec.be via the Tools > Manage File system web browser into the root folder. Then edit it to set which two timers are linked together and monitored.

By default it checks (and logs) if we're inside or outside the active interval every single minute, reacting accordingly.
But you can change it here.

For example, under Configuration > Timers I configure timer 1/t1 as start of the range (on) and timer 2/t2 as off. The first argument in the check function below is just to confirm that both should control the second/2 Tasmota switch, it must match the "output" value in both timers.

check_timer_interval_between(2, t1, t2)

Not the prettiest, but seems to work well against real-life shenanigans. Hope others find it interesting.

[Jonsonmon]

In case anyone else searches for this.

I made a tiny Berry script that reuses the Tasmota timer functionality, to turn a pair timers into a start-end range, shutting it down e.g. when a reboot happens and NTP time is still not configured (no Internet, wrong time/date on startup) and other fail-safe features that Tasmota lacks, like not shutting down something when there's a brownout and the end range timer never fires due to the device being inoperable at that second, even it it's just a small blip.

So it otherwise would stay on for the rest of the day, unlike even the most basic mechanical timer that would take care of this (which I find very silly and a regression of functionality for such a "smart" device).

So yeah, this adds that back:

https://github.com/Swyter/tasmota32-berry-timer-interval

Doesn't currently support sunrise/sunset or random offsets, though, but it does what I need it to do.

To use it you just upload autoexec.be via the Tools > Manage File system web browser into the root folder. Then edit it to set which two timers are linked together and monitored.

By default it checks (and logs) if we're inside or outside the active interval every single minute, reacting accordingly. But you can change it here.

For example, under Configuration > Timers I configure timer 1/t1 as start of the range (on) and timer 2/t2 as off. The first argument in the check function below is just to confirm that both should control the second/2 Tasmota switch, it must match the "output" value in both timers.

check_timer_interval_between(2, t1, t2)

Not the prettiest, but seems to work well against real-life shenanigans. Hope others find it interesting.

Thanks for that
But I really need sunset/sunrise with offset...