Different simple Logic?

Community Playground General Discussions
1

We probably haven’t killed the AND/OR topic yet (or did I miss the conclusion?). I suspect that maybe there is a different construct that will work, yet maybe still not satisfy the true geeks out here.

What about IF/THEN or IF/THEN/ELSE ?

Add a new button in a scene called “Add Conditional”.

IF (sundown /defined as the time between sunset and sunrise/)
THEN command

If the motion sensor trigger the scene, it will only turn the light on during sundown. No AND/OR Boolean logic (it’s there, but average Joe won’t know).

And this isn’t hard to code or make a GUI for.

Anyone need a U12 example, or was this clear enough?

2

I like the If/Then idea. If I have a scene that’s called “A/C or Heat” I could do the following.

If temp is <68 turn on heat.
If temp is >75 turn on cool.

3

seems like Javier has a plan pretty well worked out for at least adding AND to the current OR.

see his post #27 in this thread: http://forum.micasaverde.com/index.php?topic=3185.0 (BTW that seems to be the thread for constuctive discussion how to implement such a thing rather than the pissing matche threads debating if there is any value to it or not)

So far, it seems that the simplest way is to simply add more conditions to the event definition screen.

Currently, you can only define a single variable to be compared to a single argument. Adding more of these (variable/operation/argument), would do the trick. The event would fire only when all conditions are met. This is the AND.

Then, simply defining several events with the same result takes care of the ‘outer’ OR grouping.

The UI impact is minimal, and so is the extra burden on the user. I don’t know if you have already begin sketching that part (the scene/event/trigger/timer definitions); for now, simply allow for multiple conditions on a single event trigger.

What we still have to define is about the ‘back of the frontent’. Currently, it builds a JSON structure described here http://wiki.micasaverde.com/index.php/Luup_Events. We could either extend this structure, and change the Luup engine to handle it, or we could drop this structure and make it always generate Lua scripts, even for simple events.

To be honest, now it seems that this was what the users were asking from the beginning; but for hardcore programmers it wasn’t obvious. At least for me, as soon as you pass the simple list of options, you’re in programming territory. And if you don’t want to program, you need a code generator. No middle grounds! But it seems that just this addition, limited as it is, will make a big difference for some users.

In any case, the visible portion of the UI is almost unchanged (in concepts), the real work will be in how it communicates with the backend.[/quote]