Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

(Last Updated: April 25, 2021)

Feature Request: Back-up through UI

Hey Patrick, this is probably a rather large request but it would be nice to be able to download a back-up of MSR through the UI similar to how we could do it with R4V. Beyond that maybe even having the ability to create a rule set that auto backups to a NAS would be even more useful! Currently I know you can just copy the complete reactor file from the machine MSR is running on but using the UI would make backing possible from anywhere and much simpler and quicker!

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

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.

Multi-System Reactor
Can the list of rule sets be sorted?

A

Maybe a dumb question if I'm missing something obvious, but I checked the manual and searched the forum without finding anything relevant...

Can the Rule Sets on the left side of the MSR web UI be re-sorted? I just realized that it seems to be sorted with the newest ones at the top and I would prefer to have them alphabetical... and to have a multi-level tree with nested rulesets... but I'll settle for alphabetical for now if there's a way to do it 🙂

MSR latest-22266 / Raspberry Pi 4 / Docker

Multi-System Reactor
How does MSR handle renamed entities?

3

Hubitat C7 = 2.3.2.141 AND 2.3.3.123
MSR in a docker = latest-22264-93bf3814 and latest-22266-88868fc0

I'm curious if this is a bug or expected behavior. Unfortunately I don't know exactly when this began either. I have renamed a few devices over the course of the last few MSR builds, but never really brought it up before. Plus I don't rename devices too often. But I have a motion sensor right now that I renamed in Hubitat from "Office Motion" to "Living Room Motion" over 2 weeks week ago. Probably closer to 3 or 4 weeks now. I have restarted MSR several times since the rename, hard refreshed the browser, tried a different machine and different browser, and even an updated version of MSR. MSR is still showing the old name within the Entities section. I know I could rename it within MSR, but I would prefer to only have to rename devices in one location. I don't recall how long ago I started noticing this, which I know does not help at all.

5f97eb06-aa1d-4f25-ba08-1212aa28f4bb-image.png

Multi-System Reactor
InfluxDB - is it possible to log expressions as well as entities?

A

The reason for my question is a rather long story involving a virtual thermostat on my Hubitat and using InfluxDB and Grafana to graph the state of the thermostat.

The TL;DR version is that it would be helpful if I could send MSR expressions (variables) to InfluxDB. I don't currently see any way to do that, and if it isn't a current capability of MSR it might be useful as a future enhancement.

Long version: I have a rule in MSR that runs every minute to pull the thermostat information from my thermostat's cloud API. I parse the response into global variables, and then update a Hubitat virtual thermostat when those global variables change. I added the x_hubitat_Thermostat entity, along with selected capabilities, to my reactor.yaml in the InfluxDB section, 'default_capabilities', so the changes to the virtual thermostat get logged into the db.

It's working OK except when the API reports that the temperature has reached the setpoint but the system is still operating. For example, in the morning when the heat is turned up, the temp will climb until the setpoint == the temperature, but the system will continue heating for a while afterwards. It's a variable speed/heat system so it continues to run at very low output for quite a while after the temps match.

The issue I'm having is that when the temperature matches the setpoint, the Hubitat virtual thermostat switches to idle mode on it's own, despite the fact that the API is still reporting heating mode. When the virtual device sees that the setpoint has been reached, it automatically changes to idle, which makes sense as that's how you'd want a real thermostat to work .

I am working around this by having the rule that updates the temperature on the virtual device also update the operatingState. This fixes it, but for just a few milliseconds the virtual thermostat switches to idle before the rule sets it back to heat, and that state change shows up in Grafana.

If I could just directly log changes to the expressions to InfluxDB I could avoid the issue and get the same data into the database. Also I can see other applications for something like this with other APIs where MSR and InfluxDB could be used to log data without having any virtual device entities involved.

Multi-System Reactor
MSR Not Recognizing Old HASS on New VM

