@tunnus said in Reactor-Editor / Reactor-ui-Status Errors:

Just got a runtime error in UI (build 24343) when I deleted a newly created rule. Before deleting this rule, I copied reactions to it from another rule. It also contained local variables (if that matters).

I need a detail of every single step taken up the error popping up. Click by click, key by key. Also need to know what conditions were in the rule, and what actions were in the reactions.

That's... crazy. You know those things programmers say "should never happen"?

It's that.

Digging.

@Snowman said in Reactor-Editor / Reactor-ui-Status Errors:

For example, I'll go to Expressions, click the Add Expression, and when I click the Save Changes button, that is when these errors pop-up.

All of the errors you showed are in the context of the Rule Editor being active. Can you show an error message from using just the Expressions tab as in your example?

@Snowman said in Reactor-Editor / Reactor-ui-Status Errors:

I either have to close the browser or clear the cache for the errors to stop popping-up but they slowly come back.

So, this is progressive? Does it ever happen on the first use of the tab/function? Is it not resolved temporarily by simply refreshing the page/UI?

For the Status issue, you might try going to the Tools page and clicking on the Clear Local Storage link.

Also, in each case, I need to know exactly what you were doing, and when/where/how the error was presented. At least one of these errors could be logged completely harmlessly, so it's not clear to me that you are reporting an actual problem that is preventing you from doing any work, or if you are just reporting something you see going by in the log that you noticed by chance.

Yes, this should work. Just be aware that since your second condition spans midnight, the rule will set at midnight on 10/1 and reset at midnight on 4/1.

@gwp1 said in every X days field uneditable:

I want to create a ruleset that is only in effect from October thru March annually

Actually, you want to create a Rule. A RuleSet is a collection of Rules.

