Multi-System Reactor

As @cw-kid said, empty alerts were an issue several versions ago, but I think they're dealt with, so make sure you're on 21106.

A reaction being BLOCKED means that it is waiting for a driver of some type to finish work on a step (that step is identified as #0, so it's the first step in those reactions). The drivers can be Controllers (when performing an action on an entity) or Notifiers (when sending a notification). Normally, a reaction will only remain in this state for a few milliseconds, and is so quick that most people will never even know this state exists. If you have reactions in BLOCKED state and that passes within a minute, that's an indication that whatever the step is doing is timing out (e.g. communicating with a remote API that is not responding and timing out, or taking a very long time to respond). This can happen to controllers and notifiers. If a reaction is stuck in BLOCK state until you restart MSR, that indicates something went very wrong with the run of that reaction (there's a lot of coding to prevent situations like this). Either way, looking at the reactor.log file will give some clues.

@toggledbits NOTE: Yes, it was just me trying to break stuff. I really don't have any outstanding needs at the moment in terms of my daily workflows. Thanks for the tutorial (which all makes sense)!

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.

I've done some reading on the HS forums and a workable solution might be to use the HASS Controller.
The theory being to run HASS > MQTT > HS, it seems convoluted but should work, I'll give a go tomorrow.

I take it by now you read ezlo's list of "Known Issues" that include the specific issue you've reported? Seems to still be a problem, even with the second release of 7.32 beta firmware. Thus, I believe you're taking the smart route away from bridging.

If I could make one small suggestion, which may not fit your use case... namely, creating a single(!) virtual dimmer -- or even just pinpointing an otherwise unused Variable on an existing Vera device -- which MSR can watch for changes?

Then, (a) you trigger your Vera Scene (manually), (b) the Scene sets the value (of the Dimmer or Variable), (c) MSR detects the change (automatically), and (d) MSR runs the associated Rule (whose trigger is literally "Dimmer" == X or "Variable" == Y). For this setup to work reliably, I'd take it a step further with (e) MSR immediately resets "Dimmer" or "Variable" to 0.

You can tell I'm trying to get things up and running without the need for an as-yet-uncoded "Incoming HTTP Request". 🙂

Have you got anything without spam in it?

You're still going to have your work cut out for you. There's a lot of things MSR does differently. Expressions are high on that list.

@toggledbits said in Running Lua Code ? And watching device properties?:

It's not a limitation. It's the way Lua works, combined with one way Luup is broken.
The problem is that you are declaring your delay callback/handler function in a module. It is therefore not a global function, it is a module function -- it is scoped within the module, not globally.

To access functions inside a module, you have to use modulename.functionname(arguments), as you know, and the same is true for the delay handler/callback.

But the way Vera implemented luup.call_delay(), it takes a function name as a string, rather than a function reference. The function, therefore, has to be global. And it's not global, it's in a module.

One way to solve this problem (which all plugins experience, too, by the way) is to make a global alias. That means in your startup Lua, you do something like this:

mymodule = require( "mymodule" ) -- this line loads your module

-- Create a global alias for my delay handler
mymodule_delayhandler = mymodule.delayhandler

Then, in your module, instead of doing luup.call_delay( 'delayhandler', 5 ) you have to do luup.call_delay( 'mymodule_delayhandler', 5 ). This makes the delay use your global alias instead of the function name directly (which it can't).

Just trying this "Global Alias" for function delays, for the first time, but I can't get it working. I must be doing something wrong.

In the top of my VeraScenes.lua file I have added this code:

The test code checks the status of a virtual switch and sends a different HTTP request / TTS announcement etc.

I wanted a 30 second delay before anything happens at all.

When I call this function from a MSR rule by using

I can hear the TTS announcement right away, so my 30 second delay is not happening.

What am I doing wrong?

@Tarkus Did you get this working?

Thanks

I'm concerned that although you say you "like keeping [your] inventory of expressions compact," what you will in fact do by being able to create variables on-the-fly from within other variables/expressions is create a long and decidedly not compact inventory of variables created by whatever other expressions are declared, thus complicating your understanding of where they came from, how they got their value, and when they change. That will also further complicate the system's ability to know what changes affect what variables where and need to trigger evaluations of rules, etc. In your example above, I'm sure you would expect, if varInner was in fact a getEntity() call, that any change to the entity would trigger a re-evaluation of varInner, as well as its parent rule and everywhere it or an effected parent is used. It's too much, and the potential for creating unsupportable nightmare scenarios too high.

@cw-kid said in Is there a projected date for the release of v 1.0 of MSR?:

Maybe we should open a bug tracker ticket for a feature request.

Done.

@librasun Good idea

@toggledbits Yes it is but its just to toggle all off and then on so it goes quite fast.. But in Hubitat dashboard its the same thing. Because if you have all devices enabled for a dashboard it loads slower. Then they have made it so you can enable the ones you want in a dashboard. This really sucks when you make dashboard with a lot of specific devices.

@toggledbits
Yes, it works! Excellent.
Thank you for your time! Now I can continue my project. The new variable is also useful.

Aha... se the log it says 😁

@toggledbits said in Feature request on reactions side.:

whereas buttonCodes[ . ] and buttonCodes["x"] simply make no sense.

These are actually OK if buttonCodes is an object, not an array. You can use the square-bracket notation same as dot member access, so buttonCodes[ "x" ] (note the quotes so it's a string) is the same as buttonCodes.x. Using the square bracket notation lets you use a variable for the member name. You don't need a second array, you just need to structure buttonCodes correctly...
buttonCodes = { '0': 'codes for 0', '1': 'codes for 1', '.': 'codes for dot' }
key_to_send = "." # or whatever/however you get the key
send_data = buttonCodes[ key_to_send ]

I ended up using this method and it works great!

Thanks for all the help.

https://smarthome.community/post/6932

@toggledbits ok, I thought I did that, but maybe I don't remember correctly. Not a Linux expert... yet! I am now up and running 🙂

Thanks for the quick response! I'm going to try to use it in my logic