Hey Patrick, had to switch over my HA VM from VirtualBox to VMware since VirtualBox stopped playing well. Anyways I updated the IP address to the new VM IP and deleted the Long Lived Access Token and created a new one just in case (copy pasted the new token into the config file). Tried rebooting both the HA machine and the MSR one too and MSR is still not connecting. The only thing I have not tried yet is creating another controller entry, but I am worried it may create all new entities for everything forcing me to redo all my logic. Here are some logs:
[latest-22258]2022-09-20T21:17:24.749Z <HassController:WARN> HassController#hass websocket error during open/negotation: [Error]Error: Opening handshake has timed out [latest-22258]2022-09-20T21:17:24.749Z <HassController:NOTICE> HassController#hass websocket to ws://192.168.8.113:8123/api/websocket closed during open/negotiation [latest-22258]2022-09-20T21:17:24.749Z <HassController:WARN> HassController#hass failed to connect/initialize communication: [Error]Error: Opening handshake has timed out [latest-22258]2022-09-20T21:18:09.753Z <HassController:NOTICE> HassController#hass connecting to ws://192.168.8.113:8123/api/websocket [latest-22258]2022-09-20T21:18:24.761Z <HassController:WARN> HassController#hass websocket error during open/negotation: [Error]Error: Opening handshake has timed out [latest-22258]2022-09-20T21:18:24.761Z <HassController:NOTICE> HassController#hass websocket to ws://192.168.8.113:8123/api/websocket closed during open/negotiation [latest-22258]2022-09-20T21:18:24.761Z <HassController:WARN> HassController#hass failed to connect/initialize communication: [Error]Error: Opening handshake has timed out [latest-22258]2022-09-20T21:19:01.083Z <VeraController:INFO> VeraController#vera 0 dead entities older than 86400000s purged [latest-22258]2022-09-20T21:19:14.780Z <HassController:NOTICE> HassController#hass connecting to ws://192.168.8.113:8123/api/websocket [latest-22258]2022-09-20T21:19:29.785Z <HassController:WARN> HassController#hass websocket error during open/negotation: [Error]Error: Opening handshake has timed out [latest-22258]2022-09-20T21:19:29.785Z <HassController:NOTICE> HassController#hass websocket to ws://192.168.8.113:8123/api/websocket closed during open/negotiation [latest-22258]2022-09-20T21:19:29.785Z <HassController:WARN> HassController#hass failed to connect/initialize communication: [Error]Error: Opening handshake has timed out [latest-22258]2022-09-20T21:20:24.791Z <HassController:NOTICE> HassController#hass connecting to ws://192.168.8.113:8123/api/websocket [latest-22258]2022-09-20T21:20:39.813Z <HassController:WARN> HassController#hass websocket error during open/negotation: [Error]Error: Opening handshake has timed out [latest-22258]2022-09-20T21:20:39.820Z <HassController:NOTICE> HassController#hass websocket to ws://192.168.8.113:8123/api/websocket closed during open/negotiation [latest-22258]2022-09-20T21:20:39.820Z <HassController:WARN> HassController#hass failed to connect/initialize communication: [Error]Error: Opening handshake has timed out

Multi-System Reactor
Is there a search function (maybe a feature request)

T

@toggledbits

Patrick,
I've just imported a large set of rules from Vera, and I had already played with creating rules in MSR that are mixed throughout the existing Vera rules. Is there any sort of way to "find/replace" in MSR, so I can find all matches to the old rules and replace them with the new ones?

Multi-System Reactor
Migration of House Modes

T

@toggledbits

Patrick,
Yesterday I migrated a large luup Reactor group over from Vera to MSR, following the directions to importing it from Vera in the documentation. One of the odd things in the migration was the conditional rules for House Modes. Many of my rules had conditions such as "House Mode is any of Home, Night, or changes to Away.

The way the import did it was changes from 1,3 to null. This importation did not seem to trigger rules correctly.

I was able to fix all the instances by creating multiple triggers in a group:

Entity Attribute: House Mode (vera>housemode) x_vera_housemode.mode contains home
OR Entity Attribute: House Mode (vera>housemode) x_vera_housemode.mode contains night

Is this what you are expecting in importation?

Multi-System Reactor
Using Google Calendar data from HA in Reactor

T

Good morning all,
This weekend I've been playing around with Home Assistant as a replacement (long term) for my aging Vera platform. I'm pretty amazed how much more capability it has. On the other hand, the sheer amount of variables it pulls in from devices is massive.

In any case, I have added Google Calendar into Home Assistant for things like Federal Holidays and my daughter's school calendar. It connected to them without issue, which I had been having problems with in Vera an GCal3.

I connected MSR to Home Assistant, so I can start using some of the systems I've integrated into Home Assistant in MSR, and continue migrating my luup Reactor rules over to MSR. Now I'm trying to create a rule based on if today is a Federal Holiday or not. Reactor sees the calendar just fine, however, for whatever reason, it's not pulling data for today, but the next event, which in this case is Columbus day, three weeks away. The attribute that is pulling this is x_haas_attr.message.

