Let's Control It

Hello all.

Not sure exactly when rules went from 1 page to 4 available pages. I'm wondering if there is an easy way to turn on or off a page of rules. Lets say you have a setup that uses timers to control sprinklers and you need a couple different programs to control them. Like a winter vs summer schedule. So an easy way to turn "off" say a page and turn "on" another?

Is this possible? Obviously one can remove one set of rules and replace them easily via the webpage. Be nice to be able to "throw a switch" to change tho....

Hope everyone has a great holiday!!

I'd use conditions which only trigger between certain dates. Or have a physical switch that you can use to select if the rules should be activated or not.

Not possible to opt-out on pages. It might be a good idea though. If you want you may open a enhancement request on GitHub.

I like the switch idea. Probably be easier to set up. Maybe...... conditions to control rules to control rules that work under these conditions.... but not that condition.... My head is spinning already.

Does anybody else think it would be a useful enhancement? If so I can put a request on git.

+1 definitely

Yes it would make even more sense to have multiple rules pages. A command like this to activate or inactivate the pages:
rulepage,<page number>,<activate=1 inactivate=0>

+1

I need to admin I have all this logic in my server/broker but indeed it coudl be great to be able to decentralize this to a single module!

Where is the problem?

papperone wrote: ↑24 Dec 2017, 15:18 +1

I need to admin I have all this logic in my server/broker but indeed it coudl be great to be able to decentralize this to a single module!

What would be the benefit of decentralizing this to a single module, Papperone? Just curious.

To me decentralizing makes the controller implementation a lot more stream line since I don't have to handle internal logic of every single unit. I like to have the controller only acting like a link between all nodes/units since they are the ones that actually do something.

But I know that this is a ongoing debate, some think large mainframes and thin clients are the way to go, some think the opposite...

grovkillen wrote: ↑06 Jan 2018, 19:53 To me decentralizing makes the controller implementation a lot more stream line since I don't have to handle internal logic of every single unit. I like to have the controller only acting like a link between all nodes/units since they are the ones that actually do something.

But I know that this is a ongoing debate, some think large mainframes and thin clients are the way to go, some think the opposite...

I agree.
I see that like an organism, the human body for example. Most things are done automatically.
The eye's iris adapts automatically to brightnes, the brain gets just the information about more or less bright.
I could list a lot of such processes here.
So my sensors/actors (should) do most things based on themselves and just give info to my FHEM controller.
Only really complex sets with many rules and much logic, possibly including data from several sensors and
actions for many actors should be done by the controller.

Shardan wrote: ↑06 Jan 2018, 22:43

grovkillen wrote: ↑06 Jan 2018, 19:53 To me decentralizing makes the controller implementation a lot more stream line since I don't have to handle internal logic of every single unit. I like to have the controller only acting like a link between all nodes/units since they are the ones that actually do something.

But I know that this is a ongoing debate, some think large mainframes and thin clients are the way to go, some think the opposite...

I agree.
I see that like an organism, the human body for example. Most things are done automatically.
The eye's iris adapts automatically to brightnes, the brain gets just the information about more or less bright.
I could list a lot of such processes here.
So my sensors/actors (should) do most things based on themselves and just give info to my FHEM controller.
Only really complex sets with may rules and much logic, possibly including data from several sensors and
actions for many actors should be done by the controller.

Great analogy Shard!

Pasters wrote: ↑06 Jan 2018, 19:34

papperone wrote: ↑24 Dec 2017, 15:18 +1

I need to admin I have all this logic in my server/broker but indeed it coudl be great to be able to decentralize this to a single module!

What would be the benefit of decentralizing this to a single module, Papperone? Just curious.

Justa a stupid example: Garden Light control rules
- I have 2 different setup (winter and summer) which are selectable on the server as the ESPEasy modules are brainless (simply handlng on/off of devices)
- Each setup has different rules and presets which at the moment are handled at server level
- If I add a new device/light to my setup I need to go to the server and add it to the program
- to handle different behaviours in the same "scene" makes the logic program at server level more complex

With selectable rules-set I coudl create for each node 2 behaviours: summer and winter
- each node can have his own "logic" to handle the same "scene"
- from server level I need only to send out which ruleset to apply: e.g. "summer" or "winter" and all nodes will implement the local logic
- any new addition will be "locally programmed" via rules-set and nothing has to be changed either in the server nor in existing nodes
- each node can implement differen logic for the same "program" (again summer or winter)
- al nodes can be independent from the server broker/aggregator and even to be able to work in stand-alone

I know there always be people agrees with this and people who thinks diametrically opposite but still havign the option of "selectable rules-sets" can make ESPEasy much more flexible and all-purpouses!

Shardan wrote: ↑06 Jan 2018, 22:43

grovkillen wrote: ↑06 Jan 2018, 19:53 To me decentralizing makes the controller implementation a lot more stream line since I don't have to handle internal logic of every single unit. I like to have the controller only acting like a link between all nodes/units since they are the ones that actually do something.

But I know that this is a ongoing debate, some think large mainframes and thin clients are the way to go, some think the opposite...

I agree.
I see that like an organism, the human body for example. Most things are done automatically.
The eye's iris adapts automatically to brightnes, the brain gets just the information about more or less bright.
I could list a lot of such processes here.
So my sensors/actors (should) do most things based on themselves and just give info to my FHEM controller.
Only really complex sets with many rules and much logic, possibly including data from several sensors and
actions for many actors should be done by the controller.

that's a perfect way to describe what I do envision as ideal setup!

Thanks grov and Papperone.

Two examples how to do that:
First (non ESPEasy): I'm using radiator valves from eQ3, the MAX! series. They are radio controlled from my FHEM server - but the server
just reads temperature, battery state etc. The controller sets the weekly schedule stored inside the valves and i can set another temperature
manually that stays until the next schedule time. On top i can always manually turn the button on the valve itself to vary temperaturer.
The week schedule is standalone - the valves go on with the schedule even if i switch off the controller completely.

Second: I'm workig on a pH/ temperature controller for fish tanks. Definitely it would more comfortable if i could set values from
home controller. On the other side this setup would depend fully on working server, working WiFi etc. As one usualy does not
change these values often i decided to put them into rules making the controler as "standalone" as possible. Better for the fishies
The pH/T-Controller reports to the homecontrol, that's all.
(A way to store the given values from homecontrol would be nice anyways, but i'm not sure if a dummy variable is a good way as it
might get lost after a short blackout).

Regards
Shardan

Isn't there a way to store the values in an mqtt broker, not that I'm using it, I just remember having read about it on the forum...

No chance to do this at the moment. You can not enable/disable a rule with a command and you can not change the complete rule text with a command. So a MQTT broker is useless. You have to expand the source code for this new function.

- rules engine must be changed
- web server must be changed
- command engine must be changed
- the rules store structure must be changed (1 new byte for enabled/disabled) per rule set

With all that done it works.