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 23, 2021)

    • TTS in MSR?

      F

      Hi!

      In Home Assistant I sometimes uses the TTS, either to my Sonos or Google speakers. With reactor in Vera I also use TTS.
      But in MSR I can't select the TTS-service. It's simply not there. Am I missing something, or is this the case, so far?
      Thanks!
      /Fanan

      Multi-System Reactor

    • MSR Logic vs Reactor question

      R

      Hello,
      Trying to convert my Reactor scripts to MSR. Couldn't get the import to work so gave up on that. Anyway, curious on how to work with the following example.

      Have a motion sensor on my back porch. Very simple logic:
      7fbcd69e-9f85-4b7f-8138-1267d4e4ba1a-image.png The Reactor activities are as follows:
      34e715fd-c2f1-4b92-99ea-e2838fc5d3dc-image.png.

      In MSR, how do you tie activities to sub conditions like I have with the last action in activities.
      In this case I was to trigger BlueIris to trigger regardless of the time of day, but only want the light to come on at night. Do I need multiple Rule Sets?

      Thanks,
      Roger

      Multi-System Reactor

    • HASS version not supported?

      Tom_D

      I am running MSR 1.0.0-21200-16a604f and am seeing the message:

      HomeAssistant on "hass" may be an unsupported version. The reported version (2021.7.3) has not been certified/tested with this version of Reactor and may cause errors. You must either modify your HomeAssistant install, or see if an update to Reactor has been made available.

      Multi-System Reactor

    • Support for Ezlo Atom controllers?

      cw-kid

      Hi

      I just tried to add a connection for my Ezlo Atom, its added the Atom system in to the MSR Entities, but it has a "false" state and hasn't found my devices that are paired to the Atom.

      ff7f286a-e987-4b2b-a56e-0b7a067aff6e-image.png

      Also note that on the Atom controller there is no settings for:

      offlineAnonymousAccess: true or false

      offlineInsecureAccess: true or false

      So this line in the reactor.yaml file won't work for Atom's.

      set_anonymous_access: true

      This was what I added to my reactor.yaml file.

      - id: ezlo-atom enabled: true implementation: EzloController name: Ezlo Atom config: source: "wss://192.168.0.101:17000" # change the IP address serial: "70060304" # put your hub's serial here username: "myusername" # put your username here between quotes password: "mypassword" # and password # set_anonymous_access: true

      Thanks

      Multi-System Reactor

    • Vera - Attempt to set primary to power_switch.state invalid

      cw-kid

      I am seeing errors like these in the log file:

      <VeraController:NOTICE> Controller VeraController#vera-edge is now online. 2021-07-22T15:41:29.586Z <default:ERR> [Entity:setPrimaryAttribute] Attempt to set primary to power_switch.state invalid, not in { "x_vera_device": { "device_number": 139, "device_type": "urn:schemas-upnp-org:device:RGBController:1", "parent_device": 0, "failed": false, "configured": --null--, "mapped_class": "rgbcontroller_plugin", "mapped_by": "*;device_type=urn:schemas-upnp-org:device:RGBController:1" }, "x_vera_svc_upnp_org_RGBController1": { }, "x_vera_svc_upnp_org_SwitchPower1": { }, "x_vera_svc_micasaverde_com_HaDevice1": { }, "x_vera_rgbcontroller_plugin": { "device_type": "FGRGBWM-441", "configured": true, "color": "#0000000000", "message": "" } } 2021-07-22T15:41:29.587Z <VeraController:ERR> VeraController#vera exception/error while updating VeraController#vera 2021-07-22T15:41:29.588Z <VeraController:CRIT> Error: Entity#vera>device_139:setPrimaryAttribute() can't set power_switch.state, not defined for entity Error: Entity#vera>device_139:setPrimaryAttribute() can't set power_switch.state, not defined for entity

      and

      <default:ERR> [Entity:setPrimaryAttribute] Attempt to set primary to power_switch.state invalid, not in { "x_vera_device": { "device_number": 75, "device_type": "urn:schemas-micasaverde-com:device:WindowCovering:1", "parent_device": 1, "failed": false, "configured": false, "mapped_class": "fibaro_cover_scenecontrol", "mapped_by": "*;device_type=urn:schemas-micasaverde-com:device:WindowCovering:1;pnp=/^(3222)$/" }, "x_vera_svc_upnp_org_SwitchPower1": { }, "x_vera_svc_upnp_org_Dimming1": { }, "x_vera_svc_upnp_org_WindowCovering1": { }, "x_vera_svc_micasaverde_com_Protection1": { }, "x_vera_svc_micasaverde_com_EnergyMetering1": { }, "x_vera_svc_micasaverde_com_HaDevice1": { }, "x_vera_svc_micasaverde_com_ZWaveDevice1": { }, "x_vera_svc_micasaverde_com_ZWaveNetwork1": { }, "x_vera_svc_micasaverde_com_GenericSensor1": { }, "x_vera_svc_micasaverde_com_Color1": { }, "x_vera_svc_micasaverde_com_SceneController1": { }, "cover": { "state": false }, "position": { "value": 0 }, "zwave_scene_controller": { "scene_activated": "0", "key_attribute": --null--, "scene_deactivated": --null--, "central_scene": --null-- }, "x_vera_scene_controller": { "last_scene_id": "26", "last_scene_time": "1626714753" } } 2021-07-22T15:41:28.925Z <VeraController:ERR> VeraController#vera exception/error while updating VeraController#vera 2021-07-22T15:41:28.926Z <VeraController:CRIT> Error: Entity#vera>device_75:setPrimaryAttribute() can't set power_switch.state, not defined for entity Error: Entity#vera>device_75:setPrimaryAttribute() can't set power_switch.state, not defined for entity

      What does it mean?

      One is an RGBW Plugin device the other is a real Z-Wave device, a Fibaro Roller Shutter 2.

      Thanks

      Multi-System Reactor

    • Release 1.0.0

      toggledbits

      Well, it's July 19th, and as previously advertised, Reactor (Multi-System, aka MSR) has been published at release 1.0.0.

      Docker images are on DockerHub, and download package for bare-metal installs is available at https://reactor.toggledbits.com/download/

      Those of you with access to the Mantis Bug Tracker for the project, please continue to use it, particularly if you stick with the "latest" docker image tag (which will continue to be updated periodically, as will the bare-metal tarball). Feel free to open issues there on behalf of other users who do not have accounts if it seems appropriate.

      Multi-System Reactor

    • HASS.OS Install

      V

      Hi,

      Am I correct in assuming that MSR cannot be installed on a pi running HASS.OS?

      Thanks.

      Multi-System Reactor

    • Ezlo device capabilities

      Elcid

      Having gotten the Ezlo controller to connect I see these device items
      x_ezlo_item.learn_ir_code=0
      x_ezlo_item.learn_rf_code=0
      x_ezlo_item.send_ir_code=""
      x_ezlo_item.send_rf_code=""

      But they are not listed in the capabilities. It would be nice if to send Ir and Rf codes direct from MSR.

      If possible couild you add this feature.

      Multi-System Reactor

    • Entities area is this expected?

      cw-kid

      In Entities area, I selected the Ezlo controller. However when using the Capabilities drop down list, I can also see capabilities from the Vera firmware hubs as well, is that expected behaviour?

      Thanks

      entities.png

      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

    • Any instructions on how to update MSR on QNAP NAS Docker

      R

      Hello,

      Looking for a "how to" for this. That section is TBD in the documentation.

      Thanks,
      Roger

      Multi-System Reactor

    • Cannot save Restriction in MSR Rule Set

      R

      Moving my washer and dryer monitor from Reactor to MSR. I have a virtual switch to turn off notification that has worked well under Reactor. Recreating it in MSR and I cannot get the rule to save the restriction that the switch must occur prior to the wattage monitor triggering. When ever I save the rule, the restriction reverts to the default state of blank.

      Currently on 21168 running on docker.

      Let me know of any additional info you need.

      Multi-System Reactor

    • Issues connecting to Ezlo Controller

      cw-kid

      I've read the thread and the docs, thought I'd setup everything correctly, but MSR doesn't connect to my Ezlo controller.

      The docs don't say what to do if you have already previously enabled anonymous access via their Online API Tool.

      “offlineAnonymousAccess” and “offlineInsecureAccess” are set to true on my controller already.

      In my Reactor.yaml file I decided to try it first with the username and password entries commented out and also the "set_anonymous_access: true" commented out.

      I see these errors in the log file:

      2021-07-16T08:53:56.225Z <app:NOTICE> Starting Structure... 2021-07-16T08:53:56.235Z <Structure:INFO> Structure#1 starting controller interface vera (VeraController) 2021-07-16T08:53:56.245Z <Structure:INFO> Structure#1 starting controller interface vera-edge (VeraController) 2021-07-16T08:53:56.248Z <Structure:INFO> Structure#1 starting controller interface ezlo (EzloController) 2021-07-16T08:53:56.250Z <Structure:INFO> Structure#1 starting controller interface weather (OWMWeatherController) 2021-07-16T08:53:56.252Z <Structure:INFO> Structure#1 starting controller interface reactor_system (SystemController) 2021-07-16T08:53:56.379Z <default:null> Module VeraController v21195 2021-07-16T08:53:56.402Z <default:null> Module OWMWeatherController v21140 2021-07-16T08:53:56.407Z <default:null> Module SystemController v21102 2021-07-16T08:53:56.419Z <VeraController:NOTICE> VeraController#vera starting 2021-07-16T08:53:56.582Z <VeraController:INFO> VeraController#vera loaded mapping ver 21177 rev 1 format 1 notice 2021-07-16T08:53:56.623Z <VeraController:NOTICE> VeraController#vera-edge starting 2021-07-16T08:53:56.629Z <Controller:CRIT> Controller: failed to load ezlo implementation file:///home/username/reactor/server/lib/EzloController.js: Error: Cannot find module 'uuid' Require stack: - /home/username/reactor/server/lib/EzloController.js 2021-07-16T08:53:56.632Z <Controller:CRIT> Error: Cannot find module 'uuid' Require stack: - /home/username/reactor/server/lib/EzloController.js Error: Cannot find module 'uuid' Require stack: - /home/username/reactor/server/lib/EzloController.js at Function.Module._resolveFilename (internal/modules/cjs/loader.js:885:15) at Function.Module._load (internal/modules/cjs/loader.js:730:27) at Module.require (internal/modules/cjs/loader.js:957:19) at require (internal/modules/cjs/helpers.js:88:18) at Object.<anonymous> (/home/username/reactor/server/lib/EzloController.js:478:84) at Module._compile (internal/modules/cjs/loader.js:1068:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:1097:10) at Module.load (internal/modules/cjs/loader.js:933:32) at Function.Module._load (internal/modules/cjs/loader.js:774:14) at ModuleWrap.<anonymous> (internal/modules/esm/translators.js:199:29) 2021-07-16T08:53:56.692Z <Controller:NOTICE> Controller SystemController#reactor_system is now online. 2021-07-16T08:53:56.828Z <Structure:ERR> [Structure:start] failed to start controller ezlo: Error: Cannot find module 'uuid' Require stack: - /home/username/reactor/server/lib/EzloController.js 2021-07-16T08:53:56.829Z <Structure:CRIT> Error: Cannot find module 'uuid' Require stack: - /home/username/reactor/server/lib/EzloController.js Error: Cannot find module 'uuid' Require stack: - /home/username/reactor/server/lib/EzloController.js at Function.Module._resolveFilename (internal/modules/cjs/loader.js:885:15) at Function.Module._load (internal/modules/cjs/loader.js:730:27) at Module.require (internal/modules/cjs/loader.js:957:19) at require (internal/modules/cjs/helpers.js:88:18) at Object.<anonymous> (/home/username/reactor/server/lib/EzloController.js:478:84) at Module._compile (internal/modules/cjs/loader.js:1068:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:1097:10) at Module.load (internal/modules/cjs/loader.js:933:32) at Function.Module._load (internal/modules/cjs/loader.js:774:14) at ModuleWrap.<anonymous> (internal/modules/esm/translators.js:199:29) 2021-07-16T08:53:56.831Z <Controller:CRIT> Controller: failed to start controller reactor_system (file:///home/username/reactor/server/lib/SystemController.js): TypeError: Can't set NaN on attribute suninfo.astronomical_dawn (reactor_system>sun) 2021-07-16T08:53:56.832Z <Controller:CRIT> TypeError: Can't set NaN on attribute suninfo.astronomical_dawn (reactor_system>sun) TypeError: Can't set NaN on attribute suninfo.astronomical_dawn (reactor_system>sun) at Entity.setAttribute (/home/username/reactor/server/lib/Entity.js:308:19) at SystemController.run (/home/username/reactor/server/lib/SystemController.js:224:643) at /home/username/reactor/server/lib/SystemController.js:172:35 at new Promise (<anonymous>) at SystemController.start (/home/username/reactor/server/lib/SystemController.js:170:76) at /home/username/reactor/server/lib/Controller.js:273:89 2021-07-16T08:53:56.833Z <Structure:ERR> [Structure:start] failed to start controller reactor_system: TypeError: Can't set NaN on attribute suninfo.astronomical_dawn (reactor_system>sun) 2021-07-16T08:53:56.833Z <Structure:CRIT> TypeError: Can't set NaN on attribute suninfo.astronomical_dawn (reactor_system>sun) TypeError: Can't set NaN on attribute suninfo.astronomical_dawn (reactor_system>sun) at Entity.setAttribute (/home/username/reactor/server/lib/Entity.js:308:19) at SystemController.run (/home/username/reactor/server/lib/SystemController.js:224:643) at /home/username/reactor/server/lib/SystemController.js:172:35 at new Promise (<anonymous>) at SystemController.start (/home/username/reactor/server/lib/SystemController.js:170:76) at /home/username/reactor/server/lib/Controller.js:273:89 2021-07-16T08:53:56.835Z <app:INFO> Structure running; pausing for controllers' initial ready
      Multi-System Reactor

    • Change in Plans (Don't Panic)

      toggledbits

      Everyone, I've had a change in thinking.

      As many of you know, I had decided to not build an MSR interface for eZLO's new controllers, for multiple reasons, not the least of which was that I had chosen not to use an eZLO hub in my future HA. I am currently straddling three hubs: Vera, Home Assistant, and Hubitat. I am actually very much enjoying the flexibility this has provided. But these three hubs are enough for the moment, and when the venerable Vera Plus on which my house has operated since 2017 dies, I will likely just move the rest of my ZWave devices to the other hubs and reduce by one.

      Another reason for my previous decision was the risk of fluidity/instability in the eZLO APIs. Since this is first generation work, and even now as they approach the three-year mark on development and are still in "beta" with much functionality still incomplete or missing altogether (plugin UI framework?... anyone? anyone?), it stands to reason that, like all projects in this phase in particular, choices are made that need to be revisited. To be fair, Hass and Hubitat are not immune from this either, even as much more mature products with greater market penetration. In any case, I've demurred because of the high perceived risk of change and breakage, and didn't want to put myself (again) on the critical path of my own user base waiting for me to catch up. I accept now, however, that events like this are just part and parcel of the environment in which I've chosen to work. As I said, if it's not eZLO changing something, it's going to be Hass, or something else. I haven't had a breaking change hit from the Hubitat side yet, but it's probably just a matter of time. Just as I seek to improve my work, they must seek to improve theirs.

      The upshot is that I've decided to write an eZLO interface, and I've been working on that for a few days and now have a working prototype running. It works with the few devices I have available for it, and there's a lot that's assumed and untested about all the others. Think back to March, when MSR was first released -- the process of going through and stabilizing these interfaces under all the different external conditions, with devices in your environments that I don't, and sometimes cannot, have -- it takes time. Drilling out all of the details of device behaviors and data, and how each hub handles them differently, takes time. But it's going to be a reality. Aside from this, reading the other forums makes me realize just how much this is needed, if only because there appears as yet to be no articulated concrete plan (e.g. words beyond a promise with no date) to support easy migration from a Vera to an eZLO. MSR touts itself as a tool to assist such migrations between hubs. An eZLO interface must exist.

      To set expectations: you'll see the first version of this interface in a build in the next couple of weeks. It will be an add-in. Like MSR itself, I will be limiting the initial audience, and those of you that participate in the early use and testing will be asked to provide lots of diagnostics and feedback (so please don't ask/participate if you're not willing and able to put in the time). It's brand new, unfinished work; there will be lots of bugs, and lots of holes, and it's going to take a lot to get them all squashed and filled, respectively.

      Based on what I've learned so far from this project, I also want to forewarn you that it may include access to my cloud infrastructure for automatic logging (to make our mutual efforts to examine problems easier and faster), at least during the early stages. At the moment, MSR has no hard Internet-access dependencies, so this is a change for this interface work.

      Also, I probably will ultimately be charging a modest monthly or annual subscription for the eZLO interface, which is a change from policy and practice to date. The amount of effort the project has demanded and can demand in future makes it necessary that I consider a business model. I know that gives some pause, but it should also give you confidence that I am thinking of a long-term future. But, those of you who, as of this writing, hold active accounts on the MSR bug tracker and have participated so valuably in the testing and improvement of MSR, are grand-fathered in to a perpetual (personal/non-commercial use) license to MSR and this interface (no fees, at least for what parts are produced by my hand; I cannot control what others may choose to do if/when third party development takes root). I am considering extending that benefit to everyone who has donated to my projects from the start to date; that is, including those who supported Reactor for Vera, without which MSR would never had been born.

      I can probably predict from these forums and others who the active eZLO users are going to be, but if you want to work with me on it, please let me know by reply here. I will be relying on you heavily, because I am not going to be a big consumer of the hub, so a lot of the work will require data collected from you and your hub and investigative work on that evidence, rather than first-hand experience and witnessed events in my own environment. But I'm confident it will work, as much gets done this way already, and investing in more and deeper troubleshooting tools is always a good investment.

      Thanks to all of you who have supported this project. Onward...

      Multi-System Reactor

    • Multiple Holidays, one Ruleset

      G

      Seems simple enough: same landscape lights for Independence Day, Memorial Day, and Labor Day.

      Complication: one is a static date each year, the others are "last Monday of" and "first Monday of" respectively.

      Here's what I have:
      80869959-4370-489a-bf61-2810fb7da1b9-image.png

      How far off am I?

      Multi-System Reactor

    • Lock code as trigger

      G

      I'd like to trigger off of the entry of someone's lock code into my Schlage CONNECT lock. I've stared at my options in the Entities and the closest I can come is the stored x_hubitat_extra_attributes.lastCodeName="Nik".

      It just doesn't feel quite 100% like what I'm looking for - but nothing else comes even close.

      Multi-System Reactor

    • Version 1.0 Pre-release Discussion

      toggledbits

      We're 60 days out from the 1.0 release date I gave earlier in this category. For about the next 30 days, I'll entertain new feature requests for anything you all feel is absolutely needed and not yet present for a 1.0 release, and you're going to have to make a strong case. Short of that, it will have to live on the wish list for a possible future release.

      Identify and discuss in this topic, please... go!

      Multi-System Reactor

    • Trying to set variable with HTTP API request

      cw-kid

      @toggledbits said in Build 21117:

      I just added a GET for this as well just for simplicity/basic use only, to be in next build:
      http://msr-ip:8111/api/v1/variable/testme/set?value=123

      I updated and tried this:

      http://192.168.0.100:8111/api/v1/variable/run/set?value=123

      "run" is the name of my Global Expression.

      In the web browser I get this response:

      Cannot GET /api/v1/variable/run/set

      I can't see anything related in the reactor log file.

      Multi-System Reactor

    • Play media from HA:s media folder?

      F

      Hi!
      Is it possible to play mediafiles (mp3) with a Sonos speaker from the media folder within Home Assistant, with a MSR reaction? For example no one is home and a potential thief is sneaking around in my backyard - then I would want to play a certain mp3 file (a barking dog or something else). Is it possible? I have done this before, in Veras reactor, when I had the mp3 file in the "cmh-ludl" folder. But because I want to keep the Vera as unloaded and free as possible, I would like to use HA instead. Thanks in advance!
      /Fanan

      Multi-System Reactor

    • Is it possible for MSR to tell which (or how many) familymembers are home?

      F

      My question is in the topic: Is it possible for MSR to tell which (or how many) familymembers are home? I just wounder if it's even possible to create something with MSR to generate that kind of information? A scenario this would come in handy, is when I come home from work, or from a late night with friends, and I just want to ask Google home, which familymember is home. There's a lot more scenarios I could think of, but the aim of this post is to figure out if it's even possible. I've seen (kind of complicated) solutions with HA, and that's not my first pick - if it's possible to choose.
      If I would to create all the different combination with five familymembers, there are 120 different combinations - so that's not what I'm intending to do... 😂

      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

    Setting up Pushover in MSR

    Multi-System Reactor
    3
    8
    89
    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.
    • J
      jsimmo last edited by

      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.

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

        Look in /dist-config/notifications.yaml for the latest guide on configuring for Pushover

        Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

        1 Reply Last reply Reply Quote 0
        • J
          jsimmo last edited by

          Thanks. Should have known to look there. Will give it a try.

          1 Reply Last reply Reply Quote 0
          • J
            jsimmo last edited by

            Followed the guide and Pushover is now set up and working fine.

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

              I've got my Pushover config up and running (and dare I say, working great) in MSR, except for one minor "thing"...

              ...all my notifications keep coming to the default device (my cellphone) rather than the device explicitly declared in the "Device:" field of my Rule. I've double-checked the spelling (HP_mini, which matches the label assigned to my Web browser on pushover.net), verified that the Pushover client is open in Chrome and receiving messages -- particularly those I send from the Pushover web UI "as MSR", and that all keys are current and in the right places, etc.

              Like I say, the messages DO get sent. Only to the wrong endpoint. Is anyone else with multiple endpoints defined getting misdirected notices from MSR??

              • Libra "Edge Case" Sun

              P.S. I don't reckon these associated lines from Reactor.log shed any light on the URL sent (and MSR cannot capture Pushover's response, so far as I know):

              2021-04-22T22:11:10.717Z <Rule:5:Rule.js:750> Rule#rule-kntf80qj dependency notification entity-changed Entity#vera>device_110 from Entity#vera>device_110
