Reactor-Editor / Reactor-ui-Status Errors

[LibraSun]

+1 on "Entity in use by" (or "watched by" or "referenced in") and see that as a possible extension of the objects we already see under ENTITIES. If, for instance, "Sofa Lamp" was referenced twice in the "Dim Lights" rule, it could list both occurrences as:
.references: Dim_Lights._Set_Reaction, Dim_Lights.Expr_DimLevel, where both are clickable links directly to those subsections of the referencing rule.

[MikeReadington]

This post is deleted!

[MikeReadington]

+1 Libra. A clickable link to take you to the location of use would be really nice.

[LibraSun]

@mikereadington said in Version 1.0 Pre-release Discussion:

+1 Libra. A clickable link to take you to the location of use would be really nice.

Although we have to acknowledge that expressions are able to reference entities without overtly looking like that's what they do - such as using loops and arrays - so it might be a technical challenge for MSR to pick up every single reference.

[cw-kid]

@toggledbits said in Version 1.0 Pre-release Discussion:

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

Really?

Are these not two separate things with different uses.

I use the Contraints section of a rule as the main set of constraints / conditions for that rules Reaction / actions being run or not.

And then in some of my rules in its Set Reaction I also have further additional and different "Group Constraints" that are only evaluated and carried out if the Set Reaction actions were even run in the first place by the main constraints being met.

Personally I do not like at all this idea to remove the rules Contraints.

[cw-kid]

I have to strongly object to removing the rules Contraints section, which would be a major change to the concept of a rule and its work flow.

A logic engine has triggers then conditions then actions.

This is the same concept PLEG had and I used it for a decade.

We then asked you to give us the ability to have further additional conditions within the actions chain and you gave us that with Group Constraints.

The system is perfect as is.

What you are suggesting is to have triggers then actions with conditions mixed in with the actions.

Keep the main conditions in the separate Constraints section as they are now.

It's your project and creation and you can do with it what you like, but I won't be happy with this proposed major change if it happens.

[SweetGenius]

@toggledbits , As you stated in another thread "Capabilities on Hubitat are free-form, and there's no indication which capability might be the most useful or primary". Could you add the ability for a user to manually select the primary capability for each Hubitat device? This would allow the Entities screen to display info in the primary value. If the Dashboard feature is added in the future then the Hubitat device should display correctly there also.( I also would like to request the dashboard)

[Fanan]

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;

1. In which ways are we going to be able to install and start up MSR?
2. 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!!

[Matteburk]

@fanan The same thing happens with my RPI4 ... I have to start it manually...

[cw-kid]

@matteburk

There was a thread about having MSR auto start on a Pi. I set it up on my Pi and it did work MSR was started automatically after a reboot / power on.

https://smarthome.community/topic/439/how-to-auto-start-on-rpi-reboot?_=1621588014603

[therealdb]

@fanan installing on a poi side by side with anything else will not hurt. On windows, just schedule it to run at startup via task scheduler.

[toggledbits]

@fanan At least initially, like many other projects, I expect MSR to be delivered in the following forms:

1. Primary: Docker container. This facilitates not only a simpler integrated package to install that contains its dependencies, but also easily takes care of starting at boot on most systems. There are currently Docker containers available for Linux amd64 and armv7l (i.e. RPi4) architectures.
2. Generic tarball. This will be a manual install for platform power users (Linux, Windows, and anywhere else nodejs and the companion dependencies can be installed by the user). There are available examples for automatic startup for systemd.

There's no reason you cannot install MSR next to Hass or anything else on a platform that allows you to install such things (clearly you're not going to install it on your Hubitat). I don't know anything about Hass Blue, but if it lets you install docker containers or the generic package, I see no reason you can't run them side-by-side.

@cw-kid said in Version 1.0 Pre-release Discussion:

@matteburk
There was a thread about having MSR auto start on a Pi.

Slightly modernized version of the same here, should work on any platform that supports systemd: https://smarthome.community/post/8011

[toggledbits]

@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]

@toggledbits I fully understand and respect that! Thanks for taking the time!
Hope you have a great weekend!

[SweetGenius]

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?

[Matteburk]

Feature requests .. Now when we have groups in set reactions and reset reactions it would be nice if they showed up in the the visual tree under trigger and conditions.
Then you have a more visual overview of the hole logic. /Mattias

[jsimmo]

@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.

[LibraSun]

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!

[wmarcolin]

This post is deleted!

[wmarcolin]

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:

1. 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?

2. 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:

3. 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;

4. 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