Version 1.0 Pre-release Discussion
-
This might be off topic and it also reveals my lack of programming skills. But I wounder how is MSR going to be installed, once it leaves beta? I use it on a stationary Windows 10, and the problem is if the power goes out. Then my PC reboots and I have to start the app and change catalog and finally execute "node app.js". I could install it on a RPi, don't know if it can work alongside and on the same RPi as I got Home assistant installed? Then it would start straight away, when the power gets back. To summarize, it's basicly two questions;
- In which ways are we going to be able to install and start up MSR?
- Is it possible to install MSR on a RPi that already is running HA? Or on a Home assistant blue (Odroid N2+)?
Another feature that would be nice is to have a optional setting of automatic updates.
Regardsless - MSR is a great (one of the best) contribution to the smart home community - at least for me. Great job!!@fanan said in Version 1.0 Pre-release Discussion:
Another feature that would be nice is to have a optional setting of automatic updates.
I'll address this issue separately.
I think there are two interpretations here, so I'll start with the interpretation that I would more specifically call "unattended upgrades". Philosophically I'm opposed to unattended upgrades in all things, particularly on things that become "mission critical" in my environment. There is no "good time" for such updates except when I'm there to initiate them and recover if they come a gutser. History has shown that they otherwise will happen when I am far from home, usually for a sustained period and while Internet access is unavailable or inconvenient. When fully unattended upgrades to MSR happen, that will be your sign that I am no longer associated with this project.
The other interpretation is "push-to-start" upgrades from the UI. This is, frankly, a very low priority for me, and will not be something I entertain for 1.0, or likely 1.x. Docker containers are easily upgraded with a four-line script on command line-driven platforms, and still pretty painless in, for example, the Synology GUI (and still doable on the command line there as well). For users of the generic tarball, the detar and restart is even simpler. I understand that one click from the GUI would be easier, I don't disagree there, but keep in mind you've all been working in a mode where, for much of the history of its availability, MSR updates have come almost daily. That is not the norm, and I would not want it to be in production. In fact, production will go more to the model I use for R4V, where there is basically a very slow-moving release channel, a faster "stable" channel, and a bleeding-edge "latest" (what you have today).
The feature also introduces something that Reactor currently doesn't (on its own) require: access to a cloud infrastructure. Upgrades from within MSR require it to access cloud services, some existing, some not. This implies a lot of things, not the least of which include its security, its construction, and its cost to maintain and serve. If it gets done at some point, it will not come lightly, or easily, and it will likely be accompanied by license fees.
-
@fanan said in Version 1.0 Pre-release Discussion:
Another feature that would be nice is to have a optional setting of automatic updates.
I'll address this issue separately.
I think there are two interpretations here, so I'll start with the interpretation that I would more specifically call "unattended upgrades". Philosophically I'm opposed to unattended upgrades in all things, particularly on things that become "mission critical" in my environment. There is no "good time" for such updates except when I'm there to initiate them and recover if they come a gutser. History has shown that they otherwise will happen when I am far from home, usually for a sustained period and while Internet access is unavailable or inconvenient. When fully unattended upgrades to MSR happen, that will be your sign that I am no longer associated with this project.
The other interpretation is "push-to-start" upgrades from the UI. This is, frankly, a very low priority for me, and will not be something I entertain for 1.0, or likely 1.x. Docker containers are easily upgraded with a four-line script on command line-driven platforms, and still pretty painless in, for example, the Synology GUI (and still doable on the command line there as well). For users of the generic tarball, the detar and restart is even simpler. I understand that one click from the GUI would be easier, I don't disagree there, but keep in mind you've all been working in a mode where, for much of the history of its availability, MSR updates have come almost daily. That is not the norm, and I would not want it to be in production. In fact, production will go more to the model I use for R4V, where there is basically a very slow-moving release channel, a faster "stable" channel, and a bleeding-edge "latest" (what you have today).
The feature also introduces something that Reactor currently doesn't (on its own) require: access to a cloud infrastructure. Upgrades from within MSR require it to access cloud services, some existing, some not. This implies a lot of things, not the least of which include its security, its construction, and its cost to maintain and serve. If it gets done at some point, it will not come lightly, or easily, and it will likely be accompanied by license fees.
@toggledbits I fully understand and respect that! Thanks for taking the time!
Hope you have a great weekend! -
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?
-
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.