I tested with my daughter's school calendar, and it did have an entry for today, and none of the other values seemed to be different, such as a "true" or something to tell me there is an entry.

a8478a6e-d8eb-4572-ac84-c94ff012a1ec-image.png

60632486-e80b-4f0f-aed9-dc67113689a4-image.png

ab04cd0f-f849-4e14-be7d-f4c00735da77-image.png

The only thing I've been able to come up with, is there is a start_time attribute, which shows the date as 2022-10-10 00:00:00

1cbe4526-7f63-4329-a088-b331f1d03376-image.png

The only thing I can think of is there might be a way to compare the current system date to that date, but I can't seem to figure that out in MSR.

Has anybody done this? Any suggestions?

Multi-System Reactor
[Solved] VirtualEntityController setup

G

I started kicking around the VEC last evening, was cut short, and dug in a bit more this morning.

My reactor.yaml:

d3df4d99-aa7f-4b8b-8fb9-5a6c615daad9-image.png

I verified the yaml is good at https://yamlchecker.com/

What I'm seeing in MSR:

0f89ce8e-7abe-4779-baca-43123e030cf4-image.png

87560ded-7dfa-4340-8585-8be58ff22852-image.png

I believe I have followed all steps (standard disclaimers apply).

Anyone else started to tinker with this newness and, if so, what were your results?

Multi-System Reactor
Approach to Rulesets, a philosophic question

G

Having just embarrassed myself to @toggledbits by asserting that the latest release somehow had a bug when in reality it was surfacing underlying issues with my approach to building out my rulesets and automations I wanted to ask the collective for their feedback on how they've designed their rulesets.

For me, I built out a list of Global Reactions that I commonly use. For instance, for mode changes I typically change the mode entity and write that mode to a variable for some future use. When building out a ruleset I just pull in that Global Reaction vs manually recreating the entity list as my ruleset Reaction. Example, for lighting:

270bbe18-9680-491d-81d4-20308a9fe63c-image.png

Each of these contains the appropriate group of lights to turn on/off, etc.

I also have what I've dubbed my "Armed for..." rulesets. These are rulesets that can be referenced as true or false in other rulesets. Example, for my various lighting configurations in and out of the house I have these:

0d9f55d4-5d5d-42e2-a83c-8afa95df08fb-image.png

I think this is resulting in reactions stomping on other reactions creating race conditions that result in things looking like they're working when, in reality, they're one restart away from disaster.

So how are you all designing your superstructure, if you will, at a high level?

Multi-System Reactor
Entity action & controllers

Maybe more of a cosmetic issue, but certain entities could be hidden from entity actions as you cannot set any meaningful action? See Vera as an example:

Screenshot 2022-09-16 at 15.11.29.png

vera>system is then obviously a different story and should be there

Multi-System Reactor
[MSR] MQTT not echoing variables in latest update

Hi @toggledbits,

I have a bridge consuming Vera's variable using the MQTTController in MSR, and I've noticed that after I've updated to the latest version (22257), some variables are not echoed. I've already tried to reboot MSR, with no luck.

These variables are under urn:smarthome-community:serverId:Vacuum

0fe837ed-3a29-4d5d-a06c-445981d44e13-image.png

A trace via MQTT explorer:
cf919028-4f7b-4761-b99a-c3943945704a-image.png

My config has just exclude_capabilities: [] and it was working OK before the latest build. Even /query command doesn't seem to retrieve all the attributes. The values are retrieved correctly from the Vera controller, and I could use them in MSR, they're just not echoed to the bridge. Thanks!

Multi-System Reactor
MSR Reaction question - Support with iBlinds on Vera

T

Good morning all,
I"m working on converting my luup Reactor scenes over to MSR, so I can eventually introduce an Ezlo plus into the mix and not loose all the work I've done with Reactor. If nothing else, this should free up some resources on my aging Vera Plus, and maybe speed up some functions. Maybe that's just wishful thinking.

In any case, I'm moving move my first Reactor set, which is a set of rules to control the blilnds/window coverings in my home. I have two types of blinds:

iBlinds retrofit motors (IB2.1-ZWx) version from late 2019.
Bali roman shades with factory installed Somfy CSZ1 Z-wave motors.