2021-04-22T22:11:10.718Z <Rule:5:Rule.js:756> Rule#rule-kntf80qj requesting eval; entity-changed Entity#vera>device_110
2021-04-22T22:11:10.719Z <Rule:5:Rule.js:750> Rule#rule-kntf80qj dependency notification entity-changed Entity#vera>device_110 from Entity#vera>device_110
2021-04-22T22:11:10.720Z <Rule:5:Rule.js:756> Rule#rule-kntf80qj requesting eval; entity-changed Entity#vera>device_110
2021-04-22T22:11:10.721Z <Rule:5:Rule.js:951> Rule#rule-kntf80qj (rule-kntf80qj) evaluate() acquiring mutex
2021-04-22T22:11:10.722Z <Rule:5:Rule.js:951> Rule#rule-kntf80qj (rule-kntf80qj) evaluate() acquiring mutex
2021-04-22T22:11:10.723Z <Rule:5:Rule.js:955> Rule#rule-kntf80qj._evaluate() mutex acquired, evaluating
2021-04-22T22:11:10.724Z <Rule:5:Rule.js:959> Rule#rule-kntf80qj update rate is 3/min limit 60/min
2021-04-22T22:11:10.725Z <Rule:5:Rule.js:881> Rule#rule-kntf80qj evaluateExpressions() with 0 expressions
2021-04-22T22:11:10.725Z <Rule:5:Rule.js:971> Rule#rule-kntf80qj._evaluate() trigger state now false (was false)
2021-04-22T22:11:10.726Z <Rule:5:Rule.js:973> Rule#rule-kntf80qj._evaluate() constraints state true
2021-04-22T22:11:10.727Z <Rule:null> Rule#rule-kntf80qj rule state now false, changed no
2021-04-22T22:11:10.728Z <Rule:5:Rule.js:955> Rule#rule-kntf80qj._evaluate() mutex acquired, evaluating
2021-04-22T22:11:10.729Z <Rule:5:Rule.js:959> Rule#rule-kntf80qj update rate is 3/min limit 60/min
2021-04-22T22:11:10.730Z <Rule:5:Rule.js:881> Rule#rule-kntf80qj evaluateExpressions() with 0 expressions
2021-04-22T22:11:10.731Z <Rule:5:Rule.js:971> Rule#rule-kntf80qj._evaluate() trigger state now false (was false)
2021-04-22T22:11:10.732Z <Rule:5:Rule.js:973> Rule#rule-kntf80qj._evaluate() constraints state true
2021-04-22T22:11:10.733Z <Rule:null> Rule#rule-kntf80qj rule state now false, changed no
2021-04-22T22:11:10.850Z <Rule:5:Rule.js:750> Rule#rule-kntf80qj dependency notification entity-changed Entity#vera>device_110 from Entity#vera>device_110
2021-04-22T22:11:10.851Z <Rule:5:Rule.js:756> Rule#rule-kntf80qj requesting eval; entity-changed Entity#vera>device_110
2021-04-22T22:11:10.852Z <Rule:5:Rule.js:750> Rule#rule-kntf80qj dependency notification entity-changed Entity#vera>device_110 from Entity#vera>device_110
2021-04-22T22:11:10.853Z <Rule:5:Rule.js:756> Rule#rule-kntf80qj requesting eval; entity-changed Entity#vera>device_110
2021-04-22T22:11:10.854Z <Rule:5:Rule.js:951> Rule#rule-kntf80qj (rule-kntf80qj) evaluate() acquiring mutex
2021-04-22T22:11:10.855Z <Rule:5:Rule.js:951> Rule#rule-kntf80qj (rule-kntf80qj) evaluate() acquiring mutex
2021-04-22T22:11:10.856Z <Rule:5:Rule.js:955> Rule#rule-kntf80qj._evaluate() mutex acquired, evaluating
2021-04-22T22:11:10.856Z <Rule:5:Rule.js:959> Rule#rule-kntf80qj update rate is 4/min limit 60/min
2021-04-22T22:11:10.857Z <Rule:5:Rule.js:881> Rule#rule-kntf80qj evaluateExpressions() with 0 expressions
2021-04-22T22:11:10.859Z <Rule:5:Rule.js:1579> cond cond7hpkrvd evaluation state false->true
2021-04-22T22:11:10.860Z <Rule:5:Rule.js:1579> cond trig evaluation state false->true
2021-04-22T22:11:10.860Z <Rule:5:Rule.js:971> Rule#rule-kntf80qj._evaluate() trigger state now true (was false)
2021-04-22T22:11:10.861Z <Rule:5:Rule.js:973> Rule#rule-kntf80qj._evaluate() constraints state true
2021-04-22T22:11:10.862Z <Rule:INFO> Rule#rule-kntf80qj (rule-kntf80qj) triggered!
2021-04-22T22:11:10.863Z <Rule:null> Rule#rule-kntf80qj rule state changed, was false now true
2021-04-22T22:11:10.863Z <Rule:null> Rule#rule-kntf80qj rule state now true, changed true
2021-04-22T22:11:10.865Z <Rule:5:Rule.js:955> Rule#rule-kntf80qj._evaluate() mutex acquired, evaluating
2021-04-22T22:11:10.866Z <Rule:5:Rule.js:959> Rule#rule-kntf80qj update rate is 4/min limit 60/min
2021-04-22T22:11:10.867Z <Rule:5:Rule.js:881> Rule#rule-kntf80qj evaluateExpressions() with 0 expressions
2021-04-22T22:11:10.868Z <Rule:5:Rule.js:971> Rule#rule-kntf80qj._evaluate() trigger state now true (was false)
2021-04-22T22:11:10.869Z <Rule:5:Rule.js:973> Rule#rule-kntf80qj._evaluate() constraints state true
2021-04-22T22:11:10.869Z <Rule:INFO> Rule#rule-kntf80qj (rule-kntf80qj) triggered!
2021-04-22T22:11:10.870Z <Rule:null> Rule#rule-kntf80qj rule state now true, changed no
2021-04-22T22:11:10.872Z <Rule:5:Rule.js:999> Rule#rule-kntf80qj enqueueing reaction rule-kntf80qj:S
2021-04-22T22:11:10.873Z <Engine:INFO> Enqueueing "rule-kntf80qj<SET>" (rule-kntf80qj:S)
2021-04-22T22:11:10.874Z <Engine:5:Engine.js:948> Engine#1 queueReaction() starting Promise for rule-kntf80qj:S rule rule-kntf80qj task 368
2021-04-22T22:11:10.875Z <Engine:5:Engine.js:1059> _process_reaction_queue() wake-up!
2021-04-22T22:11:10.877Z <Engine:5:Engine.js:1020> _process_reaction_queue() running task 368 { "tid": 368, "id": "rule-kntf80qj:S", "rule": "rule-kntf80qj", "__reaction": [RuleReaction#rule-kntf80qj:S], "next_step": 0, "status": 0, "ts": 1619129470873, "__resolve": --function--, "__reject": --function--, "__promise": [object Promise] }
2021-04-22T22:11:10.878Z <Engine:NOTICE> Starting reaction rule-kntf80qj<SET> [RuleReaction#rule-kntf80qj:S]
2021-04-22T22:11:10.879Z <Engine:5:NotifyPushover.js:208> NotifyPushover sending profile default notification request: Test
2021-04-22T22:11:10.882Z <Engine:INFO> rule-kntf80qj<SET> all actions completed.
2021-04-22T22:11:10.883Z <Engine:5:Engine.js:1024> _process_reaction_queue() task returned, new status -1; task 368
2021-04-22T22:11:10.885Z <Engine:5:Engine.js:1059> _process_reaction_queue ending with 0 in queue; none delayed/ready; waiting
2021-04-22T22:11:11.288Z <Engine:5:NotifyPushover.js:216> NotifyPushover successful endpoint exchange (message sent)
2021-04-22T22:11:14.936Z <Rule:NOTICE> Rule#rule-kntf80qj configuration changed; reloading
2021-04-22T22:11:14.937Z <Rule:5:Rule.js:715> Rule#rule-kntf80qj reloading with new data
2021-04-22T22:11:14.937Z <Rule:NOTICE> Rule#rule-kntf80qj stopping rule
2021-04-22T22:11:14.938Z <Rule:5:Rule.js:696> Rule#rule-kntf80qj acquiring semaphore
2021-04-22T22:11:14.938Z <Rule:NOTICE> Rule#rule-kntf80qj configuration changed; reloading
2021-04-22T22:11:14.939Z <Rule:5:Rule.js:715> Rule#rule-kntf80qj reloading with new data
2021-04-22T22:11:14.940Z <Rule:NOTICE> Rule#rule-kntf80qj stopping rule
2021-04-22T22:11:14.940Z <Rule:5:Rule.js:696> Rule#rule-kntf80qj acquiring semaphore
2021-04-22T22:11:14.941Z <Rule:5:Rule.js:699> Rule#rule-kntf80qj semaphore acquired; releasing timer
2021-04-22T22:11:14.942Z <Rule:5:Rule.js:699> Rule#rule-kntf80qj semaphore acquired; unsubscribing from condition dependencies
2021-04-22T22:11:14.943Z <Rule:5:Rule.js:701> Rule#rule-kntf80qj saving states
2021-04-22T22:11:14.944Z <Rule:5:Rule.js:705> Rule#rule-kntf80qj stopped
2021-04-22T22:11:14.944Z <Rule:NOTICE> Rule Rule#rule-kntf80qj stopped
2021-04-22T22:11:14.945Z <Rule:5:Rule.js:699> Rule#rule-kntf80qj semaphore acquired; releasing timer
2021-04-22T22:11:14.945Z <Rule:5:Rule.js:699> Rule#rule-kntf80qj semaphore acquired; unsubscribing from condition dependencies
2021-04-22T22:11:14.946Z <Rule:5:Rule.js:701> Rule#rule-kntf80qj saving states
2021-04-22T22:11:14.948Z <Rule:5:Rule.js:705> Rule#rule-kntf80qj stopped
2021-04-22T22:11:14.948Z <Rule:NOTICE> Rule Rule#rule-kntf80qj stopped
              1 Reply Last reply Reply Quote 0
              • LibraSun
                LibraSun last edited by

                This post is deleted!
                1 Reply Last reply Reply Quote 0
                • toggledbits
                  toggledbits last edited by

                  Confirmed bug on the device in the Pushover notification. Open a PR!

                  Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

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

                    Fixed! Pushover sends just fine now to any designated endpoint.

                    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