Declarative programming in Reactor?

[Vinx]

Having been a PLEG fan forever, I’ve only now taken the time to look at the splendid work you did on this great plugin. I understand that most find this plugin easier to learn than PLEG, but my brains must be weird, because I find it the other way around so far .

Reactor being a rule engine, I’m trying to use it in a declarative way, so that I “just” describe what has to happen under what conditions (and nothing more). Setting and returning to a “last state” as is shown in the video’s is not declarative though (it’s procedural) and could have strange effects if something happens in between. For example if you leave the house (and let Vera know it), you wouldn’t want the thermostat go to the last state (it’s now off because you left the house). You could add that logic of course, but that would increase the complexity of the logic with each variable, wouldn’t it? My preference would be to take into account all situations and define when the heater should be on. In PLEG I have this:
Winter and (Home or GoingHome) and !Sleeping and !LateEvening and !BackDoorOpen

I could easily recreate this in Reactor, but I would end up with many Reactor devices (50-ish), or in any case that many Reactor-groups (grouping them for usability rather than logic).

Have others run into this? Do (any of) you have any advise on a suggested “knowledge architecture”?

[rigpapa]

Hmm… not sure where/how you get the impression you have to create 50 ReactorSensors. Reactor has long had the ability to group conditions, and test groups. If you wanted, you could automate your whole house in a single ReactorSensor.

Your example, in Reactor logic, using one ReactorSensor, would be structured something like this:

• Root group - AND
  • Group “Winter” – AND or OR as needed by its conditions to determine when winter occurs
  • Group “Home or Going” – OR
    • Group Home – AND/OR
      • …conditions to determine home; no group needed if single condition
    • Group GoingHome – AND/OR
      • …conditions to determine “going home”; no group needed if single condition
  • Group “Sleeping” – AND/OR + NOT
    • …conditions to determine you’re sleeping; no group needed if only one condition.
  • Group “LateEvening” – AND/OR + NOT
    • …conditions to determine it’s late evening; no group needed if only one condition.
  • Group “BackDoorOpen” – AND/OR + NOT
    • …conditions to check back door state; no group needed if only one condition.

…and you could even enclose the entirety of that within a group, and then add other logic to the ReactorSensor to other things, related or unrelated. Activities (actions) can be assigned per group as well, you’re not just using the ReactorSensor as a scene trigger.

But in this way, groups can mimic each component of a logic expression such as what you gave. Subgroups provide parenthetical nesting and precedence. They can express both logic and organization/(re)usability. I don’t think there’s anything stopping you from being declarative in your approach. Like PLEG, there is often more than one way to do something. Do whatever works best for you (suggestions from me are merely to help people solve problems expeditiously, but are neither “the right way” or “the only way” in most cases).

Check out these docs for more info, and feel free to ask more questions…

Reactor wiki – Conditions (covers intro to groups)
Reactor wiki – Modular Logic
Reactor wiki – Activities

An example, as well–I haven’t had time to make the YouTube video, but here’s a basic alarm system with entry delay (perimeter zone with delay) and immediate zones (smoke detectors) implemented entirely using the Modular Logic idea in a single ReactorSensor. It uses house mode as its arming driver: Home = smoke detectors only, Night = “stay” mode (interiors off, perimeter secured), Away/Vacation = interior and exterior secured.

As I said, I plan on a YT video explaining this step by step and showing how it works. But for this purpose, you can see you can groups to create logic elements (the groups under the “Logic Elements” parent group), and then use those groups in conditions (which is actually done throughout–everywhere you see “Group State” conditions). That’s not at all unlike PLEG, where you build conditions from triggers and other conditions.

[Vinx]

Thanks for taking the time to answer so quickly and thoroughly. I’m already familiar with the group actions (its just that 50 groups with logic like the example would still feel like I’m not using reactor in its strength somehow…) and using the group state in logic, which is really powerful indeed! I’m just careful I guess before i start rebuilding my whole house logic Nevertheless, using your example, I’ll have another go at how the architecture would look like using the group states. Thanks again and keep up the good work (love the video’s!!)