Navigation

    Discussion Forum to share and further the development of home control and automation, independent of platforms.

    SmartHome Community

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Unsolved
    (Last Updated: April 21, 2021)
    • Cant reach MSR after mowing my Pi

      M

      I decided to move my MSR pi to a permanent place and after that i cant connect to it. I can se in the logs that it has connection with hubitat ..

      I says
      2021-04-22T20:11:54.649Z Controller:ERR SystemController#reactor_system disk usage not available: Error: Cannot find module 'diskusage-ng

      What has happened? I did a hard remove by powercable....
      /Mattias

      Full log

      2021-04-22T20:10:56.493Z Controller:NOTICE Controller HubitatController#hubitat is now online.
      2021-04-22T20:10:56.497Z app:NOTICE Starting Reaction Engine...
      2021-04-22T20:10:56.498Z Engine:INFO Reaction Engine starting
      2021-04-22T20:10:56.499Z Engine:INFO Checking rule sets...
      2021-04-22T20:10:56.514Z Engine:INFO Checking rules...
      2021-04-22T20:10:56.559Z default:ERR [IndividualFileStrategy#/home/pi/reactor/storage] failed to read cs-rule-knbyvokt in /home/pi/reactor/storage/states/cs-rule-knbyvokt.json: SyntaxError: Unexpected end of JSON input
      Trapped unhandled Promise rejection SyntaxError: Unexpected end of JSON input
      at JSON.parse (<anonymous>)
      at IndividualFileStrategy.getDataObject (/home/pi/reactor/server/lib/IndividualFileStrategy.js:126:38)
      at Container.getDataObject (/home/pi/reactor/server/lib/Container.js:91:53)
      at Rule.getRuleStates (/home/pi/reactor/server/lib/Rule.js:601:98)
      at Rule.getConditionState (/home/pi/reactor/server/lib/Rule.js:626:46)
      at new Rule (/home/pi/reactor/server/lib/Rule.js:491:47)
      at Function.getInstance (/home/pi/reactor/server/lib/Rule.js:500:36)
      at /home/pi/reactor/server/lib/Engine.js:584:50
      at Array.forEach (<anonymous>)
      at Engine.checkData (/home/pi/reactor/server/lib/Engine.js:582:36)
      SyntaxError: Unexpected end of JSON input
      at JSON.parse (<anonymous>)
      at IndividualFileStrategy.getDataObject (/home/pi/reactor/server/lib/IndividualFileStrategy.js:126:38)
      at Container.getDataObject (/home/pi/reactor/server/lib/Container.js:91:53)
      at Rule.getRuleStates (/home/pi/reactor/server/lib/Rule.js:601:98)
      at Rule.getConditionState (/home/pi/reactor/server/lib/Rule.js:626:46)
      at new Rule (/home/pi/reactor/server/lib/Rule.js:491:47)
      at Function.getInstance (/home/pi/reactor/server/lib/Rule.js:500:36)
      at /home/pi/reactor/server/lib/Engine.js:584:50
      at Array.forEach (<anonymous>)
      at Engine.checkData (/home/pi/reactor/server/lib/Engine.js:582:36)
      Promise {
      <rejected> SyntaxError: Unexpected end of JSON input
      at JSON.parse (<anonymous>)
      at IndividualFileStrategy.getDataObject (/home/pi/reactor/server/lib/IndividualFileStrategy.js:126:38)
      at Container.getDataObject (/home/pi/reactor/server/lib/Container.js:91:53)
      at Rule.getRuleStates (/home/pi/reactor/server/lib/Rule.js:601:98)
      at Rule.getConditionState (/home/pi/reactor/server/lib/Rule.js:626:46)
      at new Rule (/home/pi/reactor/server/lib/Rule.js:491:47)
      at Function.getInstance (/home/pi/reactor/server/lib/Rule.js:500:36)
      at /home/pi/reactor/server/lib/Engine.js:584:50
      at Array.forEach (<anonymous>)
      at Engine.checkData (/home/pi/reactor/server/lib/Engine.js:582:36)
      }
      Trace
      at process.<anonymous> (/home/pi/reactor/app.js:197:151)
      at process.emit (events.js:315:20)
      at process.EventEmitter.emit (domain.js:467:12)
      at processPromiseRejections (internal/process/promises.js:245:33)
      at processTicksAndRejections (internal/process/task_queues.js:94:32)
      2021-04-22T20:10:56.599Z Controller:WARN HubitatController#hubitat 'Allow control of HSM' appears to be disabled in your Maker API configuration
      2021-04-22T20:10:56.604Z Controller:NOTICE HubitatController#hubitat current mode is Kv\u00e4ll (131)
      2021-04-22T20:11:54.649Z Controller:ERR SystemController#reactor_system disk usage not available: Error: Cannot find module 'diskusage-ng'
      Require stack:

      /home/pi/reactor/server/lib/SystemController.js
      2021-04-22T20:12:16.879Z Controller:ERR HubitatController#hubitat mapped capability x_hubitat_healthcheck has no implementation
      Multi-System Reactor
    • Why can't I run this LUA code ?

      cw-kid

      I have created a Global Reaction with this LUA code for my Vera to run.

      However when I run the Reaction nothing happens. I can't see anything in the log file either about this rules ID number.

      If I run the same LUA code on Vera in the test window it works OK.

      OR any other suggestions how I can set this up in a global Reaction (Scene) in MSR ?

      Instead I could use the VeraScenes.lua file in the Vera startup library, but I am wondering why I can't just paste the LUA code directly in to the MSR rule.

      Thanks

      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://SOME-HTTP-REQUEST") luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1","SetHouseMode", {Mode = 2}, 0) --Set House Mode to Away luup.inet.wget('SOME-HTTP-REQUEST' ,5); else --Not Safe to Arm luup.inet.wget("SOME-HTTP-REQUEST") luup.inet.wget('SOME-HTTP-REQUEST' ,5); end
      Multi-System Reactor
    • Setting up Pushover in MSR

      J

      Hi,

      I've been using Pushover in VeraAlerts, but now want to send my notifications from MSR.
      I see in the reactor config directory that the notification. yaml file includes Pushover, but is showing #TBD. Is this where I need to set up my Pushover user key etc. and if so what and how should the information be entered?

      Any help would be appreciated.

      Multi-System Reactor
    • Posting from log files

      toggledbits

      For years of participating in the other community, I've watched people post a single error message from a log file when asking for help. I'm now seeing the same behavior (I guess not surprisingly, given the genesis of this community) here. But it's got to stop.

      When you post just the error message, you leave out vital context that may give clues to more quickly troubleshoot whatever problem you are having. Very often, by the time someone responds to ask for more, the message is gone (e.g. rotating logs on Vera) or has become too difficult to locate.

      Please, when posting anything from a log file, you should be giving context with the message by including, let's say at least 10, messages before, and a few after. Particularly in the case of MSR, almost every exception that is logged is accompanied by a context-defining message immediately before, and in many cases, a follow-on additional data dump related to the error.

      Thanks for listening.

      P.S. My weekly (it seems) reminder: when things go wrong that obviously aren't just the UI doing something dumb, you must look at the logs.

      Multi-System Reactor
    • Reset Reaction evaluate Contraints?

      cw-kid

      I have a rule that closes my curtains when I start my Xbox activity on the Harmony hub.

      In the Contraints I have that it's day time.

      In the Reset Reaction it opens the curtains when I end the Xbox activity etc.

      Today it was day time and I started the Xbox activity and the curtains closed.

      When I turned off the Xbox it was night time, however my curtains then opened.

      I expected the curtains to remain closed as by then it was night time.

      Not sure the best way to handle this? But I want a rule that closes the curtains if it's day time and I want to play on the Xbox. If it's still day time when I end that Harmony Activity then open the curtains again. Or if it's night time then keep the curtains closed.

      I figure if I start playing the Xbox and it's already night time then the curtains would already be closed anyway via the sunset offset schedule that closes the curtains.

      Multi-System Reactor
    • Running reactions /Blocked?

      M

      What does Blocked mean in running reactions?

      Anyone having a lot of empty alerts that is not possible to erase?

      Hubitat - MSR
      /Mattias!
      Skärmavbild 2021-04-22 kl. 12.09.15.png

      Multi-System Reactor
    • PR #178 In-place modification of arrays in "each"

      toggledbits

      I'm moving the discussion on this out of the Mantis PR #178 for the benefit of all/documentation, and also because it's easier to type and format here.

      @LibraSun wrote in that PR:

      I'm 99% certain you'll explain this one away as "expected" but I naively believed it would yield different results:
      In an expression defined by:
      a=[1,2,3],
      each i in a:
      shift(a)
      // result (array) [1,2] (unexpected
      // expected [1,2,3]

      This has me thinking that 'each' is leaving items on the table, as I tried unsuccessfully pointing out above.

      The issue here is that your expression shift(a) is modifying the iteration subject array in place. Basically, here are the iteration steps that are run, starting with a=[1,2,3]

      First iteration: a=[1,2,3]; the local i is assigned the first array element 1, but it is not used in the expression. The expression shift(a) results in 1 and causes a to be reduced to [2,3] (the first element is shifted off and becomes the result). Since this is the last value in the expression, 1 is added to the each result array. Second iteration: a is now [2,3] because the previous iteration modified it. So i is assigned 3, because the iteration is on the second element/iteration through the array, but i is not used in the expression. The shift(a) causes a to be reduced to [3] and its return value is 2, so the value 2 is added to the iteration result array. Third iteration: a is now [3], and we are on the third iteration, but the iteration index of 3 (third iteration) is now off the end of the array (only 1 element long), so iteration stops.

      The result of this each is therefore [1,2] because those are two values that were shifted out, and a is left at [3] because there was no third run of shift() to remove it.

      As I said in the PR, modifying an array you are iterating through can be dangerous and confusing in many languages, because iterators keep state during iteration, and some operations you can do inside the iteration can and will invalidate that state in some way. In Lua on Vera, this often leads to deadlocks and crashes so bad that the box reboots, not just a Luup reload. It's a Bad Idea, and programmers who know are very wary of doing this type of thing in any language unless they are certain of the side-effects/lack of side-effects.

      Your additional example:

      a=[1,2,3], // The array 'a' is [1,2,3]
      a=unshift(a,0), // The array 'a' is [0,1,2,3]
      a=push(a,4), // The array 'a' is [0,1,2,3,4]
      each i in a: // Iterating over the 5 elements of 'a'
      shift(a) // Take the first element of 'a' and append it to result array [ ]
      // result [0,1,2] (unexpected)
      // and array 'a' is now [3,4]! (also unexpected)

      Also correct result. All of the gyrations before the each are not relevant to behavior here. At the start of the each, the array is [0,1,2,3,4] (5 elements). Iterations:

      a=[0,1,2,3,4], i=0, shift(a) returns 0 and modifies a to [1,2,3,4]; the each result array is now [0] a=[1,2,3,4], i=2, shift(a) returns 1 and modifies a to [2,3,4]; the each result array is now [0,1] a=[2,3,4], i=4, shift(a) returns 2 and modifies a to [3,4]; the each result array is now [0,1,2] Iteration stops because the iteration index/step is 4, but there remain only two elements in a=[3,4] (we're off the end of the array).

      So the each result is [0,1,2] and a is left with [3,4] and this is correct operation.

      Key points:

      each keeps state during the iteration (as most iterators do) about the subject of the iteration; if the subject changes in a way that affects the state, unexpected results may occur; The functions push(), pop(), shift() and unshift() modify the array in place. If you say b=shift(a) you get a value in b and a modified (shorter) a.
      Multi-System Reactor
    • Feature request: drag & drop between "triggers" and "constraints"

      PerH

      I've imported all reactors from openLuup, and find myself moving a lot of entity-actions from triggers to constraints.. It would help a lot to have "drag & drop", or a move function for this?

      Multi-System Reactor
    • Low-priority GUI feedback

      PerH

      Just thought i'd mention it, as I've walked into it multiple times when editing rules:
      dbc9e2c8-887e-46bd-8e3c-1364eb99bb03-image.png

      When I make/edit rules, i'm used to pressing "save" through the process, and when I do that, theres only the red one left to press. It does make sense, as its already saved, but I'll stop and think one more time when it says w/o saving.
      In my head, a exit button which causes a pop-up warning if changes are not saved makes more sense - like in vera reactor.

      Feel free to discard the idea, its just something to get used to mabye. 🙂

      Multi-System Reactor
    • Problems with Up grading existing MSR.

      Black Cat

      Followers will be aware of the problems I had setting up MSR, so it won;t come as a surprise that now I have problems Upgrading to the latest version. (How much I wish for a "Click to Upgrade" Button.....)
      I've been stuck on this for 6 days and am ready to throw in all into the to hard basket, surely HA shouldn't be this problematic?
      There, I've said it now I feel better....
      So what's the problem, I can upload the file using WINSCP but no matter what I've tried it won't un-tar and over write the existing files in the Reactor Directory.
      I receive the following error message which may as well be written in Martian 🙂 in my case.
      Command 'tar -xz --directory="reactor" -f "reactor-0.1-21101-0db64f0-generic.tar.gz"'
      failed with return code 2 and error message
      tar: reactor: Cannot mkdir: Permission denied
      tar: reactor: Cannot mkdir: Permission denied
      tar: reactor/INSTALL.md: Cannot open: No such file or directory
      tar: reactor: Cannot mkdir: Permission denied
      tar: reactor/LICENSE.md: Cannot open: No such file or directory
      tar: reactor: Cannot mkdir: Permission denied
      cut for sanity sake....

      This goes on for ad infinitum for every file.

      I tried with both users, no change, can anyone decipher this and explain why WINSCP won't untar the file?

      Multi-System Reactor
    • Adding Homeseer as a Controller

      Black Cat

      How can I do this?
      The topic in the instructions is very limited.

      Other Controllers
      Other controllers that you may find as add-ins will each have their own specific configuration instructions. Please refer to their accompanying documentation.

      What information should I be looking for?

      I've tried port 1880 which is used for node-red, assuming that this is a listening port - no go. Really not sure how to go about this as everything I do is mostly trial & error.

      BTW, I added my Vera Lite into the mix successfully, HS4 would make it a trifecta!

      Multi-System Reactor
    • Vera vs MSR lock code logic

      MikeReadington

      Hi Everyone,

      In the Vera Reactor logic, I used to use the operator "updates" in a lock condition.

      If I entered the door and the code used was "Mike," it would hold the condition true indefinitely because "Mike" was the last stored value. Since it is held indefinitely, setting the condition to pulsed would not allow the condition to fire again because it never went false. If I entered a different code, the condition would go false, then entering "Mike" again would cause the condition to go true.

      I did this using the operator "updates" in an AND condition along with the lock code. The code condition would stay true with "Mike," and when "Mike" is entered consecutively, the "updates" condition will go true each time, and then the whole condition would go true, triggering the action.

      Since "updates" no longer appears to be an operator, how would I do this in the new logic? I think I remember a discussion about this, but I searched and can't seem to find it.

      I'm not a programmer, so I am probably missing the easy way to do this.

      Screen Shot 2021-04-18 at 4.54.27 PM.png

      Multi-System Reactor
    • Replacing SiteSensor Plugin (Vera) with MSR

      LibraSun

      For MSR users with SiteSensor still installed back on Vera, you might want to consider letting MSR take over those duties. Here's a quick run-down of how I imported one of my SiteSensor recipes into a Rule on MSR, using OpenWeather API* as an example.

      STEP 1: Copy the Basics from Vera
      (a) Go to your Vera > Devices, locate SiteSensor (the main instance, not one of its children devices) and click ► for details then click SETTINGS.
      (b) Copy and paste (into Notepad or other text editor) the Request URL along with each of the defined expressions.

      STEP 2: Create a Rule on MSR
      (c) Jump into Rule Sets and click "Create Rule". Click its title to rename the rule 'OpenWeather (API)" and click 'Rename'.
      (d) Decide on appropriate Triggers (in my case, it's an OR group that includes an [INTERVAL] set to "Every 3 hours" plus a few [ENTITY ATTRIBUTE] entries reacting to things like entering/leaving home, waking up, etc.).
      (e) In Set Reacion, create an [HTTP REQUEST] > [GET] action.
      (f) Paste your old "Request URL" into the "Request URL" box.

      FYI GET calls to OpenWeather API* take the form:

      http://api.openweathermap.org/data/2.5/weather?zip=<your_ZIP_code>&id=<your_Wx_ID>&appid=<app-id>&units=imperial

      (g) Create four new blank Expressions (name them openWx, Tx, Hx and Rx).
      (h) Click SAVE & EXIT

      STEP 3: Process the Response
      (i) Re-open rule "OpenWeather (API)" by clicking the 'Edit' icon.
      (j) Within the [HTTP REQUEST] action, assign "Capture response to:" ► openWx
      (k) Down in Expressions, click "[+]Add Expresssion" then enter the following:
      Tx := round(openWx.main.temp,1)
      // yields current outdoor temperature
      Hx := round(openWx.main.humidity)
      // yields current humidity conditions
      Rx := openWx.rain ? ( openWx.rain['3h'] ? openWx.rain['3h'] : 0) : 0
      // yields predicted rainfall, if present; otherwise 0
      (l) Click SAVE & EXIT. Enjoy!

      Naturally, your specific needs and workflow will differ from the one I've outlined here. For instance, you may wish to explore the contents of the JSON object in openWx for additional data of interest to you, and define variables to match.

      My goal here has been to illustrate some key concepts needed for moving from SiteSensor over to MSR:

      Some syntax is the same, such as dot notation for object.item.access; Other syntax has changed, such as the use of ternary A ? B : C in place of IF (A, B, C); Manually setting an [INTERVAL] in lieu of SiteSensor's timed schedule;

      Pro tip: If your workflow demands that other Rules react to the output of the "OpenWeather (API)" rule, then be sure to create all of the aforementioned Expressions under "Global Expressions" instead, so they become accessible across all Rule Sets.

      Once the transition is complete, you can either DISARM SiteSensor on Vera or remove it entirely with "Remove Device" (which will automatically remove all of its child devices).

      *Additional reading:
      OpenWeather API : https://openweathermap.org/api
      FREE SUBSCRIPTION REQUIRED TO USE THIS SERVICE

      PRO TIP: See below for optimal way to incorporate OpenWeatherMap into your MSR workflow(s), by enabling the service directly in the reactor.yaml config file.

      Multi-System Reactor
    • Rethinking HVAC moving from Reactor (Vera) to MSR

      G

      In my Vera config I have two SiteSensors (one for Ambient Wx, one for OpenWxMap) that point to two unique Reactor devices for controlling HVAC in my home. This is done for redundancy - if the Ambient API drops it returns zero data which then triggers a standalone Master API Reactor device to flip on the OWM SiteSensor and corresponding HVAC Reactor device to continue controlling the house conditions.

      Once the Ambient API returns to available the Master API Reactor device flips back to the Ambient SiteSensor and corresponding HVAC Reactor device, turning OFF the SiteSensor for OWM to save on API calls.

      I've been able to duplicate one half of this, including the Master API role, in MSR. But... here's the tricky part... I can't turn "off" the MSR Rule Sets for the OWM version. As such, HVAC is sent conflicting data and doesn't know what to do.

      Before I go alls deep into explaining how all of this currently works, am I missing something somewhere that would allow me to trigger the on/off of MSR Rule Sets?

      Multi-System Reactor
    • Expressions and LuaXP Functions

      LibraSun

      Knowing that MSR Preview may not yet fully implement LuaXP (CORRECTION: MSR uses a different language lexpjs), I could not resist whipping up some text expressions for fun. Whereupon two things popped out at me:

      The new scaling (0.00 - 1.00) of Dimming Level will require a rewrite of certain Expressions that I use to balance my light levels. For example, it was my custom to monitor one lamp's brightness (0 - 100) with Reactor Luup, then set another lamp to 93% of that level, using this Expression: floor(getstate( 9, "urn:upnp-org:serviceId:Dimming1", "LoadLevelTarget" ) * 0.93)

      Now, in MSR, it will become necessary to modify that to read:

      floor ((getEntity( "vera>device_9" ).attributes.dimming.level * 0.93)*100)/100

      which effectively scales the value up x 100 (so that floor() can act upon it correctly), then downscale it / 100. Just an FYI to ponder.

      I'm noticing that every edit, however minor, of an Expression in MSR requires an immediate SAVE click before the 'Run' button will become active. That is to say, I cannot repeatedly evaluate the Expression during editing, without clicking SAVE first.

      Only mentioning this latter behavior since it departs so dramatically from Reactor Luup's paradigm.

      Multi-System Reactor
    • MSR API functions and documentation

      cw-kid

      Hi

      I am assuming in time MSR will have some API documentation.

      I am going to ask Bill the developer of the Home Remote dashboard app if he can add support for MSR.

      Specifically support for MSR global Reactions (Scenes), where hopefully they can be imported in to the Home Remote Designer application and then we can more easily create dashboard tiles that when pressed would run a particular MSR global Reaction etc.

      Currently in Home Remote it's possible but not so easy to create a tile that runs a http request when pressed and I have tested this and it does work and will run an MSR global Reaction.

      But I'd much prefer if in the Home Remote Designer application MSR could be added as a device type and then all its global Reactions
      imported as it does with Vera and other systems.

      Multi-System Reactor
    • Global Reactions - Constraints ?

      cw-kid

      Hi

      Will Global Reaction rules have Constraints added at some point?

      And maybe the other functions like Reset Reaction and Expressions.

      Thanks

      Multi-System Reactor
    • Creating Rules with Conditional Logic

      K

      How are folks handling situations where they want to have Conditional Actions or Branching Logic in their Set Reactions for a rule? Are you creating Duplicating the same trigger and setting different conditions and Actions?

      Is there an approach where you combine a main rule with your entity triggers with sub rules that trigger off Expressions? You then could write your conditions as Set Variable actions in the Main Rule for the Expressions that evaluate to true or false. Each sub rule would trigger based on the expression changing to true and then could also change it back to false after.

      Not sure if that's worth the complexity for the reusability and control over duplicate triggers.

      Multi-System Reactor
    • Multi-System Reactor Developer Preview AVAILABLE

      toggledbits

      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!

      Multi-System Reactor
    • Feature Request - Reaction to MQTT

      S

      I looked through the forum, but could not find it, so my apologies if this has been asked. It would be nice to be able to push a message to MQTT for further upstream integrations.

      Multi-System Reactor
    For those who registered but didn't received the confirmation email, please send an email to support@smarthome.community with the email you used

    Low-priority GUI feedback

    Multi-System Reactor
    6
    51
    467
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • PerH
      PerH last edited by

      Just thought i'd mention it, as I've walked into it multiple times when editing rules:
      dbc9e2c8-887e-46bd-8e3c-1364eb99bb03-image.png

      When I make/edit rules, i'm used to pressing "save" through the process, and when I do that, theres only the red one left to press. It does make sense, as its already saved, but I'll stop and think one more time when it says w/o saving.
      In my head, a exit button which causes a pop-up warning if changes are not saved makes more sense - like in vera reactor.

      Feel free to discard the idea, its just something to get used to mabye. 🙂

      1 Reply Last reply Reply Quote 0
      • toggledbits
        toggledbits last edited by

        The exit button does cause a pop-up if unsaved changes are pending, but I agree the three-button arrangement takes getting used to. So, you're suggesting just two buttons, "Save" and "Exit"?

        1 Reply Last reply Reply Quote 0
        • PerH
          PerH last edited by

          I think so, yes. As simple as possible, unless we loose functionality, which i don't think is the case here?

          1 Reply Last reply Reply Quote 2
          • Matohl
            Matohl last edited by

            Yes, I agree with PerH here. Seems logical

            1 Reply Last reply Reply Quote 0
            • HSD99
              HSD99 last edited by

              Piling on here---I also found this confusing. My assumptions: "Save" does just what it says. Hitting "Exit" will then exit with no prompt. Hitting "Exit" alone will prompt for "Save and Exit?" or "Don't save and exit" or something similar.

              1 Reply Last reply Reply Quote 1
              • toggledbits
                toggledbits last edited by

                OK. We'll just have Save and Exit in 21059, with tooltips to tell you more detail (hover over the buttons).

                1 Reply Last reply Reply Quote 2
                • HSD99
                  HSD99 last edited by

                  Great! Thanks!

                  1 Reply Last reply Reply Quote 0
                  • LibraSun
                    LibraSun last edited by LibraSun

                    Occurred to me this evening that you might even consider moving some of the Top Level headings in the left column under the Tools menu once it starts gathering stream.
                    Less used utilities like Scope and even Entities. Then add Backup & Restore, etc. Possibly Dashboard?
                    Tools could then act like a collapsible pane the way Rule Sets does, enabling users so sort it according to need.

                    1 Reply Last reply Reply Quote 1
                    • S
                      SweetGenius last edited by

                      Is there a way to sort Rule Sets in the left hand column? Alphabetical order vs last created on top?

                      LibraSun 1 Reply Last reply Reply Quote 0
                      • LibraSun
                        LibraSun @SweetGenius last edited by

                        @sweetgenius No clickable sort mechanism (yet) just drag and drop for now.

                        1 Reply Last reply Reply Quote 0
                        • S
                          SweetGenius last edited by SweetGenius

                          You are correct. That is what I wanted, Just not smart enough to try drag and drop. That works perfectly.
                          Thanks

                          1 Reply Last reply Reply Quote 1
                          • PerH
                            PerH last edited by

                            Haven't touched my system for a while (or read updates here), busy with other projects..
                            Just have to mention that I updated to the latest today and found the new entity selector tool... LOVE it! That has been my only nagging thing about reactor since vera reactor, all that scrolling..
                            Thanks, @toggledbits, this is really turning into something VERY good!

                            1 Reply Last reply Reply Quote 2
                            • LibraSun
                              LibraSun last edited by LibraSun

                              @toggledbits I'm finally checking out the [RULE RESULT] condition type, and with only a cursory look (I don't recall it from the Docs -- just found its stub at /docs/Rule-Conditions/), come away with more questions than solid understanding... (the rest of my day will be spent gaining the latter):

                              • I see the options [is TRUE], [is FALSE], [is NULL], [is not NULL], and [changes state] (which make sense to me)
                              • I believe the [is NULL] state applies to the target Rule's status reading "undefined -- false as of 10:18:46" (i.e. "undefined" and NULL being treated as equivalent) -- but wonder if users should therefore see its status as "NULL -- false as of 10:18:46" for clarity?
                              • I believe that only Rules that have never (ever) been Run* will match with [is NULL]?
                              *Probably more apt to say "has never been RESET" (since I noticed never-run Rules on which I manually click RESET go from "undefined" to "null")
                              • Disabled rules, since they continue to display their last state (true or false), are not distinguished by this mechanism

                              In light of the last fact, I propose that two more states be included for testing: [is Enabled] and [is Disabled]

                              This would allow a couple of important decisions in the logic flow, such as "Don't do this if the other Rule isn't firing", as well as allow a kind of "Master Switch" setup whereby the referred Rule can serve as a "virtual switch" to effectively enable/disable all of the referring Rules.

                              toggledbits 1 Reply Last reply Reply Quote 0
                              • toggledbits
                                toggledbits @LibraSun last edited by

                                @librasun said in Low-priority GUI feedback:

                                In light of the last fact, I propose that two more states be included for testing: [is Enabled] and [is Disabled]
                                This would allow a couple of important decisions in the logic flow, such as "Don't do this if the other Rule isn't firing", as well as allow a kind of "Master Switch" setup whereby the referred Rule can serve as a "virtual switch" to effectively enable/disable all of the referring Rules.

                                Slippery slope defined.

                                I've already been asked to make an action to enable and disable rules at will. This strikes me as a highway to nightmarish scenarios in which not only does a user's (and by extension likely my) troubleshooting necessarily include the already ample detective work of figuring out the states of conditions in enabled rules (and how the logic came to be, and what the problem is that that logic is intended to solve), but now also we have added carnival funhouse horror that any reaction anywhere in the system can enable or disable any rule at will. In other words, you're moving a part of the logic of a rule out to some other part of the system where there is no visibility from the rule in question that the rule may, in fact, be run or not. I have not yet seen an argument in favor of an enable/disable action that overwhelmes my concerns over how they will be applied.

                                So, if there's a test for is Enabled and is Disabled, I can see right on the heels of that the question coming (again) for an action to cause those states. And your further "Master Switch" comment pretty much confirms this direction.

                                whereby the referred Rule can serve as a "virtual switch" to effectively enable/disable all of the referring Rules.

                                I'd rather provide a built-in set of virtual entities that live entirely in the MSR side. It's also more consistent with the model.

                                So, sorry, I understand how much power enable/disable might be, and how it could be used for good, but in this case the potential for abuse is rife.

                                bd5caaa9-1795-44cd-a32b-f243e2b8a32c-image.png

                                1 Reply Last reply Reply Quote 1
                                • LibraSun
                                  LibraSun last edited by LibraSun

                                  All valid reasoning, as per usual. There's plenty logic in place as-is for users to construct what they need in the way of gates.

                                  My next question has to do with HTTP Request: Do you plan to add "PUT" and other methods (e.g. "PATCH", "DELETE"), alongside "GET" and "POST"?

                                  1 Reply Last reply Reply Quote 0
                                  • toggledbits
                                    toggledbits last edited by

                                    Yes, can do.

                                    1 Reply Last reply Reply Quote 1
                                    • LibraSun
                                      LibraSun last edited by LibraSun

                                      I vote that the expanded list of Rule Sets be (a) indented slightly, so as to distinguish them from the primary UI elements (e.g. "Entities" et seq), and (b) perhaps display a vertical rule | alongside to further differentiate them as a "submenu".

                                      Something like:
                                      rule_sets_indent.png

                                      Right now, the bold-vs-not-bold sometimes throws me, because my list of Rule Sets (greatly truncated here, for clarity) can be longer than the scroll window itself.

                                      P.S. THANKS for the "PUT" and other verbs now available with HTTP Request!

                                      1 Reply Last reply Reply Quote 1
                                      • LibraSun
                                        LibraSun last edited by LibraSun

                                        @toggledbits would it be possible to augment vera>housemode with its own timestamp, so that repeated setting to the same mode can be detected? Currently, I have no obvious way to trigger on "HOME" if Vera is already set to "HOME", etc.

                                        I wasn't even certain that Vera herself reacts internally in any way when I click "HOME" on the Dashboard while she's already in "HOME" mode, so I peeked in her LuaUPnP log and saw:

                                        08	04/06/21 8:56:08.257	JobHandler_LuaUPnP::HandleActionRequest device: 0 service: urn:micasaverde-com:serviceId:HomeAutomationGateway1 action: SetHouseMode <0x70a0e520>
                                        08	04/06/21 8:56:08.257	JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1 <0x70a0e520>
                                        08	04/06/21 8:56:08.258	JobHandler_LuaUPnP::HandleActionRequest argument action=SetHouseMode <0x70a0e520>
                                        08	04/06/21 8:56:08.258	JobHandler_LuaUPnP::HandleActionRequest argument Mode=1 <0x70a0e520>
                                        08	04/06/21 8:56:08.258	JobHandler_LuaUPnP::HandleActionRequest argument rand=0.7538517467636494 <0x70a0e520>
                                        06	04/06/21 8:56:08.261	Device_Variable::m_szValue_set device: 224 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Armed was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0x1057770/NONE duplicate:1 <0x70a0e520>
                                        06	04/06/21 8:56:08.282	Device_Variable::m_szValue_set device: 264 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Armed was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0x1057770/NONE duplicate:1 <0x
                                        

                                        Short of creating a virtual switch or sensor that Vera "arms" on every mode change, I'm unsure how to detect the logged reactions back on MSR. Any thoughts?

                                        P.S. Funny, I'm also just discovering that Vera cannot trigger her own Scenes based on House Mode changing. Who knew?

                                        EDIT: So, I went with creating a (binary on/off) Virtual Switch using Switchboard plug-in. By having Vera turn this switch "On" for every House Mode, MSR can now detect "updates" to House Mode, not merely "changes". This is useful to my workflow. I'll simply create an additional action in SET REACTION which turns the new VS back "Off" automatically.

                                        toggledbits 1 Reply Last reply Reply Quote 0
                                        • toggledbits
                                          toggledbits @LibraSun last edited by toggledbits

                                          I would not be able to make this work on RFV or MSR. There is no timestamp for house mode on Vera because it isn't a state variable, it's an attribute of (virtual) device 0, the HomeAutomationGateway1 engine (which is why it appears as an attribute of the root in user_data). There's nothing to put a watch callback on, because you can only watch state variables. This is why the HouseModes plugin has to poll for changes. Reactor (for Vera) takes a different approach (to eliminate polling and the response delay it causes--RFV reacts immediately), but nonetheless can't see when house mode is set to what it already is because Vera itself won't take any action when that happens. And therefore MSR cannot see it either (although MSR uses yet another approach and can respond immediately on changes like RFV).

                                          1 Reply Last reply Reply Quote 1
                                          • toggledbits
                                            toggledbits last edited by

                                            By the way, this could also segue into a treatise about why there's no updates operator in MSR, because it's related, so let's do that:

                                            On Vera, every state variable also has a timestamp. The general behavior on Vera is that when a state variable value changes, its timestamp is updated as well. If a state variable is set to the same value it already has (write without change), the timestamp does not change. There are, however, exceptions to this rule: state variables whose name starts with sl_ will get a timestamp update when their value is set, even if it is set to the same value it already has. This specifically allows scene controllers, locks, and keypads to work. These device types all use sl_-named variables for those states/data that can be "active" when set to the same value (e.g. the same lock code is used twice on a keypad or lock, or the same button is pressed back-to-back on a scene controller).

                                            This also manifests in Vera as a call to the watch callback for the variable, if any. The watch callback is typically only called when the value of the state variable changes, unless it's an sl_-named variable, in which case the watch callback is called unconditionally. This is how Reactor for Vera (RFV) detects and implements the updates operator.

                                            Given that information, one might think that you can, from outside Luup (i.e. in MSR using HTTP requests for interface), detect same-value updates by tracking the timestamp, but there are two problems:

                                            1. The timestamp is not exported in the user_data or status requests (or any that I'm aware of), so you can't access it from outside the system. The only place it is visible/available is within Luup itself by calling luup.variable_get();
                                            2. Even if we got the timestamps, the timestamps are not stable, they are volatile: Luup does not store the timestamps in user_data.json, it only keeps them in RAM (which is probably also why they are not exported). Every time Vera reloads, every state variable's timestamp is updated/rewritten to the current time during startup. So it's actually not usable as a persistent value to compare to prior values across reloads, it's only usable within the context of the current Luup reload. That raises the complexity of determining if a timestamp change is the result of an actual change, or a reload with no change in value, or a reload with a change in value during downtime.
                                            3. If we stored timestamps with values, it would double the memory consumption of attributes (because then it has to store two values for every attribute rather than one, and there are a lot of attributes in memory), and do so only for the benefit of one operator applicable in a very small number of cases.

                                            Aside from this, MSR isn't a Vera plugin, or a logic engine just for Vera. Neither Hubitat nor Hass, nor any other system I've yet seen, has timestamps with which an equivalent comparison could be made, or a replacement mechanism by which updates could be reliably implemented for entities originating in any HAC. So in all, updates hasn't (yet) shown a use case/demand that overwhelms the costs in the face of the available workarounds.

                                            1 Reply Last reply Reply Quote 1
                                            • First post
                                              Last post

                                            Welcome. If you’d like to participate in the discussion, rather than just read, then you can join the forum. As a member, you can interact with others here to share your experience and ask the questions you need answered.

                                            Powered by NodeBB | Contributors
                                            Hosted freely by PointPub Media Communications Inc. | Contact us