Version 1.0 Pre-release Discussion
-
Would a Menu item for accessing the reactor log file or portion of the log be possible.Or ideally a way to monitor the log in real time from the GUI for troubleshooting?
@sweetgenius said in Version 1.0 Pre-release Discussion:
Would a Menu item for accessing the reactor log file or portion of the log be possible.Or ideally a way to monitor the log in real time from the GUI for troubleshooting?
+1 for this.
-
How about exposing the Status and Alerts levels under Reactor_System, so that Rules could be written to react to, say, a Rule getting stuck SET for too long, or the count of a particular (esp. unexpected) Alert going too high, etc.? I love my warning messages!
-
Potential change: now that constraints apply to groups in a Rule's reactions, I see no value in keeping the Constraints as a separate subsection at the top level of a rule (that is, the section between Triggers and the Set Reaction when you edit a Rule). So, I'm thinking about removing them from here (any rules you have with constraints in this area would just get them restructured into a group constraint).
Thoughts?
-
Hi!
I've only been using MSR for 3 days, so I'm too much of a beginner to have opinions, but I want to try to collaborate:
-
First thanks to @cw-kid , with the simple tip of the installation page in the manual, I finally managed to take the step and install it on Windows 10. I see some comments on automatic startup, it was simple to put in the task scheduler a bat to run the "node app.js", and works very well on computer restarts. Now I did not understand why the instruction "Running Reactor Continuously" with the command "nohup ./app.sh &", what is the difference?
-
Regarding the Constraints question, I don't see much value, or don't know how to use them. I thought that if we first have the obligation to meet the Constraints (e.g. be in home mode and time between 8am and 5pm), only then do we start evaluating the Triggers (e.g. movement in room, open door...) it would make more sense to me. That is Constraints as a basic obligation, and Triggers in the next group of the variables of the action. Right now I'm thinking of putting everything in the Triggers block.
As I commented I only have 3 days, but I already see that Patrick @toggledbits again doing an exceptional job, if the Reactor was already great, I do not know how to classify what will be the MSR by the little I've seen. What I see for the future:
-
A translation will be needed in the selectors of so many technical terms, for a more fluent, layman-friendly message. An example FROM x_vera_svc_micasaverde_com_SecuritySensor1.Tripped TO only Tripped;
-
A dashboard unique to the Rule Sets. What you have today allows us to turn on/off, edit, reset... I think of something simple and straightforward like the Action Icon (I love the Reactor icon), green color on, yellow already have conditions met and could go into execution, and red in execution. It would be a dashboard for easier visualization on the phone. If you can then configure that shows or not would be great, who knows version 3, 4....;
And sorry this may not be the forum, but reading the posts I see a strong tendency to recommend the use of the Docker container. Is there a real difference in usage with respect to having the Windows 10 installation? Are there performance issues? Any functions that will not operate well? Is the communication between HA and the computer running Windows 10 worse? I see on the Vera panel that a device changes condition to unTrigger, and it takes quite a while to see the reaction on the MSR, is there a difference between container and windows?
Once again my many thanks to everyone for the work being done, I finally see a light in not depending on hardware to be able to have good automation at home, in a simpler way. As many have commented, soon Vera will be just a radio antenna
-
-
I would love if there was an option, at least for us old Vera users, to be able to use the house modes natively, which is possible in the Vera reactor app.
-
It's possible, but looks a bit different in MSR, since instead of a pick list you must type your own:
In this example, the condition would be true if house mode is "away" or "home".
Possible values are
home,away,nightandvacation. -
It's possible, but looks a bit different in MSR, since instead of a pick list you must type your own:
In this example, the condition would be true if house mode is "away" or "home".
Possible values are
home,away,nightandvacation.@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.
-
@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.
