Subject: Allow multiple timer plans per timer (and some related ideas)

Use this forum to discuss possible implementation of a new feature before opening a ticket.
A developer shall edit the topic title with "[xxx]" where xxx is the id of the accompanying tracker id.
Duplicate posts about the same id. +1 posts are not allowed.

Moderators: leecollings, remb0

Post Reply
vobo
Posts: 2
Joined: Tuesday 30 January 2018 10:50
Target OS: Raspberry Pi / ODroid
Domoticz version: 2021.1
Location: Krakow, Poland
Contact:

Subject: Allow multiple timer plans per timer (and some related ideas)

Post by vobo »

Feature suggestions:
  • (1) Allow the same timer to be present in multiple timer plans
  • (2) Create a mechanism to detect timer plan changes in scripts
  • (3) Possibly list associated timers in: Setup->More options->Plans->Timerplan

Rationale:

Timer plans should be related to timers much like rooms to devices. A device could be in many rooms while, currently, a timer could belong only to one timer plan. Timer plans could become a really usable tool for automation, if they are a bit more flexible.

Rooms provide an elective grouping of devices. We may understand rooms as static views of the configuration (what you possess). Timer plans should reflect all dynamics of your home (how you use what you have). Which is to say, they should reflect more than just switching timers; one should be able to react to a timer plan change the similar way, how it’s possible in scripts to react to a change of a device status.

The current implementation of timer plans have two conflicting functionalities:
  • (a) You use an active timer plan to switch sets of active timers
  • (b) You use an active timer plan to assign to it a timer just being created for a device
Thus, if you need to create a timer for a device in some plan, you need to actually switch to that plan, which may fire other already existing events related to that plan – an action not always welcome. It is also a frequent case, when you would like to have the same timer available in many (if not all) of your timer plans. E.g.: I have three aquariums in the house and need to change lights, switch off aeration while switching on food dispensers, etc. – regardless of whether I’m at home, away or the alarm is armed.

I have 5 timer plans: off (everything switched off just in case of some problems), home, away, armed and party. If I need to have the same timer present in all of them, I need to enter separate copies of it. Should I need to change such a timer, I’d need to do it in all the copies separately. Let’s assume I have timer(s) to close or open blinds, that I use in a few of my plans. Should a mechanical or electrical failure happen to my blinds, I'd need to “disable” (currently meaning – DELETE) all the respective timers until my blinds are fixed and then, enter all of them again from the scratch.

The way it should work, imho, is that when you create a timer for a device, you should be able to select multiple timer plans this timer belongs to, instead of it being assigned to just one, currently active timer plan. This should be easier to implement and use than a separate list of timer plans to which timers are assigned – like devices are assigned to room plans. However, the database solution might be similar to the “DeviceToPlanMap” in domiticz.db database table. Such an assignment would also allow to temporarily disable a particular timer altogether without actually deleting it. Some additional enhancement though, would be listing the associated timers when entering Setup->More options->Plans->Timerplan (my suggestion (3)).

As timer plans may be used to much more than just switching timer sets (e.g. one may need to turn some switches on or off, adjust thermostats, etc. – depending if we are at home or away…) some way to react to timer plans change would be nice to have in scripts. Now, the ways to achieve it I can think of, is either to consequently use a selector switch with associated JSON actions assigned to its positions and react on changes in that switch (taking possible loops into consideration) or to do some `hacking` - that is to create a domoticz variable and a trigger in sqlite database that changes the variable when the active plan is being changed. For now, the latter works for me, although I’d prefer to have some standard solutions in domoticz or ezVents scripts.

Matt
/using v3.8841 self-compiled on Rpi 3/
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest