I was just thinking, these forums remind me of my earliest days working in startups, when you showed up for an interview and the furniture was clearly from a local thrift shop, the coffee station was a folding table or plywood over two saw horses, and your interview was conducted with all parties in jeans and a t-shirt. In those days, the focus was strictly on the work and bringing something exciting into the market. People of every history and skill were brought together. The CEO worked right next to you and could be seen cleaning the office's only toilet on a Friday night before he went home. And he was there on Saturday, and on Sunday, because we only worked on days ending in "y".

These forums are a refuge. It's a place where technical discussion can lead over corporate policy and the pressure to sanitize and control the view. It's a place where we can take a wide view of the HA market, and not be beholden to one product. We can share success and failure with, and our adulation or bewilderment for, any product in the space. We talk about bugs and needs and challenges. We get work done. We get work done for each other.

This is shaping up to be a really fun community, and I'm excited to be involved. The direction is forward. Onward!

Jeeez, he's still ranting. Have any of you ever heard of "confession by projection"?

Edit: It's time to bring the temperature down over there. We all know who we're dealing with. We've made our point. Thank you all who have chimed in on my behalf as well, and offered words of support here. I'm not leaving until he kicks me off. But it's time to let this one die out, cool the temp and let the forum get back to the business of the community. His anger on display won't change anything anyway; the market will sort him out, not me or anyone else here. For myself, I'm getting on with the business of building tools, and if a single-digit percentage of people use my work, I call that a pretty good day.

Everyone: for some weeks now, I've buried myself in getting as much done on MSR as possible before this coming week. This is the week I had planned to put out the first developer preview of MSR, and it's looking good for that to happen.

The first previews will be for Linux-based systems only, and will not be docker containers, but stand-alone installs. You'll need to be running a fairly modern version of Ubuntu, Debian, etc. (so that includes RPi Raspios Buster).

What I really need at this early stage is people who will give me good, solid data on what doesn't go well. I really cannot, at this stage, spend time with anyone who isn't functionally fluent with Linux system administration. While I suspect most of the people here are already firmly in the former camp, I'm about to make a public announcement on the Vera forums that I suspect will drive a new cadre of people here, so the mix may change a bit. But it's simply a fact that the better the information I get up front, the faster I can fix things that have gone wrong, thus the more I can fix in any given period of time, and the sooner it will be that my time will be freed so I can start helping everyone.

I will be using this community as the focus of communication, as in, announcements and discussions. For issues, however, I have set up a MantisBT (Mantis Bug Tracker) server at https://reactor.toggledbits.com/mantisbt/ and I invite and encourage you to sign up. I will only address bugs opened in that tool. This is an administrative choice to keep me somewhat sane and not be overwhelmed by juggling feedback from however it might come at me. I'm pipelining the process.

There's still a lot to do. I've been running my own house on it, but as I've often said, that's me running it one way -- one data point. I'm sure there will be a lot to look at. There are still some functional gaps, and the documentation is a mess, but I think that's less of an issue for current Reactor users than it is for newcomers.

Stay tuned... more to follow....

I've also rolled my own. It will be included for optional use with the new multi-system Reactor.

He's publishing the truth himself, I don't need to say anything. Honestly, I don't know how he doesn't see that he looks like a fool. I don't want to be ugly with him, but I won't not defend myself.

