Posts

• ---

  Organizing/ structuring rule sets and rules
  T therealdb

  I prefer a structure where I organize them by features. The name reflects the rule set they're in (ie Lights-Outdoor-Gate is in Lights-Outdoor) to simplify discoverability, until a global search is added

• ---

  Organizing/ structuring rule sets and rules
  T toggledbits

  I do a mix. I have rule sets for each room. Generally, these manage lighting, and maybe a small number of specific devices in that area. I have functional rule sets for other things like determining house mode (which is really a blend of season, day of week, time of day, and other switches I can throw for when we're having a party or overnight guests). Functional rule sets also cover room- or level-spanning rules. For example, I bring management of all leak detectors to a single utility rule set.

  There's no harm in moving things around. Rules in rule sets have unique IDs that are not affected by their parent location, so moving them changes nothing operationally, it's just an organizational tool for the user. Make a structure and evolve it as you find need. You'll settle into something that works for you.

• ---

  Moving MSR from a QNAP container to RP 5 - some issues
  T toggledbits

  I know I sound like a broken record, but look at the logs. At startup, much is logged, and if there are problems with file permissions (which I suspect), you'll see it mentioned there in some form.

• ---

  Moving MSR from a QNAP container to RP 5 - some issues
  T therealdb

  the clock problem is a know bug. update to latest.

  Please be 100% extra sure to copy everything under storage. this includes any file/directory under the path. do it while bot reactors are stopped for better accuracy.

• ---

  Reactor (Multi-System/Multi-Hub) Announcements
  T toggledbits

  Reactor build 25097

  • Expression syntax enhancement: it is now possible to use a variable's value as a key when creating an object on the fly. For example, if the variable cmd contains the word "econo" (presumably derived from configuration or some other dynamic source), it is now possible to create an object { econo: true } by enclosing the key source in square brackets: obj = { [cmd]: true }. For reference, this syntax mimicks JavaScript.
  • Fixed a UI crash when bringing up Reactor initially after using the About page bypass.
  • OWMWeatherController: implement sys_system.restart, which will cause all locations to be refreshed immediately.
  • OWMWeatherController: new config option (boolean) ignore_certs can be set to ignore certificate errors. These seem to pop up occasionally, perhaps because of a misconfiguration in the load balancing at OWM.

• ---

  Deleting widgets
  T toggledbits

  As of build 24343, widget deletion is accomplished by dragging the widget to the top navigation bar (only). Dragging to the left margin no longer deletes the widget.

• ---

  Widget deletion does not work and landing page (status) is empy
  T toggledbits

  

  This change was also mentioned in the release notes for build 24343.

• ---

  Need help reducing false positive notifications
  T toggledbits

  @tamorgen Frankly, it looks like you've made an overly simplistic sensor that you're trying to improve on in the rule... you're taking a low-res image of the device and trying to make it back into something higher-res.

  I'd just look at the power directly in Reactor:

  

  

• ---

  Need help reducing false positive notifications
  T toggledbits

  @tamorgen said in Need help reducing false positive notifications:

  Any thoughts? I know I can set up a a condition to monitor the power sensor value, and make sure it is above 3.5 for 5 minutes, but the condition I need is for the power value to go to the standby value of under 2.9 after that condition is met. That's what I'm unclear how to do.

  Look at the condition options (for any condition). You'll see the ability to sequence conditions there -- set a condition so it can only go true after another condition has gone true.

  Your problem seems simpler to me, though. Maybe I just don't get the full scope from what you wrote, but what you asked for can be done without sequencing.

  If you just want to know if the machine is running, make a rule for power >5W (your 3.7W plus some headroom) sustained for at least 5 minutes (see condition options again). If you want to know if the machine is not running, make a rule for (guessing) power < 15W sustained for 5 minutes. I think you'll find these pretty effectively ignore the transitions between cycles and bumps at the controls or door left open (light on) if you get the power values right for your machine's behavior.

  Now you have two rules, one to tell you that it appears to be idle, and the other that it appears to be running. We could use one rule, but by using two rules with a gap between the power values, we create additional hysteresis to prevent those false positives. For you rules that need to react to the machine going idle, use a Rule State condition to check your idle rule; for rules that need to react to the machine running, check the running rule.

• ---

  Need help reducing false positive notifications
  T therealdb

  I haven't moved this particular piece into MSR yet, but my logic is:

  • watch for idle: if watts<5 for at least 15 secs, that's done. If previous status is running, mark as completed. Otherwise, stays idle.
  • watch for watts. if idle and watts > 50 for at least 15 secs, that's running.

  I think the best way to achieve this is by having two different rules. I'll probably design it with a virtual device with a string_sensor, containing the current state. I've never moved this part of my system to MSR, because I want to write a controller doing exactly this, but the logic is not complex.