-
Build 21228 has been released. Docker images available from DockerHub as usual, and bare-metal packages here.
Home Assistant up to version 2021.8.6 supported; the online version of the manual will now state the current supported versions; Fix an error in OWMWeatherController that could cause it to stop updating; Unify the approach to entity filtering on all hub interface classes (controllers); this works for device entities only; it may be extended to other entities later; Improve error detail in messages for EzloController during auth phase; Add isRuleSet() and isRuleEnabled() functions to expressions extensions; Implement set action for lock and passage capabilities (makes them more easily scriptable in some cases); Fix a place in the UI where 24-hour time was not being displayed. -
I have a Hikvision camera for a month and have been playing with it. Now I read a post of cw-kid (post : System integration roadmap) that you can control the camera by HTTP API request. That's cool if that also will work for me. Can someone explain what to enter in MSR for HTTPS request command to do so. (Marked red arrows)
93ca9c9a-9ab1-443c-9201-5efcff3a45e2-image.png
I want to turn the smart supplement light on and off at a specific time. Now I do that with scheduled switch, but it is better to control that with sunrise and sunset function with MSR. I'm curious how it works.
-
Hey crew, I followed the tutorial to get MSR installed on Rasbperry Pi (bare metal). Just having a little trouble getting Vera to connect to it.
I'm getting error messages-- I searched in the forum and didn't see other people running into these messages. Here are the two main errors I've been getting...
2021-09-21T01:30:36.477Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632187836460 failed, reason: socket hang upand
2021-09-21T01:26:08.296Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632187568275 failed, reason: connect ECONNREFUSED 10.0.0.141:3480I'm sure it'll be an easy fix, but truthfully I'm stumped here and would love any advice. Thank you!
-
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...
-
Might be a known issue already, but seems that with Safari on iOS you cannot move/drag conditions
-
Is there a way to get a variable from a rule into an expression of some other rule?
Just like what Vera Reactor did with the Export button then allowing you to reference that variable in another rule set. I'm guessing there's a function like there was in vera getstate()? Thanks
Hopefully my question is clear, it's late 🙂
-
In my work flow, I send a number of http requests to my device. Is it possible to wait for a http response of the current action before executing the next http request action?
Thanks.
-
Hi,
I need help to create a search within MSR that shows me the name of all sensors in a certain status.
User case: Based on the information from category_num and subcategory_num, return in a string or array the name of all devices that meet the Tripped = 1 status.
Example: generate a warning message of all the windows that are open before triggering the alarm.
Which function should I use in MSR? What would this search look like?
Thanks.
-
Hey guys,
is there a bug in the UI of MSR (and also in the history pane of HASS btw) or do I have an issue with my iPhone? Or am I the only iPhone 12 min user which seems unlikely.
I cannot use MSR on my iPhone, the right pane does not show up on the screen, just the left pane. This is the same on chrome and safari, also when I hold the phone horizontally.
I can simulate this on the MacBook when I crop the safari window.
-
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 & EXITSTEP 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 SERVICEPRO 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.
-
I don't know if this was a result of the 21256 update or 21257, but all of my constraints triggers are showing no data. Even if the device has a triggered change. In addition, it is not showing the Conditional match either. In my screenshot, the Front door - auto locks (Day Time) is all true, but it has to be true for 15 minutes. I am not seeing the timer counter either. I tried a couple of browsers and even my tablet. No Data is seen on every rule. The actions are still running though. My lock did auto lock after 15 minutes.
2021-09-15_100734.jpg -
@toggledbits Is there a way to get Current Alerts as an entity so I could monitor those and send notifications if needed.
My usecase is sometimes openLuup crashes and MSR picks that up pretty quick, sending a pushover notification to me would get my attention to restart it.
Of course there are many ways to monitor connectivity but since MSR already is doing that it would be neat to take advantage of it. -
Hello anyone,
is there a simple trick to send native HASS notifications from MSR? I guess I could call a scene or something with some parameters but I have little experience so would need some clear pointers on this. Thanks in advance!
-
Hello @toggledbits ,
I'm testing the MSR and have connected VERA, EZLO and Home Assistant to it, i tried to do some automation but i'm missing the sustained for option in triggers350b4212-73dc-467d-9f6a-ab36851b3b67-image.png
i'm i missing something?
Best regards
-
Hey guys,
I am new here and decided to move my 10+ year old vera installation to hass.
Decision based upon the activity in this forum, the new Reactor plugin and my NX584 alarm panel being supported by HA.
These have been challenging days where I learned a lot about docker and a lot of other new stuff.
On my path I now stumbled upon an error in importing the reactor files from a recent vera backup into my new rector docker container running on a Qnap TS473A.
The error is:
Fetching current rulesets...
Can't parse config from tools/verabackup.tar: SyntaxError: Unexpected token e in JSON at position 0
at JSON.parse (<anonymous>)
at /opt/reactor/tools/import_reactor_backup.js:382:22
at processTicksAndRejections (internal/process/task_queues.js:95:5)
The backup file must be from a current version of Vera Reactor. This file reports undefinedI am running Reactor 3.8 which is supposed to be the latest according to the auto update.
Any pointers anyone?
-
I'm trying to migrate a couple of SiteSensors to MSR, and implementing those as rules with HTTP request reactions. MSR build in use is 21243.
Some challenges though, as I'm capturing an array and because I need those values in the array in multiple rules, I have to use global expressions. Seems that these global expressions/variables are not updating after initialization, but if I try local expressions, they update normally.
Screenshot 2021-09-09 at 23.24.52.png
(for testing purposes I'm switching between "g_UplinkResponse" and "temp_local_array" in capture response)
Screenshot 2021-09-09 at 23.37.47.png
Global expressions:
Screenshot 2021-09-09 at 23.29.23.pngSo "g_temp_var" and "temp_local_var" should yield the same result, but in this case the values are different (85.9 vs. 36.8, the latter being the most current & correct value)
I also have a test rule using "g_temp_var" just to induce change, but the value stays the same.
Screenshot 2021-09-09 at 23.36.00.png
@toggledbits, have I understood something wrong or could this be a bug?
-
Using MSR on Docker. The automation is to send xml body to my Hikvision camera to change the WDR based on the time of day. But getting the following error:
TypeError: Cannot read property 'length' of undefined
at Engine._resume_reaction (/opt/reactor/server/lib/Engine.js:1319:192)
at Engine._process_reaction_queue (/opt/reactor/server/lib/Engine.js:1114:100)My MSR rule:
HTTP Request: PUT
HTTP Request: http://camipaddr/ISAPI/Image/channels/1/WDR/day
HTTP Header: Content-Type: application/xml; charset="UTF-8"
HTTP Body:
<?xml version="1.0" encoding="UTF-8"?>
<WDR version="2.0" xmlns="http://www.hikvision.com/ver20/XMLSchema">
<mode>open</mode>
<WDRLevel>40</WDRLevel>
</WDR>Any idea why I am getting the above error?
Thanks.
-
Hi,
Am I correct in assuming that MSR cannot be installed on a pi running HASS.OS?
Thanks.
-
Hi all,
I am running MSR along HA on a RPi-4. MSR is talking to HA as well as my vera plus. Following a power outage MSR is showing a bunch of error messages complaining about entities not being available along with a yellow triangle besides my rules. My guess is that upon power restoral, MSR becomes ready before vera or HA.
Question:
Assuming that the devices/system used by MSR becomes fully functional, will the rules still properly works or the initial error and the yellow triangle means that they are not operational?I underatand that the ideal situation would be to install UPS (several in my case) on everything related to automation. Falling short of that, I was wondering if there would be a benefit to have something in the MSR configuration to pause its startup, providing dependencies enough time to become ready. This would prevent a bunch of (unnecessary) error message following a power outage. In my case, following a power outage, waiting a couple more minutes is not really an issue.
Tx
-
After update no entities are being executed in Hubitat..... I can se in Recently Changed Entities that a motion sensor for example is triggered but the rule in it is not getting set
im I missing something in the update @toggledbits ?getting this in msr log:
Require stack:
/home/pi/reactor/server/lib/Engine.js /home/pi/reactor/server/lib/httpapi.js /home/pi/reactor/app.js
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:880:15)
at Function.Module._load (internal/modules/cjs/loader.js:725:27)
at Module.require (internal/modules/cjs/loader.js:952:19)
at require (internal/modules/cjs/helpers.js:88:18)
at Engine._get_lexp_extensions (/home/pi/reactor/server/lib/Engine.js:862:25)
at Rule.evaluateExpressions (/home/pi/reactor/server/lib/Rule.js:904:330)
at Rule._evaluate (/home/pi/reactor/server/lib/Rule.js:994:344)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:93:5)
at async /home/pi/reactor/server/lib/Rule.js:963:17 {
code: 'MODULE_NOT_FOUND',
requireStack: [
'/home/pi/reactor/server/lib/Engine.js',
'/home/pi/reactor/server/lib/httpapi.js',
'/home/pi/reactor/app.js'
]
}
Stop action in progress
-
Scenario: After fulfilling the Trigger conditions, action 1 below starts its path, and stops at the Delay step, waiting for 300 seconds.
In the process of waiting, the Trigger becomes false and action 1 doesn't stop, it follows the countdown, I don't know if it is an error or not, if it shouldn't stop.
The change of the scenario of action 1 to false, triggers another action 2, which has in its step to stop action 1, step 3 below.
But what is happening, is that the stop action is actually putting action 1 on hold, and when action 1 is not completed, action 2 also goes on hold and does not finish in the same way.
Door Kitchen Close is action 1, see that I perform 4 steps out of 6, it is just stopped by the action of the group that is the delay.
Door Kitchen Opened is action 2, which should have stopped action 1, executed two steps, and is stopped at path 3 which is the call to Stop Reaction.
In this scenario, I now have two actions in waiting. To try to stop it, I created a third action that says interrupted, it also goes into waiting.
@toggledbits I didn't open a defect, because I have doubts if I am running the scenario in the correct way or not:
- Should an action in a Delay stage, when having the trigger changed to a false state, stop counting time and not follow the next steps? I think I've read something, when an action is started, it doesn't stop, even if the trigger status is changed, I think it is correct;
- but then I understand that the Stop Action must stop the Delay and in this case force the interruption of the following steps, stop the action at the stage it is at, and terminate any following step.
Comments and suggestions please, if possible the first one on how to stop these actions, because if I do not stop the counting the process works.
Thanks.
-
A rule-based reaction will not stop when the rule triggers/constraints that invoked it become false, unless there is a counter-reaction. This is a documented feature of Reactor (both for Vera and Multi-hub). A counter-reaction is an action that opposes the running reaction. For example, the reset reaction is the counter to the set reaction. If the set reaction starts, but the rule state changes and the reset reaction now needs to be run, the set reaction will be stopped, but only if the reset reaction is not empty. If the reset reaction is empty, the set reaction is allowed to finish.
Also, your screen shots are all too small to see. I don't know if there's been a change to the forum software recently to manage space (by downsizing the images), or if you posted them at that small size/resolution, but they're barely readable, at least not for my old eyes. When I click on them, the forum displays them at the same size that they are in the posting, which isn't useful. It would also be helpful if you included the name of the rule (either as text in the description or as part of the screen shot) so I can tell what screen shot is what rule or reaction. It's not at all clear here, and I can't really respond further because of it. But my suggestion is that you make use of counter-activities if you can, rather than making extra rules and using stops.
-
@toggledbits Ok first part I understood, very good to understand that if there is no rule in case of reset the action will end. This already helps to improve.
I will try to post the images again.
Image of the first scene - action 1 that stops when the Delay starts within the group.
Action 2 which has in its execution the call to interrupt action 1 that is stopped running the Delay.
As I commented Action 2 when calling 1 does not interrupt the Delay stage and enters waiting, and also Action 1 enters waiting.
I will post again to see if it increases the image.
-
Door Kitchen Close is action 1, the first image.
Door Kitchen Opened is action 2, second image. -
Update to 21236 and see if that continues. There was an issue stopping child tasks (I noted you had a constraint group in one reaction, and that's a child task).
-
@toggledbits Ok I have already updated the version, but first I have to kill the processes that were in wating, how can I do?
-
Stop Reactor, remove the file
storage/states/reaction_queue.json, and the start Reactor. -
@toggledbits ok, I removed the file as you explained.
But the new version still didn't solve the problem, I tried again and the Stop Action instruction is not stopping the current counter.
But I see something new, this line that indicates that the action stopped in "delayed".
See the screen print that MSR DISCONNECTED. Even with Ctrl + F5 it didn't come back. I had to stop the service, restart and then come back. Now see that the delayed line no longer appears on the status screen.
I repeated the test again, same result, disconnects the MSR and it is only possible to return by restarting the service, the Stop Reaction instruction does not stop the action that has a delay in progress, and then both are in waiting.
Restart the MSR
-
OK. Let's make sure you followed my instructions to the letter here, because I'm not getting a warm feeling from your description of events.
You have to stop MSR completely first. Not restart. Stop. Full stop.
Then you remove the file
storage/states/reaction_queue.jsonfrom the Reactor install directory.Then you start Reactor again.
When you've done this correctly, there will be no running/waiting/delayed processes in the status view, until you lauch your rules/reactions. But it should come up idle.
-
@toggledbits correct, I followed your instruction exactly: stop MSR > remove file > star MSR > I executed the actions and it goes back to the waiting status. The instruction that exists in the Door Kitchen Opened action to stop the Door Kitchen Closed action does not happen. But now there is a new situation that is bringing down the MSR. To get it working again, I have to do a Stop > Start in the system.
-
OK, I was able to build a test case that I think duplicates the behavior you are describing. And I was able to find the issue (I opened PR#254 to track it going forward). I will do an updated "latest" build shortly that contains the fix...
-
@toggledbits problem solved, already downloaded and tested the version 21237 with the same previous scenario and worked perfect! Once again Super Patrick saves the day! Thanks.
-
Ha! More like Lucky Patrick. But I'll take it. Good bug. Meaty, hard to find, important to find. Thanks for digging it out!