MSR will be very familiar to users of Vera Reactor. There are changes, for sure, but conceptually it works very much the same, and many of the displays have a similar look and feel. The systems are close enough that I have been able to craft an importer to read a Vera Reactor backup file and create MSR rules and reactions (they still need review and adjustment, but at least it's not starting from a blank slate). The biggest difference is that Vera Reactor's device model is determined by Vera/Luup, where I had to invent a model for MSR. In doing so, I borrowed concepts from other available controllers and services like MQTT, choosing what I thought were the best ideas and set the stage for the broadest reach platform-wise, and the most extensibility. I would say that if you have something you want to get done today in Vera Reactor, go ahead and do it. It will only smooth the path for you starting with MSR.

FYI, Reactor's direct support for your plugin (in the Notify action) is now available in 3.9-20321, the stable branch release (so in AltUI, go to Plugins, and on the Reactor row enter "stable" as the version and click the update button).

Wait... is he... talking about these forums in his own thread? Another rule violation? And with a picture?

OK, people, here we go! At long last, Multi-System Reactor developer preview is available!

The package can be downloaded from the Reactor bug tracker, a MantisBT system (at https://reactor.toggledbits.com/mantisbt/). There is a download button in the left margin, as well as links to the documentation, which you will need for installation.

UPDATE 2021-02-24 -- To keep spammers off, I've locked down registration on the Bug Tracker. To get access to the Bug Tracker and preview downloads, please PM me (not reply here) your full name and email address and I will set up an account for you.

This version of MSR will run on Linux systems, including RPi's under Raspios Buster, running node.js version 12.10 or higher (v14.15.1). For RPi users, there is an installation script that will install a local copy of node.js (for the logged-in user).

Bugs reports will be handled through the bug tracker only. Discussion and questions in this forum are fine, though (if that leads to a bug report, we'll transition).

This version supports Vera (and openLuup to the degree it's compatible with Vera Luup), Hubitat, and Home Assistant. Some of the device support on the H platforms is still a bit basic, but it is largely controlled by configuration and progress can be made quickly.

The documentation beyond installation is a mess. Of course, I started with the existing documentation and have been massaging into MSR's particulars, but it still has a long way to go on the detail.

I know I don't have to say this, but I will anyway... let me know how it goes!

I would strongly recommend that you take the time to learn some basic *nix command line and system administration in the background of other work, and I'm addressing the audience in general here, not @Black-Cat or anyone specifically. This will pay huge dividends. You need to be able to successfully navigate the file system (commands cd, pwd, ls, find, rm, mkdir, rmdir, ln, cat, more/less), understand the differences in user permissions and how to manipulate them (commands chmod and chown), compress and uncompress files (commonly gzip and gunzip; there are many others but all operate in a similar way), edit files (you don't have to learn vi, but nano is useful), and update your system (via apt, yum, apk or whatever it uses). This basic knowledge will vastly increase your comfort with other more complex tasks that incorporate these basic tools. Permissions problems, for example, is probably a top 3, if not #1, *nix issue for beginning users, and changing permissions to everything world-read/write is not an answer (in some cases, it will make the problem worse -- ssh itself, for example, is famous for ignoring its own config files when their permissions don't smell right to its nose).

I've been on *nix for decades (I was at Berkeley in the late 70s and early 80s), but remember well the pain of trying to learn the odd foreshortened command names (with their quirky history -- why grep and cd are acronyms but ls is not, and what the heck is cat?), the options for those commands, and of course the editing environment (at 300 baud on a good day). And that's when my brain was young and not addled by age and accretion of useless bits that defy purging to make room for things of greater relevance. I empathize; I really do. But the core of what you need to know is actually pretty small, and if you're going to have these systems in your home, you really need to understand them at a basic level. You also make yourself unsupportable when you rely on tools like MC, Norton, or WinSCP; there's a reason that the installation instructions for almost everything rarely mention these tools and give "bare metal" commands. I'm not saying you're wrong to do it and make your life easier for the most common tasks you do for yourself, that's absolutely fine; but know that you won't get away with not knowing what you really need to know. You will continue to hit roadblocks and be frustrated, and helping you will be more complex and take longer. If the tool has side-effects or behaviors that work differently from the system tools, and you just happen to forget to mention that you're using such a tool, you can create a lot of unnecessary confusion and excess, likely fruitless, labor. If you are going to make these systems an indispensable part of your home, you need to understand them well enough to maintain them.

Since the constraint group(s) only have one condition, AND and OR give the same result, but it's always my preference to use AND on singles. Looks good.

@cw-kid It will work, but not the way you think.

The "OR" only applies to the conditions within the group. It does not look outside the group at any states.

That means that what you have here (assuming there is not a global rule constraint, not shown) is that the light will be set to 100% every time the reaction runs, and at night a few milliseconds later it will be reduced to 25%. That may or may not look right or work consistently.

You need two groups, one for day, one for night, the former setting 100%, the latter setting 25%.

So then it appears then that when Vera updates the device from itself (ZWave), it sets both variables, but when you run the action, they only apply the change to one. Well, I'll switch it to the one the UI uses. That's sure to break some other device, but we can cross that bridge when we come to it.

You cannot "Set Variable" on a variable that has an expression assigned to it. It will not set the value, because the expression, when present, always controls the value. "Set Variable" can only be used on expressionless variables.

If you want to store the value of a dimmer in a "Set Variable", the target variable has to be expressionless, but you can (must) use a getEntity() expression in the "Set Variable" operand. In the example below, the "Set Variable" saves the current dimming level at step 1, then the entity action sets the level to 100%, then there's a delay, and then the dimmer is set back to the saved value from step 1.

Test by dial and by Vera UI and by MSR UI. I'm guessing there may be an inconsistency in the 'driver" (Vera internals) and there may be one or more cases where the variables aren't kept in sync.

Sorry, everybody. Link updated.

Did you set it the same way each time? Or perhaps through your dashboard one time and the Vera UI the other? Did you upgrade firmware since setting it up?

There's nothing new here. The device type Heater1 implements both the TemperatureSetpoint_Heat and TemperatureSetpoint services, so it's ambiguous as to which would be the correct one to use, and one might hope that Vera (or the plugin responsible for this device) would keep them in sync. What kind of device is this?

Build 21123

• 0000084 Ruleset click-to-expand needs visual cue (also done for reactions and entities with similar behavior)
• 0000199 (Hass) Cover device missing position MSR capability/attribute (Hass-native was available, however)

The range operator '..' (e.g. 1..10) is now available in expressions and produces an array.

By the way, I forgot to mention, as is often necessary in many languages because of the reference issue, there is a clone() function that makes a new copy of an existing array or object. So a=[1,2,3],b=clone(a),push(b,99) will result in a having [1,2,3] and b having [1,2,3,99].