You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ;)
The text was updated successfully, but these errors were encountered:
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)
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)
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
inxdrv_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 inuser_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:
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 ;)
The text was updated successfully, but these errors were encountered: