Multi-System Reactor

701 Topics 6.9k Posts
  • Problems with Up grading existing MSR.

    Locked
    9
    0 Votes
    9 Posts
    208 Views

    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.

  • Adding Homeseer as a Controller

    Locked
    4
    0 Votes
    4 Posts
    141 Views

    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.

  • Vera vs MSR lock code logic

    Locked
    17
    0 Votes
    17 Posts
    559 Views

    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.

  • Global Reactions - Constraints ?

    Locked
    10
    0 Votes
    10 Posts
    244 Views

    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". 🙂

  • Feature Request - Reaction to MQTT

    Locked
    6
    0 Votes
    6 Posts
    231 Views

    Have you got anything without spam in it?

  • Import question

    Locked
    12
    0 Votes
    12 Posts
    307 Views

    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.

  • 0 Votes
    69 Posts
    3k Views

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

    module("VeraScenes", package.seeall) -- TODO: personalize it mymodule = require( "mymodule" ) -- this line loads your module -- Create a global alias for my delay handler mymodule_delayhandler = mymodule.delayhandler --Away Mode Scene function mymodule_delayhandler() local status = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1", "Status", 419) --Status of Safe to Arm virtual switch if status == "0" then --Safe to Arm luup.inet.wget("http://SEND-TTS-MESSAGE1") else --Not Safe to Arm luup.inet.wget("http://SEND-TTS-MESSAGE2") end end luup.call_delay( 'mymodule_delayhandler', 30 )

    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

    VeraScenes.mymodule_delayhandler()

    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

  • 0 Votes
    2 Posts
    82 Views

    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.

  • 2 Votes
    12 Posts
    321 Views

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

  • Feature Request: MSR Rule Snapshot Exporter

    Locked
    4
    2 Votes
    4 Posts
    136 Views

    @librasun Good idea

  • Hubitat and virtual devices

    Locked
    5
    0 Votes
    5 Posts
    587 Views

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

  • calculate with MSR variables in LuaXP

    Locked
    9
    0 Votes
    9 Posts
    320 Views

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

  • Current Alert Tasks

    Locked
    2
    0 Votes
    2 Posts
    110 Views

    Aha... se the log it says 😁

  • Feature request on reactions side.

    Locked
    37
    0 Votes
    37 Posts
    1k Views

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

  • 0 Votes
    2 Posts
    89 Views
  • MSR doesn't change Mode in Hubitat

    Locked
    1
    0 Votes
    1 Posts
    100 Views
    No one has replied
  • Installing build 0.1-21089

    Locked
    5
    0 Votes
    5 Posts
    165 Views

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

  • TimeStamp variable in MSR

    Locked
    4
    0 Votes
    4 Posts
    153 Views

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

  • Status Tab Preview

    Locked
    20
    2 Votes
    20 Posts
    489 Views

    Also, so as to minimize the number of "SET" (but otherwise inactive) Rules, I decided to change all of my

    [ Entity Attribute ] [ X ] [ is FALSE] // remains true indefinitely when OFF

    to

    [ Entity Attribute ] [ X ] [ changes ] [ (any) ] to [ FALSE ] // only true briefly when turned OFF

    Dunno if I'm OCD or just didn't want Status implying that something was "going on" when it's not. 🙂

  • This topic is deleted!

    Locked
    40
    0 Votes
    40 Posts
    123 Views

Recent Topics