Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More than 8 RuleTimer #3561

Closed
benzino77 opened this issue Aug 23, 2018 · 2 comments
Closed

More than 8 RuleTimer #3561

benzino77 opened this issue Aug 23, 2018 · 2 comments
Labels
enhancement Type - Enhancement that will be worked on fixed Result - The work on the issue has ended

Comments

@benzino77
Copy link

Have you look for this feature in other issues and in the wiki?
Yes
Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
It is mainly general question whether changing
#define MAX_RULE_TIMERS 8 to lets say #define MAX_RULE_TIMERS 16 in xdrv_10_rules.ino file is dangerous in terms of stability. There is this default limitation (8) for some reason.

Describe alternatives you've considered
Well, I've changed MAX_RULE_TIMERS to 16 (recompile, upload new firmware) and it looks like it works, but I need an opinion from developers how safe it is or what are the possible traps. Will it help or mitigate threads if I "strip" the code from most sensors (by disabling them in user_config_override.h) and leave only i2c and MCP support?

Additional context
Recently MCP23017 sensor was added (OUTPUT functionality) which give us the ability to have 16 relays (or more) which can be controlled by Tasmota. I'm planning to use Tasmota and MCP230xxxx for watering system and the possibility to turn off the relay automatically after defined period of time (even if there is no MQTT or WiFi) could prevent the situation when my garden became a lake ;)

Here is the solution I thing to use:
define rules:

on event#R0 do backlog ruletimer1 %value%;sensor29 0,on endon on rules#timer=1 do sensor29 0,off endon
...
on event#R9 do backlog ruletimer10 %value%;sensor29 9,on endon on rules#timer=10 do sensor29 9,off endon

then from controller/mobile/whatever I can do event R5=60 to start watering of section 5 for 60 seconds.

(Please, remember to close the issue when the problem has been addressed)
Ok i will remember ;)

@arendst
Copy link
Owner

arendst commented Aug 23, 2018

Other than that it uses more RAM (4 bytes per timer) and that looping the rule timer check is doubled I see no real problem.

@benzino77
Copy link
Author

That's a great information.
Maybe you can consider to allow the "overwrite" this parameter MAX_RULE_TIMERS in user_config_override.h?

arendst added a commit that referenced this issue Aug 23, 2018
6.1.1.9
 * Allow user override of define MAX_RULE_TIMERS (#3561)
 * Allow user override of define MAX_RULE_VARS
 * Add GPIO options ButtonXn, SwitchXn and CounterXn to select INPUT mode instead of INPUT_PULLUP (#2525)
 * Fix OtaMagic when file path contains a dash (-) (#3563)
@arendst arendst added enhancement Type - Enhancement that will be worked on fixed Result - The work on the issue has ended labels Aug 23, 2018
@arendst arendst closed this as completed Aug 23, 2018
curzon01 pushed a commit to curzon01/Tasmota that referenced this issue Sep 7, 2018
6.1.1.9
 * Allow user override of define MAX_RULE_TIMERS (arendst#3561)
 * Allow user override of define MAX_RULE_VARS
 * Add GPIO options ButtonXn, SwitchXn and CounterXn to select INPUT mode instead of INPUT_PULLUP (arendst#2525)
 * Fix OtaMagic when file path contains a dash (-) (arendst#3563)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Type - Enhancement that will be worked on fixed Result - The work on the issue has ended
Projects
None yet
Development

No branches or pull requests

2 participants