I'm setting up reactions for both types of window coverings. One of the problems I always had in Vera was with iBlinds, I had to do it by luup commands:
luup.call_action("urn:upnp-org:serviceId:Dimming1","SetLoadLevelTarget",{ newLoadlevelTarget="50" },316)
The reason for this, is that the open position was 100%, and the close position was 0%. In other words, the blinds were closed one way 100% an closed 100% the other way. I've been informed by iBlinds support that even in Ezlo, they still do it this way, which is different than most other Z-wave controller manufacturers. I'm not sure how the others do it, but some how "open" is right in the middle (50%).

So, in MSR, i can still set the Dimming1.SetLoadLevelTarget to 50, but I also noticed some other commands I haven't seen before in Reactor

3cdeeb89-5986-45bc-8a3b-79067050a22c-image.png

Is there some way in MSR to set that middle value to 50% so I can use cover.open? The command cover.close works as expected, so I'm wondering how I might use that cover.set.

Thanks for any advise.

Multi-System Reactor
OpenWeatherMap not providing any data

T

I configured OWM Weather on MSR (latest-22257-dd9b9271), created an account with OWM, generated an API key, put the key in the yaml file, and I’ve waited over a day now. OWM Weather shows as up on the the Controller Status widget.

I’ve tried to create a trigger or constraint to use the data, and nothing is really showing up.

5B8611C1-33D0-4D3C-B507-7383CB81E25A.jpeg

I only have a free subscription with OWM, but I was expecting some data.

Is this expected behavior (i.e., still in development), or do I do more configuration other than the .yaml file?’

I still am able to pull Weather data through Dark Sky in my Vera plus controller, however, I know that will no longer work at some point.

Multi-System Reactor
How to close these new metadata windows?

Was just looking at the new metadata stuff in Entities for a lamp. I was on the dimming.level attritube and I then changed the dim level of the lamp several times and some how I got all these windows.

I then selected a different attribute color_temperature.value and that window was then shown over the top of all the others.

267e6d0d-7245-4816-ac93-ac83cfda509e-image.png

I don't know how to close these windows down ?

b09fd5f1-fffe-40c2-8ba6-8cffacd1e28b-image.png

Thanks

Multi-System Reactor
Add Ability to Limit Amount of Time a Condition Pulses

Hey Patrick, similar to R4V it would be nice if we could set the max amount of time a condition pulses. Currently in MSR you can only set it to pulse once or repeat continually until the condition goes false.

I currently have a rule that pings dead devices and occasionally the dead device needs a few pings for it to come back alive but I don't want it to keep pinging forever if the device is actually not functioning.

Multi-System Reactor
MSR web UI stops connecting after a period of time

Hi

Anyone else been having issues with the MSR web UI not connecting after a period of time? Or is it just me?

If I reboot the Linux Debian box then MSR starts working again and I can open the web UI and it says connected.

However after sometime I then cannot later connect to the web GUI. It just says connecting all the time.

I also have Node-Red and HA Bridge running on the same box and I can connect to those two fine still.

Thanks

Multi-System Reactor
ZWaveJS new device alerts

S

Is is possible for MSR to show newly detected ZwaveJS devices in the current alerts windows like Hubitat and HA? New devices show in the Entities but there is not an alert.

Multi-System Reactor
Where do the icons come from?

R

Hi Patrick,
For as long as I can remember, I have red x's instead of icons in MSR.

05f25684-b338-4f69-8d0a-8a482a9fe1a2-image.png

I am running MSR in Docker and am on version 22252. If hosted in the cloud, they could be getting blocked by pihole.

Thanks,
Roger

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

Entity Action/Capabilities

Multi-System Reactor

S
SweetGenius last edited by

In the actions for a device, can someone explain what the differences is for a Hubitat device such as power_switch.on and x_hubitat_Switch.on.
Synology Docker MSR, Hubitat, Home Assistant, Homebridge, ZwaveJS, MQTT, NUT controller.
1 Reply Last reply
Reply Quote 0
toggledbits last edited by toggledbits

The power_switch capability is MSR's native capability. The x_hubitat_Switch capability is MSR echoing Hubitat's native capability. Unfortunately, Hubitat's APIs do not give complete information about devices, and the relationships between their native capabilities and the devices they manage (neither does HomeAssistant, for the record; Vera is the best of the three platforms at this, if you can imagine that).

Both actions in their respective capabilities will do the same thing. But, if you move a device from Hubitat to another controller, it won't have the Hubitat native capability (x_hubitat.Switch) and its action, but it would retain the MSR capability (power_switch) and action, which may simplify the process of amending your rules to reflect the change..
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
Locked by toggledbits

1 / 1