Different individual pulsetime for the timers

[drbitmap]

I have a requirement to set different pulsetimes for a output/relais, depending on the time.
Tasmota support a pulsetime for each output/relais, but unfortunatly this pulsetime is fixed for all timer events.
This requirement can maybe realized by script, but I (and maybe others) like to have a web interface to configure such simple timeout more easyily.
Reason as example:
watering system for flowers/garden:
mornig time: need more water (pump must work longer before auto-power-off)
noon time: need less water (pump must work shorter before auto-power-off)
evening time: need more water (pump must work longer before auto-power-off)

heather switching (by socket/relais):
morning time: longer heating period before auto-power-off
noon time: short heating period before auto-power-off
evening time: longer heating period before auto-power-off

Advantage:
No rule nor script need to be written.
No need to utilize an additional timer to switch off the output.
No limitation to the minimum 1 minute resolution of the timer setting.
No need to have a (WLAN) connection to the ESP to send power-off command, power off automactic done locally.
Timeout is as same as pulsetime (100ms steps until 11seconds or 1sec. steps until approx. 15 hours).
The web interface allows easy timeout setting (h/m/s/ms).

I already modified some code for testing (based on 12.2.0.3), mainly the xdrv_09_timers.ino, to support up to 16 individual pulsetimer.
The code:

• works fine as far as I tested and I will continue with the web interface for the timer (compressed and not compressed).
• is backward compatible to existing pulsetime, so if the "new timer-pulsetime" is set to 0, the original pulsetime is used (if not 0).
• returns the timer result incl. new PulseTime setting as example like:
  Timer1 {"Enable":1,"Mode":0,"Time":"14:15","Window":0,"Days":"1111111","Repeat":1,"Output":1,"Action":1,"PulseTime":120}
  or
  Timer1 {"Enable":1,"Mode":0,"Time":"14:15","Window":0,"Days":"1111111","Repeat":1,"Output":1,"Action":1,"PulseTime":0}
  instead of:
  Timer1 {"Enable":1,"Mode":0,"Time":"13:30","Window":0,"Days":"1111111","Repeat":1,"Output":1,"Action":1}
• solves a small internal issue with pulsetime as benefit.
  (if poweronstate = 4, than pulsetime (if set) will be everytime restarted, because power never goes off. This continues endless.)

NOW before I continue, a big question to the maintainer and developer team of tasmota:
I would like to utilze 16 words (32 bytes) of the settings area, to store all pulsetimers there.
The most logical place to put the variables would be the Timer structure, but this will move all following parameters to a different position (+32).
To avoid a parameter movement, I would like to utilize the memory area of the TSettings struct:
uint8_t free_ea6[32]; // EA6
and change it to something like:
uint16_t timer_pulse_timer[16]; // EA6
or
uint16_t timer_pulse_timer[MAX_TIMERS]; // EA6

Question:

1. Do you agree to use "EA6 memory area" or do you have other plans with this memory area?

Thanks a lot for your comment.
Volker
[screenshot sample web i/f]

[sfromis]

Gobbling up so much settings space for a quite slim edge case is not likely to be done in the project, especially when what you want can can be done with rules without too much trouble.

Reserving bytes in settings for single purposes is not a question of specific "plans", but about being parsimonious with very limited resources, with other solutions preferred. Some drivers get around this by not depending on persistent settings, but reestablishing values automatically after boot.

Disclaimer: I'm not project owner, nor much involved in development, the above "merely" aligns with what I've seen during my involvement.

[drbitmap]

Thank you for your comment sfromis.

I total understand and agree with you, to use as less as possible settings space.
Unfortunately timer settings (and pulsetimer) need to be persistent to surrive a power cut, if not always connected to a home automation.
Supporting 16 pulsetimers are maybe oversized and this quantity of pulsetimers may never be used.

1. Other idea can be to re-use a previous used pulse_timer setting space area to save data for up to 8 pulsetimer (instead of 16).

uint16_t ex_pulse_timer[8]; // 532 ex_pulse_timer free since 11.0.0.3

(Above setting memory was used originally for pulsetimer in older tasmota version).

Question:
-Still to much setting memory usage and if yes, what should be the maximum limit?

Thanks again for reviewing!

[sfromis]

I have no comment around the potential for reducing PulseTimer count, other than the history of having more than 8. I know there were users of devices with lots of relays finding that it did not fulfill their use cases not to have PulseTimer on all relays. As going from only 8 to more than 8 was a deliberate enhancement, going back seems less likely. Devices with 16 relays are not too uncommon, good for a central panel.

More generally, I'm not making decisions about what can be done here, but IMO what you want is a slim edge case, reasonably handled via rules (or other automation), instead of being a core part of the Tasmota builds. The Timers feature in Tasmota is created for the simple cases handling the large majority of needs, instead of more detailed profiles.

[drbitmap]

The target was not reducing the pulsetimer count. The number of existing pulsetimers in tasmota is untouched (MAX_PULSETIMERS = 32).
The goal is to allow a timer (MAX_TIMERS = 16) to start an "own, individual" pulsetimer, depending on the timer event.
First idea was to allow 16 pulsetimers (for each tasmota timer a pulsetimer).
But due to the memory requirement as you commented, other idea was to reduce the number to 8.
Like: timer 1...8 are able to support an additional "own" pulsetimer, where timer 8...16 are same as original and not having this feature.

I agree not to change the core just for "my slim edge case". I guessed that extension will increase the timer flexibility in general and there are some use cases.

Anyway, thank you. I will implement this functionality only for my private use, compiled into a separte binary for devices which requiere it.