Version 1.0 Pre-release Discussion
-
@librasun @fanan I think this is a better example, if I may:
In this example, the condition would be true if house mode is "Away" or "Vacation". Works the same as the R4V example you posted (had those boxes been checked).
EDIT: Too much blood in my caffeine system this morning; I didn't see @LibraSun 's values (wrapped to new line) in his original image, so his example is actually fine.
@toggledbits - should there be a space after the comma? "home,night" or "home, night"? Does it matter?
-
No spaces, unless the space is part of the string you want to detect.
-
It might be nice for global reactions to get a timestamp so that we know the last time one was run. Right now I have rules that run the set reaction of other rules directly, and I am unable to know precisely when those executed because the target rule is never technically set.
But having at least a last-run time for global reactions makes sense.
-
Also, could a very slight (500ms?) delay or "fade away" be added to "Set Rules" and "Running Reactions" so that one gets a glimpse of "What just happened?" MSR is so fleetingly fast that even knowing what rule or reaction is about to execute, my eyes never see more than a blip, then blankness.
-
Suggestion for MSR version 2 or 3.
In Tiggers and Reactions could have an Action by Category/Sub-Category, i.e., instead of having to select all door sensors one by one, if all are in the same group the action would be for all.
I believe there should be a panel similar to Enteries that would list all the devices based on the existing list (http://wiki.micasaverde.com/index.php/Luup_Device_Categories). The list would have this division and would show the name of all the devices, and it should be possible to select which device would be part of the action. I.e., I can have for example 10 window sensors, but I want only 5 to be part of the group action, I would deselect the other 5 for an independent control.
In Trigger and Reaction the selection would be as suggested Entety Group Action > a Category selector > and a Subcategory selector > binary_sensor.state (primary) TRUE or FALSE.
My suggestion is not to have to create an action like the one below.
-
This horse may have been ridden already above and I just missed it but here goes: Is it possible to make
Current Alertsclick-thru to the offending Ruleset? I had to scramble to do some renaming just so I could figure out what ruleset was having the issue when it got flagged there. -
Another suggestion for upcoming versions is to have some of the most common Expressions easy configurable and available by default. Many of us, including myself, who chooses MSR instead of coding in luup or yaml or even use Node red - do that mainly because of our lack of coding experience. Therefor we would really appriciate all the help we could get, and if I'm correct, it would even be more accessible for a broader audience - just like Vera is more accessible for the common person than HA. An example that I think of is the difference in temperature (or other values) between a sensor indoors and a senor outdoors, would be neat to have as a choice by default. There must be a lot of similair examples . Don't know if this is possible to achive or worthwile, but I thought it was worth to throw it up in the air and see if anyone or anything catches. By the way - have a great weekend!
-
Perhaps your example (which is basically just subtractions of two numbers) is too trivial. But my current thinking in response is that (a) if you want to use expressions, learn how to use expressions, and (b) each expression is the... uh... expression of a lot of local knowledge applied to the problem (what the devices are, why you want to do it, how it will be used, etc.). There isn't enough "common" there to make it worth including in the system itself. It's not a problem requiring a feature solution; documentation would likely be sufficient, including prior Q&A in forum posts.
But to reiterate, this is going to be a hard and fast rule for me: if you want to use a tool, invest the time to learn how to use the tool. You cannot build a reliable and supportable environment for yourself by assembling parts you don't understand. If a problem is important enough for you to want to solve, it's important enough for you to learn how to solve it.
-
Point taken. Thanks for your swift reply. I totally agree with you. It's important, not to say crucial, to understand the tools you're using. It was a longshoot, born out of lazyness, combined with a very limited portion of time - and so much to learn in home automation, especially for us with no coding skills. But as they say; every journey starts with a single step...
-
I plan to contribute examples of expressions that have worked for me with hopes that the most basic ones might get incorporated into the official documentation. Yet I agree with Patrick that it could be unwieldy to include those templates in the body of MSR itself.
-
I plan to contribute examples of expressions that have worked for me with hopes that the most basic ones might get incorporated into the official documentation. Yet I agree with Patrick that it could be unwieldy to include those templates in the body of MSR itself.
I was just going to reply to @Fanan about reading examples on the forum can really help point you in the right direction. @LibraSun posted some examples of some things I was struggling with, and that made all the difference. Carefully dissect the examples, refer back to the docs, and the dots will start to connect.
One thing that I think helped me a whole bunch was an Amazon Prime "The Great Courses" course on programing called "How to Program: Computer Science Concepts and Python Exercises." (only $7.99 a month for access) While it is not an MSR programing language course, it helped give me some foundational knowledge that sort of transfers. An example of this would be the principle of "lists" in Python to help you understand the basics of "arrays" in MSR.
Small steps and little victories will keep you going.
-
T toggledbits locked this topic on