Now, I have to read between the lines of your problem description a bit here, but I'm thinking you mean that you want a rule to trigger once per day from October to March? If that's the case, an Interval is not the way to go, IMO. I would use two Date/Time conditions in an AND group. The first condition would constrain the dates (i.e. "between 1 October and 1 April", assuming you want it to trigger throughout March"), and the second "after 00:00" (assuming you keep the default Follow output mode on the condition and its parent group). The second condition will only trigger once per day, whenever it can (i.e. if the system is down at midnight, it will trigger as soon as it comes back up).

If you want the trigger to happen at some other time of day, say 10am, just put that in the Date/Time after condition instead of midnight.

Set hours to zero first.

Reactor build 24343

BARE-METAL USERS: Please run npm run deps from your Reactor install directory to upgrade packages. Remove any existing package-lock.json file first if it exists. These steps are only required for bare-metal installs (does not apply to Docker).

NOTE: Notable UI Change: removing widgets on the Status tab now requires you to drag the widget (by its header) to the top navigation bar and release it there. Previously, moving a widget anywhere outside the content panel would remove it, but this was troublesome for small touch displays (too easy to remove items while scrolling).

NOTE: If your Current Alerts widget displays two menu icons in its header, remove the widget (by dragging it to the top nav bar and releasing it), and then create a new replacement Current Alerts widget.

• PR 0000389: Improve mobile device compatibility. Although many aspects of the UI have been tweaked for better presentation on small displays, it will continue to be the case that editing of major system objects (Rules, Reactions, Expressions) is a high-interactivity task, and the design goals do not and will not include "mobile first" compatibility for that.
• PR 0000387: Make VirtualEntityController operation of reactor_system.set_attribute action identical to (and in fact, just an alias for) x_virtualentity.set_attribute. On virtual entities, all attributes are de-facto writable.
• PR 0000386: Fix an issue with HubitatController where it could attempt to set NaN on an attribute, generating a warning in the log.
• The Reaction List has been modified to show a spinner while a Reaction is running, rather than holding a green highlight.
• Fix an issue with the Reaction List not repainting correctly after editing a (global) reaction.
• Additional hard-coded colors in some CSS styles have been removed in favor of CSS variables (Bootstrap- or Reactor-defined). This should help user making custom themes.
• Improve the error message given when a script/expression attempts to set a global variable that is not writable (i.e. it's not expressionless).
• The default action handlers for increasing/decreasing values in dimming, position, and volume capabilities has been updated to more consistently move in increments of the related step value. For example, when the current dimming level is 0.55 (55%), the dimming.up action with a step of 0.1 will move to 0.6 rather than 0.65 as previously implemented. Not all devices/Controllers use the default action handlers for these actions — if the Controller implements its own semantics, this change has no effect.
• VirtualEntityController can now do HTTP requests in actions. This allows you to create a virtual entity that functions as an interface for a device that is HTTP-controllable without the need to write a custom Controller instance. See the docs for VirtualEntityController for updated section on actions.
• HassController: Bless Hass to 2024.11.3

I am working on some bigger structural changes to Reactor, and have been for a while now. In the interest of finishing those changes, the rate of latest builds is going to go down for a bit. I will, of course, address any serious issues that need fixing during that time.

Frankly, I wouldn't update. The amount of changes you've made are making your entire system a moving target. You're good until 2026. Leave it alone for now. Get everything else working, and get it stable.

In the meanwhile, grab yourself a Pi or something else cheap that can run Linux, and practice. Install versions and get to know where things go and how they are connected together. Upgrade it. Blow it up, wipe it, and do it again until you understand why it blows up. The time you invest will pay you back later when you deal with your "production" system. Sandboxes are a lovely thing. Go play!

Yeah, but I can see in that screen shot that there are other broken permissions that are going to cause problems. For example, look at the reactions folder. It's owned by root, with no write permission for group or other users, so that's going to prevent you from saving new reactions, at least, and depending on individual file permissions within that folder, editing and saving any existing reactions. So I suspect the parent folder storage, and maybe even the Reactor install directory itself, have gotten broken permissions/ownership along the way of your efforts.

You need to fix the entire directory tree to be safe, using the commands I gave you.

@cw-kid said in Which user to install nodejs as ? Debian Linux:

I installed it globally instead with apt via the command from this webpage here.

Sigh. OK. Unfortunately, that version (20) is already out of development, but at least it's LTS and will hold until 2026. Or maybe the header on the page is wrong and it's been updated to install the latest LTS. Either way, Reactor will support it as long as it's under maintenance with the authors.

There's nothing wrong with your expressions.json file. I'm guessing it's a permissions problem after you copy it from whatever source you copied it from (it's keeping the user and group IDs on the file from whatever source, and the user ID has changed between the two systems).

As I said, you should copy the entire storage directory, don't cherry pick, because there are other important files in there that align with your installation. Once you've copied everything, run the following commands in a shell from the Reactor install directory (where Reactor's app.js is located), substituting <user> and <group> with the user and group names, respectively:

sudo chown -R <user>:<group> .
sudo chmod -R ug=rwX,o= .

This should fix all file permissions. Then start Reactor.

If that's the case, your global expressions file is damaged/unreadable for some reason. I'll send you a link privately to upload it to me, and I'll see if I can repair it for you.

When backing up and restoring, the entire storage folder should always go as a unit. No cherry-picking.

nvm is a per-user tool and installs node on a per-user basis. You need to run it logged in as the non-root user that will run Reactor and the other things you want to install. Be sure to install an LTS version of node, not just the highest-numbered version (e.g. nvm install --lts).

@tunnus et al, please don't post screen shots of code/expressions or logs. Screen shots often end up displaying at a reduced size that makes them very difficult to read. Just copy-paste the actual text and use a fenced code block.

To the question, as @therealdb said, judicious use of the coalesce operators will generally help here, particularly if you apply local knowledge of the desired outcome. There's another one that's often helpful when working with sources for numeric values that can be occasionally null:

The ?# operator will take any left side expression and convert it to a number or the value on the right side, so someexp ?# -1 would produce -1 if the value of someexp can't be converted to a number or is null or NaN. In other words, the general form somexp ?# altval is shorthand for do local t=float(someexp), isvalue(t) ? t : altval done

You can use this to produce, for example, an "off scale low" value that wouldn't trip a "greater than" operator on a trigger for a temporary missing value on an entity. This would let you write your expression more tightly as:

round( getEntity( "..." )?.attributes?.current_sensor?.value ?# 0 * 
    getEntity( "..." )?.attributes?.x_hubitat_extra_values?.voltagePhase1 ?# 0, 0 )

Note that the ?# operator has higher precedence than the math operators (like * and +) so you don't need parentheses around the subexpression in this case.

That said, if it's specifically zero you're after where there's a null, you may not need to do anything special, because the expression language follows the JavaScript semantics for null in arithmetic: null is treated as zero (e.g. null * 8 = 0 * 8 = 0 and null + 8 = 0 + 8 = 8). So this could be written even shorter as:

round( getEntity( "..." )?.attributes?.current_sensor?.value * 
    getEntity( "..." )?.attributes?.x_hubitat_extra_values?.voltagePhase1, 0 )

@mrFarmer said in MSR UI on a mobile browser:

Toggling the hamburger menu shows most pages except status. That rarely shows a widget especially in landscape mode. I would not think about making or changing rules on a small screen, but being able to look at the status would be nice.

Found and fixed for next build. That sent me on a bit of a mission to try to improve the general appearance on the UI, even if editing will never really be fully supported (it may work, but I'm not going to approach it as a "mobile first" redesign, because I don't think that makes sense for this project). Here are some examples of work so far.

This is a Samsung Galaxy S24 phone. Reduced top (nav)bar, menu moved from left margin to top and stripped of text. Columns removed from lists at this size.

This is Samsung Galaxy S2 tablet. At this size, the menu returns to the left side, but still without text.

The Status widget problem is fixed, and in addition, there was an issue where the Status widgets would drag if you touched anywhere in them -- they're only supposed to drag from their headers. Touch is still not working great on the phone (smallest size), but I'm still chipping at it, trying to find a workaround (the gridstack library controls the touch behavior, so I'm at the mercy of their choices and issues).

Your test is for fourth Friday, but Thanksgiving is the fourth Thursday which just happens to be a day before the fifth Friday of this month. Don't you just love our "modern" calendar? Another imperial unit that we still haven't given up...

Harmless. Just a warning. I'll see about quieting it for the next build.

@tunnus said in MSR UI on a mobile browser:

Using iOS 18 and Safari/Chrome browser.

From the requirements listed in the documentation:

@Pabla said in New to Home Automation Looking for a Single app?:

Company's like Ring (Amazon) notoriously block third party use of their APIs at random, so what may work now will not be guaranteed to work in the future.

Good reason for folks like us to not choose those products.

The error message will be improved, but for reference for future readers, there are two ways to fix this when it happens:

1. Change the name of your local variable.

2. Explicitly declare and initialize your local variable at the start of your expression as explicitly local. For example, assuming alpha is the name of a global expression/variable but we want to use it as a local variable name:

    local alpha=0, each e in matchEntities( { capability: 'dimming' } ): alpha = alpha + 1