-
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'
]
}
Version 1.0 Pre-release Discussion
-
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!
-
The only thing that comes to mind is fleshing out the Docs (gonna be a fun chore!) and introducing more little (i) icons throughout the UI so that users can quickly jump to the related section of Docs for that panel/pane/action.
Right now, 21140 is like butter and I have no pressing outstanding Feature Requests to suggest.
Thanks for all the hard work you've put into making MSR as awesome as it is, even in beta! -
Virtual Devices as discussed here:
https://smarthome.community/topic/546/let-s-talk-about-msr-provided-virtual-devices-not -
possibly add future wind readings to weather entity like rain(1h and 24hr)
-
+1 on the docs. As a non-programmer, I struggled with what could probably best be described as the lack of prerequisite programming knowledge. I certainly would never expect a programming course in the docs, but examples in the "how-to" section will really help point people like me in the right direction. The installation (docker), logic, and concept sections were excellent for me, but I already had the basic gist of things from Vera Reactor.
+1 on the virtual devices.
Dashboard: I don't know if you view this as a separate but related project, but since MSR concentrates entities in one system, it would be a wonderful addition.
The only other thing I had thought of was a global "pause" button. I had to make lots of controller/device changes at one point, and I found myself looking for a way to put everything on hold while I reconfigured.
I just wanted to say thank you again for everything you have created. MSR has brought a level of maturity to my automation that was not previously possible for me to accomplish at my skill level.
-
Potential change: now that constraints apply to groups in a Rule's reactions, I see no value in keeping the Constraints as a separate subsection at the top level of a rule (that is, the section between Triggers and the Set Reaction when you edit a Rule). So, I'm thinking about removing them from here (any rules you have with constraints in this area would just get them restructured into a group constraint).
Thoughts?
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
On the constraints, once groups were introduced, I stopped using the constraint subsection unless it was a straightforward rule that did not require groups. I think opinions on this would vary based on the way people have settled in on rule construction and layout. Groups allowed me to consolidate my rule sets, so I have less use for them.
I thought of one other thing that would be helpful to me personally...
Would you or anyone else see any value in an "entity in use by" inspector/report generator? As things got more complex, I found myself doing a little digging when I needed to address a logic issue with an entity used in multiple sections of logic.
-
+1 on "Entity in use by" (or "watched by" or "referenced in") and see that as a possible extension of the objects we already see under ENTITIES. If, for instance, "Sofa Lamp" was referenced twice in the "Dim Lights" rule, it could list both occurrences as:
.references: Dim_Lights._Set_Reaction, Dim_Lights.Expr_DimLevel, where both are clickable links directly to those subsections of the referencing rule. -
This post is deleted! -
+1 Libra. A clickable link to take you to the location of use would be really nice.
-
@mikereadington said in Version 1.0 Pre-release Discussion:
+1 Libra. A clickable link to take you to the location of use would be really nice.
Although we have to acknowledge that expressions are able to reference entities without overtly looking like that's what they do - such as using loops and arrays - so it might be a technical challenge for MSR to pick up every single reference.
-
@toggledbits said in Version 1.0 Pre-release Discussion:
now that constraints apply to groups in a Rule's reactions, I see no value in keeping the Constraints as a separate subsection at the top level of a rule (that is, the section between Triggers and the Set Reaction when you edit a Rule). So, I'm thinking about removing them from here
Really?
Are these not two separate things with different uses.
I use the Contraints section of a rule as the main set of constraints / conditions for that rules Reaction / actions being run or not.
And then in some of my rules in its Set Reaction I also have further additional and different "Group Constraints" that are only evaluated and carried out if the Set Reaction actions were even run in the first place by the main constraints being met.
Personally I do not like at all this idea to remove the rules Contraints.
-
I have to strongly object to removing the rules Contraints section, which would be a major change to the concept of a rule and its work flow.
A logic engine has triggers then conditions then actions.
This is the same concept PLEG had and I used it for a decade.
We then asked you to give us the ability to have further additional conditions within the actions chain and you gave us that with Group Constraints.
The system is perfect as is.
What you are suggesting is to have triggers then actions with conditions mixed in with the actions.
Keep the main conditions in the separate Constraints section as they are now.
It's your project and creation and you can do with it what you like, but I won't be happy with this proposed major change if it happens.
-
@toggledbits , As you stated in another thread "Capabilities on Hubitat are free-form, and there's no indication which capability might be the most useful or primary". Could you add the ability for a user to manually select the primary capability for each Hubitat device? This would allow the Entities screen to display info in the primary value. If the Dashboard feature is added in the future then the Hubitat device should display correctly there also.( I also would like to request the dashboard)
-
This might be off topic and it also reveals my lack of programming skills. But I wounder how is MSR going to be installed, once it leaves beta? I use it on a stationary Windows 10, and the problem is if the power goes out. Then my PC reboots and I have to start the app and change catalog and finally execute "node app.js". I could install it on a RPi, don't know if it can work alongside and on the same RPi as I got Home assistant installed? Then it would start straight away, when the power gets back. To summarize, it's basicly two questions;
- In which ways are we going to be able to install and start up MSR?
- Is it possible to install MSR on a RPi that already is running HA? Or on a Home assistant blue (Odroid N2+)?
Another feature that would be nice is to have a optional setting of automatic updates.
Regardsless - MSR is a great (one of the best) contribution to the smart home community - at least for me. Great job!! -
@fanan The same thing happens with my RPI4 ... I have to start it manually...
-
There was a thread about having MSR auto start on a Pi. I set it up on my Pi and it did work MSR was started automatically after a reboot / power on.
https://smarthome.community/topic/439/how-to-auto-start-on-rpi-reboot?_=1621588014603
-
@fanan installing on a poi side by side with anything else will not hurt. On windows, just schedule it to run at startup via task scheduler.
-
@fanan At least initially, like many other projects, I expect MSR to be delivered in the following forms:
- Primary: Docker container. This facilitates not only a simpler integrated package to install that contains its dependencies, but also easily takes care of starting at boot on most systems. There are currently Docker containers available for Linux amd64 and armv7l (i.e. RPi4) architectures.
- Generic tarball. This will be a manual install for platform power users (Linux, Windows, and anywhere else nodejs and the companion dependencies can be installed by the user). There are available examples for automatic startup for systemd.
There's no reason you cannot install MSR next to Hass or anything else on a platform that allows you to install such things (clearly you're not going to install it on your Hubitat). I don't know anything about Hass Blue, but if it lets you install docker containers or the generic package, I see no reason you can't run them side-by-side.
@cw-kid said in Version 1.0 Pre-release Discussion:
@matteburk
There was a thread about having MSR auto start on a Pi.Slightly modernized version of the same here, should work on any platform that supports systemd: https://smarthome.community/post/8011
-
@fanan said in Version 1.0 Pre-release Discussion:
Another feature that would be nice is to have a optional setting of automatic updates.
I'll address this issue separately.
I think there are two interpretations here, so I'll start with the interpretation that I would more specifically call "unattended upgrades". Philosophically I'm opposed to unattended upgrades in all things, particularly on things that become "mission critical" in my environment. There is no "good time" for such updates except when I'm there to initiate them and recover if they come a gutser. History has shown that they otherwise will happen when I am far from home, usually for a sustained period and while Internet access is unavailable or inconvenient. When fully unattended upgrades to MSR happen, that will be your sign that I am no longer associated with this project.
The other interpretation is "push-to-start" upgrades from the UI. This is, frankly, a very low priority for me, and will not be something I entertain for 1.0, or likely 1.x. Docker containers are easily upgraded with a four-line script on command line-driven platforms, and still pretty painless in, for example, the Synology GUI (and still doable on the command line there as well). For users of the generic tarball, the detar and restart is even simpler. I understand that one click from the GUI would be easier, I don't disagree there, but keep in mind you've all been working in a mode where, for much of the history of its availability, MSR updates have come almost daily. That is not the norm, and I would not want it to be in production. In fact, production will go more to the model I use for R4V, where there is basically a very slow-moving release channel, a faster "stable" channel, and a bleeding-edge "latest" (what you have today).
The feature also introduces something that Reactor currently doesn't (on its own) require: access to a cloud infrastructure. Upgrades from within MSR require it to access cloud services, some existing, some not. This implies a lot of things, not the least of which include its security, its construction, and its cost to maintain and serve. If it gets done at some point, it will not come lightly, or easily, and it will likely be accompanied by license fees.
